Рабочее место ответственного должностного лица по ПНИИИМР

Реестр событий и реестр предсобытий: два взгляда на один поток

Риск, который это снимает. Пока сообщения о возможных нарушениях живут в почте и таблицах, ответственное лицо не может назвать их количество — а значит, не может доказать, что рассматривались все. Первое, что спрашивают при проверке, — полнота учёта.

Как устроено. Реестр событий регуляторного риска и реестр предсобытий — это одно табличное представление с противоположными фильтрами по статусу: в реестре предсобытий видны только необработанные сообщения, в основном реестре — всё остальное. Ответственное лицо смотрит на два разных вопроса: «что ещё не оценено» и «что в работе». В представлении реестра настроены 26 колонок.

Узел меню, на который у сотрудника нет права, не строится вовсе — состав навигатора у ответственного должностного лица и у рядового работника разный. Это не косметика: сотрудник с единственной ролью координатора видит реестр предсобытий в урезанном представлении и работает только со своим участком, а полный реестр ему просто не показывается.

Запросы информации с установленной и фактической датой ответа

Риск, который это снимает. «Мы запросили, нам не ответили» — самое частое объяснение, почему разбор события затянулся, и самое слабое: подтвердить его нечем, если запрос был отправлен письмом. Пункт 1.1.22 Методических рекомендаций № 23-МР прямо говорит о форме запроса, требованиях к его содержанию и сроках рассмотрения.

Как устроено. Запрос — самостоятельная запись, привязанная к событию, с собственными реквизитами и вложениями. Он ведётся на отдельной вкладке карточки, у которой свои права на чтение и изменение. В маршруте ему соответствуют статусы «Запрос информации у инициатора» и «Информация по запросу предоставлена»: пока ответа нет, событие не движется дальше, и это видно в реестре.

Механизм запросов работает на пункт 1.1.22 Методических рекомендаций № 23-МР о порядке запроса инсайдерской информации: форма запроса, содержание, сроки рассмотрения и полученный ответ фиксируются в карточке события — см. карту «требование ↔ функция».

Двухпороговый контроль сроков: жёлтая линия и критическая линия

Риск, который это снимает. Просрочка обнаруживается тогда, когда её уже нечем исправить. Человеческий фактор здесь неустраним по-другому: следить за сроками по десяткам событий вручную невозможно, а один общий срок «14 дней» ничего не даёт — нужен сигнал заранее.

Как устроено. Для каждого статуса задаются два порога в минутах от даты последнего изменения карточки: «жёлтая линия» и «критическая линия». Из них строятся два непересекающихся диапазона, поэтому событие не получает оба оповещения сразу. Если задан только один порог, работает только он.

Третья особенность, о которой важно знать при настройке: пороги считаются от даты последнего изменения карточки, а не от даты регистрации события. Любая работа по событию — комментарий, правка поля, смена статуса — сдвигает отсчёт вперёд. Это защищает от ложных срабатываний по активно разбираемым событиям, но требует осознанного выбора значений порогов.

Кому и как уходит оповещение

Адресаты определяются членством в роли: оповещение получают те, кто может выполнить следующий шаг по этому событию. Дополнительно может проверяться подразделение, обнаружившее событие, — тогда сигнал уходит не всем носителям роли, а тем, кто отвечает за конкретный участок.

Помимо оповещений о сроках, система рассылает сообщения о назначении ответственным, создании события, смене статуса, назначении меры и новом комментарии — всего 11 типов. Отдельно стоит предупреждение о том, что событие останется без рассмотрения, если следующий статус недоступен ни одному пользователю системы: это предохранитель против обрыва маршрута согласования, о котором подробно сказано в разделе о правилах внутреннего контроля.

Оба канала включаются флагами настроек. Адрес доставки берётся из служебного адреса электронной почты сотрудника в оргструктуре, поэтому его актуальность — часть регламента сопровождения, а не техническая мелочь.

Доказательная выгрузка для ответа на запрос Банка России

Статья 14 224-ФЗ даёт Банку России право требовать документы и информацию, необходимые для проверки соблюдения закона. Отвечать на такой запрос приходится не рассказом о процедуре, а материалами. Ниже — что можно выгрузить из системы.

• Протокол смены статусов события

  Дата и время, старый и новый статус, фамилия сотрудника, комментарий — по каждому событию.

  Отвечает на вопрос «как рассматривалось конкретное сообщение».

• Отчёт по событиям

  Выборка событий за период с настраиваемым составом колонок, выгрузка в офисные форматы.

  Период задаётся полузакрытым интервалом: события на дату «по» в выборку не входят — предупреждение об этом выводится прямо на форме.

• Нарушенные требования

  Ссылка на нормативный документ с точностью до абзаца: тип, номер, статья, часть, пункт, подпункт, абзац.

  Плюс отдельная таблица оснований для привлечения к ответственности.

• Журнал аудита безопасности

  Попытки входа с причиной отказа, состав ролей вошедшего, изменение пользователей, назначение и снятие ролей, правка разрешений. Выгружается в файл.

• Отчёт о своевременности

  Соблюдение сроков в шести разрезах с цветовой шкалой значений.

• Интерактивная отчётность

  Произвольные срезы по событиям для внутренней отчётности перед руководством.

  Каждый отчёт — самостоятельный объект доступа с отдельным правом на чтение.

День ответственного должностного лица

1. Утро: реестр предсобытий Что поступило со вчерашнего дня — из почтового ящика, от работников, загрузкой. Каждое сообщение нужно провести через первичную валидацию: другого выхода из статуса «Предсобытие» в маршруте нет.
2. Просроченное Оповещения жёлтой и критической линии показывают события, по которым нет движения дольше установленного порога. Отсчёт ведётся от последнего изменения карточки.
3. Запросы без ответа Разница между установленной и фактической датой ответа видна в карточке события — просрочку не нужно вспоминать, она зафиксирована.
4. Согласование События, дошедшие до финального звена, требуют решения эксперта: закрыть, вернуть СПНП или отправить в черновик. Каждый из этих переходов требует непустого комментария.
5. По запросу регулятора Протокол смены статусов, отчёт по событиям, перечень нарушенных требований и журналы выгружаются из системы, а не собираются по переписке.

Что это даёт ИТ-директору

• Одно рабочее место вместо набора файлов. Реестр, карточка из 12 разделов, запросы, чат по событию, оповещения и отчётность — в одном приложении с одной моделью доступа.
• Оповещения не требуют внешнего планировщика. Расписание задаётся свойством конфигурации; каналы «в системе» и «по почте» включаются независимо.
• Данные оргструктуры не дублируются. Сотрудники и подразделения загружаются регламентным импортом из кадровой системы и службы каталогов; адрес доставки оповещений берётся оттуда же.
• Выгрузки без выгрузки базы. Отчёты и журналы сохраняются в файл из интерфейса — обращаться к базе данных напрямую для ответа регулятору не нужно.

Требования к инфраструктуре, поддерживаемые системы управления базами данных и варианты развёртывания подтверждает поставщик на этапе пилота.

Куда идти дальше

• Контрольный контур выражен ролями «Эксперт ПНИИИМР», «Сотрудник СПНП», «Сотрудник СВК», «Аудитор» и другими; сопоставление этих ролей подразделениям организации закрепляется в матрице доступа при внедрении.
• Подотчётность выражена конструкцией маршрута: финальное согласование замкнуто на эксперта ПНИИИМР.
• Замещение выполняется переназначением роли: права привязаны к роли, а не к человеку, поэтому передача участка работы занимает одно действие администратора.

Смежные разделы: маршрут события и статусная модель; порядок доступа и разграничение прав; карта «требование ↔ функция» по статье 11; ответственность по статье 15.35 КоАП РФ.