# Почему в детском саду кормят так, как кормят: сбой в ролевой модели
> Разбор лекции по процессному управлению из программы MBA CIO: ролевая модель процесса — потребитель, пользователь, заказчик, владелец процесса, аудитор, руководитель экземпляра, владелец и администратор ресурсов, поставщик; какие роли стоит совмещать и почему заказчик не может быть ниже владельца процесса по должности.
Источник: https://blog.uspeshnyy.ru/blog/pochemu-v-detskom-sadu-kormyat-tak/
Автор: Александр Успешный · blog.uspeshnyy.ru
Опубликовано: 2014-11-29
Теги: MBA, система, стратегия, аналитика, Процессное управление, Владислав Сирота
---
Работая с администрацией подмосковного города, лектор разобрал по ролям процесс приготовления пищи в детском саду. Начиналось всё нормально.
**Потребители — не дети, а родители.** У родителей есть потребность в сытых и здоровых детях. Если бы потребителями были дети, меню состояло бы из чипсов и газировки. Дети здесь **пользователи**: они с помощью еды удовлетворяют потребность родителей. Если бы и детей в модели не было, кормить пришлось бы рыбьим жиром и морковкой — самой здоровой едой, которую никто не ест.
За баланс между «полезно» и «съедят» отвечает **заказчик** — заведующий детским садом. Он же отчитывается наверх, в администрацию.
А дальше выясняется, что **владелец процесса** — тот самый куратор в администрации, которого заведующий информирует. То есть заказчик по должности **ниже** владельца процесса.
Тот, для кого делают, слабее того, кто делает. С этого момента система не чинится изнутри: даже если родители убедили заведующего, что кормить надо иначе, сделать он ничего не может — схема спущена сверху. Санэпидемстанция, другие повара, родительские комитеты пытались — не влияют.
Это пятая лекция [процессного управления](/blog/krasnye-i-sinie-konverty/) из программы MBA CIO, целиком посвящённая ролевой модели. Разбираю её — и в конце вернусь к садику.
## Роль — это не должность
Начинается всё с различения, на котором спотыкаются почти все.
**Должность** — набор компетенций, за которые вам платят. **Роль** — набор связанных между собой задач с общей целью, которые вы выполняете.
Чтобы человек хорошо выполнял роль, нужны две вещи, и обе обязательные: **компетенции** позволяют, **мотивация** есть желание. Без первого не сможет, без второго не станет.
Один человек может исполнять несколько ролей, а одну роль могут делить несколько человек. И ещё одно ограничение, которое ломает половину нарисованных схем: **роль выполняет только физическое или должностное лицо**. Таксопарк не может быть владельцем ресурсов — им является начальник гаража.
## Одиннадцать ролей и четыре группы
| Роль | За что отвечает |
|---|---|
| **Потребитель** | чья потребность удовлетворяется процессом |
| **Пользователь** | кто с помощью продукта эту потребность удовлетворяет |
| **Заказчик** | чтобы потребитель был доволен, а пользователь работал эффективно |
| **Информируемый** | нужна информация о процессе, но не сам результат; обычно регуляторы |
| **Владелец процесса** | результативность и эффективность; разрабатывает схему |
| **Эксперт-консультант** | закрывает нехватку знаний владельца о технологиях |
| **Контролёр-аудитор** | проверяет, работают ли люди по схеме |
| **Руководитель экземпляра** | управляет исполнителями в одном прецеденте |
| **Исполнитель** | выполняет работы по схеме |
| **Владелец ресурсов** | чтобы исполнителей хватало и они были готовы |
| **Администратор ресурсов** | кого именно поставить на конкретный прецедент |
| **Поставщик** | владелец процесса, результат которого — вход в ваш |
**Три роли опциональны** и появляются только тогда, когда владелец процесса перестаёт справляться сам. Эксперт-консультант — когда не хватает знаний. Аудитор и руководитель экземпляра — когда не хватает времени: три одновременных прецедента владелец проверит и проконтролирует сам, тридцать три — уже нет.
## Потребитель, пользователь и заказчик — обычно разные люди
Разложить эту тройку правильно труднее, чем кажется. Два примера из лекции.
**Подарок от бабушки.** Бабушка даёт вам денег, чтобы вы купили подарок своему ребёнку — от её имени. Потребитель — **бабушка**: её потребность в том, чтобы внук был рад и любил бабушку. Пользователь — **ребёнок**: он играет с машинкой. Заказчик — **вы**: ваша задача свести баланс так, чтобы и бабушка была довольна, и ребёнок не забросил игрушку через день. Отсюда, кстати, знакомая практика — добавить к бабушкиным двум тысячам ещё десять своих.
Поменяйте вводные — роли переедут. Если внук сам попросил у бабушки конкретную машинку, потребитель уже **внук**, пользователем становится **бабушка**: она с помощью машинки удовлетворяет потребность внука. Заказчик по-прежнему тот, кто идёт в магазин.
**Корпоративный тренинг.** Здесь ошибаются массово: участники уверены, что они потребители. Ничего подобного — они **пользователи**. В них вливают продукт под названием «информация», и делают это не для того, чтобы им было хорошо, а чтобы они лучше работали. Учим менеджеров по продажам — потребители не они, а **клиенты компании**. Учим системных администраторов — потребители те, кого они поддерживают. Заказчик — начальник отдела продаж. Директор по персоналу — информируемый: ему важно знать, что тренинг был.
Практическое следствие: если пользователя не мотивировать, он начнёт минимизировать собственные затраты — то есть спать на занятиях. Идеально, когда у него есть и своя потребность: администратор сам хочет изучить новую систему. Тогда он потребитель и пользователь одновременно, и тренинг проходит на ура. Но это побочный выигрыш, а не цель.
## Зачем процессу аудитор
Логика этой роли объясняется одним рассуждением, и оно того стоит.
Вы владелец процесса. Ваш основной инструмент — схема: вы отдаёте её людям и говорите работать по ней. Вы отслеживаете параметры и однажды видите, что они не те, какими должны быть.
Возможных объяснений ровно два:
1. люди не выполняют то, что должны;
2. схема не соответствует жизни.
**Аудитор нужен, чтобы исключить первое.** Если он подтверждает, что люди работают по схеме, а результата всё равно нет, — значит, дело в схеме, и менять надо её.
Различение важное, потому что срабатывает известный эффект: изобретатель влюблён в собственную работу и считает её лишённой недостатков. Без аудитора владелец процесса будет годами объяснять расхождение тем, что мир недостаточно хорош для его схемы.
**И оговорка про автоматизацию.** Роль аудитора может исполнять софт — там, где проверку в принципе можно формализовать, например на потоке банковских транзакций. Заодно работает и обратная логика: чем меньше в процессе людей, тем меньше нужен контроль исполнения. Робот выполняет программу всегда; если не выполняет — то не выполняет постоянно, и это видно сразу.
## Какие роли стоит совмещать
Роли внутри одной группы совмещаются свободно. Интереснее связки между группами — те, что добавляют ценности.
**Заказчик и владелец процесса.** Заказчик отвечает за то, чтобы потребитель был доволен, а пользователи работали эффективно. Владелец процесса — за результативность и эффективность. Это одно и то же, сказанное разными словами, — интересы не конфликтуют.
**Пользователь и руководитель экземпляра.** Решение о том, как сделать потребителя довольным, лучше принимает тот, кто работает с ним напрямую: у него меньше транзакционных издержек.
**Потребитель и контролёр.** Идеальный контролёр — тот, чью потребность удовлетворяют. Дайте ему информацию о том, что контролировать, и он добьётся своего лучше любого аудитора.
**Руководитель экземпляра обязан быть одним из исполнителей.** Управление процессом должно находиться внутри него. Как только вы выделяете человека, стоящего вне деятельности, он начинает считать, что проблемы деятельности — не его: он не для того залезал наверх.
Две связки работают как скрепки, которые держат конструкцию: заказчик — владелец процесса — владелец ресурсов и пользователь — руководитель экземпляра — исполнитель.
## Право исполнителя остановить процесс
Классический конфликт: исполнитель знает, как сделать потребителю хорошо, но начальник говорит так не делать. Сегодня исполнитель не делает — до потребителя далеко, до руководителя близко, и деньги платит второй.
В ролевой модели процесса этот конфликт снят прямо: **исполнитель вправе приостановить выполнение и обратиться к владельцу процесса** — прими решение, потому что в твоей схеме этого нет.
Это не прыжок через голову. Это последний шанс процесса сделать потребителя довольным, и заодно способ снять с исполнителя невыносимый выбор между премией за клиента и штрафом за непослушание.
**Где сегодня помогает AI.** Разложить конкретный процесс по ролям — работа на вечер с моделью: она задаёт вопросы по каждой роли и сразу подсвечивает две типовые беды — роль, которую не исполняет никто, и роль, которую делят люди с конфликтующими интересами. Дальше нужен человек, потому что проверить ответы можно только по жизни.
## Кто такой поставщик и где начинается процесс
Поставщик — это не любой, кто вам что-то привозит. Это **владелец процесса, чей результат является входом в ваш**.
Разберём на рознице. Вы продаёте оргтехнику со склада, закупленную оптом. Кто поставщик? Не производитель — вы не знаете, когда и как закупка происходила, и повлиять на него не можете. Вы видите только склад. **Поставщик — начальник склада.**
Отсюда следует ответ на вопрос, где начинается процесс продажи. Не тогда, когда пришёл клиент. **Он начинается, когда вы получили информацию, что товар есть.** До этого момента вы не идёте искать покупателя — и, кстати, по закону о торговле не имеете права его продавать. Если товар делается под заказ, это уже другая модель, и о ней покупателя предупреждают заранее.
**И различение, которое ловит половину ошибок в схемах:** поставщик или исполнитель? Проверяется двумя вопросами — **сделано ли это под ваш конкретный прецедент** и **сделано ли до его начала**.
| | Поставщик | Исполнитель |
|---|---|---|
| Кофе и печенье на кофе-брейк | ✓ произведены для широкого круга и до тренинга | |
| Типография с раздаткой | | ✓ печатает после подписания договора, с логотипом заказчика |
| Помещение под требования тренинга | | ✓ подбирается под конкретный прецедент |
Тонкость: если без конкретного вида кофе тренинг не состоится, кофе тоже переезжает в исполнители. Граница проходит не по типу товара, а по тому, затачивается ли он под ваш прецедент.
## Возвращаясь к детскому саду
Теперь дефект виден целиком. Роли расставлены почти правильно: потребители — родители, пользователи — дети, исполнители — повара и воспитатели, руководитель экземпляра — старший смены, владелец ресурсов — заведующий, контролёры есть. Ломается одно место: **заказчик по должности ниже владельца процесса**.
Починить это можно двумя способами, и оба структурные:
- **сделать заведующего владельцем процесса** — тогда он отвечает за то, как кормят, перед теми, для кого кормят;
- **поднять заказчика до уровня владельца** — либо заказчиком становится сам куратор, но с мотивацией, привязанной к удовлетворённости родителей и к тому, съедают ли дети еду, либо им становится структура, у которой есть реальное право прийти в администрацию.
Показательно, что в частных садах эта проблема исчезает сама: куратор из администрации остаётся там просто информируемым.
Насколько зрелым процесс получился в итоге, меряется отдельно — [опросником из двадцати вопросов](/blog/oprosnik-zrelosti-processa/), на которые отвечают не эксперты, а обычные сотрудники.
**И то же самое в ИТ.** Знакомая история: компания внедряет сервисную модель, аккуратно расписывает взаимосвязи функций — но человека, персонально отвечающего за конкретное обращение, в схеме нет. Клиент звонит: «Что с моей заявкой?» Первая линия отвечает, что заявка на второй. Со второй линией поговорить нельзя. За то, чтобы обратившийся был доволен, не отвечает никто. Ровно та же дыра, что и в садике, только называется иначе.
## Вывод
Ролевая модель — не бюрократия, а способ найти в процессе места, где ответственность повисла.
Три вещи стоит унести. **Потребитель, пользователь и заказчик — почти всегда разные люди**, и путать их дорого: продукт делают для того, кто им пользуется, а не для того, чья потребность удовлетворяется. **Аудитор нужен не для наказания, а чтобы отделить «люди не работают по схеме» от «схема не годится»** — без этого разделения владелец процесса будет вечно винить реальность. И **заказчик не может быть слабее владельца процесса**: как только тот, для кого делают, оказывается ниже того, кто делает, процесс перестаёт чиниться изнутри.
**Следующий шаг:** возьмите свой процесс и выпишите по фамилиям, кто в нём потребитель, кто пользователь и кто заказчик. Если на все три роли у вас один человек — скорее всего, вы описали функцию, а не процесс. Если заказчик оказался в подчинении у владельца процесса — вы нашли то, что не получится починить регламентами.