Що таке 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 пов'язує їхні записи про спільні об'єкти та керує еталонними значеннями. Чи повертаються виправлення в ці системи, залежить від обраної моделі.
Хто в компанії відповідає за майстер-дані?
Власник даних від бізнесу визначає правила для свого домену, наприклад комерційний директор для клієнтів. Стюард даних щодня розбирає спірні збіги. ІТ відповідає за платформу та інтеграції, але не за те, яке значення правильне.