Описание бизнес-процессов: как сделать, чтобы им пользовались

Компания заказывает описание бизнес-процессов. Через два месяца приносят сорок схем в красивой нотации. Ещё через полгода выясняется, что реальная работа идёт иначе: часть шагов отмерла, часть появилась, а схемы никто не обновлял, потому что для этого нужен тот самый аналитик, которого уже нет.

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

Зачем вообще описывать

Полезно сразу отделить настоящие причины от ритуальных. Описание бизнес-процессов имеет смысл в четырёх случаях:

• Сроки срываются, и непонятно где. Заказ идёт две недели вместо трёх дней, каждый отдел говорит, что у него всё быстро.
• Компания растёт и теряет управляемость. То, что держалось на пяти людях, знающих всё, ломается на двадцати.
• Люди меняются. Уход одного человека останавливает направление, потому что знание было только у него.
• Готовитесь автоматизировать. Автоматизировать можно только описанное — иначе вы зафиксируете хаос в системе.

Ритуальная причина одна: «в нормальных компаниях процессы описаны». Это плохая мотивация, и проекты с такой мотивацией дают папку схем.

С чего начинать

Не с отделов, а со сквозного пути. Возьмите два маршрута, которые проходят через всю компанию:

1. Путь заказа — от обращения клиента до денег на счёте.
2. Путь продукта — от закупки или производства до отгрузки.

Эти два маршрута дают 80% всех потерь. Внутренние процессы отделов — бухгалтерию, кадры, ИТ — описывают позже и только если там реально болит.

Как описывать: рабочая форма

Схема в нотации красива и почти никем не читается. Для среднего бизнеса достаточно таблицы.

Последняя колонка — самая ценная и та, которой нет в стандартных описаниях. Она показывает не сколько шаг длится, а сколько он ждёт. Обычно выясняется, что чистое время работы над заказом — четыре часа, а проходит он две недели.

В примере выше видно типичную находку: согласование скидки занимает пять минут работы и до трёх дней ожидания. Дальше вопрос простой — почему это вообще согласовывается вручную и нельзя ли задать границу, внутри которой менеджер решает сам. Это уже про делегирование полномочий, и такие находки — основная польза от описания.

Кто описывает

Правило, которое определяет судьбу проекта: описывает тот, кто работает по процессу. Роль внешнего человека — модератор, а не автор.

Формат, который работает: собрать за столом всех участников одного сквозного пути — от менеджера до кладовщика — и пройти маршрут вместе, шаг за шагом. Занимает два-три часа на один процесс.

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

До какого уровня детализации

Главный источник мёртвых описаний — избыточная подробность. Ориентир: один процесс — одна страница, не больше пятнадцати шагов.

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

Проверка достаточности простая: новый сотрудник, прочитав описание, должен понять последовательность и своё место в ней. Научиться делать работу по нему он не должен — для этого есть регламент и наставник.

Почему описания умирают

• Нет владельца процесса. У документа должен быть человек, отвечающий за его актуальность. Без него описание устаревает за квартал.
• Описали идеальную версию. Люди рассказывают, как должно быть, а не как есть. Обходные пути, которыми реально пользуются, в схему не попадают — и схема расходится с жизнью с первого дня.
• Слишком сложная форма. Если для правки нужен специальный редактор и знание нотации, правок не будет.
• Описание ради описания. Проект без конкретной боли заканчивается сдачей документа, а не изменениями.
• Не пересматривают. Раз в полгода пройтись по ключевым процессам — минимальная гигиена.

Что делать сразу после

Описание — это не результат, а материал. Результат появляется на следующем шаге, когда по каждому процессу задают три вопроса.

Первый: где заказ ждёт дольше всего и почему. Второй: какие шаги можно убрать без потери качества — обычно это согласования, которые за год ни разу ничего не изменили. Третий: что здесь делается дважды или вручную там, где можно иначе. Отдельно об этом — в разборе автоматизация бизнес-процессов.

Ответы на эти три вопроса дают список изменений. Вот он и есть то, ради чего затевалась работа, — а не папка со схемами.