Опишите бизнес-процесс по следам одной настоящей заявки

Бизнес-процесс без регламента проще всего описать по заявкам, которые уже закрыли. Возьмите две-три и восстановите их путь по следам. Следы — это почта, чаты, история в CRM или 1С, платёжки, файлы с датами. Запишите путь строками: кто передал заявку, кому, что именно, как получатель узнал, что пора, и сколько она ждала. Потом пройдите эти строки с каждым участником по отдельности и спросите, что бывает иначе. Исключения соберите отдельным списком. Готово описание тогда, когда человек, который этот процесс никогда не вёл, проводит по нему новую заявку.

Совещания с руководителем в этом списке нет. Оно понадобится позже.

У процесса три версии

Руководитель расскажет процесс таким, каким он его задумал: заявка, замер, проект, договор, производство. Пять квадратиков, две недели. Он не врёт. Просто исключения до него не доходят, а живёт процесс как раз в них.

Исполнители расскажут подробнее: «смету иногда согласуем три круга», «замерщик сам звонит клиенту». Это ближе к правде, но тоже рассказ. Люди говорят про обычный случай, а в обычном случае ничего не ломается.

Третья версия — то, что случилось с конкретной заявкой. Её никто не рассказывает, она лежит в следах. Именно её и надо описывать, сверяя со второй. Первая — это план на будущее, состояние «как должно быть». Если начать с неё, вы получите аккуратную схему того, чего нет.

Мысль не новая. В 1992 году в Harvard Business Review вышла статья «Staple Yourself to an Order» — «Прикрепите себя к заказу». Руководителям в ней предлагали пройти вместе с одним заказом весь его путь по компании. Я писал о том же в эссе «AI не исправит плохой процесс». Перед автоматизацией я прошу нарисовать процесс так, как он идёт на самом деле. Половина проблемы обычно решается прямо на этом листе.

Как описать бизнес-процесс по одной заявке: шаги

1. Назовите процесс через начало и конец: «от заявки с сайта до запуска в цех». На входе событие, на выходе результат, который можно увидеть. Без границ описание расползается на всю компанию.
2. Выберите две-три недавно закрытые заявки: одну обычную и одну, с которой были проблемы. Самую показательную не берите — она нетипичная.
3. Соберите следы: письма, сообщения в чатах, историю изменений в CRM или 1С, платёжки, файлы. По ним восстановите путь и поставьте у каждого шага дату и время.
4. Запишите путь строками. Новая строка начинается каждый раз, когда заявка переходит к другому человеку.
5. Пройдите с каждым участником его кусок. По одному, без начальства в комнате. Покажите строки и спросите: всегда так? а когда было иначе?
6. Исключения запишите отдельным списком: что случилось, что делают, кто решает.
7. Отдайте описание человеку, который этот процесс не вёл, и пусть проведёт по нему следующую настоящую заявку.

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

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

Пример описания бизнес-процесса: кухня на заказ

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

Понедельник, 11:20. Заявка с сайта пришла на общую почту. Почту разбирают утром, поэтому менеджер перезвонил во вторник в 10:05. Разговор на пятнадцать минут.

Вторник. Менеджер написал в общий чат: «есть замер». Замерщик сам созвонился с клиентом и поехал в пятницу. Замер — полтора часа.

Пятница. Замерщик сфотографировал эскиз и отправил конструктору в личные сообщения. Конструктор был занят другим заказом и открыл фото в следующую среду. Менеджер всё это время не знал, где заявка: в его системе после замера ничего не происходило.

Среда. Проект и смета — три часа работы. Клиент попросил другие фасады, правка заняла сорок минут. В пятницу подписали договор, на это ушло полчаса.

Понедельник. Клиент внёс предоплату, бухгалтер её увидел. Цех узнал во вторник, когда менеджер спросил, запустили ли заказ.

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

И ни один человек в этой истории не работал плохо. Каждый свою часть сделал нормально и в срок, как он его понимал.

Без меток времени этого не видно: на схеме все шаги выглядят одинаково важными. А по доле работы мастерская вполне типична. Майкл Джордж в книге «Lean Six Sigma» (2002) приводит типичную долю работы во всём времени процесса: для офисных процессов — 10%, для творческих — 5%. Если процесс доводили до ума методами бережливого производства, доля поднимается выше 25%. У мастерской из примера выходит меньше 7%.

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

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

Записывайте передачи между людьми

Обычное описание процесса — список действий: принять заявку, выполнить замер, подготовить смету. В примере все действия выполнены. Сломалось то, что между ними.

У этого места есть старое имя. Гири Раммлер и Алан Брейч в 1990 году выпустили книгу «Improving Performance» с подзаголовком «Как управлять белым пространством на оргструктуре». Как объясняет Алан Рамиас, позже писавший с Раммлером продолжение этой книги, белое пространство — это любое место, где работа переходит от одной роли к другой. Оно ничьё, поэтому им никто не управляет. Там и случаются недопонимания, ошибки и задержки.

Для каждой передачи заведите шесть колонок:

• кто отдаёт;
• кому;
• что именно: файл, фото, сумму, договорённость с клиентом;
• как получатель узнаёт, что пора;
• где лежит заявка, пока ждёт;
• сколько она обычно ждёт.

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

Исключения: где на самом деле живёт процесс

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

Про исключения не спрашивают «а что бывает иначе?» — на это отвечают «да всё обычно нормально». Спрашивают про конкретный случай: «Когда последний раз всё пошло не так? Что вы сделали? Кому позвонили?» Вторая заявка из второго шага, та, что с проблемами, нужна как раз для этого разговора.

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

Отдельно отметьте ответы вида «это знает только Ирина». Если на половину исключений ответ один и тот же, процесс держится на одном человеке. Описание это не лечит, но хотя бы показывает. До первого отпуска Ирины.

Таблица, схема или BPMN: в чём описывать процесс

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

Схему с дорожками, как в примере, рисуют, когда таблица готова: показать её людям на одном листе и найти глазами, где заявка ждёт дольше всего.

BPMN, нотация для схем бизнес-процессов, нужна позже. Например, когда процесс собираются автоматизировать: в n8n, Make или кодом переносить удобнее со схемы, где ветки и события уже записаны строго. Действующая версия нотации, 2.0.2, вышла в 2014 году, и значков в ней много. На практике нужна малая часть. Михаэль зур Мюлен и Ян Рекер разобрали 120 BPMN-схем: в среднем в каждой девять разных значков, а регулярно используется меньше 20% нотации.

С CRM так же. Процесс, описанный по следам, сразу показывает, какие этапы должны быть в воронке продаж и чего ждать от CRM. Внедрять систему до описания — значит перенести общую почту и личку в новый интерфейс.

Проверка новичком

Описание не готово, когда его согласовали. Согласовать можно что угодно, особенно если читать по диагонали.

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

Каждая его остановка — дыра в описании. Каждый звонок «а что дальше?» — строка, которую вы не записали.

Обычно звонят Ирине.