The post has been translated automatically. Original language: Russian
Teams often start a new system implementation with screens, fields and notifications. That is too early. If the real process has not been examined, software merely hard-codes its contradictions and produces errors faster.
Describe one real case from trigger to final outcome first. BPMN can provide a shared language, but a simple table of steps, roles and decisions is already useful.
Ask eight questions: What exact event starts the process? What does “done” mean? Who owns the end-to-end outcome? Which data is mandatory? Where is approval required? What happens when something fails? Which actions are genuinely repetitive? Which metric will prove improvement?
A minimum process map needs seven columns: step, input, output, performer, system, transition rule and exception. Walk through a normal case, a complex case and a failed case. Contradictions found here are much cheaper to fix than after migration and training.
Automate high-volume work with stable rules, measurable error cost and a clear owner first. Avoid starting with rare situations that depend on negotiation or change every week.
Success is not “everything moved into the system.” It is shorter cycle time and fewer errors without losing control. Sometimes the best first automation decision is simply removing an unnecessary step.
Когда компания покупает новую систему, команда часто начинает с экранов и полей: какие статусы создать, какие справочники загрузить, какие уведомления включить. Это преждевременно. Если реальный процесс не разобран, система лишь закрепит его противоречия и ускорит появление новых ошибок.
До настройки инструмента полезно описать один реальный кейс от начала до конца. BPMN можно использовать как общий язык, но даже простой лист с шагами, ролями и решениями уже лучше обсуждения по памяти.
Восемь вопросов к процессу
- Что запускает процесс? Не «клиент написал», а конкретное событие: получен заказ с обязательными данными или подписан договор.
- Как выглядит результат? Например: товар доставлен, документы приняты, оплата сопоставлена, задолженность отражена.
- Кто владеет процессом целиком? У отдельных этапов могут быть исполнители, но один человек должен видеть итог.
- Какие данные обязательны? Если без серийного номера или страны назначения следующий шаг невозможен, система должна проверять это заранее.
- Где принимается решение? Скидка, частичная отгрузка, возврат и исключение из правила требуют явной точки согласования.
- Что происходит при ошибке? У процесса нужен не только happy path, но и маршрут возврата, исправления и эскалации.
- Какие действия действительно повторяются? Автоматизировать стоит устойчивые правила, а не редкие ситуации, где постоянно требуется суждение человека.
- Как измеряется эффект? Подойдут время цикла, доля возвратов на исправление, число ручных касаний, просроченные задачи и стоимость одной операции.
Минимальная карта до разработки
Соберите таблицу из семи колонок: шаг, вход, результат, исполнитель, система, правило перехода, исключение. Затем проведите по ней три кейса: обычный, сложный и неудачный. Противоречия, обнаруженные на этом этапе, исправляются дешевле, чем после миграции данных и обучения команды.
Красивую схему не нужно путать с работающим процессом. Проверьте ее на людях, которые ежедневно выполняют работу, и на реальных документах. Только после этого переносите логику в CRM, ERP, low-code или собственного бота.
Что автоматизировать первым
Хороший первый кандидат имеет большой объем, стабильные правила, измеримую цену ошибки и понятного владельца. Плохой кандидат встречается редко, зависит от переговоров или меняется каждую неделю.
Автоматизация дает эффект не тогда, когда «всё перенесли в систему», а когда снизились время цикла и число ошибок без потери управляемости. Иногда лучший результат первого этапа - не новый робот, а удаленный лишний шаг.
Share
