Почему в детском саду кормят так, как кормят: сбой в ролевой модели

Работая с администрацией подмосковного города, лектор разобрал по ролям процесс приготовления пищи в детском саду. Начиналось всё нормально.

Потребители — не дети, а родители. У родителей есть потребность в сытых и здоровых детях. Если бы потребителями были дети, меню состояло бы из чипсов и газировки. Дети здесь пользователи: они с помощью еды удовлетворяют потребность родителей. Если бы и детей в модели не было, кормить пришлось бы рыбьим жиром и морковкой — самой здоровой едой, которую никто не ест.

За баланс между «полезно» и «съедят» отвечает заказчик — заведующий детским садом. Он же отчитывается наверх, в администрацию.

А дальше выясняется, что владелец процесса — тот самый куратор в администрации, которого заведующий информирует. То есть заказчик по должности ниже владельца процесса.

Тот, для кого делают, слабее того, кто делает. С этого момента система не чинится изнутри: даже если родители убедили заведующего, что кормить надо иначе, сделать он ничего не может — схема спущена сверху. Санэпидемстанция, другие повара, родительские комитеты пытались — не влияют.

Это пятая лекция процессного управления из программы MBA CIO, целиком посвящённая ролевой модели. Разбираю её — и в конце вернусь к садику.

Роль — это не должность

Начинается всё с различения, на котором спотыкаются почти все.

Должность — набор компетенций, за которые вам платят. Роль — набор связанных между собой задач с общей целью, которые вы выполняете.

Чтобы человек хорошо выполнял роль, нужны две вещи, и обе обязательные: компетенции позволяют, мотивация есть желание. Без первого не сможет, без второго не станет.

Один человек может исполнять несколько ролей, а одну роль могут делить несколько человек. И ещё одно ограничение, которое ломает половину нарисованных схем: роль выполняет только физическое или должностное лицо. Таксопарк не может быть владельцем ресурсов — им является начальник гаража.

Одиннадцать ролей и четыре группы

flowchart TB
    subgraph VH["Роли входа"]
        P1["Поставщик"]
    end
    subgraph RES["Роли ресурсов"]
        R1["Исполнитель"]
        R2["Владелец ресурсов"]
        R3["Администратор ресурсов"]
    end
    subgraph UPR["Роли управления"]
        U1["Владелец процесса"]
        U2["Эксперт-консультант"]
        U3["Контролёр-аудитор"]
        U4["Руководитель экземпляра"]
    end
    subgraph VYH["Роли выхода"]
        V1["Потребитель"]
        V2["Пользователь"]
        V3["Заказчик"]
        V4["Информируемый"]
    end
    VH --> RES --> UPR --> VYH

Роль	За что отвечает
Потребитель	чья потребность удовлетворяется процессом
Пользователь	кто с помощью продукта эту потребность удовлетворяет
Заказчик	чтобы потребитель был доволен, а пользователь работал эффективно
Информируемый	нужна информация о процессе, но не сам результат; обычно регуляторы
Владелец процесса	результативность и эффективность; разрабатывает схему
Эксперт-консультант	закрывает нехватку знаний владельца о технологиях
Контролёр-аудитор	проверяет, работают ли люди по схеме
Руководитель экземпляра	управляет исполнителями в одном прецеденте
Исполнитель	выполняет работы по схеме
Владелец ресурсов	чтобы исполнителей хватало и они были готовы
Администратор ресурсов	кого именно поставить на конкретный прецедент
Поставщик	владелец процесса, результат которого — вход в ваш

Три роли опциональны и появляются только тогда, когда владелец процесса перестаёт справляться сам. Эксперт-консультант — когда не хватает знаний. Аудитор и руководитель экземпляра — когда не хватает времени: три одновременных прецедента владелец проверит и проконтролирует сам, тридцать три — уже нет.

Потребитель, пользователь и заказчик — обычно разные люди

Разложить эту тройку правильно труднее, чем кажется. Два примера из лекции.

Подарок от бабушки. Бабушка даёт вам денег, чтобы вы купили подарок своему ребёнку — от её имени. Потребитель — бабушка: её потребность в том, чтобы внук был рад и любил бабушку. Пользователь — ребёнок: он играет с машинкой. Заказчик — вы: ваша задача свести баланс так, чтобы и бабушка была довольна, и ребёнок не забросил игрушку через день. Отсюда, кстати, знакомая практика — добавить к бабушкиным двум тысячам ещё десять своих.

Поменяйте вводные — роли переедут. Если внук сам попросил у бабушки конкретную машинку, потребитель уже внук, пользователем становится бабушка: она с помощью машинки удовлетворяет потребность внука. Заказчик по-прежнему тот, кто идёт в магазин.

Корпоративный тренинг. Здесь ошибаются массово: участники уверены, что они потребители. Ничего подобного — они пользователи. В них вливают продукт под названием «информация», и делают это не для того, чтобы им было хорошо, а чтобы они лучше работали. Учим менеджеров по продажам — потребители не они, а клиенты компании. Учим системных администраторов — потребители те, кого они поддерживают. Заказчик — начальник отдела продаж. Директор по персоналу — информируемый: ему важно знать, что тренинг был.

Практическое следствие: если пользователя не мотивировать, он начнёт минимизировать собственные затраты — то есть спать на занятиях. Идеально, когда у него есть и своя потребность: администратор сам хочет изучить новую систему. Тогда он потребитель и пользователь одновременно, и тренинг проходит на ура. Но это побочный выигрыш, а не цель.

Зачем процессу аудитор

Логика этой роли объясняется одним рассуждением, и оно того стоит.

Вы владелец процесса. Ваш основной инструмент — схема: вы отдаёте её людям и говорите работать по ней. Вы отслеживаете параметры и однажды видите, что они не те, какими должны быть.

Возможных объяснений ровно два:

1. люди не выполняют то, что должны;
2. схема не соответствует жизни.

Аудитор нужен, чтобы исключить первое. Если он подтверждает, что люди работают по схеме, а результата всё равно нет, — значит, дело в схеме, и менять надо её.

Различение важное, потому что срабатывает известный эффект: изобретатель влюблён в собственную работу и считает её лишённой недостатков. Без аудитора владелец процесса будет годами объяснять расхождение тем, что мир недостаточно хорош для его схемы.

И оговорка про автоматизацию. Роль аудитора может исполнять софт — там, где проверку в принципе можно формализовать, например на потоке банковских транзакций. Заодно работает и обратная логика: чем меньше в процессе людей, тем меньше нужен контроль исполнения. Робот выполняет программу всегда; если не выполняет — то не выполняет постоянно, и это видно сразу.

Какие роли стоит совмещать

Роли внутри одной группы совмещаются свободно. Интереснее связки между группами — те, что добавляют ценности.

flowchart LR
    subgraph S1["Первая скрепка"]
        A1["Заказчик"] --- A2["Владелец процесса"] --- A3["Владелец ресурсов"]
    end
    subgraph S2["Вторая скрепка"]
        B1["Пользователь"] --- B2["Руководитель экземпляра"] --- B3["Исполнитель"]
    end
    subgraph S3["Контроль"]
        C1["Потребитель"] --- C2["Контролёр"]
    end

Заказчик и владелец процесса. Заказчик отвечает за то, чтобы потребитель был доволен, а пользователи работали эффективно. Владелец процесса — за результативность и эффективность. Это одно и то же, сказанное разными словами, — интересы не конфликтуют.

Пользователь и руководитель экземпляра. Решение о том, как сделать потребителя довольным, лучше принимает тот, кто работает с ним напрямую: у него меньше транзакционных издержек.

Потребитель и контролёр. Идеальный контролёр — тот, чью потребность удовлетворяют. Дайте ему информацию о том, что контролировать, и он добьётся своего лучше любого аудитора.

Руководитель экземпляра обязан быть одним из исполнителей. Управление процессом должно находиться внутри него. Как только вы выделяете человека, стоящего вне деятельности, он начинает считать, что проблемы деятельности — не его: он не для того залезал наверх.

Две связки работают как скрепки, которые держат конструкцию: заказчик — владелец процесса — владелец ресурсов и пользователь — руководитель экземпляра — исполнитель.

Право исполнителя остановить процесс

Классический конфликт: исполнитель знает, как сделать потребителю хорошо, но начальник говорит так не делать. Сегодня исполнитель не делает — до потребителя далеко, до руководителя близко, и деньги платит второй.

В ролевой модели процесса этот конфликт снят прямо: исполнитель вправе приостановить выполнение и обратиться к владельцу процесса — прими решение, потому что в твоей схеме этого нет.

Это не прыжок через голову. Это последний шанс процесса сделать потребителя довольным, и заодно способ снять с исполнителя невыносимый выбор между премией за клиента и штрафом за непослушание.

Где сегодня помогает AI. Разложить конкретный процесс по ролям — работа на вечер с моделью: она задаёт вопросы по каждой роли и сразу подсвечивает две типовые беды — роль, которую не исполняет никто, и роль, которую делят люди с конфликтующими интересами. Дальше нужен человек, потому что проверить ответы можно только по жизни.

Кто такой поставщик и где начинается процесс

Поставщик — это не любой, кто вам что-то привозит. Это владелец процесса, чей результат является входом в ваш.

Разберём на рознице. Вы продаёте оргтехнику со склада, закупленную оптом. Кто поставщик? Не производитель — вы не знаете, когда и как закупка происходила, и повлиять на него не можете. Вы видите только склад. Поставщик — начальник склада.

Отсюда следует ответ на вопрос, где начинается процесс продажи. Не тогда, когда пришёл клиент. Он начинается, когда вы получили информацию, что товар есть. До этого момента вы не идёте искать покупателя — и, кстати, по закону о торговле не имеете права его продавать. Если товар делается под заказ, это уже другая модель, и о ней покупателя предупреждают заранее.

И различение, которое ловит половину ошибок в схемах: поставщик или исполнитель? Проверяется двумя вопросами — сделано ли это под ваш конкретный прецедент и сделано ли до его начала.

	Поставщик	Исполнитель
Кофе и печенье на кофе-брейк	✓ произведены для широкого круга и до тренинга
Типография с раздаткой		✓ печатает после подписания договора, с логотипом заказчика
Помещение под требования тренинга		✓ подбирается под конкретный прецедент

Тонкость: если без конкретного вида кофе тренинг не состоится, кофе тоже переезжает в исполнители. Граница проходит не по типу товара, а по тому, затачивается ли он под ваш прецедент.

Возвращаясь к детскому саду

Теперь дефект виден целиком. Роли расставлены почти правильно: потребители — родители, пользователи — дети, исполнители — повара и воспитатели, руководитель экземпляра — старший смены, владелец ресурсов — заведующий, контролёры есть. Ломается одно место: заказчик по должности ниже владельца процесса.

Починить это можно двумя способами, и оба структурные:

• сделать заведующего владельцем процесса — тогда он отвечает за то, как кормят, перед теми, для кого кормят;
• поднять заказчика до уровня владельца — либо заказчиком становится сам куратор, но с мотивацией, привязанной к удовлетворённости родителей и к тому, съедают ли дети еду, либо им становится структура, у которой есть реальное право прийти в администрацию.

Показательно, что в частных садах эта проблема исчезает сама: куратор из администрации остаётся там просто информируемым.

Насколько зрелым процесс получился в итоге, меряется отдельно — опросником из двадцати вопросов, на которые отвечают не эксперты, а обычные сотрудники.

И то же самое в ИТ. Знакомая история: компания внедряет сервисную модель, аккуратно расписывает взаимосвязи функций — но человека, персонально отвечающего за конкретное обращение, в схеме нет. Клиент звонит: «Что с моей заявкой?» Первая линия отвечает, что заявка на второй. Со второй линией поговорить нельзя. За то, чтобы обратившийся был доволен, не отвечает никто. Ровно та же дыра, что и в садике, только называется иначе.

Вывод

Ролевая модель — не бюрократия, а способ найти в процессе места, где ответственность повисла.

Три вещи стоит унести. Потребитель, пользователь и заказчик — почти всегда разные люди, и путать их дорого: продукт делают для того, кто им пользуется, а не для того, чья потребность удовлетворяется. Аудитор нужен не для наказания, а чтобы отделить «люди не работают по схеме» от «схема не годится» — без этого разделения владелец процесса будет вечно винить реальность. И заказчик не может быть слабее владельца процесса: как только тот, для кого делают, оказывается ниже того, кто делает, процесс перестаёт чиниться изнутри.

Следующий шаг: возьмите свой процесс и выпишите по фамилиям, кто в нём потребитель, кто пользователь и кто заказчик. Если на все три роли у вас один человек — скорее всего, вы описали функцию, а не процесс. Если заказчик оказался в подчинении у владельца процесса — вы нашли то, что не получится починить регламентами.