Как описать бизнес-процессы перед автоматизацией
Практика3 минРедакция Innovialabs
Коротко
Сначала опишите процесс как он идёт сейчас, отметьте узкие места и передачи между людьми, затем нарисуйте целевую схему и переведите каждый её шаг в требования: кто, что делает, с какими данными и по какому правилу.
Зачем описывать процесс до автоматизации
Если автоматизировать хаос, получится быстрый хаос. Описание процесса показывает, что на самом деле происходит, где теряется время и что из этого стоит отдать системе. Для разработчиков такая карта — лучшие вводные: она отвечает на вопросы, которые иначе всплывут посреди проекта.
Работа идёт в два шага:
- As-is («как есть») — процесс в его нынешнем виде, со всеми обходными путями.
- To-be («как должно быть») — целевой процесс после изменений и автоматизации.
Шаг 1. Выберите один процесс и его границы
Не пытайтесь описать всю компанию. Возьмите один процесс и зафиксируйте:
- старт — какое событие его запускает (пришла заявка, клиент позвонил);
- финиш — чем он заканчивается (заказ доставлен, оплата получена);
- участники — роли или отделы, а не конкретные люди;
- цель — что должно стать лучше: скорость, ошибки, прозрачность.
Шаг 2. Опишите «как есть»
Лучший источник — сами исполнители. Пройдите процесс вместе с ними на реальных примерах и записывайте, что происходит, а не как «должно быть по регламенту».
Для схемы хватит нескольких элементов нотации BPMN:
| Элемент | Что означает |
|---|---|
| Круг | Начало или конец процесса |
| Прямоугольник | Действие (задача) |
| Ромб | Решение или развилка |
| Дорожка (swimlane) | Роль, которая выполняет действия |
| Стрелка | Последовательность шагов |
Простой пример в виде текста:
[Клиент] (старт) -> Оставляет заявку на сайте
[Менеджер] Копирует заявку в таблицу -> Звонит клиенту -> <Клиент согласен?>
да -> Пишет счёт вручную -> Отправляет бухгалтеру в мессенджер
нет -> (конец)
[Бухгалтер] Проверяет оплату в банке -> Сообщает менеджеру -> (конец)
Рисовать можно на доске, в любом редакторе диаграмм или прямо в таблице. Главное — чтобы схему понимали те, кто работает в процессе.
Шаг 3. Найдите узкие места и передачи
Пройдите по схеме и отметьте:
- передачи между ролями — каждая стрелка из одной дорожки в другую. Здесь задачи теряются и ждут;
- ручной перенос данных — копирование из одной системы в другую;
- ожидания — шаги, где процесс стоит, пока кто-то не ответит;
- повторы и возвраты — когда работу переделывают из-за ошибок;
- развилки без правил — решения, которые принимают «по опыту».
Для каждой проблемы запишите, как часто она случается и к чему приводит. Цифры берите из реальных данных, если они есть, или честно помечайте как оценку.
Шаг 4. Нарисуйте «как должно быть»
Целевая схема убирает лишние шаги и передачи, а оставшиеся делит на:
- автоматические — система делает сама (создать сделку, отправить счёт, напомнить);
- ручные с поддержкой системы — человек решает, система подсказывает и фиксирует;
- полностью ручные — то, что автоматизировать нецелесообразно.
Не автоматизируйте всё подряд. Иногда достаточно убрать лишний шаг или договориться о правиле.
Шаг 5. Превратите карту во вводные для разработчиков
Для каждого шага целевой схемы опишите:
- кто выполняет (роль) или что запускает шаг;
- какие данные нужны на входе и что получается на выходе;
- правила — условия развилок, сроки, ограничения;
- исключения — что делать, если что-то пошло не так;
- уведомления — кому и когда сообщать;
- интеграции — с какими системами нужен обмен.
Приложите схемы as-is и to-be, список ролей и примеры реальных документов. Такой пакет разработчики могут оценить и превратить в техническое задание.
Частые ошибки
- Описывать процесс по регламенту, а не по факту.
- Рисовать слишком подробно — схема становится нечитаемой.
- Пропускать исключения: именно они занимают много времени в разработке.
- Не согласовать целевую схему с теми, кто будет в ней работать.