Книга: Бизнес-процессы. Как их описать, отладить и внедрить. Практикум

9.3. Описываем процессы на верхнем уровне

Двигаемся дальше. Перечень шагов процесса – это хорошо, но все же полноценным описанием его назвать пока сложно. А вот по итогам этой главы вы сможете создать схему, которую реально внедрить. И которая принесет компании пользу.

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

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

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

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

Вот и получается, что хорошо владеют подобными методиками лишь специалисты-аналитики. Но! Экспертами в вашем бизнесе являетесь вы и ваша команда. А значит, эти схемы надо создавать именно вам. Тем более что вы же являетесь их потребителями. Иначе получаются модели, которые приносят мало пользы. Это как если бы должностные инструкции в вашей компании были написаны на китайском языке!

В одном из проектов меня пригласили в компанию, где до этого в течение нескольких месяцев штатный бизнес-аналитик занимался описанием процессов. Он часами сидел с руководителями подразделений, старательно выспрашивая их о нюансах работы. Результаты заносил в схемы стандарта IDEF0. Была создана громоздкая иерархия процессов. Как в кулуарах выразился один из топ-менеджеров: «И что толку? Время потрачено – а в реальной работе НИЧЕГО не изменилось».

Почему же тогда подобные методики применяются? Потому что это выгодно тем, кто их продвигает: проект получается долгий, а значит дорогой. Часто бесполезный, но кого это волнует? Деньги-то заплачены. Ну и мода сказывается.

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

У вышеописанного клиента на сессии с нашей помощью команда просто и наглядно описала несколько ключевых процессов, смогла решить застарелые проблемы. В том числе – восстановить управление собственным большим кол-центром[144], который находился в другом городе. После того как несколько ключевых людей уволились, никто из оставшихся руководителей не знал, как с ним работать: знания ушли из компании вместе с прежними специалистами.

У другого клиента – российской «дочки» международной консалтинговой (!) компании в области HR[145] – ушел год на то, чтобы собрать на сессию учредителей, руководителей и ключевых сотрудников. В том числе из-за границы. А потом за три дня они с нашей поддержкой разгребли годами копившийся бардак в основных процессах.

И ведь сами грамотные! Но вот уж правда: нет пророка в своем отечестве…

Хорошая методика – как качественная обувь. Не жмет, не натирает – ее не замечаешь. Через некоторое время пользоваться ею становится так же естественно, как дышать.

По сути, способ описания процессов – это новый способ мышления, язык, на котором удобно думать и общаться в команде.

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

В описании процесса – две основные части (рис. 20):

Шапка, где задают его основные параметры.

Тело, в котором описывают его шаги.

9.3.1. Шапка процесса

В шапке обычно указывают:

• Название процесса.

• Цель процесса.

• Архитектора процесса.

• Руководителя процесса.

• Показатели процесса.

Рисунок 20. Шапка и тело процесса

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

Например, «Обслуживание клиента в ресторане от встречи до проводов».

Возможно, вы добавите в название его первый и последний шаги после того, как опишете тело. Тогда границы процесса станут для вас более понятными.

Цель процесса должны одинаково понимать все, кто им управляет и в нем работает, а также смежники. Ну и, конечно, высшие руководители компании. Чем четче она сформулирована, тем более слаженно будут работать люди.

Архитектор процесса (АП) отвечает за то, чтобы схема (модель) процесса, по которой он многократно исполняется во всей компании, была эффективной. Архитектор отвечает не за выполнение процесса. А за его качественное проектирование и дальнейшее улучшение.

АП – это не должность, а роль. Здесь указывают должность сотрудника, который ее выполняет.

Но, конечно, не ФИО[146] конкретного человека. Ведь он может смениться, и это не должно повлиять на бизнес-процесс.

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

Помните, в главе 5 «Роли в бизнесе» я спросил вас: кому в бизнесе быть архитектором? Так вот,

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

Станислав Фокин. Собрать всех, кого касается БП, выслушать мнение каждого, обсудить ситуацию, поспорить и главное – договориться.

Конечно, модели процессов (и не только) утверждает высшее руководство компании.

Тут у вас может возникнуть сомнение: если АП и его рабочая группа только проектируют процесс, но не отвечают за его выполнение – не получится ли так, что они будут витать в облаках, придумывать схемы, далекие от жизни?

Нет, не получится. Потому что эти люди – кто?

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

Если же архитектурой процесса никто не занимается, он всё равно выполняется, но как попало. Растет как сорняк под забором. Нет четкой, согласованной схемы. Порой кто-то из руководителей и работников «вытягивает» его исполнение на своем энтузиазме. Но тут уж как повезет…

Г. Эмерсон (1911 год): «Выяснить действительную, фактическую практику работы предприятия – это дело трудное и требующее много времени, ибо разные работники, начиная с самого председателя правления, могут иметь самые разные взгляды и теории, тогда как подлинная практика, не считаясь с этими взглядами, постоянно меняется месяц от месяца.

Очень часто бывает, что директор-распорядитель или председатель правления совершенно не знает, как фактически ведется работа на управляемом им предприятии. Люди ведь делают не то, что им говорят, а то, что они могут сделать. Наша цель должна быть не в том, чтобы выяснить, что считается практикой предприятия, а в том, чтобы выяснить, какова эта практика на деле.

Добившись этой цели, надо согласовать все противоречия, выбросить все лишнее и пополнить все то, что останется, необходимым добавлением»[148].

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

Таким образом, АП – «законодательная власть», а РП – «исполнительная»[149].

РП – тоже роль. Она соответствует роли «Оперативный управляющий», которую мы с вами разбирали[150]. Здесь, как и в случае с архитектором, также указывают должность, на которой работают те, кто будет играть эту роль.

В компании могут одновременно выполняться сотни экземпляров[151] (штук) одного и того же процесса. Например, в работе находятся множество заказов клиентов, выполняемых согласно данному бизнес-процессу. Или идет подбор кандидатов на разные должности.

Так вот – у каждого экземпляра процесса должен быть руководитель.

Чтобы был ответственный. Чтобы было с кого спросить.

Как говорится, «если два солдата идут за дровами, один из них должен быть главным».

РП – очень важная роль. Ключевая в процессном подходе к управлению.

Если его нет, то часто получается как у Аркадия Райкина: «К пуговицам претензии есть? – Нет! Пришиты насмерть, не оторвёшь!»[152] То есть каждый участник процесса свою работу сделал неплохо. А вот костюмчик-то – кривой вышел.

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

Но кто же будет думать о процессе в целом? О том, чтобы он выполнялся правильно, в срок и качественно. Чтобы достигал своих целей и плановых показателей. Чтобы клиент процесса[154] получил то, что ему нужно, и остался доволен.

Вот для этого и нужен РП.

Но если экземпляров процесса – много (и разных процессов тоже), значит ли это, что вам теперь нужно нанять в компанию новых людей? Во многих случаях – нет.

Во-первых, РП – это роль. И на нее обычно определяют кого-то из действующих сотрудников.

Во-вторых, один человек может быть РП во многих экземплярах процесса. Если это разумно и реально, если процесс позволяет.

Кого назначать на роль руководителя процесса – важный вопрос, в каждом случае нужно тщательно его продумывать[155].

Показатели процесса нужны, чтобы управлять им на основе числовых данных и их анализа, а не по принципу «пол-палец-потолок».

Я очень уважаю интуицию, «чуйку», сам активно ее применяю в жизни[156]. Но хорошо, если в качестве входных данных вы дадите ей достоверную информацию – результаты будут лучше. Ну и логический анализ – тоже дело полезное. Я за дружбу логики и интуиции!

Детально мы обсудим показатели в главе 11 «Определяем показатели процессов».

Хочу подробнее остановиться на названиях ролей, связанных с бизнес-процессом. В том числе – термине «руководитель процесса». В своей первой книге[157] я использовал выражение «менеджер процесса». С моей подачи его стали активно применять руководители во многих компаниях.

Однако сейчас я хочу внести изменение в терминологию. Слово «менеджер» в современном русском деловом языке прочно ассоциируется у людей с «менеджером по продажам» (странное название продавца, родившееся в первые годы постсоветской рыночной экономики). Хотя процессом далеко не всегда руководит продажник.

Само слово «менеджер» – это английский аналог нашего понятия «руководитель».

К тому же лучше использовать слова из родного языка: для нас они сильнее, чем иностранные[158].

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

Итак, отныне терминов всего два:

«Архитектор процесса» (АП).

«Руководитель процесса» (РП).

Все четко и просто.

Тем, кто работает по моей прошлой книге, статьям и вебинарам, рекомендую перейти на новую терминологию. Пора делать upgrade[159].

9.3.2. Тело процесса

Здесь мы описываем шаги. Основываемся на том списке шагов, который сделали на прошлом этапе[160]. Хотя сейчас мы можем его уточнить.

Рекомендую использовать следующую таблицу (рис. 21):

Рисунок 21. Описание шагов бизнес-процесса

С номером шага и его названием – все понятно. Называем шаги по тем правилам, которые мы с вами уже обсудили.

Результаты шага – ради них он выполняется. Они могут быть:

• Информационными, то есть показывать, какая информация должна появиться или измениться по итогам данного шага. Например, утверждено техническое задание, документ такой-то создан или проведен в 1С.

• Материальными. Что изменилось в материальном мире. Например, товар перемещен со склада в торговый зал. Или дверь смонтирована у клиента.

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

Информационные результаты могут быть в электронной или бумажной форме.

Главное – не только в устной. Есть такое золотое правило: «Каждый шаг должен оставлять след». Чтобы не было потом отмазок: «Так ведь я же ему говорил! Это он забыл сделать». Ну прям детский сад.

Результаты шага должны быть проверяемыми: товарно-транспортная накладная заполнена, акт подписан и т. п.

Хорошо, конечно, когда по итогам выполнения шага клиент доволен. Но для четкого бизнес-процесса такой результат слишком эфемерный, его сложно потрогать. Если хотите указать удовлетворенность клиентов как один из результатов шага, то оценивайте ее по понятной, четкой методике[161] и заносите результаты в бланк или в компьютер.

Для чего сохранять информацию? Ведь это дополнительные затраты времени и сил, бюрократия. Чтобы позже вы могли проследить ход выполнения работы на основе записей. У вас будут достоверные фактические данные. Вы сможете накапливать статистику, анализировать ее, принимать обоснованные управленческие решения.

При этом чем меньше времени будет занимать сохранение информации, тем лучше. Система должна быть простой и удобной!

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

Если же результатов шага слишком много (например, больше пяти) и шаг становится перегруженным, сложным для восприятия – укрупните результаты, подберите обобщающие формулировки (например, пакет закрывающих договор документов, подписанный нами и клиентом). А детально распишете, если будете раскрывать этот шаг глубже.

Главный принцип описания процесса на верхнем уровне: учесть все принципиально важное. Но при этом не закопаться слишком глубоко.

Часто бывает так, что какого-то информационного результата, нужного по логике, у вас в компании пока нет. Например, секретарь принимает входящий звонок, но нигде его не фиксирует – устно передает информацию другим работникам. Это бардак – информация часто теряется, невозможно провести анализ входящих обращений клиентов, рассчитать эффективность маркетинговых мероприятий (в которые вы вкладываете серьезные ресурсы) и т. д.

Что делать? Заведите новый документ: бумажный или электронный, для начала лучше бумажный[162]. В данном случае – Журнал регистрации входящих звонков. Пусть секретарь заносит туда каждый звонок: кто звонил, когда, суть вопроса, контактные данные, откуда звонивший узнал про вашу компанию. Это будет один из ЗБР для данного процесса.

Когда в следующий раз будете в McDonald’s или на заправке, входящей в крупную сеть, зайдите в туалет, в районе двери осмотритесь. Обратите внимание, какой информационный результат есть у одного из шагов их бизнес-процесса «Уборка помещений».

Ответственный за шаг – это тот, с кого РП может спросить за результаты шага, качество, сроки и т. п. Ответственный всегда должен быть один и только один. Иначе это бардак.

Хорошо, если ответственный – из числа исполнителей шага. И дюже плохо, если это большой босс[163].

Исполнители шага – это те, кто участвует в его выполнении. Если их несколько, перечислите. Если получается много – обобщите до категорий. Например, рабочие цеха покраски (даже если они имеют разные должности).

В колонках «Ответственный за шаг» и «Исполнители шага» указывайте конкретные должности. Но не отделы – с них не спросишь! Уходим от невнятного «мы»: «мы забыли», «мы потеряли», «мы профукали». К четкому и однозначному «я» – сделал, получил результат, передал смежнику.

Также не стоит писать ФИО конкретных работников.

Если среди исполнителей – внешний подрядчик, обязательно должен быть кто-то с вашей стороны, кто отвечает за взаимодействие с ним.

Одним из исполнителей бывает даже внешний клиент – к примеру, он утверждает техническое задание.

Но вот быть ответственным за шаг подрядчик и внешний клиент быть не могут.

Бывает, что среди исполнителей – большой руководитель. Например, генеральный директор, который подписывает договор.Записывайте всё так, как есть в жизни. Потом, если захотите, сможете улучшить процесс: директор делегирует право подписи на договорах кому-то из своих подчиненных.

Кстати, бывает, что руководит процессом или отвечает за конкретный его шаг рядовой по должности сотрудник. А руководитель подразделения или компании в целом – среди исполнителей этого шага. Допустим, продавец ведет сделку с клиентом от начала и до конца, он – руководитель процесса привлечения клиента. А директор компании или коммерческий директор – в числе исполнителей на шаге «Заключение договора», как в вышеописанном примере с подписанием договора. Это нормально – значит, в компании действуют элементы матричной структуры[164]. Хотя, возможно, пока и неосознанно.

Как вы понимаете, Ответственный за шаг и его Исполнители – это роли, а не должности.

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

Но не злоупотребляйте этим полем, не используйте его как помойку для слива всего того, чему не смогли найти места в других колонках. Мыслите четче, договаривайтесь – и вам воздастся.

При правильном подходе поле «Комментарии» зачастую остается пустым.

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

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

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

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

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

Кстати, кто становится руководителем такого подпроцесса? Тот, кто является ответственным за него, когда он описан как шаг в схеме верхнего уровня.

Иногда есть смысл использовать «матрешки» и на следующем – третьем уровне детализации. Хотя часто это или вообще не нужно, или тут используются другие инструменты[167].

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

Оглавление книги