Автоматизация закрепляет правила процесса в системе. Если правила не описаны, разработчик восстанавливает их из противоречивых объяснений, а сотрудники ожидают разное поведение. В результате система может технически работать, но не соответствовать реальному бизнесу.
Качественное описание не обязательно требует сложной нотации. Для большинства малых и средних компаний достаточно понятной карты и таблицы правил, если они охватывают основной поток, решения и исключения.
Сначала определите границы процесса
Название «обработка заказа» слишком широкое. Для одного сотрудника процесс начинается со звонка, для другого — с оплаты, для склада — со списка на комплектацию. Поэтому зафиксируйте четыре границы:
- Событие запуска: что создаёт новый экземпляр процесса.
- Вход: какие данные и документы нужны для начала.
- Результат: какой проверяемый статус означает завершение.
- Владелец: кто отвечает за итог всего процесса, а не отдельного шага.
Пример: процесс начинается, когда сайт передаёт подтверждённый заказ. Завершается, когда склад получает корректное задание на комплектацию с зарезервированным товаром. Доставка и возвраты в первую границу не входят.
Минимальный паспорт процесса
| Поле | Что записать | Пример |
|---|---|---|
| Цель | Бизнес-результат, а не действие системы | Передать складу полный и проверенный заказ |
| Старт | Конкретное событие | Сайт создал подтверждённый заказ |
| Финиш | Проверяемое состояние | Товар зарезервирован, задача складу создана |
| Владелец | Ответственный за итог | Руководитель отдела продаж |
| Участники | Роли, а не фамилии | Менеджер, склад, бухгалтер |
| Системы | Источники и получатели данных | Сайт, учёт, служба доставки |
| Показатели | Время, качество, стоимость | Время до резерва, доля исправлений |
Паспорт заполняют до детализации шагов. Он не позволяет незаметно расширять проект и задаёт общий критерий завершения.
Опишите текущий процесс AS-IS
Не начинайте с желаемой системы. Сначала зафиксируйте, как работа выполняется сейчас, включая таблицы, чаты, звонки и ручные обходные действия. Иначе критическая зависимость обнаружится после запуска.
Для каждого шага запишите:
- номер и короткое название;
- роль исполнителя;
- событие или результат предыдущего шага;
- входные данные;
- действие;
- результат и новый статус;
- нормальный срок;
- возможную ошибку или исключение.
| Шаг | Роль | Вход | Действие | Результат | Исключение |
|---|---|---|---|---|---|
| 1. Получить | Менеджер | Заказ с сайта | Проверить контакты и состав позиций | Заказ принят | Нет телефона или адреса |
| 2. Проверить остаток | Менеджер | Позиции и количество | Сверить доступный товар | Наличие подтверждено | Дефицит или резерв другого клиента |
| 3. Подтвердить условия | Менеджер | Цена, оплата, доставка | Проверить стандартные условия | Условия согласованы | Индивидуальная скидка |
| 4. Зарезервировать | Система или менеджер | Подтверждённый заказ | Создать резерв | Товар недоступен другим заказам | Остаток изменился |
| 5. Передать складу | Менеджер | Заказ с резервом | Создать задание | Склад видит актуальную версию | Заказ изменён после передачи |
Отделите действие от решения
Шаг «проверить заказ» скрывает несколько решений. Системе нужны точные условия:
- какие поля обязательны;
- какой остаток считается доступным;
- когда разрешена наложенная оплата;
- какая скидка проходит без согласования;
- что делать при частичном наличии;
- кто может менять заказ после резерва;
- когда требуется повторное задание складу.
Правило записывают в форме «если — то — иначе» и добавляют источник данных. Например: если все позиции доступны, сумма не превышает лимит наложенного платежа и адрес прошёл проверку, создать резерв автоматически; иначе передать заказ менеджеру с указанием причины.
Создайте отдельный реестр исключений
Исключения не нужно скрывать или пытаться автоматизировать полностью в первом релизе. Для каждого исключения определите:
- как система его обнаруживает;
- какие данные показывает человеку;
- кто принимает решение;
- сколько времени разрешено;
- как процесс возвращается в основной поток;
- какой след решения сохраняется.
| Исключение | Признак | Ответственный | Решение | Возврат в процесс |
|---|---|---|---|---|
| Недостаточный остаток | Доступно меньше заказанного | Менеджер | Замена, ожидание или частичная отгрузка | Обновить состав и повторить резерв |
| Нестандартная скидка | Превышен лимит роли | Руководитель продаж | Согласовать или отклонить | Зафиксировать цену и продолжить |
| Изменение после передачи | Версия заказа новее задания | Склад и менеджер | Остановить старое задание | Создать новую актуальную версию |
Рисуйте TO-BE только после AS-IS
Будущий процесс не должен быть цифровой копией каждой ручной операции. Для каждого шага проверьте:
- нужен ли он для результата или контроля риска;
- можно ли получить данные без повторного ввода;
- может ли правило выполняться автоматически;
- можно ли объединить проверки;
- должен ли человек принимать решение или только подтверждает очевидное;
- какие события требуется журналировать.
В примере менеджер больше не переносит заказ и не проверяет стандартные случаи. Система создаёт документ, проверяет поля, резервирует товар и передаёт задание. Менеджер работает только с очередью исключений.
Опишите данные и единый источник истины
Для каждого ключевого поля укажите источник, формат, владельца и момент обновления. Особенно это относится к цене, доступному остатку, резерву, статусу оплаты, контактам клиента и версии заказа.
Если сайт и склад показывают разные остатки, автоматизация лишь ускорит конфликт. До запуска определите, какая система является источником истины и как остальные получают обновления.
Добавьте права и журнал событий
Карта должна отвечать не только на вопрос «что происходит», но и «кто имеет право». Зафиксируйте, кто может менять цену, отменять резерв, возвращать процесс на предыдущий этап и закрывать исключение. Для значимых действий сохраняйте автора, время, старое и новое значение, причину.
Сформулируйте критерии приёмки
- стандартный заказ автоматически получает резерв не позднее чем через минуту;
- заказ без обязательного поля не переходит на склад и содержит понятную причину;
- изменение количества после резерва создаёт новую версию задания;
- менеджер видит единую очередь исключений со сроком;
- каждое решение по скидке записывается в историю;
- показатели до и после запуска считаются по одинаковым правилам.
Фразы «должно быть удобно» или «всё должно работать быстро» не являются критериями приёмки.
Типичные ошибки описания
- Описан только успешный путь. Первое исключение останавливает работу.
- Используются фамилии вместо ролей. Процесс ломается после кадровой замены.
- Шаги названы слишком широко. Внутри скрыты решения без правил.
- AS-IS подменяют желаемой схемой. Теряются фактические зависимости.
- Не определён источник данных. Системы показывают разные состояния.
- Нет версии процесса. После изменений непонятно, по каким правилам тестировать.
- Не установлены показатели. Невозможно доказать результат автоматизации.
Готовый результат подготовки
Перед разработкой команда должна иметь паспорт процесса, карту AS-IS, карту TO-BE, таблицу правил, реестр исключений, перечень источников данных, матрицу прав и критерии приёмки. Для небольшого процесса это помещается в несколько страниц и одну схему.
Описание согласуют владелец процесса, ключевые исполнители и технический ответственный. Согласование не означает неизменность: номер версии и журнал изменений позволяют корректно обновлять правила.
Процессы в Business Reactor
Business Reactor связывает роли, статусы, документы, товары и операции в одном контуре. Благодаря этому карта не остаётся отдельной презентацией: её правила можно сопоставить с реальными правами, событиями и данными системы.
После описания процесса нужно проверить экономическую целесообразность: сколько стоит текущая работа, какие потери реально исчезнут и за какой срок окупится внедрение.
Вывод
Корректное описание начинается с границ и бизнес-результата. Затем фиксируются текущие шаги, решения, данные и исключения, и лишь после этого проектируется будущий порядок работы. Такая карта снижает противоречия и даёт проверяемые критерии для разработки.
Следующий шаг — перевести время, ошибки и задержки в финансовую модель и рассчитать окупаемость автоматизации. Ядро системы Business Reactor.
