Управление НСИ: как построить MDM-контур

Управленческая задача

Контрагенты, номенклатура, ЦФО, статьи затрат, проекты, договоры и оборудование должны иметь владельцев, правила создания, проверки и изменения.

Когда проблема становится заметной

• дубли в справочниках
• разные коды одного объекта
• отчеты требуют ручной чистки
• планирование строится на неполных нормативах

Как проектировать решение

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

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

Типовые ошибки

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

Эти ошибки не всегда видны на демонстрации, но быстро проявляются в промышленной эксплуатации.

• считать НСИ технической задачей
• не описывать жизненный цикл объекта
• не контролировать изменения после запуска

Ключевые выводы

• НСИ является управленческим активом.
• У каждого мастер-объекта должен быть владелец.
• Правила качества нужны до внедрения.
• ИИ и BI зависят от надежных справочников.

Суть решения

Для темы «Мастер-данные и НСИ в корпоративной архитектуре» результат формулируется как изменение управленческой практики. В центре находится объект «показатели и пороги»: у него должны появиться согласованный источник, владелец решения и наблюдаемое состояние после действия «согласовать идентификаторы и справочники».

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

Что входит в MDM-контур

MDM управляет жизненным циклом мастер-объектов: контрагентов, номенклатуры, подразделений, проектов, договоров, оборудования и классификаторов. Для каждого объекта задаются идентификатор, атрибуты, системный источник, владелец смысла, правила создания, согласования, слияния дублей и прекращения использования.

MDM не исправляет качество само по себе. Рабочий контур включает заявки на изменение, проверки, журнал решений, публикацию эталонной записи и контроль доставки изменений в ERP, BI, APS и другие зависимые системы.

Какими объектами управляем

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

Основная граница проходит по объекту «витрины и семантические модели». Для него фиксируют системный источник, владельца смысла, владельца качества, частоту обновления и допустимые преобразования. Отдельно определяется ошибка: кто её исправляет и как изменение попадает в зависимые отчёты, планы или документы.

• Объект 1: Мастер-данные и классификаторы. Поля карточки: источник, владелец смысла, владелец качества, правило актуализации. Контрольный сигнал: Один показатель имеет несколько значений.
• Предметная область 2: Источники и преобразования. Основание проверки: системный источник, полномочия владельца и признак «пользователь не видит происхождение цифры».
• Карточка 3. Объект: Витрины и семантические модели. Обязательные сведения: идентификатор, происхождение, правило качества и событие обновления. Сигнал: Справочник меняется без владельца.

Интеграционный контракт

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

У каждого обмена есть бизнес-владелец, технический владелец и наблюдаемая точка контроля. API, очередь сообщений, файл или другая технология выбираются после определения частоты, объёма, устойчивости и модели ошибок. Для признака «панель не приводит к действию» качество оценивается до передачи и после загрузки, чтобы найти источник расхождения.

• Граница 5. Объект: Ошибки, исправления и журнал качества. Для него задаются источник, периодичность, допустимые преобразования и реакция на сигнал «ошибки исправляются только вручную».
• Контрольная запись 4. Объект: Показатели и пороги. Наблюдаемый признак: Панель не приводит к действию. Ответственность: владелец смысла и владелец качества.
• Карточка 3. Объект: Витрины и семантические модели. Обязательные сведения: идентификатор, происхождение, правило качества и событие обновления. Сигнал: Справочник меняется без владельца.

От сигнала к решению

Вопрос статьи — Мастер-данные и НСИ в корпоративной архитектуре. Смежная управленческая задача — MDM система. У этих вопросов могут совпадать данные или участники, но различаться горизонт решения, права ролей и архитектурная граница; поэтому их фиксируют отдельными строками в карте решений.

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

• Решение 1: объект — мастер-данные и классификаторы; сигнал — справочник меняется без владельца; действие — согласовать идентификаторы и справочники.
• Решение 2: объект — источники и преобразования; сигнал — панель не приводит к действию; действие — определить проверки и исправления.
• Решение 3: объект — витрины и семантические модели; сигнал — ошибки исправляются только вручную; действие — вести происхождение и версии.

Правила качества и исправления

Для объекта «показатели и пороги» последовательность начинается с действия «согласовать идентификаторы и справочники». Его выход проверяет владелец следующего шага; неполный результат возвращается с конкретным замечанием к данным, правилу, полномочию или архитектурной зависимости.

Для объекта «показатели и пороги» ведётся журнал допущений. Каждая запись содержит основание, владельца, дату пересмотра и событие, после которого допущение нужно подтвердить, изменить либо закрыть.

• Контрольная точка 1 объединяет действие «выделить ключевые объекты» и результат «мастер-данные и классификаторы».
• 2. Действие — назначить системные источники; проверяемый результат — источники и преобразования.
• Решение 3: согласовать идентификаторы и справочники. Основание для следующего шага — витрины и семантические модели.
• Шаг 4. Определить проверки и исправления. Выход: показатели и пороги.

Диагностика до выбора решения

Диагностика рассматривает конкретный эпизод, связанный с объектом «витрины и семантические модели». В карточке указываются время, участники, использованные данные, принятое решение и последствие; повторяемость проверяется по второй выборке.

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

• Событие для проверки — один показатель имеет несколько значений. Доказательство показывает время, частоту и последствие для объекта «мастер-данные и классификаторы».
• Признак: Пользователь не видит происхождение цифры. Для разбора понадобятся фактический пример и изменение объекта «источники и преобразования».
• Диагностический признак 3: Справочник меняется без владельца. Карточка содержит пример и влияние на объект «витрины и семантические модели».

Полномочия и эскалация

Матрица полномочий строится вокруг решений, связанных с объектом «ошибки, исправления и журнал качества». Отдельно назначаются право изменить правило, обязанность подготовить данные, право разрешить исключение и ответственность за подтверждение результата.

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

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

Сквозная проверка результата

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

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

• Свидетельство 1 описывает мастер-данные и классификаторы, сопоставимые условия проверки и ответственного за вывод. Сигнал: Справочник меняется без владельца.
• Проверка 2 относится к объекту «источники и преобразования». Зафиксированы методика, владелец интерпретации и источник результата. Сигнал: Панель не приводит к действию.
• Контрольная запись 3: Витрины и семантические модели; версия данных, правило расчёта, ожидаемое изменение и фактический результат. Сигнал: Ошибки исправляются только вручную.
• Для критерия 4 выбран объект «показатели и пороги»; результат сопоставляется с базовой выборкой по одной методике. Сигнал: Один показатель имеет несколько значений.

Ограничения и контроль риска

Для риска «владелец данных не имеет полномочий» формулируют наблюдаемое условие и контрольное решение. Запись также содержит владельца, срок реакции, доказательство выполнения и правило возврата, если контроль не сработал.

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

• Условие риска 1: Единая витрина без единого смысла. Ответное действие: Выделить ключевые объекты. Проверяемый факт: Витрины и семантические модели.
• Сценарий риска «качество измеряется без процесса исправления» закрывается действием «назначить системные источники» и подтверждается объектом «показатели и пороги».
• Контролируемое ограничение: self-service без каталога метрик. Владелец выполняет действие «согласовать идентификаторы и справочники» и предъявляет ошибки, исправления и журнал качества.
• Для риска «аномалия трактуется как доказанный факт» заранее назначаются действие «определить проверки и исправления» и свидетельство «мастер-данные и классификаторы».

Первая рабочая сессия

Первая сессия рассматривает один реальный случай по объекту «витрины и семантические модели». Участники приносят первичный документ или выборку, схему движения данных, действующий регламент и пример отклонения «панель не приводит к действию».

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

• Контрольная точка 1 объединяет действие «выделить ключевые объекты» и результат «мастер-данные и классификаторы».
• 2. Действие — назначить системные источники; проверяемый результат — источники и преобразования.
• Для критерия 4 выбран объект «показатели и пороги»; результат сопоставляется с базовой выборкой по одной методике. Сигнал: Один показатель имеет несколько значений.
• Критерий 5: Ошибки, исправления и журнал качества; нужны исходная выборка, ожидаемое изменение, владелец интерпретации и источник факта. Сигнал проверки: Пользователь не видит происхождение цифры.