Что такое MDM: управление мастер-данными простыми словами
MDM (Master Data Management, управление мастер-данными) — это процессы, правила и технологии, благодаря которым CRM, ERP и другие системы компании используют согласованные данные о клиентах, товарах, поставщиках и других ключевых объектах. Результат MDM — эталонная, или «золотая», запись о каждом объекте и связь этой записи с карточками во всех системах.
Что такое мастер-данные
Мастер-данные — это справочники о бизнес-объектах, на которые ссылаются все операции компании: клиенты, товары, поставщики, склады, сотрудники, финансовые иерархии. Они отвечают на вопросы «кто» и «что», а транзакционные данные фиксируют событие: кто и что купил, когда и за сколько.
| Тип данных | Примеры | Что происходит при ошибке |
|---|---|---|
| Мастер-данные: бизнес-объекты | Контрагент, товар, склад, подразделение | Ошибка расходится по всем операциям и отчётам, где использован этот объект |
| Транзакционные данные: события | Заказ, счёт, отгрузка, платёж | Обычно затрагивает конкретную операцию |
| Справочные значения: стандартные перечни | Валюты, страны, единицы измерения | Данные сложно сравнивать между системами |
Поэтому одна неточная карточка может затронуть больше, чем одна неточная операция. Если клиент заведён дважды, распыляются его история сделок, дебиторка и объём продаж, а менеджер и финансист видят разные цифры об одной компании.
Что такое золотая запись: пример контрагента
Золотая запись (англ. Golden Record) — это согласованная версия объекта, собранная из нескольких источников по утверждённым правилам. Она не обязательно копирует одну из имеющихся карточек: каждый атрибут может происходить из того источника, которому для этого поля компания доверяет больше всего.
Условный пример. Одна компания записана в трёх системах по-разному:
| Атрибут | Что записано в системах | Золотая запись |
|---|---|---|
| Название | CRM: «Агрозахид»; учёт: ООО «Агро-Захид»; Excel: «Агро Захид ООО» | ООО «Агро-Захид» (из учёта) |
| Код ЕГРПОУ | CRM и Excel: пусто; учёт: код есть | Код из учёта |
| Юридический адрес | CRM: старый; учёт: актуальный; Excel: пусто | Адрес из учёта |
| Контактное лицо | CRM: актуальное; учёт: пусто; Excel: старое | Контакт из CRM |
Правила выбора значений здесь простые: реквизиты берём из учёта, контакты из CRM. В реальном проекте их согласовывают отдельно для каждого поля, а спорные случаи передают стюарду данных, то есть сотруднику, который решает, действительно ли это одна компания. Карточки в источниках при этом не исчезают: они сохраняют свои локальные коды и связываются с общим MDM-идентификатором.
Почему кода ЕГРПОУ не всегда достаточно
Для украинских юридических лиц код ЕГРПОУ — естественный ключ сопоставления. Однако правила нельзя строить только на нём, потому что есть исключения.
- ФЛП. Физические лица-предприниматели не имеют кода ЕГРПОУ, их идентифицируют по 10-значному налоговому номеру (РНУКПН). Это персональные данные, поэтому поле требует отдельных прав доступа и не должно попадать в каждый отчёт.
- Обособленные подразделения. Филиал может иметь собственный код, а может идентифицироваться через код юридического лица и внутренний номер подразделения. Нужно заранее решить, отдельный это объект или часть родительской записи.
- Несколько точек одной компании. В дистрибуции одно юридическое лицо может иметь много адресов доставки. По коду они совпадают, но для логистики это разные объекты.
- Правильный формат не означает правильный код. Код ЕГРПОУ содержит восемь цифр, последняя контрольная. Такая проверка ловит опечатки, но не показывает, что компания существует и действует. Для этого нужна сверка с внешним реестром, например через интеграцию YouControl с CRM.
- Записи без кода и нерезиденты. Старые файлы и иностранных контрагентов приходится сопоставлять по нормализованному названию, адресу, телефону или налоговому номеру страны, то есть нечётким поиском с проверкой человеком.
Ошибка здесь дорога: автоматическое объединение двух разных компаний исправить сложнее, чем пропущенный дубликат. Поэтому в проектах Progresia правила сопоставления сначала проверяем в пилоте, а автоматически обрабатываем только надёжные совпадения. Остальное идёт в очередь стюарда.
Четыре модели MDM: где живёт эталон
Модель MDM определяет, где хранится золотая запись и возвращаются ли исправления в рабочие системы. Четыре распространённые модели отличаются именно этим, хотя поставщики описывают границы между ними немного по-разному.
| Модель | Как работает | Когда уместна и ограничения |
|---|---|---|
| Реестр | Хранит соответствия ключей между системами, а источники не меняет | Быстро связывает данные для отчётов и поиска, но ошибки в источниках остаются |
| Консолидация | Собирает копии в центральном хранилище, очищает и формирует эталон для аналитики | Главная цель — отчётность, однако рабочие системы исправлений не получают |
| Сосуществование | Эталон формируется централизованно и синхронизируется обратно в источники | Исправленные данные нужны в CRM и ERP, поэтому надо согласовать направления обмена и разрешение конфликтов |
| Централизованное ведение | Новые записи создают и меняют только в MDM, другие системы подписаны на него | Самый строгий контроль справочника, но и самое большое изменение процессов для бизнеса |
Модели не обязательно выбирать раз и навсегда. Одна компания может применить сосуществование для контрагентов и реестр для локаций, а начать с более лёгкой модели и со временем перейти к более сложной. Как выбрать технологии под модель, мы разобрали в статье MDM на Microsoft: Dataverse, Fabric, Purview или отдельная платформа.
Чем MDM отличается от CRM, ERP и хранилища данных
MDM не заменяет ни одну из этих систем. Каждая из них ведёт данные для своих задач, а MDM следит за тем, чтобы общие объекты совпадали между ними.
| Система | Её задача | Чего она не делает за MDM |
|---|---|---|
| CRM | Продажи, сервис, работа с клиентами | Не согласует своих клиентов с карточками в ERP или Excel |
| ERP / учёт | Финансы, склад, производство | Ведёт собственные справочники, даже если они качественные |
| Хранилище данных и BI | Аналитика и отчётность | Показывает расхождения, но не решает, какое значение правильное |
| Каталог данных | Описывает, какие данные есть и где они лежат | Сам не формирует золотые записи |
| Разовая дедупликация | Убирает имеющиеся дубликаты | Не мешает новым дубликатам появляться завтра |
Когда MDM нужно, а когда нет
Отдельный MDM-контур оправдывает себя, когда общие объекты живут минимум в двух системах и расхождения уже стоят денег или времени.
- Отчёты не сходятся. Продажи и финансы показывают разные цифры по одному клиенту, потому что группируют разные карточки.
- Сверка стала работой. Кто-то регулярно вручную сопоставляет справочники в Excel.
- Один товар имеет разные коды. ERP, сайт и поставщики используют собственные артикулы без надёжного соответствия.
- Появился новый источник. После слияния, нового юрлица или интернет-магазина появилась ещё одна база со своими кодами.
- Планируете миграцию или AI. Перенос или подключение помощников к грязным данным умножает имеющиеся проблемы.
А вот когда MDM, скорее всего, лишнее:
- Система фактически одна. Если дубликаты только в одной CRM, сначала стоит настроить встроенные механизмы. В Dataverse это правила обнаружения дубликатов и объединение записей для организаций, контактов и лидов. О заполненности базы мы писали в статье качество данных в CRM.
- Справочников мало, они меняются редко. Хватит владельца данных и регламента.
- Некому принимать решения. Без владельцев данных и стюардов технология не заработает. Сначала стоит назначить людей.
Зачем MDM, если компания планирует AI
AI-помощник отвечает на основе данных, к которым имеет доступ. Если клиент существует в трёх карточках, ответ «сколько он купил в этом году» будет зависеть от того, какая карточка найдена. В феврале 2025 года Gartner спрогнозировала, что до конца 2026 года организации откажутся от 60% AI-проектов, не обеспеченных пригодными для AI данными. В том же материале говорится, что 63% организаций не имеют соответствующих практик управления данными или не уверены в них.
Это прогноз, а не измеренный результат. MDM закрывает лишь часть задачи: согласованные справочники. Для качественных ответов нужны ещё подключённые источники и правильно настроенные доступы, поэтому стоит прочитать также о безопасности Copilot и конфиденциальных данных.
С чего начать: три практических шага
Выберите один домен, где расхождения обходятся дороже всего
Обычно это контрагенты или номенклатура. Если начать со всех справочников сразу, проект растянется раньше, чем покажет результат.
Измерьте проблему
Сколько записей в каждой системе, какая доля без ключевых полей, сколько вероятных дубликатов. Эти цифры станут базой для сравнения после пилота.
Назначьте владельца данных и проверьте правила на пилоте
Кто-то должен решать, какое значение правильное. Только после этого стоит масштабировать решение на новые домены.
Этот путь Progresia проходит вместе с клиентом во время внедрения MDM в экосистеме Microsoft: аудит одного домена, правила сопоставления, пилот на реальных данных, а по результатам аудита честный ответ, нужен ли вам отдельный MDM-контур или достаточно улучшить имеющиеся правила и интеграции.
Частые вопросы
Что такое MDM простыми словами?
Это способ сделать так, чтобы об одном клиенте, товаре или поставщике все системы компании знали одно и то же. MDM находит записи об одном объекте, формирует эталонную версию и поддерживает её актуальной по согласованным правилам.
Чем Master Data Management отличается от Mobile Device Management?
Это разные области с общей аббревиатурой. Master Data Management управляет справочниками бизнес-данных. Mobile Device Management управляет корпоративными устройствами: настройками, приложениями и безопасностью смартфонов и ноутбуков.
Что такое золотая запись (Golden Record)?
Это согласованная эталонная версия объекта, сформированная из записей в разных системах. Каждое поле берётся из самого надёжного для него источника по утверждённым правилам, а спорные случаи решает стюард данных.
Заменяет ли MDM систему CRM или ERP?
Нет. CRM и ERP по-прежнему ведут продажи, финансы и склад. MDM связывает их записи об общих объектах и управляет эталонными значениями. Возвращаются ли исправления в эти системы, зависит от выбранной модели.
Кто в компании отвечает за мастер-данные?
Владелец данных от бизнеса определяет правила для своего домена, например коммерческий директор для клиентов. Стюард данных ежедневно разбирает спорные совпадения. ИТ отвечает за платформу и интеграции, но не за то, какое значение правильное.