Карта процессов — это описание того, как задача проходит через компанию: какие шаги, кто их делает, в каких системах и что происходит, когда что-то идёт не так. Форматов ровно три, и они не конкурируют между собой: таблица на шесть колонок, блок-схема на одном листе и схема в нотации BPMN. Разница между ними не в качестве, а в том, что каждый следующий формат показывает то, чего предыдущий физически не может.
Ошибка, которая стоит дороже всего, — выбрать формат из соображений солидности. Компания на сорок человек заказывает описание всех процессов в BPMN, получает сто тридцать листов, кладёт их в папку и больше туда не заглядывает. Обратная ошибка дешевле, но тоже стоит денег: подрядчику отдают таблицу по процессу с тремя развилками, он не видит ветвления и даёт вилку оценки вдвое шире нужной.
Ниже — один и тот же процесс приёма заявки в трёх форматах, минимальный словарь BPMN, критерий выбора и расчёт часов. Модельный пример прежний: оптовая компания на 90 человек, 480 заявок в месяц, реестр из 26 процессов, собранный при аудите своими силами.
Таблица из шести колонок: минимальный рабочий формат
Таблица — это не «упрощённое описание», а полноценный формат со своей областью применения. Шесть колонок подобраны так, чтобы по заполненной строке можно было и посчитать деньги, и увидеть, где процесс ломается: шаг, что его запускает, кто делает, в какой системе, сколько занимает, где отказывает.
| Шаг | Что запускает | Кто делает | Система | Время | Точка отказа |
|---|---|---|---|---|---|
| Регистрация заявки | Письмо, звонок или сообщение в мессенджере | Менеджер | Почта, CRM | 2 мин | Заявка из мессенджера в CRM не попадает вовсе |
| Проверка клиента и условий | Заявка зарегистрирована | Менеджер | CRM, 1С:УТ | 4 мин | У нового клиента нет карточки и реквизитов |
| Проверка остатка и срока | Состав заявки известен | Менеджер | 1С:УТ | 5 мин | Остатка нет, нужен ответ отдела закупок |
| Согласование цены и отсрочки | Условия выходят за типовые | Руководитель отдела | Мессенджер, устно | 6 мин | Решение нигде не фиксируется, через месяц о нём спорят |
| Оформление заказа и счёта | Условия подтверждены | Менеджер | 1С:УТ | 8 мин | Реквизиты переносятся руками, отсюда опечатки |
| Отправка счёта клиенту | Счёт проведён | Менеджер | Почта | 2 мин | Факт отправки не отмечается, клиенту звонят повторно |
| Резерв и передача на склад | Счёт отправлен | Менеджер | 1С:УТ | 4 мин | Резерв ставят не всегда, товар уходит другому клиенту |
Семь строк, 31 минута чистой работы. Этого достаточно, чтобы посчитать цену процесса: 480 заявок в месяц × 31 минуту × полную ставку 780 ₽ в час даёт 193 440 ₽ прямых трудозатрат. Методику самого замера — журнал, выборка, калибровка — мы разбирали в статье о том, как измерить процесс до внедрения; таблица здесь нужна для того, чтобы было куда положить измеренное.
Колонка «точка отказа» — самая ценная и самая часто пропускаемая. Без неё таблица описывает работу, но не описывает проблему, а подрядчик оценивает по проблемам. Правило заполнения: в каждой строке должна быть хотя бы одна точка отказа или явная пометка «отказов нет». Пустая ячейка означает «не выясняли», а не «всё в порядке».
Второе правило — про масштаб строки. Одна строка соответствует одному действию одного человека без переключения между задачами; обычно это от одной до десяти минут. Строка на сорок минут почти наверняка склеила три разных шага и спрятала внутри себя ожидание или согласование, а строка на полминуты — лишняя детализация, которая раздувает таблицу и ничего не добавляет к смете. Практический ориентир: у сквозного процесса нормальная таблица укладывается в 6–12 строк. Если строк тридцать, вы описываете не процесс, а инструкцию для нового сотрудника, и это другой документ с другой судьбой.
Чего таблица не покажет никогда
У строк есть жёсткое ограничение: они идут сверху вниз одна за другой. Всё, что не укладывается в последовательность, таблицей не выражается. Таких вещей три, и каждая встречается в обычном процессе небольшой компании.
- Развилки. «Если клиент постоянный — сразу счёт, если новый — сначала запрос документов и проверка» — это две разные ветки, а не два соседних шага. В таблице их приходится писать в одну колонку словами, и читатель сам достраивает логику, обычно неверно.
- Параллельные ветки. Резерв на складе и отправка счёта клиенту идут одновременно и не ждут друг друга. В таблице они стоят одна под другой, из чего читающий делает вывод, что резерв ставится после отправки, — и в системе это потом реализуется именно так, с ошибкой.
- Ожидание внешнего события. Процесс останавливается и ждёт: оплаты, ответа закупок, подтверждения клиента. В строках ожидание выглядит как ещё один шаг с длительностью, хотя его природа другая — никто над задачей не работает. В модельном процессе чистой работы 31 минута, а ожидания — 2 часа 10 минут, то есть задача проводит в очереди большую часть жизни. Спутать труд с ожиданием — значит пообещать сокращение срока там, где снимается только ручной ввод.
Переделка — это возврат на предыдущий шаг, а строки назад не ходят. В модельном примере 11 % заявок возвращаются на исправление, и разбор одного возврата занимает 18 минут; в месяц это 15,8 часа и 12 324 ₽ сверх прямых трудозатрат. В таблице петля выражается только припиской, которую легко не заметить при оценке. Как только доля переделок больше нескольких процентов, процесс нужно рисовать, а не расписывать.
Блок-схема: когда нужен лист, а не строки
Простая блок-схема — это те же шаги, но выложенные на плоскость: прямоугольники, стрелки и ромбы развилок. Никакой нотации соблюдать не требуется, достаточно трёх договорённостей внутри компании: действие — прямоугольник, вопрос с ответом «да/нет» — ромб, начало и конец — овалы. Такую схему рисуют на листе А3 или в любом редакторе, и её читает без обучения любой сотрудник.
Что появляется по сравнению с таблицей: видны обе ветки развилки «постоянный клиент — новый клиент», видна петля возврата на переделку, видно, что процесс имеет два разных конца — «счёт отправлен» и «заявка отклонена». Последнее особенно полезно: процессы почти всегда заканчиваются несколькими способами, а в таблице конец один по определению.
Простая блок-схема сверху вниз. Овал «Заявка поступила» → прямоугольник «Регистрация, 2 мин» → ромб «Клиент постоянный?» с двумя ветками: «нет» уводит в прямоугольник «Запрос документов и создание карточки», ветка возвращается в основную линию; «да» идёт прямо. Далее прямоугольник «Проверка остатка, 5 мин» → ромб «Условия типовые?»: ветка «нет» уходит в прямоугольник «Согласование у руководителя, 6 мин» и возвращается, ветка «да» идёт прямо → «Оформление заказа и счёта, 8 мин» → «Отправка счёта, 2 мин» → «Резерв и передача на склад, 4 мин» → овал «Счёт отправлен». Сбоку штриховая стрелка-петля от «Отправка счёта» назад к «Оформление заказа» с подписью «переделка, 11 % заявок». От ромба «Условия типовые?» вниз-вбок второй овал «Заявка отклонена». В углу подпись «чистая работа 31 минута». Чертёжный стиль, всё по-русски.
Ограничение блок-схемы одно, зато существенное: на ней не видно, кто именно делает каждый шаг. Пока исполнитель один, это не мешает. Как только в процессе появляются менеджер, руководитель отдела, склад и клиент, схема перестаёт отвечать на главный вопрос сметы — сколько раз задача переходит из рук в руки. А переходы стоят дороже шагов: именно на них теряются заявки и накапливается ожидание.
BPMN и словарь из семи элементов
Общепринятая нотация описания процессов: набор фигур с фиксированным значением, одинаковым для всех. Смысл её не в красоте, а в однозначности — схему, нарисованную по правилам, любой аналитик прочитает одинаково, без сопроводительного письма и созвона. В полной спецификации больше сотни элементов, но для процессов небольшой компании достаточно семи.
| Элемент | Как выглядит | Что означает | Когда без него нельзя обойтись |
|---|---|---|---|
| Дорожка | Горизонтальная полоса с именем роли | Все задачи внутри полосы делает эта роль | Как только исполнителей больше одного |
| Стартовое событие | Тонкий круг | С чего процесс начинается | Всегда. Процесс, у которого не находится старта, — сам по себе находка |
| Задача | Прямоугольник со скруглёнными углами | Одно действие одного исполнителя | Всегда |
| Исключающий шлюз | Ромб с крестом | Дальше идёт ровно одна из веток | Есть условие «если… то…» |
| Параллельный шлюз | Ромб с плюсом | Обе ветки идут одновременно и потом сходятся | Два действия не ждут друг друга |
| Промежуточное событие | Двойной круг с конвертом или часами | Процесс ждёт сообщения извне или наступления срока | Есть ожидание оплаты, ответа, подтверждения |
| Конечное событие | Круг с жирной обводкой | Один из вариантов окончания процесса | Всегда, и обычно их больше одного |
Стрелок в этом списке нет намеренно: поток — не элемент словаря, а грамматика, они просто соединяют фигуры в порядке выполнения. Этих семи фигур хватает примерно на девять из десяти процессов обычной небольшой компании — на все, где задача идёт по маршруту, ветвится, иногда ждёт и заканчивается одним из нескольких способов. Всё остальное богатство нотации — подпроцессы, компенсации, сигналы, границы событий на задачах — нужно там, где схема исполняется движком, а не читается человеком. Требовать их от описания процесса приёма заявки в компании на девяносто человек не за что.
Схема BPMN слева направо с двумя горизонтальными дорожками. Верхняя дорожка подписана «Менеджер», нижняя — «Руководитель отдела»; сверху отдельной узкой полосой чёрный ящик «Клиент». В верхней дорожке: тонкий круг «Заявка поступила» → задача «Регистрация» → ромб с крестом «Клиент постоянный?» с веткой «нет» в задачу «Запрос документов» → задача «Проверка остатка» → ромб с крестом «Условия типовые?». Ветка «нет» уходит стрелкой в нижнюю дорожку, в задачу «Согласование цены и отсрочки», и возвращается обратно. Далее задача «Оформление заказа и счёта» → ромб с плюсом, из него две параллельные ветки: «Отправка счёта клиенту» и «Резерв и передача на склад», которые сходятся во втором ромбе с плюсом. После него двойной круг с часами «Ждём оплату, 3 рабочих дня» и два круга с жирной обводкой: «Оплата получена» и «Счёт аннулирован». Сбоку легенда из семи подписанных фигур. Чертёжный стиль, всё по-русски.
Проверить собственную схему можно за десять минут тремя вопросами, не привлекая аналитика. Первый: у каждого ромба есть подпись-вопрос и у каждой выходящей стрелки — подпись-ответ? Ромб без подписей читается по-разному и обесценивает всю схему. Второй: каждая задача названа глаголом с существительным — «оформить счёт», а не «счёт» и не «работа с документами»? Существительное на месте задачи почти всегда прячет подпроцесс. Третий: от каждого конечного события можно проследить путь назад к стартовому, не упираясь в тупик? Висящие ветки — самый частый дефект схем, нарисованных за один присест.
Разница с блок-схемой измерима. На схеме BPMN сразу видно, что задача трижды переходит между дорожками — от менеджера к руководителю и обратно, — и что после отправки счёта процесс не заканчивается, а стоит и ждёт оплаты до трёх рабочих дней. Именно эти два факта определяют состав будущей системы: нужен маршрут согласования и нужен таймер с напоминанием. По таблице ни того, ни другого не видно, и в смете они не появятся.
Как выбрать формат: кто читает и что делает дальше
Критерий один и он не про размер компании. Спросите себя, кто возьмёт эту схему в руки и какое действие совершит после. Формат — это минимальный уровень детализации, достаточный для этого действия; всё сверх него оплачивается вашими часами и не окупается.
| Кто читает | Что он с ней делает | Достаточный формат | Часов на один процесс |
|---|---|---|---|
| Вы и руководитель отдела | Сравнивают процессы между собой, выбирают кандидатов | Таблица на шесть колонок | 0,7–1,0 |
| Команда и смежный отдел | Договариваются о порядке работы, фиксируют изменение | Блок-схема на листе | 1,5–2,0 |
| Подрядчик или аналитик | Даёт оценку срока и цены, пишет техническое задание | BPMN, 7 элементов | 4,0–6,0 |
| Аудитор, сертифицирующий орган | Проверяет соответствие требованию или стандарту | BPMN плюс текстовый регламент | 6,0–10,0 |
Из таблицы следует практический порядок работы: описывать сверху вниз и сужать. Все процессы реестра — таблицей, финалистов рейтинга — блок-схемой, и только те один-два, по которым вы собираетесь получать коммерческое предложение, — в BPMN. Обратный порядок, когда с BPMN начинают, съедает бюджет описания на процессах, которые в работу всё равно не пойдут.
Таблица-сравнение из трёх колонок с заголовками «Таблица, 6 колонок», «Блок-схема», «BPMN». Строки слева: «Шаги и время» — галочка во всех трёх; «Точки отказа» — галочка во всех трёх; «Развилки» — прочерк, галочка, галочка; «Петли переделки» — прочерк, галочка, галочка; «Кто делает шаг» — галочка, прочерк, галочка; «Параллельные ветки» — прочерк, прочерк, галочка; «Ожидание внешнего события» — прочерк, прочерк, галочка; «Часов на один процесс» — «0,7–1,0», «1,5–2,0», «4,0–6,0»; «Кто читатель» — «вы и руководитель», «команда», «подрядчик». Внизу подпись: «26 процессов: таблицей — 21,7 часа, в BPMN — 130 часов». Чертёжный стиль, всё по-русски.
Пять ошибок, из-за которых схемой нельзя пользоваться
Схема бывает нарисована аккуратно и при этом непригодна для оценки. Пять дефектов встречаются чаще остальных, и все пятеро чинятся до отправки подрядчику.
- 1Смешение ролей и систем. На схеме появляется дорожка «1С» рядом с дорожкой «Менеджер». Система ничего не делает сама — действие совершает человек в системе, поэтому дорожка отводится роли, а система подписывается на задаче. Если оставить как есть, подрядчик не поймёт, где обмен данными, а где ручной ввод, и заложит не то.
- 2Нет точек отказа. Схема, на которой ни одна ветка не ведёт к отказу, ошибке или возврату, описывает не процесс, а намерение. Проверка простая: если на схеме нет ни одного ромба с веткой «нет», её рисовали по регламенту, а не по практике.
- 3Схема идеального мира. Нарисован только основной маршрут. В модельном примере он покрывает 71,5 % потока: из 480 заявок 137 идут не по нему. Смета, посчитанная по такой схеме, окажется заниженной ровно на стоимость разбора исключений — а это самая дорогая часть любого проекта.
- 4Задачи разного масштаба на одном листе. Рядом стоят «нажать кнопку „Провести“» и «согласовать условия поставки с клиентом». Правило калибровки: одна задача — это то, что один человек делает за один присест, не переключаясь. Если шаг занимает больше получаса или включает переписку с кем-то, это не задача, а подпроцесс, и его надо разворачивать отдельно.
- 5Процесс без стартового события. Схема начинается сразу с задачи, потому что на вопрос «что запускает работу» ответа не нашлось. Это не оплошность рисовальщика, а находка: процесс, который стартует «когда вспомнят» или «когда клиент напомнит», уже теряет заявки, и чинится он не системой, а назначением триггера.
Две схемы рядом, слева и справа. Левая помечена крестом в углу и подписана «так нельзя»: три дорожки с названиями «Менеджер», «1С», «Почта», задачи распределены между ними, ни одного ромба, единственный конец «Готово». Правая помечена галочкой и подписана «так надо»: две дорожки «Менеджер» и «Руководитель отдела», на каждой задаче мелкой припиской указана система — «1С:УТ», «CRM», «Почта», есть два ромба с ветками «нет» и два разных конца — «Счёт отправлен» и «Заявка отклонена». Под правой схемой подпись «основной маршрут — 71,5 % потока, остальные 137 заявок из 480 идут по веткам». Чертёжный стиль, всё по-русски.
Сколько стоит описание процессов и как не переплатить
Часы на описание — это рабочее время руководителя проекта, и они считаются по полной ставке, а не по окладу. Для оклада 115 000 ₽ полная стоимость часа с взносами, отпусками и рабочим местом составляет 1 250 ₽ при 146 фактически отработанных часах в месяц. Ниже — три сценария описания реестра из 26 процессов.
Экономия здесь не в том, что схем стало меньше, а в том, что подробные схемы нарисованы только для тех процессов, которые пойдут в работу. Двадцать четыре процесса из двадцати шести не попадут в проект ни в этом году, ни в следующем — описывать их в нотации значит платить за документ, который никто не прочитает. Как отобрать финалистов по цене процесса и шести критериям, разобрано в статье про выбор первого процесса.
Столбчатая диаграмма на три столбца, единица — рубли. Первый столбец «Только таблица, 26 процессов» — 27 125 ₽, подпись под ним «21,7 часа, для сметы не хватает». Второй столбец «Всё в BPMN» — 162 500 ₽, подпись «130 часов, 24 схемы никто не прочитает», столбец показан штриховкой. Третий столбец «Гибрид: таблица 26 + схема 7 + BPMN 2» — 54 500 ₽, подпись «43,6 часа», столбец выделен заливкой и разделён на три сегмента с числами 27 125, 14 875 и 12 500. Между вторым и третьим столбцами вертикальная выноска с подписью «−108 000 ₽ и −86 часов». Чертёжный стиль, всё по-русски.
Отдельно про то, кто рисует. Своими силами схема выходит дешевле, но она описывает процесс изнутри — со всеми привычками компании и слепыми пятнами. Подрядчик рисует дороже и медленнее, зато задаёт вопросы, которые внутри не задаются. Что именно входит в платное предпроектное обследование и какие пять документов остаются у заказчика при любом исходе, разобрано отдельно; схема — только один из них и не самый важный.
Когда схема не нужна вовсе
Три случая, в которых рисование — потерянное время, и в каждом есть что делать вместо.
- Процесс линейный, один исполнитель, меньше пяти шагов. Выгрузка отчёта по расписанию, рассылка напоминаний, ежедневная сводка остатков. Здесь достаточно четырёх строк текста, и любая схема будет длиннее описываемого процесса. Признак: в процессе нет ни одного «если».
- Процесс меняется прямо сейчас. Схема фиксирует состояние на дату. Если в компании идёт перестройка отдела или смена ключевого поставщика, к моменту разговора с подрядчиком документ устареет, и переделывать его придётся целиком. Разумнее зафиксировать объёмы и вернуться к описанию через квартал — объёмы переживают перестройку, схемы нет.
- Схема нужна как аргумент в споре, а не как инструмент. Иногда описание заказывают, чтобы доказать руководству, что отдел перегружен. Для этого схема бесполезна: она показывает порядок работы, а не её объём. Спор о загрузке решают три числа — частота, время операции и полная ставка, — и получают их замером, а не рисованием.
Схема стоит ровно столько, сколько стоит решение, которое по ней принимают. Если решения нет, любая нотация — просто аккуратно оформленный расход.
И последнее. Схема — не техническое задание и не заменяет его: она отвечает на вопрос «как идёт работа», а ТЗ отвечает на вопрос «что должна делать система и как проверить, что она это делает». Разбор того, из каких разделов собирается техническое задание на автоматизацию, вынесен в отдельный материал; схема входит туда приложением, а не подменяет содержание.
