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