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

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

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

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

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

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

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

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

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

* * *

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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