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

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

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

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