Страница 24 из 30
5. А от кого официант может получить всю эту информацию? Смотря какую.
• Пожелания гостя – от него самого.
• Информацию о свободных / занятых и забронированных столиках – от администратора зала (рис. 16).
Рисунок 16. Полное описание одного шага в SIPOC
Мы дошли до очень важного момента. Сейчас гость и администратор зала являются внутренними поставщиками для официанта. И должны удовлетворить его потребности. Пожалуй, все, кроме гостя (внешнего клиента): от него официант должен получить информацию сам, причем в приятной для того манере. А вот если администратор зала не сообщил своему сотруднику нужную информацию – как он может требовать от него качественной работы?[122]
Ведь это и есть бардак! Спонтанный бизнес…
Получается, что в одной ситуации официант является поставщиком и должен удовлетворять своих клиентов, а в другой – клиентом и может выдвигать требования к своим внутренним поставщикам.
Важнейший вывод: в компании выстраиваются цепочки «клиент – поставщик», и от того, насколько отлажены эти стыки, насколько поставщики удовлетворяют своих клиентов, зависит эффективность бизнеса[123] (рис. 17).
Рисунок 17. Цепочка «Клиент – поставщик»
Если развить эту мысль дальше, между клиентами и поставщиками (как внутренними, так и внешними), могут заключаться «соглашения об уровне обслуживания»[124]. В них стороны фиксируют договоренности по тем или иным параметрам взаимодействия (скорость, количество допустимых дефектов и т. д.). Результаты (не) выполнения этих соглашений могут иметь вполне материальные последствия для сторон.
Итак, мы с вами подробно описали один шаг процесса. На первый взгляд, кажется, что это долго. В действительности основное время уходит на обдумывание, обсуждения. Само рисование занимает секунды. В итоге вы получаете однозначное понимание процесса, согласованное между всеми его участниками. А схема – это всего лишь инструмент.
Напомню последовательность, в которой мы анализировали шаг процесса. Запомните ее как мантру, т. к. нарушение зачастую приводит к потере смысла.
1. Шаг: название, ответственный, исполнители.
2. Выход (ы) шага.
3. Клиент (ы), которому нужны эти выходы и который предъявляет к ним свои требования (отдельно по каждому выходу).
4. Вход (ы) этого шага.
5. Поставщик (и) по каждому входу. К ним ответственный за данный шаг предъявляет свои требования.
После того как мы полностью описали один шаг, переходим к следующему (рис. 18). Замечу, что в процессе такого глубокого анализа исходный состав и последовательность шагов могут измениться. Но и обойтись без общей схемы процесса[125], как правило, не получается.
Рисунок 18. Несколько шагов схемы процесса в нотации SIPOC
Нарисуйте схему SIPOC для выбранного ранее основного процесса вашей компании.
Это обсуждение, как и другие, команде удобно проводить вокруг флипчарта.
3.3.4. Улучшаем и внедряем процесс
[126]
Мало нарисовать процесс в том виде, как он протекает сегодня. Потому что, как правило, он выполняется не самым лучшим образом. Это происходит потому, что процессы в компании складываются исторически. И надо сделать новые, более эффективные версии процессов, внедрить их в работу.
Классический подход к оптимизации выглядит так:
1. Сначала процесс описывают «как есть» (состояние «AS IS»).
2. Потом проектируют «как должно быть» (состояние «TO BE»).
3. После этого пытаются внедрить разработанный процесс.
Какие минусы у такого подхода?
• Описание «как есть» – долгий и трудоемкий процесс, а польза его очень сомнительна. Вот представьте, что вы[127] изучали компанию, положим, месяц. В конце получили кипу отчетов, которые кратко презентуете руководству. Ну и что толку? Что со всем этим делать? Это выгодно консультантам, но приносит очень мало пользы компании. Зачастую и вред, т. к. в процессе описания руководителей и сотрудников компании отвлекают от работы, а результат все равно создается промежуточный. В итоге люди разочаровываются, и когда доходит до реальных перемен, они уже перестают верить в улучшения и консультантов[128].
• Часто в процессе описания уже возникает желание сделать какие‑то улучшения, но при такой технологии – нельзя! Кстати, описание «как есть» вообще часто является фикцией, т. к. процессы в компании зачастую протекают по‑разному (в зависимости от конкретного сотрудника, его настроения и т. д.).
• Проектирование новых процессов часто выполняют консультанты и / или руководители в «кабинетном режиме», т. е. без контакта с теми, кто в этих процессах реально участвует. А потом выясняется, что в новых процессах не учтено множество нюансов, и попытки «натянуть» их на реальную компанию приводят к провалу. Поскольку сотрудники компании не участвовали в проектировании новых процессов, то в ходе внедрения начинается их активное и пассивное сопротивление.
Описанный выше подход мы называем революционным.
А в своих проектах используем другой – более мягкий и результативный – эволюционный.
1. Команда описывает процесс, отталкиваясь от того, как он протекает сегодня, но «с прицелом» на ближайшее будущее: как есть + ЗБР[129]. То есть рисуем его таким, каким он должен стать в течение ближайшего месяца-трех. В обсуждении процесса участвуют все связанные с этим процессом руководители и ключевые сотрудники. По ходу они выдвигают предложения, которые, во‑первых, хорошо обоснованы, а во‑вторых, не будут в дальнейшем вызывать сопротивления при внедрении.
2. Как только вы определили, кто архитектор процесса, он назначается ответственным со стороны компании за его описание и развитие, лидером рабочей группы. Таким образом:
• ответственность за внедрение остается в компании, а не на консультантах[130];
• АП получает хорошую мотивацию: теперь он может проявить себя в полезном интересном деле, внести ценный вклад в бизнес, да еще и отладить стыки со смежниками (зачастую они входят в рабочую группу по процессу), решить застарелые конфликты;
• высшее руководство компании освобождается от рутинной деятельности по улучшению процессов, оставляя за собой только функции создания общей архитектуры компании и контроля ее развития.
3. Команда постепенно внедряет процесс.
• Сначала проводит несколько практических «прогонов», в ходе которых выявляются недочеты, не замеченные раньше.
• По итогам процессы оттачиваются, доводятся до ума.
• Когда новый процесс показал хорошие результаты, он утверждается руководством, внедряется во всей компании и становится обязательным к применению.
• Также необходимо обновить процесс в библиотеке процессов компании[131].
122
См. п. 6.9 «Управление знаниями».
123
Это же относится и к производственным цепочкам, в которые выстраиваются различные компании, а также подразделения холдингов.
124
Service level agreements (SLA).
125
См. начало п. 3.3 «Описываем и отлаживаем основные процессы своего бизнеса».
126
Улучшение и внедрение процессов – непростая задача. Как правило, именно она вызывает основные трудности и разочарования. В книге «Бизнес-процессы: как их описать, отладить и внедрить. Практикум» я посвятил этому целый раздел III «Улучшаем процессы и внедряем их в жизнь».
127
Или нанятые вами консультанты.
128
Вообще не нужно просить консультантов описать ваши процессы за вас. Это пустое. «Волшебные таблетки» не приносят пользы. Хороший консультант может сильно помочь вашей команде. Но делать за вас он никогда не станет.
129
Зона ближайшего развития. См. п. 3.3.2.1 «Выделяем шаги процесса».
130
Если вы повесите на консультанта ответственность за изменения вашего бизнеса, то проект обречен на провал. Подробнее см. п. 8.3 «Работа с консультантами».
131
См. п. 3.4 «Управление документацией компании».