Событие идёт по маршруту, а не по договорённости. Девять статусов и двадцать два перехода задают, кто и когда может сдвинуть событие дальше, — и ровно этот маршрут потом показывается проверяющему как процесс управления операционным риском.
Схема листается вбок — она шире экрана.
Наведите указатель или перейдите табуляцией на любое обозначение — покажется, что оно означает в процессе.
Ниже — полная матрица переходов. Её стоит читать вместе со своим регламентом: там, где ваш порядок отличается, статусная модель настраивается — переход остаётся объектом защиты, а право на него выдаётся роли.
| Из статуса | В статус | Кто выполняет | Комментарий обязателен |
|---|---|---|---|
| На регистрации | Готово для первой валидации | Регистратор данных | — |
| На регистрации | Качество проверено | Регистратор данных | — |
| На регистрации | Закрыто | Регистратор данных | — |
| На регистрации | Отменено | Регистратор данных | Да |
| Готово для первой валидации | Готово для второй валидации | Первый валидатор | — |
| Готово для первой валидации | На редактировании | Первый валидатор | Да |
| Готово для первой валидации | На отмену | Первый валидатор | Да |
| Готово для первой валидации | Отменено | Первый валидатор | Да |
| Готово для второй валидации | Качество проверено | Второй валидатор | — |
| Готово для второй валидации | На редактировании | Второй валидатор | Да |
| Готово для второй валидации | На отмену | Второй валидатор | Да |
| Готово для второй валидации | Закрыто | Второй валидатор | — |
| Готово для второй валидации | Отменено | Второй валидатор | Да |
| На отмену | Отменено | Регистратор данных | Да |
| На редактировании | Готово для первой валидации | Регистратор данных | — |
| На редактировании | Качество проверено | Регистратор данных | — |
| На редактировании | Закрыто | Регистратор данных | — |
| На редактировании | Отменено | Регистратор данных | Да |
| Качество проверено | На регистрации | Регистратор данных или второй валидатор | Да |
| Закрыто | На регистрации | Регистратор данных или второй валидатор | Да |
| Отменено | На регистрации | Без ограничения роли | Да |
| Готово к контролю качества | На регистрации | Без ограничения роли | Да |
Статус «Готово к контролю качества» — исторический: он остаётся в модели, чтобы события, заведённые до перехода на двухлинейную схему, возвращались на регистрацию штатным переходом, а не правкой в базе.
Тот, кто завёл событие, не подтверждает его качество. Тот, кто провёл первую валидацию, не закрывает вторую. Это не организационная договорённость, которую забудут при отпуске, — право на каждый переход проверяется ролью в момент нажатия кнопки.
Первая линия
Регистратор данных заводит событие, заполняет описание, классификацию, потери и возмещения и отправляет на валидацию.
Не может провести валидацию собственного события.
не пересекаются
Вторая линия
Первый валидатор проверяет полноту и классификацию и передаёт дальше. Второй валидатор подтверждает качество и закрывает событие.
Первый валидатор не закрывает вторую валидацию.
Защита от внутреннего фрода и от халатности сразу
Разделение полномочий закрывает два разных риска одним механизмом. Первый — сотрудник, которому выгодно, чтобы событие не попало в отчётность. Второй — сотрудник, который спешит и закрывает событие «чтобы не висело». В обоих случаях кнопка перехода просто недоступна, и обходить её приходится не в системе, а через администратора безопасности — то есть заметно.
Кому в вашей организации соответствуют эти роли, вы задаёте сами: роли настраиваются под вашу структуру, а членство назначается группами каталога. Подробно — на странице прав доступа.
Крупное событие невозможно провести мимо первой линии контроля, а мелкое — не засоряет её очередь. Порог работает в обе стороны, и обходится он не «уговором», а изменением суммы потерь — то есть действием, которое остаётся в истории изменений.
Если фактические прямые потери по событию достигают 350 000 ₽, из статусов «На регистрации» и «На редактировании» доступен один переход — «Готово для первой валидации». Попытка увести событие сразу в «Качество проверено» или в «Закрыто» останавливается сообщением.
Событие с потерями меньше порога на первую валидацию не пропускается. Очередь первой линии не забивается мелочью, и валидатор занимается тем, ради чего он в процессе.
Значение порога — параметр правила, а не свойство характера сотрудника: его видно в сообщении системы, оно одинаково для всех подразделений и не зависит от того, кто сегодня дежурит по разбору событий.
Возврат без объяснения — это второй круг работы и потерянная неделя. Система требует комментарий на каждом переходе, который отбрасывает событие назад или снимает его, и без текста переход не выполняется. В статусной модели события таких переходов тринадцать из двадцати двух — они отмечены в матрице выше.
| Что происходит | Почему комментарий обязателен |
|---|---|
| Возврат на редактирование с первой или второй валидации | Автор события получает не «верните и доделайте», а конкретный список претензий — и второй круг не превращается в третий. |
| Отправка события на отмену и сама отмена | Отмена события — это сумма, которая не попадёт в расчёт и в отчётность. Основание фиксируется текстом и остаётся в протоколе смены статусов. |
| Возврат на регистрацию из «Качество проверено», «Закрыто», «Отменено» и «Готово к контролю качества» | Пересмотр уже принятого события — самое чувствительное действие в базе: у него всегда есть автор, дата и написанная причина. |
| Возврат группы показателей с согласования | Согласующий объясняет редактору, что именно не так, — модель разделения полномочий исполнителя и проверяющего работает по той же логике. |
| Возврат аналитики по событию с согласования | Аналитик видит, по какой причине результат не согласован, и не гадает. |
Комментарий попадает в протокол смены статусов, а сам факт перехода — в историю на уровне поля. Через квартал вопрос «почему это событие вернули» закрывается за минуту.
Событие берёт в работу один сотрудник. Пока оно у него, второй не может ни редактировать карточку, ни двигать статус — и не увидит потом, что его правки затёрты чужими.
Сообщение о том, что событие уже взято в работу, с именем того, кто его взял. Не «форма недоступна», а понятная причина и понятный адресат, к которому идти.
Принудительно забрать событие из работы может только обладатель отдельного права — оно выдаётся не вместе с ролью, а самостоятельно. Обычно это администратор процесса, к которому обращаются, когда сотрудник в отпуске или уволился.
Что происходит без такого механизма
Два человека открывают одно событие, каждый вносит свою версию суммы потерь, сохраняет последний — и расхождение всплывает уже после сдачи отчётности, когда искать концы дороже. Исключительная блокировка снимает этот класс расхождений целиком.
Событие с незакрытым резервом невозможно объявить закрытым. Система считает остаток сама — как сумму последствий с признаком резерва минус расформирования, — и держит событие открытым, пока остаток не сойдётся в ноль.
Что должно сойтись, чтобы событие ушло в «Закрыто»
Отметьте условия, которые выполнены на вашем событии, — кнопка перехода станет доступна тогда же, когда она становится доступна в системе.
Не выполнено условий: из . Ровно так ведёт себя и система: переход недоступен, пока условие не выполнено.
Все условия выполнены — переход доступен второму валидатору.
Событие закрыто. Дальше оно возвращается на регистрацию только с обязательным комментарием.
Симметричное правило работает и на переходе в «Качество проверено»: он недоступен, пока по событию вообще нет нерасформированных резервов, — качество проверяют на событии с актуальным резервом, а не задним числом.
Значимое событие не должно ждать, пока кто-то заметит его в реестре. Система сама признаёт событие значимым по формальным признакам и рассылает его заданному списку получателей — руководителю подразделения операционного риска и всем, кого он в этот список добавил.
Достаточно выполнения любого из четырёх условий:
Четвёртое условие — про недобросовестность, а не про сумму
Событие с признаками преднамеренных действий уходит наверх независимо от суммы. Мелкая по деньгам, но умышленная операция — это сигнал о дыре в контроле, и он не должен теряться в потоке бытовых ошибок.
Отдельным правилом контролируется отмена: если у отменяемого события потери от 350 000 ₽ либо в его группе больше десяти связанных событий, уведомление уходит первому и второму валидатору.
Статусная модель — не бизнес-логика, зашитая в форму, а объект защиты со своими разрешениями и своим протоколом. Отсюда предсказуемость: маршрут события меняется настройкой прав, а каждое изменение маршрута остаётся в журнале.
Статусная модель события объявлена типом объекта защиты с действиями «чтение», «запись» и «выполнение». Право на переход выдаётся на целевой статус, право на редактирование — на текущий. Матрица согласуется со службой информационной безопасности один раз и дальше живёт как конфигурация.
Смены статусов пишутся отдельно по событию, по аналитике события, по КИР, по анкете и по группам показателей. Запрос внутреннего аудита «покажите движение всех событий за квартал» закрывается выгрузкой, а не разбором логов приложения.
26 статусов и 44 перехода описаны единообразно: событие, аналитика события, карточка ELOR, анкета и группа показателей работают на одном движке. Новый маршрут не требует нового кода.
Порог валидации, контроль резервов и блокировка «взято в работу» — серверные проверки на переходе. Их нельзя обойти ни прямой ссылкой, ни повторной отправкой формы.
Пройдём событие по всему маршруту — от регистрации до закрытия, с возвратом, отменой и контролем резервов, — и сверим его с вашим регламентом валидации.
Как с нами связаться
Отвечаем в рабочие дни. Если удобнее письмом — напишите, приложив вопрос по существу.