Процесс это последовательность действий, которая превращает вход в результат для клиента. БА моделирует процессы, чтобы увидеть, как работа идёт сейчас (AS-IS), и договориться, как она пойдёт после изменения (TO-BE).
AS-IS
Модель текущего состояния. Задача не нарисовать красиво, а найти проблемы: ожидания, ручной ввод, повторные проверки, возвраты на доработку, разрывы между отделами.
Как собирать: интервью с участниками каждого шага, наблюдение, данные из систем (сколько заявок, сколько времени на шаг). Описывайте, как есть на самом деле, а не как написано в регламенте. Если регламент и реальность расходятся, это уже находка.
Сколько детализировать AS-IS? Ровно настолько, чтобы увидеть проблемы и измерить базовую линию. Глубоко рисовать процесс, который вы всё равно выбросите, дорого.
TO-BE
Модель целевого состояния. Строится от целей: что должно стать лучше и на сколько. TO-BE показывает, какие шаги убираем, автоматизируем, объединяем, кто становится владельцем. Разница AS-IS и TO-BE и есть объём изменений (об этом модуль про анализ разрывов).
BPMN: что нужно знать БА
BPMN 2.0 это стандарт нотации процессов (OMG, также ISO/IEC 19510).
- Пул: участник процесса (организация или внешняя сторона). Между пулами только потоки сообщений.
- Дорожка: роль или подразделение внутри пула.
- Задача: прямоугольник со скруглёнными углами, глагол плюс объект: «Проверить заявку».
- События: круги. Начальное (тонкий контур), промежуточное (двойной), конечное (толстый). Типы: таймер, сообщение, ошибка.
- Шлюзы: ромбы. Исключающий XOR (один путь по условию), параллельный AND (все пути одновременно), включающий OR (один или несколько).
- Поток управления: сплошная стрелка внутри пула. Поток сообщений: пунктир между пулами.
- Подпроцесс: свёрнутый блок с плюсом, чтобы не перегружать схему.
Уровни детализации
- Уровень 1, обзорный: 5-10 шагов, для руководства, без шлюзов исключений.
- Уровень 2, описательный: роли, основные развилки, события. Самый частый уровень для БА.
- Уровень 3, исполняемый: для движка (Camunda и аналоги), с данными и техническими деталями. Обычно уже зона системного аналитика.
Правила хорошей схемы
- Одно начальное событие на понятный триггер, конечные события названы по результату («Заявка одобрена», «Заявка отклонена»).
- Задачи названы действием, а не «Обработка».
- Ветки после XOR подписаны условиями.
- Что разветвили AND, то собрали AND. Смешивать XOR на разветвлении и AND на слиянии нельзя: процесс зависнет.
- Не больше 15-20 элементов на схеме, остальное в подпроцессы.
Другие нотации
- EPC (событийная цепочка): исторически в ARIS, встречается в крупных российских компаниях.
- IDEF0: функциональная модель с входами, выходами, управлением и механизмами. Встречается в госсекторе.
- Блок-схема и swimlane без BPMN: для быстрых обсуждений.
- Value Stream Map: поток создания ценности с временем ожидания и обработки, из бережливого производства.
Метрики процесса
Длительность цикла (от начала до конца), время обработки и время ожидания, доля возвратов, стоимость экземпляра процесса, число передач между ролями. Без цифр AS-IS невозможно доказать, что TO-BE лучше.
Частые ошибки
- Рисовать TO-BE, не разобрав AS-IS и проблемы.
- Перепутать поток сообщений с потоком управления.
- Одна схема на всё на 80 элементов.
- Задачи без глагола, шлюзы без условий.
- Моделировать регламент, а не реальность.
Что спросят на собесе
- Зачем нужны AS-IS и TO-BE, всегда ли нужен AS-IS.
- Чем отличаются шлюзы XOR, AND и OR.
- Пул против дорожки, поток сообщений против потока управления.
- Как вы выбираете уровень детализации.
- Как доказать, что TO-BE лучше.