Ознакомительная версия.
Описываете полный, нормальный, линейный ход процесса. Объясню подробнее:
«Полный» – то есть включающий все основные шаги, даже те, которые выполняются не каждый раз. Например, с некоторых клиентов вы берете 100 %-ную предоплату, с некоторыми (особо доверенными) работаете по отсрочке платежа. А с некоторых – берете частичную предоплату с получением оставшейся суммы по мере выполнения работ. Но шаги «получение предоплаты» и «получение окончательной оплаты» нужно включить в процесс.
Или одним клиентам вы осуществляете доставку, а другие – сами забирают товар с вашего склада. Включите доставку в основной процесс как отдельный шаг. То же с монтажом и т. п. Часто бывает, что исполнение процесса на каком-то этапе прерывается.
Например, клиент не стал заключать с вами договор или не внес предоплату. Это печально. Но схема процесса все равно остается прежней. Хотя если такая ситуация повторяется слишком часто, наверное, нужно в нем что-то улучшить.
«Нормальный» – то есть такой, как он выполняется в большинстве случаев. Если однажды в качестве клиента к вам обращался король – наверное, вы обслуживали его иначе, чем других клиентов. Но это – исключение. Не нужно заносить его в процесс. Только в случае, если вы решили стать постоянным поставщиком двора Его Величества – тогда сделайте для этого отдельный бизнес-процесс.
«Линейный» – то есть вы отражаете все шаги процесса как последовательные, идущие цепочкой друг за другом. Даже если некоторые из них в жизни выполняются параллельно, если в алгоритме есть циклы и ветвления.
Как же так? Мне как бывшему специалисту по ИТ и по управлению проектами[138], тоже было трудно к этому привыкнуть. Однако практика показывает, что если в чем-то можно допустить ошибки (накосячить), сотрудники обязательно сделают это. Поэтому с некоторой долей условности любой алгоритм можно представить как последовательный. Нюансы раскроете на более глубоких уровнях детализации (при необходимости). А если вы действительно обнаружили несколько разных вариантов выполнения – может быть, и правда процессов здесь несколько? Иногда имеет смысл их разделить. Обсудим это чуть позже.
Сейчас ваша задача – согласовать в команде общую логику выполнения процесса, не углубляясь в детали.
• Смотрим на процесс с одной точки зрения – с колокольни РП, который отвечает за его выполнение[139]. Например, шаг, на котором вы получаете деньги от клиента, так и называется «Получение оплаты от клиента», а не «Оплата». Не вы платите, а он.
• Шаги называем отглагольными существительными. То есть производными от глаголов. Например, шаг называется не «Договор» и не «Заключить договор», а «Заключение договора».
Шаг – это всегда действие (поэтому не «Договор»). А почему существительное? Так благозвучнее получается.
• Описываем процесс «как есть» + ЗБР.
– Как есть – значит, как он выполняется на сегодняшний день. Если по-разному (у разных сотрудников, в разных филиалах, до получки и после) – определите, как чаще. И как лучше для бизнеса. Это и возьмите за основу.
– ЗБР – зона ближайшего развития[140]. То, что вы хотите внедрить в этом процессе в ближайшие 1–3 месяца (именно внедрить в работу). С одной стороны, не нужно ограничивать себя рамками того, как происходит сейчас. Ваша цель – улучшить работу компании. С другой – не сто́ит «улетать в космос». Так, в одной маленькой компании люди на сессии написали, что некий шаг будет выполнять маркетолог. А на наш удивленный вопрос ответили: «Ну ведь в приличной компании должен быть маркетолог!»
Оставайтесь в реальности.
Эволюция бизнеса, а не революция[141] приведет вас к успеху.
ЗДР, то есть зона дальнего развития, – это ваши идеи по поводу того, как можно улучшить этот процесс в более отдаленном будущем. Такие мысли полезно тоже записывать, сохранять и возвращаться к ним позже. Но не нужно заносить их в нынешнюю схему процесса, запутывая себя и коллег.
Часто встает вопрос: один перед нами процесс или несколько? Например, когда есть разные варианты его выполнения.
Понять это можно только на практике. Попробуйте выделить, к примеру, два разных процесса, назвать их, выписать цепочки шагов для каждого. Повесьте рядом на стену, спокойно посмотрите, сравните, обсудите.
Тогда и поймете: они и правда такие разные или нет. Если различия существенные (цели, шаги, ответственные и пр.) – разделяйте. Если нет – оставьте одним процессом, а тонкости раскроете при детализации. Напоминаю: мы описываем процесс как линейный, без развилок.
Как-то мы проводили сессию в группе из нескольких компаний, у которых один главный собственник и несколько младших партнеров. Руководители и сотрудники традиционно считали эти бизнесы сильно разными – компании даже находились в разных концах города. Однако после того, как их основные процессы описали на верхнем уровне и повесили рядом на стену, выяснилось, что они почти полностью совпадают. И неудивительно: компании работают на смежных рынках.
В итоге решили унифицировать процессы компаний, входящих в группу. Это сделало работу более простой и прозрачной, упростило управление.
Практическое задание 25Возьмите один из основных процессов своего бизнеса, которые выделили раньше. Лучше – самый крупный с точки зрения оборота и прибыли. С ним и будете дальше работать в этой книге.
Составьте список его шагов: 1, 2, 3…
Учтите все рекомендации этой главы. Поначалу это может показаться сложным. При регулярной практике скоро это становится привычным и естественным – как дышать.
9.3. Описываем процессы на верхнем уровне
Двигаемся дальше. Перечень шагов процесса – это хорошо, но все же полноценным описанием его назвать пока сложно. А вот по итогам этой главы вы сможете создать схему, которую реально внедрить. И которая принесет компании пользу.
Для этого нам понадобится некоторая методология, т. е. подход к описанию и улучшению. А также нотация, т. е. способ отображения процесса. Можно, конечно, описывать как попало, но до добра это не доведет. Мы часто встречаем в разных компаниях такие самопальные творения – памятники неудачным инициативам по улучшению бизнеса.
Для описания бизнес-процессов в мире разработаны десятки методологий, каждая из которых позволяет отобразить те или иные стороны работы компании. Это такие подходы, как ARIS, IDEF0 (SADT), IDEF3, DFD и многие другие (рис. 19). Однако, по нашему опыту, в большинстве случаев их применение неоправданно и даже вредно[142].
Рисунок 19. Пример схемы в формате SADT[143]. Как вам?..
Почему? Они логически очень правильные, но весьма сложны в изучении. То есть для того, чтобы начать ими грамотно пользоваться, надо сначала пройти курс длительностью до месяца. Причем понимают такие подходы далеко не все. Они близки аналитикам, программистам, инженерам, но сколько таких людей в обществе и в вашем бизнесе? Обычно меньшинство. А остальные от этого очень далеки.
Вот и получается, что хорошо владеют подобными методиками лишь специалисты-аналитики. Но! Экспертами в вашем бизнесе являетесь вы и ваша команда. А значит, эти схемы надо создавать именно вам. Тем более что вы же являетесь их потребителями. Иначе получаются модели, которые приносят мало пользы. Это как если бы должностные инструкции в вашей компании были написаны на китайском языке!
В одном из проектов меня пригласили в компанию, где до этого в течение нескольких месяцев штатный бизнес-аналитик занимался описанием процессов. Он часами сидел с руководителями подразделений, старательно выспрашивая их о нюансах работы. Результаты заносил в схемы стандарта IDEF0. Была создана громоздкая иерархия процессов. Как в кулуарах выразился один из топ-менеджеров: «И что толку? Время потрачено – а в реальной работе НИЧЕГО не изменилось».
Почему же тогда подобные методики применяются? Потому что это выгодно тем, кто их продвигает: проект получается долгий, а значит дорогой. Часто бесполезный, но кого это волнует? Деньги-то заплачены. Ну и мода сказывается.
Мы же применяем предельно простые средства, на первичное изучение которых уходит несколько часов. После чего команда клиента (от владельца до рядового сотрудника) активно работает с их помощью над реальными задачами своего бизнеса.
У вышеописанного клиента на сессии с нашей помощью команда просто и наглядно описала несколько ключевых процессов, смогла решить застарелые проблемы. В том числе – восстановить управление собственным большим кол-центром[144], который находился в другом городе. После того как несколько ключевых людей уволились, никто из оставшихся руководителей не знал, как с ним работать: знания ушли из компании вместе с прежними специалистами.
Ознакомительная версия.
