Описание бизнес-процессов: почему подробная схема сама по себе не ускоряет работу

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

Как выглядит схема на сорок блоков

Сцена собирательная, не история конкретного клиента. Аналитик приносит схему согласования договора. Сорок блоков, три дорожки, легенда, версия 2.4. Тридцать пять блоков описывают, что делает секретарь: открыла письмо, проверила реквизиты, присвоила номер, сохранила в папку, отправила юристу. На всё это у неё уходит десять минут.

Юрист на схеме представлен одной стрелкой. Стрелка называется «согласование». Договор под этой стрелкой лежит три дня.

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

Понятными стали десять минут из трёх дней. Остальное время нарисовано линией без длины.

Почему аналитик рисует секретаря, а не очередь у юриста

Аналитик подробно описывает то, что можно наблюдать. Действия одного человека за одним столом видны: можно сесть рядом, записать каждое нажатие, расставить квадратики в правильном порядке. Это проверяемая работа, и за неё легко отчитаться количеством блоков.

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

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

14 октября 2026 года Stormbpmn опубликовал разбор раздела 6.3 ABPMP CBOK, свода знаний по управлению бизнес-процессами, сделанный по встрече их книжного клуба. Это учебная интерпретация, не исследование, но вывод там тот же. Если операцию выполняет один исполнитель и роль не меняется, дробить её на микрошаги не нужно: получается операционная инструкция вместо модели, такую модель труднее менять, а узкие места обычно не внутри действий, а между ними, в очередях, ожиданиях и точках передачи.

Что подробная модель обещает руководителю и когда она права

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

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

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

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

В чём прав сотрудник, который называет это бюрократией

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

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

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

Что измерять первым: время между шагами

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

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

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

Отдельно отметьте возвраты. Часть из них нужна для дела, но если договор раз за разом возвращают за одними и теми же недостающими данными, это движение без продвижения к подписи.

Это и есть карта той территории. На ней может не оказаться ни одного квадратика про секретаря, и это нормально.

Как проверять развилки и правила согласования

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

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

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

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

Почему нельзя сразу автоматизировать целевую схему

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

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

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

Как проверить работу аналитика до оплаты

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

Проверка до заказа и при сдаче:

1. Какое решение примут по этой схеме и сколько стоит ошибка в нём. Нет ответа, заказывать описание рано.
2. Измерено ли полное время прохождения и где документ ждёт, хотя бы на нескольких недавних договорах.
3. Подробно описан только участок с высокой ценой ошибки, остальное на уровне ролей и передач.
4. У каждой развилки есть ответ на «зачем»: число случаев и цена ошибки.
5. Новый порядок сначала проверен простыми средствами, и известно, по какому сроку его признают лучше.

Если из пяти пунктов выполнен только третий, вы получили подробный документ. Стала ли работа быстрее, никто не знает.

Количество блоков на схеме согласование не ускоряет. Ускоряет решение по стрелке, длину которой сначала кто-то измерил.