На воркшопе участники описывают процесс от действий отдела до его результата. По какому критерию аналитик должен провести границы модели?
Границы бизнес-процесса следует задавать по его событию запуска и проверяемому результату, а не по границам подразделения или используемой системы. Процесс начинается с однозначного состояния или события, требующего действий, и заканчивается достижением результата для клиента или другого получателя.
Процессный подход появился как способ анализировать работу сквозь границы функций, должностей и подразделений. Одно подразделение часто выполняет только часть цепочки, поэтому описание работы отдела само по себе не показывает, как создаётся итоговая ценность.
Фиксация границ нужна, чтобы разные участники одинаково понимали, что именно моделируется. Это также позволяет сравнивать варианты процесса, измерять его длительность и находить потери на стыках ответственности.
Если началом процесса считать начало рабочего дня отдела, а концом — завершение его последней операции, модель будет зависеть от организационной структуры. При реорганизации подразделений такая модель потеряет актуальность, хотя сам бизнес-результат может не измениться.
Слишком широкая граница приводит к перегруженной схеме: в неё попадают несколько самостоятельных процессов с разными результатами. Слишком узкая граница скрывает важные передачи работы, ожидания и решения, из-за чего оценка улучшений становится неполной.
Сначала аналитик формулирует триггер: внешнее или внутреннее событие, после которого возникает обязательство выполнить процесс. Формулировка должна описывать состояние или факт, например «получена заявка», а не действие конкретного сотрудника вроде «оператор открыл карточку».
Затем определяется конечный результат и его получатель. Результат должен быть наблюдаемым: услуга оказана, решение принято, заказ передан, заявка закрыта с зафиксированным статусом. Простое завершение последней операции сотрудника результатом не является, если бизнес-потребность ещё не удовлетворена.
После этого проверяется, относятся ли промежуточные действия к достижению данного результата. В модель включают значимые передачи, ожидания, проверки и развилки, влияющие на срок, стоимость, качество или соответствие правилам.
Границы не обязаны совпадать с границами системы, проекта или подразделения. Однако уровень детализации выбирают под задачу: для анализа клиентского пути нужна более широкая цепочка, а для автоматизации отдельного участка — детальная модель подпроцесса с явно указанными входами и выходами.
Полезно проверить границы несколькими вопросами:
Главный компромисс связан с детализацией. Чем шире модель, тем лучше видны межфункциональные зависимости, но тем труднее поддерживать её и согласовывать; чем уже модель, тем проще анализ, но выше риск потерять причины задержек на соседних этапах.
Компания анализировала возврат товара. Руководитель операционного отдела предложил начинать процесс с регистрации возврата в системе и заканчивать передачей задания на склад. Такой вариант был удобен для отдела, но не показывал, как возникает запрос клиента и когда обязательство компании считается выполненным.
Рассматривались три варианта. Границы по подразделению были простыми для описания, но скрывали работу поддержки и финансового отдела. Границы по системе облегчали поиск автоматизации, но исключали ручные проверки и коммуникации вне системы. Границы по событию и бизнес-результату требовали согласовать владельцев и исключения, зато показывали всю цепочку.
Выбрали третий вариант: запуском считали подтверждённый запрос на возврат, а завершением — возврат денег или иной согласованный результат, сообщённый клиенту. В модель включили проверку права на возврат, передачу товара, решение по спорным случаям и финансовую операцию.
Такой результат позволил увидеть, что основная задержка возникала не внутри одного отдела, а между подтверждением получения товара и передачей решения в финансовую службу. Модель не утверждает конкретный способ улучшения, но корректно определяет участок, на котором можно оценивать варианты решения.
Нет, если до этого существует событие, создающее потребность в процессе. Первое действие сотрудника — это уже реакция на вход, а его использование как границы скрывает время ожидания до регистрации и затрудняет анализ полного клиентского пути. Такое начало допустимо только для намеренно ограниченной модели подпроцесса, если её вход явно зафиксирован.
Нет. Если отказ, отмена или эскалация являются предусмотренными исходами, их следует моделировать как допустимые конечные результаты или ветви процесса. Важно, чтобы каждый исход был наблюдаемым и имел понятного получателя или дальнейшего владельца; иначе модель создаёт ложное впечатление, что процесс заканчивается только при успехе.
Нужно проверить, являются ли они вариантами одного результата или признаками нескольких процессов. Если все исходы удовлетворяют одной цели и запускаются одним типом события, их можно оставить в одной модели как ветви. Если у них разные цели, владельцы, получатели и критерии завершения, лучше выделить отдельные процессы или верхнеуровневый процесс с подпроцессами, чтобы не смешивать разные объекты анализа.