Система не даст забыть о просроченной переоценке
В MCA дата следующей переоценки адекватности используется для ежедневной проверки сроков. При наступлении даты модуль автоматически рассылает уведомления.
Даты последней и следующей переоценки
У каждого контроля и мониторинга — две даты: когда адекватность оценивали в последний раз и когда пора снова. Обе даты обновляются не вручную: как только карточка проходит согласование, дата последней оценки становится сегодняшней, а следующая переоценка автоматически назначается на год вперёд. Часы обновляются от реального события — согласования, а не от отдельного календарного плана, который можно забыть свериться.
Ежедневный планировщик уведомлений
Раз в сутки фоновая задача проходит по всем контролям и мониторингам и находит те, у кого дата следующей переоценки уже наступила или прошла — до начала завтрашнего дня. Задача не ждёт, что кто-то откроет реестр и заметит просрочку сам: уведомление «Требуется оценка адекватности» уходит автоматически, от имени системы, а не случайного сотрудника, поэтому в журнале рассылок такие напоминания всегда видно отдельно от ручных действий.
По умолчанию — каждое утро, а время настраивается
Плановое время запуска задачи — свойство платформы, а не жёстко зашитое значение: по поставке она отрабатывает ежедневно в 8:00, а точное время можно изменить под режим работы вашей организации.
Кто получает уведомления
Напоминание о просроченной переоценке получают не ответственный за карточку, а все сотрудники с ролью проверяющего сразу — так просрочка не зависит от того, свободен ли именно сегодня один конкретный человек. Если ни одного проверяющего пока не назначено, задача просто завершается без рассылки — тихо, без ошибок в логе на пустом месте.
Отдельно от планировщика система следит и в обратную сторону: если по пересчитанным данным адекватность контроля или мониторинга меняется, ответственный получает собственное уведомление с прямой ссылкой на карточку — он узнаёт об этом из системы, а не из следующего планового обхода реестра.
| Уведомление | Когда приходит | Кому |
|---|---|---|
| Изменение согласовано | Предложенное изменение подтверждено | Автору изменения |
| Изменение отклонено | Предложенное изменение отклонено | Автору изменения |
| Требуется оценка адекватности | Ежедневно, по просроченным датам | Всем проверяющим |
| Контроль/мониторинг признан неадекватным | При смене расчётной адекватности | Ответственному по карточке |
Настраиваемые параметры самооценки
Экран «Конфигурация» задаёт четыре параметра, общих для всего модуля, — без обращения к разработчику при каждом изменении методологии:
| Параметр | Значение по умолчанию | Где используется |
|---|---|---|
| Период привязки события операционного риска, дней | 90 | В расчёте эффективности контроля — «слишком свежая» привязка не даёт эффективности |
| Порог общей суммы валовых потерь, руб | 300 000 | В расчёте эффективности контроля по привязанным событиям операционного риска |
| Период подачи первичного результата мониторинга, дней | 60 | Организационный ориентир на экране конфигурации |
| Срок для внесения результатов, дней | 20 | Организационный ориентир на экране конфигурации |
Первые два параметра напрямую участвуют в расчёте эффективности контроля и меняют результат сразу для всего реестра. Оба срока подачи результата хранятся вместе с остальной конфигурацией и видны каждому, кто планирует цикл мониторинга.
Связь просрочки со статусом и рейтингом
Просрочка переоценки не блокирует карточку сама по себе — она встроена в общий расчёт: контроль, чья методология или мониторинг которого просрочены, не сможет набрать наивысший рейтинг эффективности, а риск без активных, подтверждённых контролей не может считаться «в скоупе» самооценки. Подробнее о том, что происходит с риском при выходе из скоупа — на странице каскадной деактивации.
Что это даёт ИТ-директору
Планировщик переоценки — фоновая задача платформы с собственным журналом выполнения, отдельным от общего лога приложения, поэтому разбор «дошли ли уведомления» не требует поиска по всем логам сервера. Время запуска задаётся свойством конфигурации, а не значением, зашитым в код, — изменить расписание можно без пересборки модуля.