Процесс, риск, контроль, мониторинг: единая цепочка
MCA (Manager’s Control Assessment) ведёт самооценку по одной сквозной цепочке: у каждого процесса — свои риски, у каждого риска — свои контроли, у каждого контроля — свои мониторинги. Ни один уровень не существует в отрыве от остальных: карточку риска нельзя включить в оценку без контролей, а контроль — без мониторингов, которые подтверждают, что он действительно работает.
Объекты цепочки и их связь
Четыре типа карточек — процесс, риск, контроль, мониторинг — образуют одну цепочку: процесс порождает риски, риск — контроли, которые его снижают, контроль — мониторинги, которые подтверждают, что он реально исполняется. У всех четырёх типов — одна и та же внутренняя механика: общий статус, общий порядок согласования, общий владелец и заместитель владельца. Это значит, что сотруднику, который один раз разобрался с карточкой риска, не нужно заново учиться работать с карточкой контроля или мониторинга — экран, кнопки и правила те же самые.
Каждая карточка получает собственный человекочитаемый номер — риск R12, контроль C34, мониторинг M56 — и на него можно сослаться в переписке или отчёте, не открывая систему.
Справочники-таксономии
Имя и описание карточки риска, контроля или мониторинга не вводятся вручную — они берутся из общего справочника-таксономии, к которому карточка привязана. Это исключает ситуацию, когда один и тот же риск в двух подразделениях называется по-разному: название всегда одно, потому что источник один.
Риск или контроль добавляются в карточку через модальное окно «Выбрать из справочника»: дерево таксономии, множественный выбор, выбирать можно только конечные узлы — категорию верхнего уровня целиком добавить нельзя, только конкретный пункт. Система также не даёт добавить один и тот же риск в процесс дважды: при повторной попытке выводится предупреждение «Риск "{0}" уже был добавлен».
Правила создания карточек
Любая новая карточка — риск, контроль или мониторинг — создаётся в статусе «Черновик» (рабочий план на стадии наполнения) и сразу получает пустую анкету самооценки: заполнять её можно постепенно, ничего не теряя между сессиями. У вновь добавленного риска сразу выставляется признак «требует тестирования» и статус «Нет оценки» по общему рейтингу контролей — до первой оценки система явно показывает, что решения ещё нет, а не подставляет благополучный результат по умолчанию.
Без готового решения — не «эффективно», а «нет оценки»
Риск, по которому ещё не выставлена ни одна оценка контроля, не выглядит ни хорошим, ни плохим в отчётах — он помечен как неоценённый, и это невозможно перепутать с «риск проверен и признан контролируемым».
Обязательные и утверждаемые поля
По каждому типу карточки система разводит три разных списка полей: что считается автоматически, что требует согласования при изменении на активной карточке, и что обязано быть заполнено, прежде чем карточку вообще можно активировать. Это не три пересекающихся набора «на всякий случай» — это три разных момента жизненного цикла, где поле имеет значение.
| Карточка | Считается автоматически | Требует согласования при изменении |
|---|---|---|
| Риск | Присущий риск, остаточный риск | Статус, описание, признак «требует тестирования», ответственный, заместитель |
| Контроль | Рейтинг адекватности, эффективность | Статус, название, описание, уровень автоматизации, тип и периодичность, цель, подтверждение выполнения, ответственный, заместитель |
| Мониторинг | Адекватность мониторинга | Статус, название, описание, частота, цель мониторинга, порог и его тип, покрытие, ответственный, заместитель |
Расчётные поля недоступны для ручного ввода в принципе — значение подставляет система по результатам анкеты и связанных объектов. Изменить их «руками» нельзя, только повлиять на них через анкету, мониторинги и привязанные нарушения.
Правила активации и каскадная деактивация
Активировать карточку раньше времени не получится: риск нельзя перевести в статус «Активен», пока не рассчитан присущий риск и пока у него нет ни одного активного контроля, а контроль — пока под ним нет ни одного активного мониторинга. Это не подсказка, а жёсткая проверка: попытка активации при незаполненном обязательном поле останавливается сообщением «Невозможно активировать Риск {0}: не заполнено обязательно поле {1}», а без контролей или мониторингов — отдельными сообщениями «Невозможно активировать риск без активных контролей» и «Невозможно активировать контроль без активных мониторингов».
Риск исключён из области обязательного контроля — контроли и мониторинги автоматически деактивируются
Для присущего риска установлен порог обязательного контроля: риски уровней 1–3 должны иметь контроли и мониторинги; для рисков уровней 4–5 это требование не применяется. Как только присущий риск пересчитывается ниже этого порога, признак «требует тестирования» снимается автоматически — и вместе с ним каскадно деактивируются все активные контроли этого риска и все мониторинги под ними. Реестр не копит контроли, которые перестали быть нужны математически, но остались активными по инерции.
Массовые команды на дереве процессов — «Активировать риск и все уровни ниже», «Деактивировать все контроли», «Активировать все мониторинги» и подобные — применяют те же самые проверки сразу ко всей ветке, а не только к одной карточке.
Правила удаления карточек
Удалить карточку может только её создатель, и только пока она в статусе «Черновик» — после первой же активации кнопка удаления перестаёт быть вариантом: карточку с историей нельзя просто стереть, только деактивировать. Удаление риска или контроля забирает с собой всю нижестоящую ветку, но лишь при одном условии — каждый дочерний элемент тоже должен быть в статусе «Черновик». Если хотя бы один контроль или мониторинг уже прошёл дальше черновика, система останавливает удаление сообщением «Невозможно удалить: существуют дочерние элементы со статусом, отличным от Черновик» — так рабочая история контроля не может пропасть вместе с удалением риска над ним.
Мониторинг — нижний уровень цепочки, поэтому его удаление в статусе «Черновик» проходит всегда без дополнительных проверок дочерних объектов.
Что это даёт ИТ-директору
Единая модель поведения для всех четырёх типов карточек означает предсказуемую нагрузку на обучение и поддержку: правила согласования, история изменений и права доступа устроены одинаково на риске, контроле и мониторинге, а не описаны отдельно для каждого экрана. Пересчёт запускается событием сохранения или согласования и идёт через общий расчётный движок платформы — отдельного пересчётного сервиса для MCA разворачивать не нужно. Все действия по цепочке — от активации до удаления — фиксируются в общей истории изменений, которую можно выгрузить для аудита или разбора инцидента.