Страница 22 из 30
Ответственный за шаг – тот, кто отвечает за его результаты и точность выполнения технологии. Перед кем? Правильно, перед руководителем процесса.
Ответственный всегда должен быть один. Хорошо, если ответственный за шаг – из числа его исполнителей.
Исполнители шага. А вот их может быть много. Желательно вспомнить всех. Если получается слишком много – объединяйте, например, рабочие цеха покраски.
Комментарий – это поле для ваших заметок. Например, сюда можно записывать ЗБР по шагу. Но лучше не перегружать эту колонку, пусть лучше она останется пустой.
1. Определите шаги выбранного ранее процесса, соблюдая принципы, которые я рассказал выше.
2. Опишите их в формате таблицы. Делайте это после того, как согласуете перечень и порядок шагов.
Удобно делать это маркерами на флип-чарте. Итоги потом переносят в компьютер, например в Microsoft Word или Excel.
3.3.2.3 Подпроцессы («Мартешки»)
Так мы в шутку называем крупные шаги («черные ящики») процессов, которые есть смысл раскрыть более детально. Для их описания мы обычно предлагаем клиентам использовать тот же «язык», что и для процессов более высокого уровня – мы с вами разобрали его чуть выше (рис. 8).
Рисунок 8. Подпроцессы («Матрешки»)
Название шага процесса переходит в название подпроцесса.
Ответственный за шаг становится РП в подпроцессе, исполнители «расходятся» по его шагам.
Естественно, что и цели, и показатели подпроцесса должны логически подчиняться таковым в вышестоящем процессе.
А вот архитектор у подпроцесса может быть другой. Конечно, и он, и рабочая группа, которую он возглавляет, должны работать в связке с командой, которая работает над процессом более высокого уровня.
Иногда бывает полезно разобрать процесс в виде «матрешек» и на следующем – третьем уровне глубины.
У меня для вас хорошая новость. В большинстве случаев описания процесса в виде шапки, тела и раскрытых крупных шагов-матрешек достаточно. В нашей практике этот способ использовали даже крупные компании с тысячами сотрудников – и получали много пользы. От прояснения того, как же они работают, устранения множества дыр и «кривизны» в своих процессах.
Раскройте наиболее крупные шаги своего процесса из прошлого задания как подпроцессы («мартешки») на один уровень вглубь.
Удобно делать это маркерами на флип-чарте. Итоги потом переносят в компьютер, например в Microsoft Word или Excel. Но иногда нужно идти еще глубже.
3.3.3. Копаем глубже. SIPOC и «Клиент-поставщик»
К восьмому изданию. Наверное, когда я писал первую версию этой книги, я был перфекционистом[110]. И я питал иллюзии, что все такие ☺. Однако время и новый опыт расставили все по своим местам.
Сейчас в наших консалтинговых проектах мы далеко не всегда используем методику SIPOC, описанную в этой главе. Она глубока и прекрасна, но сложна и избыточна для большинства людей и команд. По крайней мере на том уровне зрелости, на котором они обычно начинают внедрять процессный подход. Причем это касается даже «продвинутых» ИТ-компаний и руководителей, окончивших MBA. Потому что теория – это одно, а жизнь – другое. Так, если огород на даче можно вспахать при помощи соседа дяди Васи или работника Ильяса, не нужно покупать для этого новейшие технические средства – это неразумно и нерентабельно.
Как правило, в большинстве организаций на несколько лет хватает инструментария, описанного выше. Хотя, конечно, бывают случаи, когда методика SIPOC и лежащая в ее основе концепция «клиент-поставщик» действительно нужны, а люди к ним – готовы.
Только, пожалуйста, не ныряйте в SIPOC как в омут с головой – утонете. Примеров немало. Сначала опишите процессы на верхнем уровне, как мы с вами разобрали. Протестируйте их, внедрите, получите результаты. Поживите с этим какое‑то время – чтобы прижились обновленные процессы и привычка по ним работать. А вот уж потом, если будет нужно…
Тем не менее, я советую вам изучить эту главу сейчас – в ней много мыслей, которые раньше-позже принесут вам большую пользу.
Дальнейший текст этой подглавы я сохранил почти в первозданном виде[111].
Общая схема процесса, которую мы сделали, достаточно для многих целей. Однако это довольно грубая модель, и есть много важных нюансов, которые она не учитывает. Поэтому сейчас углубимся в более детальный анализ процесса.
Пример 45. Василий Торопин, менеджер компании «Вымпелком» («Билайн»): «Одно из основных ноу-хау – степень детальности описания процессов. Этим делом можно увлечься и парализовать работу: вместо дела – описание процессов. Золотая середина, поиск разумной достаточности – вечная тема в любом деле, и в особенности в этом!»
Для этого нам понадобится некоторая методология, т. е. подход к описанию и анализу процесса. А также нотация, т. е. способ его отображения.
Для описания бизнес-процессов в мире разработаны десятки методологий, каждая из которых позволяет отобразить те или иные аспекты деятельности компании. Это такие подходы, как ARIS, IDEF0 (SADT), IDEF3, DFD и многие другие (рис. 9). К сожалению, зачастую их применение в практической работе неоправданно и даже вредно[112].
Рисунок 9. Пример схемы в формате SADT[113]. Как вам?..
Почему? Они логически очень правильные, но сложны в изучении. То есть для того, чтобы начать ими грамотно пользоваться, надо сначала пройти курс обучения длительностью от нескольких дней до пары недель. У вас есть это время? А у ваших сотрудников?
Вот и получается, что хорошо владеют подобными методиками лишь специалисты-аналитики. Но! Экспертами в вашем бизнесе являетесь вы и ваша команда. А значит, эти схемы надо хорошо понимать именно вам. Тем более, что вы же являетесь их потребителями. Иначе создаются модели, которые принесут вам мало пользы. Это как если бы должностные инструкции в вашей компании были написаны на китайском языке!
В одном из проектов нас позвали в компанию, где до этого в течение нескольких месяцев штатный бизнес-аналитик занимался описанием процессов. Он часами сидел с руководителями подразделений, старательно выспрашивая их о нюансах работы. Результаты заносил в схемы стандарта IDEF0. Была создана громоздкая иерархия процессов. Как в кулуарах выразился один из топ-менеджеров: «И что толку? Время потрачено – а в реальной работе НИЧЕГО не изменилось».
Почему же тогда подобные методики применяются? Потому что это выгодно тем, кто их продвигает: проект получается долгий, а значит дорогой. Часто еще и бесполезный, но кого это волнует? Деньги‑то потратили[114]. Ну и мода сказывается.
Пример 46. Алексей Тимонин, генеральный директор интернет-магазина путешествий OZON. travel: «Методология описания БП крайне важна. Люди вообще не любят читать описания БП, а если описания состоят преимущественно из текста, то они его почти гарантированно не прочитают. В итоге у нас в компании была выработана собственная упрощенная методология описания БП – с упором на визуальные представления (диаграммы), а текст используется исключительно во вспомогательных целях. Распространенные методологии описания БП действительно нам было сложно использовать в полном масштабе. Я думаю, в том числе из‑за того, что каждая из таких методологий создавалась в определенную историческую эпоху, для определенной индустрии и даже для определенных языков – и их адаптационные возможности ограничены».
110
От англ. perfect – совершенный. А перфекцинист – тот кто стремится к совершенству.
111
Напоминаю, что новая версия методологии подробно изложена в книге «Бизнес-процессы: как их описать, отладить и внедрить. Практикум.»
112
Тут многие коллеги могут на меня обидеться. Почему – см. ниже.
113
Пример из книги D. Marca, C. McGowan, Structured Analysis and Design Technique, McGraw-Hill, 1987.
114
См. п. 10.1 «Антикоррупция».