Михаил Рыбаков - Как навести порядок в своем бизнесе. Как построить надежную систему из ненадежных элементов. Практикум
Раскройте наиболее крупные шаги своего процесса из прошлого задания как подпроцессы («матрешки») на один уровень вглубь.
3.3.3. Копаем глубже. SIPOC и «клиент – поставщик»
К девятому изданию. Наверное, когда я писал первую версию этой книги, я был перфекционистом[120]. И я питал иллюзии, что все такие ☺. Однако время и новый опыт расставили все по своим местам.
Сейчас в наших консалтинговых проектах мы далеко не всегда используем методику SIPOC, описанную в этой главе. Она глубока и прекрасна, но сложна и избыточна для большинства людей и команд. По крайней мере на том уровне зрелости, на котором они обычно начинают внедрять процессный подход. Причем это касается даже «продвинутых» ИТ-компаний и руководителей, окончивших MBA. Потому что теория – это одно, а жизнь – другое. Так, если огород на даче можно вскопать при помощи соседа дяди Васи или работника Ильяса, не нужно покупать для этого новейшие технические средства – это неразумно и нерентабельно.
Как правило, в большинстве организаций на несколько лет хватает инструментария, описанного выше. Хотя, конечно, бывают случаи, когда методика SIPOC и лежащая в ее основе концепция «клиент – поставщик» действительно нужны, а люди к ним – готовы.
Только, пожалуйста, не ныряйте в SIPOC как в омут с головой – утонете. Примеров немало. Сначала опишите процессы на верхнем уровне, как мы с вами разобрали. Протестируйте их, внедрите, получи́те результаты. Поживите с этим какое-то время – чтобы прижились обновленные процессы и привычка по ним работать. А вот уж потом, если будет нужно…
Тем не менее я советую вам изучить эту главу сейчас – в ней много мыслей, которые раньше-позже принесут вам большую пользу.
Дальнейший текст этой подглавы я сохранил почти в первозданном виде[121].
* * *Общая схема процесса, которую мы сделали, достаточно для многих целей. Однако это довольно грубая модель, и есть много важных нюансов, которые она не учитывает. Поэтому сейчас углубимся в более детальный анализ процесса.
Пример 45. Василий Торопин, менеджер компании «ВымпелКом» («Билайн»): «Одно из основных ноу-хау – степень детальности описания процессов. Этим делом можно увлечься и парализовать работу: вместо дела – описание процессов. Золотая середина, поиск разумной достаточности – вечная тема в любом деле, и в особенности в этом!»
Для этого нам понадобится некоторая методология, т. е. подход к описанию и анализу процесса. А также нотация, т. е. способ его отображения.
Для описания бизнес-процессов в мире разработаны десятки методологий, каждая из которых позволяет отобразить те или иные аспекты деятельности компании. Это такие подходы, как ARIS, IDEF0 (SADT), IDEF3, DFD и многие другие (рис. 9). К сожалению, зачастую их применение в практической работе неоправданно и даже вредно[122].
Рисунок 9. Пример схемы в формате SADT[123]. Как вам?..
Почему? Они логически очень правильные, но сложны в изучении. То есть для того, чтобы начать ими грамотно пользоваться, надо сначала пройти курс обучения длительностью от нескольких дней до пары недель. У вас есть это время? А у ваших сотрудников?
Вот и получается, что хорошо владеют подобными методиками лишь специалисты-аналитики. Но! Экспертами в вашем бизнесе являетесь вы и ваша команда. А значит, эти схемы надо хорошо понимать именно вам. Тем более, что вы же являетесь их потребителями. Иначе создаются модели, которые принесут вам мало пользы. Это как если бы должностные инструкции в вашей компании были написаны на китайском языке!
В одном из проектов нас позвали в компанию, где до этого в течение нескольких месяцев штатный бизнес-аналитик занимался описанием процессов. Он часами сидел с руководителями подразделений, старательно выспрашивая их о нюансах работы. Результаты заносил в схемы стандарта IDEF0. Была создана громоздкая иерархия процессов. Как в кулуарах выразился один из топ-менеджеров: «И что толку? Время потрачено – а в реальной работе НИЧЕГО не изменилось».
Почему же тогда подобные методики применяются? Потому что это выгодно тем, кто их продвигает: проект получается долгий, а значит дорогой. Часто еще и бесполезный, но кого это волнует? Деньги-то потратили[124]. Ну и мода сказывается.
Пример 46. Алексей Тимонин, генеральный директор интернет-магазина путешествий OZON.travel: «Методология описания БП крайне важна. Люди вообще не любят читать описания БП, а если описания состоят преимущественно из текста, то они его почти гарантированно не прочитают. В итоге у нас в компании была выработана собственная упрощенная методология описания БП – с упором на визуальные представления (диаграммы), а текст используется исключительно во вспомогательных целях. Распространенные методологии описания БП действительно нам было сложно использовать в полном масштабе. Я думаю, в том числе из-за того, что каждая из таких методологий создавалась в определенную историческую эпоху, для определенной индустрии и даже для определенных языков – и их адаптационные возможности ограничены».
Мы же применяем простые средства, на изучение которых уходит несколько часов, после чего команда клиента (от владельца до рабочего) активно работает с их помощью над реальными задачами своего бизнеса. Одно из таких средств мы сейчас и изучим.
У вышеупомянутого клиента с нашей помощью команда руководителей за один день просто и наглядно описала несколько ключевых процессов компании, смогла прорешать многие годами копившиеся проблемы.
У другого клиента – известной консалтинговой (!) компании – ушел год на то, чтобы собрать вместе учредителей, руководителей и ключевых сотрудников. А потом – один день, за который мы с ними разгребли годами копившийся бардак в основных процессах.
Методика называется SIPOC[125] по первым буквам английских слов.
Возьмем чистый лист бумаги, лучше – большой, для флипчарта. Его удобно располагать горизонтально – схема широкая.
Сверху разместим шапку нашего процесса: его название, цель, РП и т. д.[126] Напоминаю, что пример называется «Обслуживание клиента в ресторане от встречи до проводов».
Под ним равномерно распределите по горизонтали слова:
• Поставщик (Supplier)
• Вход (Input)
• Шаг (Process)
• Выход (Output)
• Клиент (Client)
Получится примерно следующее (рис. 10):
Рисунок 10. Шапка схемы SIPOC
Движемся дальше. Сейчас мы детально проанализируем первый шаг процесса. Как мы помним, это «Встреча и размещение гостя».
1. Сначала запишем его по центру под словом «Шаг» и обведем прямоугольником. Можно проставить номер шага (рис. 11):
Рисунок 11. Шаг процесса в схеме SIPOC
Рисуйте компактно: справа и слева вам понадобится много места.
Кто отвечает за встречу и размещение гостя? Скорее всего – официант.
Давайте запишем ответственного за шаг и исполнителей. Ответственного удобно выделять жирным шрифтом. Вполне возможна ситуация, когда он сам является и исполнителем. Тогда достаточно написать его один раз. То есть отдельных исполнителей может и не быть, а вот ответственный должен быть всегда (рис. 12).
Рисунок 12. Шаг процесса с указанием ответственного и исполнителей
Ответственный и исполнители – те же, о которым мы говорили при описании тела процесса в формате таблицы. Хотя, конечно, при более глубоком рассмотрении процесса вы можете уточнить как состав шагов, так и их параметры[127].
2. Теперь нам надо определить выходы данного шага. Выходом может быть информация, а также нечто материальное[128].
Каждый шаг выполняется ради своих выходов. То есть если их нет, шаг не имеет смысла и, скорее всего, не нужен. Поэтому выходы надо определить максимально точно.
Выходы шага – это то же самое, что его результаты в табличной форме описания процесса.
Что будет выходом нашего шага? Информация о размещении гостя. То есть сведения о том, какой столик он занял.
Часто у шага бывает несколько выходов.
Удобно соединить шаг и каждый его выход отдельной стрелкой. Получается следующее (рис. 13):
Рисунок 13. Шаг процесса и его выход(ы)
3. А сейчас давайте подумаем: а кому в ресторане нужна такая информация?
Старшему официанту: чтобы знать, куда направить свободного официанта для принятия заказа.
