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

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

Кстати, часто у одного шага результатов несколько – вспомните и запишите их все. Если оказалось слишком много (больше пяти), объединяйте в смысловые группы (например, пакет документов от клиента). Раскроете на более детальном уровне.

Ответственный за шаг – тот, кто отвечает за его результаты и точность выполнения технологии. Перед кем? Правильно, перед руководителем процесса.

Ответственный всегда должен быть один. Хорошо, если ответственый за шаг – из числа его исполнителей.

Исполнители шага. А вот их может быть много. Желательно вспомнить всех. Если получается слишком много – объединяйте, например, рабочие цеха покраски.

Комментарий – это поле для ваших заметок. Например, сюда можно записывать ЗБР по шагу. Но лучше не перегружать эту колонку, пусть лучше она останется пустой.

Практическое задание 30

1. Определите шаги выбранного ранее процесса, соблюдая принципы, которые я рассказал выше.

2. Опишите их в формате таблицы. Делайте это после того, как согласуете перечень и порядок шагов.

Флипчарт вам в помощь ☺.

3.3.2.3 Подпроцессы («Матрешки»)

Так мы в шутку называем крупные шаги («черные ящики») процессов, которые есть смысл раскрыть более детально (рис. 8). Для их описания мы обычно предлагаем клиентам использовать тот же «язык», что и для процессов более высокого уровня – мы с вами разобрали его чуть выше.

Рисунок 8. Подпроцессы («Матрешки»)

Название шага процесса переходит в название подпроцесса.

Ответственный за шаг становится РП в подпроцессе, исполнители «расходятся» по его шагам.

Естественно, что и цели, и показатели подпроцесса должны логически подчиняться таковым в вышестоящем процессе.

А вот архитектор у подпроцесса может быть другой. Конечно, и он, и рабочая группа, которую он возглавляет, должны работать в связке с командой, которая работает над процессом более высокого уровня.

Иногда бывает полезно разобрать процесс в виде «матрешек» и на следующем – третьем уровне глубины.

У меня для вас хорошая новость. В большинстве случаев описания процесса в виде шапки, тела и раскрытых крупных шагов-матрешек достаточно. В нашей практике этот способ использовали даже крупные компании с тысячами сотрудников – и получали много пользы. От прояснения того, как же они работают, устранения множества дыр и «кривизны» в своих процессах.

Практическое задание 31

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

3.3.3. Копаем глубже. SIPOC и «клиент – поставщик»

К девятому изданию. Наверное, когда я писал первую версию этой книги, я был перфекционистом[120]. И я питал иллюзии, что все такие ☺. Однако время и новый опыт расставили все по своим местам.

Сейчас в наших консалтинговых проектах мы далеко не всегда используем методику SIPOC, описанную в этой главе. Она глубока и прекрасна, но сложна и избыточна для большинства людей и команд. По крайней мере на том уровне зрелости, на котором они обычно начинают внедрять процессный подход. Причем это касается даже «продвинутых» ИТ-компаний и руководителей, окончивших MBA. Потому что теория – это одно, а жизнь – другое. Так, если огород на даче можно вскопать при помощи соседа дяди Васи или работника Ильяса, не нужно покупать для этого новейшие технические средства – это неразумно и нерентабельно.

Как правило, в большинстве организаций на несколько лет хватает инструментария, описанного выше. Хотя, конечно, бывают случаи, когда методика SIPOC и лежащая в ее основе концепция «клиент – поставщик» действительно нужны, а люди к ним – готовы.

Только, пожалуйста, не ныряйте в SIPOC как в омут с головой – утонете. Примеров немало. Сначала опишите процессы на верхнем уровне, как мы с вами разобрали. Протестируйте их, внедрите, получи́те результаты. Поживите с этим какое-то время – чтобы прижились обновленные процессы и привычка по ним работать. А вот уж потом, если будет нужно…

Тем не менее я советую вам изучить эту главу сейчас – в ней много мыслей, которые раньше-позже принесут вам большую пользу.

Дальнейший текст этой подглавы я сохранил почти в первозданном виде[121].

* * *

Общая схема процесса, которую мы сделали, достаточно для многих целей. Однако это довольно грубая модель, и есть много важных нюансов, которые она не учитывает. Поэтому сейчас углубимся в более детальный анализ процесса.

Пример 45. Василий Торопин, менеджер компании «ВымпелКом» («Билайн»): «Одно из основных ноу-хау – степень детальности описания процессов. Этим делом можно увлечься и парализовать работу: вместо дела – описание процессов. Золотая середина, поиск разумной достаточности – вечная тема в любом деле, и в особенности в этом!»

Для этого нам понадобится некоторая методология, т. е. подход к описанию и анализу процесса. А также нотация, т. е. способ его отображения.

Для описания бизнес-процессов в мире разработаны десятки методологий, каждая из которых позволяет отобразить те или иные аспекты деятельности компании. Это такие подходы, как ARIS, IDEF0 (SADT), IDEF3, DFD и многие другие (рис. 9). К сожалению, зачастую их применение в практической работе неоправданно и даже вредно[122].

Рисунок 9. Пример схемы в формате SADT [123] . Как вам?..