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