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