Согласование критичных изменений и история решений
Изменение критичного поля на активной карточке MCA (Manager’s Control Assessment) не применяется в тот же клик. Оно уходит в очередь на подтверждение, а прежнее значение остаётся в силе, пока кто-то другой не согласится с изменением.
Запрет согласования собственных изменений
Разделение полномочий — это защита от собственной ошибки и от чужого злоупотребления, а не бюрократическая формальность: тот, кто внёс изменение, не может его же и подтвердить. Система проверяет это на уровне действия, а не полагается на дисциплину: при попытке согласовать собственную правку она останавливает операцию сообщением «Нельзя согласовать собственные изменения». Одного и того же человека невозможно назначить ответственным и заместителем ответственного одновременно — за это отвечает отдельная проверка при выборе сотрудников на карточке.
Четыре глаза — не пожелание, а условие сохранения
Правило работает на уровне действия «Согласовать», а не на уровне интерфейса — обойти его сменой роли на том же аккаунте нельзя: система проверяет, что автор изменения и согласующий — разные сотрудники.
Очередь согласования и правило «было → стало»
Изменение критичного поля на уже активной карточке не подменяет значение сразу: старое значение продолжает действовать, а предложенное — уходит отдельной записью в историю с пометкой «требует подтверждения». Пока запись висит без решения, сама карточка считается нередактируемой — по ней нельзя внести новое изменение поверх неподтверждённого. Согласующий видит ровно то, что предлагается изменить: и старое, и новое значение рядом, без необходимости лезть в историю отдельно.
Проведите пальцем по таблице, чтобы увидеть статус.
| Поле | Было | Стало | Статус |
|---|---|---|---|
| Частота контроля | Ежемесячно | Ежеквартально | Требует подтверждения |
| Ответственный | — | — | Согласовано |
| Признак «требует тестирования» | Да | Нет | Отклонено |
Решение по предложенному изменению — три исхода: согласовать (значение переносится в карточку и автор получает уведомление «Изменение согласовано»), отклонить (карточка остаётся как есть, автор получает «Изменение отклонено» с комментарием) или запросить дополнительную информацию — тогда комментарий проверяющего добавляется к карточке, а запись остаётся открытой до следующего решения.
История изменений по каждому индикатору
В истории MCA изменения фиксируются по каждому полю: указываются карточка, название поля, прежнее и новое значения. Также записываются изменения ответов анкеты и привязка или отвязка нарушений и событий операционного риска с названием соответствующего объекта. История карточки позволяет определить, что и когда изменилось, без ручного сравнения выгрузок.
Роли, участвующие в согласовании
Создатель заполняет и предлагает изменения, проверяющий их согласовывает или отклоняет — право на согласование выдаётся отдельной именованной функцией, а не следует автоматически из факта редактирования. На дереве процессов согласование каскадное: подтверждение на уровне процесса последовательно проходит по всем его рискам, их контролям и их мониторингам одним действием — так же работает и отклонение. После согласования мониторинга запускается пересчёт показателей по всей ветке вверх.
Прослеживаемость решений
Отдельная кнопка «Согласовать оценку адекватности» доступна проверяющему именно тогда, когда дата следующей переоценки контроля или мониторинга уже наступила или прошла, — подробнее на странице сроков и уведомлений. Каждое такое решение, как и любое действие в модели прав модуля, попадает в отдельный журнал безопасности с действием, датой, администратором и сотрудником — подробнее в разделе регистрации модуля в реестре безопасности.
Что это даёт ИТ-директору
Запрет самосогласования и очередь «было → стало» реализованы на уровне серверной логики модуля, а не только интерфейса — их нельзя обойти прямым вызовом с другого экрана. История изменений и журнал безопасности — независимые записи: первая объясняет, что произошло с данными, второй — кто и когда выполнил административное действие. Оба выгружаются для процессов аудита без обращения к разработчику.