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

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

Составьте список его шагов: 1, 2, 3…

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

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

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

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

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

Рисунок 19. Пример схемы в формате SADT[146 - Пример из книги D. Marca, C. McGowan. Structured Analysis and Design Technique, McGraw-Hill, 1987.]. Как вам?..

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

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

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

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

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

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

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

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

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

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

* * *

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Архитекторы компании – это ее управленческая команда. Это руководители подразделений и ведущие специалисты[150 - См. разд. III «Улучшаем процессы и внедряем в жизнь».].

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