Михаил Рыбаков - Как навести порядок в своем бизнесе. Как построить надежную систему из ненадежных элементов. Практикум Страница 20

Раскройте наиболее крупные шаги своего процесса из прошлого задания как подпроцессы («матрешки») на один уровень вглубь.

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. А сейчас давайте подумаем: а кому в ресторане нужна такая информация?

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