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