Как понять, что бизнес-процесс пора разделить на два?

Разделить бизнес-процесс на два стоит не тогда, когда схема стала длинной. Главный признак другой: после одного и того же старта у работы появляются разные владельцы, разные сроки, разные риски или разные правила успеха. Тогда один общий маршрут начинает скрывать важные решения.

Например, заявка на закупку может быть обычной и срочной. Снаружи это один тип обращения. Но для срочной заявки нужны другой срок, отдельное подтверждение и понятная причина. Если притвориться, что путь один, сотрудники начнут решать исключения в мессенджере — и система потеряет смысл.

Не путайте два процесса с двумя статусами

Разделение не означает, что на каждую редкую ситуацию нужно строить новый маршрут. Иногда достаточно одного статуса или дополнительного условия. Делить стоит там, где меняется сама логика работы: участники, обязательные данные, ответственность за решение или последствия ошибки.

Полезная проверка проста: может ли сотрудник пройти общий путь, не делая вид, что важного отличия не существует? Если для каждого второго случая приходится добавлять комментарий «тут по-особому», процесс уже просит отдельную ветку.

Пять признаков, что ветка стала самостоятельной

• Другой владелец результата. Обычный заказ ведёт менеджер, а спорный — финансовый руководитель.
• Другой срок. Один путь можно выполнить за день, другой требует реакции в течение часа.
• Другой набор данных. Для типового случая хватает карточки клиента, а для нестандартного нужно основание и документы.
• Другой риск. Ошибка в одном варианте неприятна, в другом влияет на деньги, договор или безопасность.
• Другая метрика. В одном пути важна скорость, в другом — корректность и объяснимость решения.

Достаточно не всех пяти, а одного-двух устойчивых признаков. Важно, чтобы отличие повторялось, а не возникало раз в год. Иначе система станет шкафом с сотней ящиков, где никто не знает, какой открыть.

Начните с точки разделения

Не нужно сразу рисовать две большие схемы. Найдите момент, где работа честно расходится. До него оставьте общий вход: кто создал обращение, какие данные проверили, что считается принятым. После него дайте каждому пути свой набор правил.

В истории со скидкой таким моментом может стать порог суммы. Ниже порога менеджер действует по обычному маршруту. Выше — заявка превращается в отдельную задачу согласования со сроком и владельцем. Это прозрачнее, чем прятать всё в одном статусе «на рассмотрении».

Отдельный маршрут полезен и для исключений. Но он не должен быть свалкой: в нём нужен ответственный и понятный выход. Подробнее о том, как не потерять нестандартный случай, есть в статье про организацию исключений в автоматизированном процессе.

Что сохранить общим

Когда процессы разделяют слишком рано, компания получает две копии одних и тех же данных и две команды, которые по-разному называют одну работу. Поэтому общий вход и общий итог лучше удержать там, где это честно.

Например, у двух веток может быть единый номер обращения, клиент, предмет запроса и финальный результат. А вот правила проверки, роли и сроки — разные. Тогда руководитель видит картину целиком, а исполнители не вынуждены каждый раз проходить чужие шаги.

Как не сделать разделение новой проблемой

1. Соберите несколько реальных случаев, где сотрудники обходили общий маршрут.
2. Назовите точку, после которой работа меняет владельца или риск.
3. Опишите для каждой ветки вход, ответственного, срок и результат.
4. Оставьте безопасный путь, если система не может выбрать ветку сама.
5. Через несколько недель проверьте, не стали ли ветки снова одинаковыми.

Последняя проверка нужна, потому что процесс живой. Иногда отдельная ветка оправдывает себя. Иногда выясняется, что она была временной и её можно снова объединить. Хорошая автоматизация не защищает схему ради схемы, а помогает людям быстрее принимать понятные решения.

Если правила ещё меняются, полезно сначала отделить устойчивый маршрут от подвижных условий. Этот подход разбираю в материале об автоматизации при меняющихся правилах. Он помогает не превращать каждое управленческое изменение в переписывание всего процесса.

Короткий вывод

Два процесса нужны там, где два разных обещания работы. Если отличаются риск, владелец или результат, честнее показать это в системе. А если разница лишь в одном условии, лучше оставить общий путь и не усложнять жизнь пользователю. Такая граница делает процесс понятнее не только разработчикам, но и тем, кто работает в нём каждый день.