MDM/НСИ ведение и согласование нормативно-справочной информации
Запросить демонстрациюДемонстрация
MDM/НСИ: ведение и согласование нормативно-справочной информации

Остановите правки нормативно-справочной информации «на глазок»: каждое изменение проходит подтверждение другим сотрудником, фиксируется в журнале до последнего поля — и без единой строчки нового кода становится доступно сразу всем модулям риска и комплаенса.

607 сущностей и 1792 показателя платформы больше не живут в разрозненных Java-классах и жёстко закодированных таблицах: 19 справочников редактируются по одному сценарию — черновик, согласование сотрудником, отличным от автора правки, запись каждого расхождения по каждому полю в журнал изменений. Новый справочник или новое поле заводится данными (миграцией и CSV), а не переписыванием модели.

Записаться на демо-показ

MDM — Master Data Management (общепринятый отраслевой термин управления нормативно-справочной информацией); НСИ — нормативно-справочная информация (общепринятый термин в российской банковской практике).

Что это

Не справочник-администратор поверх кода, а модельный слой платформы. Сущность (какая физическая таблица), показатель (какое поле, какого типа) и связь между ними описаны не Java-классами, а строками в таблицах-метаданных — а экран справочника строится по этим данным на лету.

607 сущностей описано в индикативной схеме платформы grounding.json → platform_usage.metadata_volume
1792 показателя (атрибута) у этих сущностей grounding.json → platform_usage.metadata_volume
4794 связи сущность–показатель, по которым строятся формы и таблицы grounding.json → platform_usage.metadata_volume
19 справочников редактируется через интерфейс модуля grounding.json → purpose.editable_directories_19
42% Java-файлов платформы (971 из 2296) опираются на эту схему grounding.json → platform_usage.code_coverage
3 роли модуля: Оператор НСИ, Менеджер НСИ, Администратор ИБ grounding.json → security_and_roles.roles

Выгода считается не в лицензии, а в отказе от ручной синхронизации. Сокращение трудозатрат на подготовку к проверкам и защита от операционных убытков — за счёт того, что одни и те же справочники и метаданные видят сразу все прикладные модули платформы, а не только модуль НСИ.

Как работает цикл правки

Правка не уходит в боевые таблицы сразу. Она проходит три статуса — «Ввод данных» → «На согласовании» → «Согласовано», — и согласовать её не может тот же сотрудник, который последним её вносил.

Один человек не заведёт правку и не согласует её сам

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

Рабочее место НСИ Пример заполнения

Таблица листается вбок на узком экране.

Роль Наименование Может вносить изменения
Менеджер НСИСотрудник 1Да
Оператор НСИСотрудник 2Да
Оператор НСИСотрудник 3Нет

Право на запись выдаётся отдельной записью на каждого сотрудника и каждый справочник — не на модуль целиком.

Интерфейс модуля на нейтральных данных. Состав вкладок, статусов и колонок — как в продукте.

Один согласованный источник вместо правок в обход процесса

Разница не в интерфейсе, а в том, что у каждой правки появляется вторая подпись и след в журнале — и что тот же справочник не приходится вести второй раз в другом модуле.

Без НСИ

  • Прямая правка таблицы справочника без второй подписи и без записи в журнал изменений
  • Новое поле справочника требует правки Java-класса и релиза приложения
  • Свой список у каждого модуля риск, комплаенс и остальные модули ведут отдельные копии

Кто изменил поле и когда — видно только по логам базы данных, если их вообще кто-то смотрел.

В модуле НСИ

Вид потерь · правка сотрудника 2 На согласовании
Оргструктура · правка согласована сотрудником 3 Согласовано
Новый показатель «Дата закрытия» · заведён CSV-миграцией Без правки Java-кода

Журнал изменений по каждому полю · протокол смены статусов · отдельный журнал аудита ролей и прав

Одна и та же метамодель видна всем прикладным модулям платформы: правку в НСИ не нужно повторять руками в остальных модулях риска и комплаенса.

Ключевые механизмы

Не «система поддерживает разграничение доступа», а конкретные правила, зашитые в продукт и проверяемые на демонстрации.

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

Менеджер НСИ назначает оператора на конкретный справочник отдельной записью, и право на запись проверяется именно по этой записи. Один и тот же сотрудник может быть оператором пяти справочников и не иметь доступа к шестому.

Согласовать может только другой сотрудник

Перевести правку в статус «Согласовано» не может тот же сотрудник, который последним её вносил — проверка выполняется при каждом переходе, а не только при первом сохранении.

Черновик не трогает боевые таблицы

Набор правок хранится отдельно, в виде черновика, пока не пройдёт весь цикл статусов «Ввод данных → На согласовании → Согласовано». В целевые таблицы справочника изменения попадают только после согласования.

Каждое поле — отдельная запись в журнале

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

Аудит ролей — отдельно от аудита данных

Протокол смены статусов правки и журнал аудита безопасности модуля (кто менял роли и права) — две разные таблицы, не смешанные между собой.

Удаление — мягкое, с отменой

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

Новый справочник — без строчки нового кода

Справочник и его поля заводятся миграцией и CSV-файлами в модель «сущность — показатель», а не переписыванием Java-классов. Экран строится по метаданным автоматически.

Выгрузка защищена от формульной инъекции

Строка, начинающаяся со знака «=», запрещена к вводу — заведомо опасное значение не попадёт в выгрузку справочника в Excel.

Кому адресован модуль

Три роли в решении о покупке — и у каждой свой вопрос.

Менеджер НСИ — владелец процесса

Без назначенного ответственного за каждый справочник непонятно, кто отвечает за качество мастер-данных. Менеджер НСИ назначает операторов на конкретные справочники и отвечает за то, что в них происходит.

Администратор информационной безопасности — технический согласователь

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

Руководитель ИТ-архитектуры платформы — закупщик уровня платформы

Индикативная схема, которую ведёт НСИ, — не частность одного модуля: на неё опираются 971 из 2296 Java-файлов (42%) во всех прикладных модулях платформы риска и комплаенса. Решение о покупке НСИ — это решение об архитектуре всей платформы, а не одного рабочего места.

Отрасли

Метамодель одна и та же, различается состав справочников и привязка к нормативной базе.

Банки (кредитные организации) под надзором Банка России

Прямая привязка справочников к нормативным актам регулятора: в модуле заведён справочник «Процессы по 716П», связывающий бизнес-процессы банка с процессами конкретного нормативного акта.

Разделы модуля

Единая метамодель 607 сущностей и 1792 показателя описаны данными, а не Java-классами Ведение и согласование правок Черновик, отправка на согласование, принцип «четырёх глаз», возврат на доработку с комментарием Реестр справочников 19 справочников — от оргструктуры и процессов до справочника «Процессы по 716П» История изменений и аудит Пополевой журнал изменений, протокол смены статусов и отдельный журнал аудита безопасности модуля Интеграция с платформой 971 из 2296 Java-файлов платформы (42%) опираются на эту схему Права доступа Назначение операторов на конкретный справочник, роли «Менеджер НСИ» и «Администратор информационной безопасности» Архитектура и внедрение Состав таблиц метамодели и требования к развёртыванию

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

Границы применимости — с обеих сторон, чтобы разговор сразу шёл по существу.

Подходит

  • Банк или профучастник рынка ценных бумаг под надзором Банка России, где справочники правят несколько сотрудников и нужен второй подписант на каждую правку
  • Нужна единая метамодель для всех прикладных модулей платформы риска и комплаенса — не отдельный справочник-администратор для одной системы
  • Готовы заводить новые справочники и поля миграцией и CSV, а не ждать релиза с правкой Java-кода
  • Нужен пополевой журнал изменений и отдельный от него журнал аудита ролей и прав

Не подходит

  • Нужен самостоятельный интерфейс для создания сущностей и показателей «на лету», без миграций и CSV, — в модуле такого редактора метамодели нет
  • Нужен полный откат согласованной правки к прежней версии данных одним действием — в коде такого механизма нет, доступны журнал изменений и возврат карточки в статус «Ввод данных»
  • У вас один справочник и три сотрудника — хватит обычной таблицы; ценность НСИ — в том, что одну и ту же метамодель используют остальные модули платформы
  • Нужна работа в стороне от остальных модулей платформы риска и комплаенса — сама метамодель ценна тем, что её используют они все

Справочники — под нормативную базу Банка России

Модуль разработан с учётом требований Банка России к ведению нормативно-справочной информации: в справочниках заведена прямая привязка к 716-П. Состав справочников и полей настраивается под вашу организацию без правки кода.

Разработчик — российская компания ООО «Ланселот-ИТ». Модуль хранит персональные данные сотрудников заказчика (список операторов справочников) и разворачивается в инфраструктуре заказчика вместе с остальной платформой.

Посмотреть, как это работает

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

Записаться на демо-показ Требования к развёртыванию