Архитектура

Master Data Management для оператора: один источник правды по клиенту, продукту, дилеру

У оператора пять «правильных» версий клиентского имени. MDM устанавливает источник истины для критических справочников и обеспечивает их распространение.

Обсудить задачу

Зачем оператору MDM

Один и тот же клиент, продукт, тарифный план или дилер представлен в 5-15 системах оператора. В каждой — своё описание, свой ID, свой статус. Когда система A говорит «активен», а система B — «приостановлен», операционные инциденты неизбежны.

Master Data Management — дисциплина и архитектура для того, чтобы для каждой критической бизнес-сущности существовал один установленный источник истины (golden record), и чтобы обновления распространялись из этого источника во все потребительские системы.

Без MDM:

Маркетинг таргетит по сегменту, который не совпадает с биллинговым.
Дилерская комиссия рассчитывается по справочнику, отличному от регуляторной отчётности.
Тарифный план в IVR описан иначе, чем в app, иначе чем в biller.

Какие домены охватывает MDM в операторе

Customer Master. Физлица и юрлица. Поля идентичности (паспорт, ИНН), контакты, статус, иерархии (для корпоративных), сегментация.

Product Master. Тарифные планы, услуги, бандлы, контент. Атрибуты (пакетные минуты, gigabytes), правила comp/conflict с другими продуктами.

Dealer / Channel Master. Дилерская сеть, точки продаж, географическая иерархия, контракты, комиссионные модели.

Network / Asset Master. Базовые станции, секторы, частотные диапазоны, оборудование. Привязка к географии.

Reference data. Справочники, которые консистентно используются: страны, валюты, операционные коды.

Не каждый домен требует full MDM — но критические для бизнеса должны быть.

Структурные элементы MDM-платформы

Source identification. Для каждой entity определяется, какая система — system of record (SOR), какая — system of reference. SOR владеет создание и обновлением, references только consume.

Golden record builder. Логика merge данных из нескольких источников в единую запись. Survivorship rules: какое поле выигрывает при конфликте.

Identity resolution. Алгоритмы matching (deterministic + probabilistic) для дедупликации записей. В телекоме — особенно для customer (несколько MSISDN на одного человека).

Distribution layer. Updates из MDM пушатся consumer-системам через event bus или batch sync. Гарантия eventual consistency.

Stewardship UI. Интерфейс для data steward’а: разрешение конфликтов, manual merge, data quality alerts.

Audit. Кто/что/когда изменил. Без audit MDM становится зоной недоверия.

Где обычно ломается

MDM строится как ещё один data warehouse — без распространения изменений обратно в operational системы. Аналитика хорошая, операции по-прежнему фрагментированные.

Не определены SOR. Несколько систем считают себя источником истины для одной entity — и MDM разруливает конфликты в каждом случае «по обстоятельствам». Через год доверие потеряно.

Stewardship не выделена как функция. Data conflicts накапливаются, никто не разруливает.

MDM пытается охватить всё одновременно. Через 18 месяцев большой проект без видимого business effect отменяется.

Distribution медленный (batch overnight). Operational системы получают updates через сутки, что снова создаёт расхождения.

Identity resolution слишком strict — пропускает duplicates. Или слишком loose — мерджит разных людей.

Operating model

Owner — Chief Data Officer или Head of Master Data. Cross-functional роль с mandate перекрывать business domains.

Команды:

MDM platform engineering
Data stewards per domain (customer steward, product steward, dealer steward)
Data quality (мониторинг, алерты, root cause)

Routine — еженедельный data quality review per domain, ежеквартальный business review с domain owners.

Что меряется

Match rate — какая доля entity автоматически дедуплицируется без stewardship intervention.

Distribution lag — сколько времени update доезжает до consumer-системы.

Conflict resolution time — сколько занимает разрешение конфликта между источниками.

Data quality scores per domain — completeness, accuracy, timeliness.

Как SamaraliSoft подключается

MDM Blueprint — 8-10 недель. Domain prioritization, текущий ландшафт SOR, дизайн target architecture, identity resolution approach, governance, choice of platform (Informatica, Reltio, build). Pilot — обычно один domain (customer или product) с 3-5 consumer-системами.