Что такое MDM (управление мастер-данными)

Прежде чем разбираться, стоит убедиться, что вы читаете про нужный MDM. Аббревиатура занята дважды, и системы не имеют между собой ничего общего.

• Master Data Management — управление мастер-данными: единые справочники клиентов, контрагентов, товаров. Задача — качество и непротиворечивость данных. Об этом дальше вся статья.
• Mobile Device Management — управление корпоративными мобильными устройствами: выдача политик, удалённая блокировка, установка приложений. Задача — безопасность парка телефонов и планшетов.

Если вам нужен второй вариант, ищите по «управление мобильными устройствами» или EMM/UEM — так выдача будет точнее.

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

В России рядом живёт термин НСИ — нормативно-справочная информация, и его часто используют как синоним. Точнее считать НСИ частью мастер-данных: это справочники и классификаторы (единицы измерения, виды деятельности, категории товаров), тогда как мастер-данные включают ещё и «живые» сущности вроде конкретного контрагента с его реквизитами.

MDM никогда не внедряют «на все данные сразу». Работают доменами — по типам сущностей, и первый домен выбирают по тому, где ошибки дороже всего.

• Клиенты и контрагенты. Самый частый старт: дубли мешают считать выручку, работать со скидками и понимать, кому вы уже продаёте. Отсюда прямая связь с разработкой CRM под процесс — в CRM эти дубли видны первыми и мешают ежедневно.
• Номенклатура и товары. Один и тот же артикул под разными названиями от разных поставщиков — боль дистрибуции, ритейла и производства.
• Поставщики. Нужны, чтобы видеть весь оборот с группой компаний, а не с семью её юрлицами по отдельности.
• Сотрудники и организационная структура. Критично там, где от структуры зависят доступы и согласования.
• Места и активы. Склады, точки, оборудование — часто недооценённый домен, без которого не сходится логистика.

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

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

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

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

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

Слияние и правила выживания (survivorship). Из группы найденных дублей собирается эталон. Правила решают, чьё значение поля побеждает: у ИНН доверяем ЕГРЮЛ, у адреса — последнему подтверждённому, у названия — источнику с наивысшим приоритетом.

Распространение. Эталон отдаётся обратно в системы-потребители — через API, шину или репликацию. Здесь и живёт основная серверная часть такого решения: очереди, идемпотентность, разрешение конфликтов при одновременных правках.

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

Это тот раздел, из-за которого проекты по данным затягиваются, и его почти не встретишь в обзорах MDM. Алгоритмы сопоставления, обученные на латинице и западных адресах, на русских данных работают заметно хуже.

Типовые ловушки: «ООО „Ромашка“», «Ромашка, ООО» и «ромашка ооо» — одна компания, три строки. Фамилия в двух вариантах написания через «е» и «ё». Адрес «г. Москва, ул. Ленина, д. 5 к. 2» против «Москва, Ленина 5/2». Номенклатура, где поставщик пишет «болт М8х40 ГОСТ 7798», а склад — «Болт M8*40».

Классификация Gartner, которую используют все вендоры. Выбор стиля — это выбор того, кто в вашем ландшафте главный по данным.

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

Техническая часть MDM — меньшая половина проекта. Большая — договорённости о том, кто отвечает за данные, и ежедневная работа по их поддержанию.

Ключевые роли две. Владелец домена данных — руководитель со стороны бизнеса, который решает спорные вопросы: как правильно называется контрагент, какой источник главный, что считать дублем. Data steward — специалист, который каждый день разбирает спорные группы, правит атрибуты и следит за качеством.

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

Полезно завести и метрики качества: доля записей с заполненным ключом, количество спорных групп в очереди, время до разбора, число автослияний. Без цифр governance превращается в декларацию.

Честный разговор, который вендор платформы обычно не заводит. MDM — тяжёлая дисциплина, и в ряде случаев проблему решают дешевле.

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

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

Проверочный вопрос перед стартом: способны ли вы назвать одно конкретное решение, которое сегодня принимается неверно из-за состояния данных? Если да — проект окупится. Если ответ «просто хотим порядок», сначала стоит найти это решение.

Западные MDM-платформы — Informatica MDM, SAP Master Data Governance, IBM MDM, Oracle Customer Hub — с российского рынка ушли, и вопрос замены встал остро: справочники нельзя «поставить на паузу».

Что представлено сейчас: Юнидата (Unidata MDM) — платформа в реестре российского ПО (запись №11696, решение от 27.09.2021), с редакциями от стандартной до высоконагруженной; 1С:MDM — логичный выбор там, где ландшафт уже вокруг 1С; а также «Компо MDM», 7TECH MDM, «Крок НСИ», «Гармония MDM», «Планета.НСИ». Класс закрыт неплохо — выбор идёт не по принципу «есть ли аналог», а по нагрузке, доменам и интеграциям.

На что смотреть при выборе:

• Наличие в реестре отечественного ПО — обязательное условие для госкомпаний, объектов КИИ и части закупок.
• Работа с вашими объёмами — миллионы записей и десятки правил матчинга ведут себя иначе, чем демо на сотне строк.
• Рабочее место стюарда — насколько им реально пользоваться каждый день.
• Интеграции с вашим ландшафтом — 1С, CRM, склад, шина: есть ли коннекторы или всё придётся писать.
• Миграция правил — если вы уходите с западной платформы, правила матчинга и очистки придётся переносить, и это отдельный проект, а не пункт в чек-листе.

Третий путь между «купить платформу» и «ничего не делать» существует и часто оказывается самым практичным.

Порядок, который снижает риск утонуть в данных.

Шаг 1. Найти дорогое решение. Не «навести порядок», а конкретное решение или процесс, который сейчас ломается из-за данных. Это и будет критерий успеха.

Шаг 2. Выбрать домен и границы. Один домен — например, контрагенты. Договориться, какие источники входят в объём, а какие пока нет.

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

Шаг 4. Договориться о правилах. Приоритеты источников, правила выживания полей, критерии дубля, пороги автослияния. Это работа с бизнесом, а не с базой.

Шаг 5. Собрать конвейер и рабочее место. Нормализация, матчинг, слияние, распространение — и интерфейс стюарда с первого дня, не «на второй фазе».

Шаг 6. Запустить обратный поток. Эталон должен вернуться в системы-потребители, иначе порядок останется внутри хаба.

Шаг 7. Тиражировать. Следующий домен по той же механике, с уже отработанными правилами и метриками.

Начать со всех доменов сразу. Классический способ получить два года работы без результата. Один домен, один процесс, измеримый эффект — потом следующий.

Считать MDM техническим проектом. Правила «что считать дублем» и «чей адрес правильный» знает бизнес, а не разработчики. Без владельца домена проект встанет на первом же споре.

Забыть про обратный поток. Эталон собран, а в CRM всё те же семь «Ромашек». Пользователи справедливо считают, что ничего не изменилось.

Не дать стюарду инструмент. Разбор дублей в Excel и переписке работает первые две недели, потом очередь растёт, и очистка перестаёт делаться вообще.

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

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

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