Master Data Management for an operator: one source of truth for customer, product, dealer

Why an operator needs MDM

The same customer, product, tariff plan or dealer is represented in 5-15 systems of the operator. In each — its own description, its own ID, its own status. When system A says “active” and system B says “suspended”, operational incidents are inevitable.

Master Data Management is the discipline and architecture that ensures one established source of truth (golden record) for every critical business entity, and that updates are distributed from that source to all consuming systems.

Without MDM:

• Marketing targets a segment that does not match the billing one.
• Dealer commission is calculated against a reference different from regulatory reporting.
• The tariff plan is described one way in IVR, another in the app, another in the biller.

Which domains MDM covers in an operator

Customer Master. Individuals and companies. Identity fields (passport, tax ID), contacts, status, hierarchies (for corporates), segmentation.

Product Master. Tariff plans, services, bundles, content. Attributes (package minutes, gigabytes), comp/conflict rules with other products.

Dealer / Channel Master. Dealer network, points of sale, geographic hierarchy, contracts, commission models.

Network / Asset Master. Base stations, sectors, frequency bands, equipment. Geographic binding.

Reference data. Reference lists used consistently: countries, currencies, operating codes.

Not every domain requires full MDM — but those critical to the business should be covered.

Structural elements of an MDM platform

Source identification. For each entity it is defined which system is system of record (SOR), which is system of reference. SOR owns creation and update, references only consume.

Golden record builder. Logic that merges data from several sources into one record. Survivorship rules: which field wins on conflict.

Identity resolution. Matching algorithms (deterministic + probabilistic) for record deduplication. In telecom — especially for customer (several MSISDNs per person).

Distribution layer. Updates from MDM are pushed to consumer systems via event bus or batch sync. Eventual consistency guarantee.

Stewardship UI. Interface for the data steward: conflict resolution, manual merge, data quality alerts.

Audit. Who/what/when changed. Without audit MDM becomes a zone of mistrust.

Where it usually breaks

MDM is built as another data warehouse — without distributing changes back into operational systems. Analytics is fine, operations remain fragmented.

SORs are not defined. Several systems consider themselves the source of truth for one entity — and MDM resolves conflicts case by case “as it goes”. A year later trust is lost.

Stewardship is not staffed as a function. Data conflicts accumulate, nobody resolves them.

MDM tries to cover everything at once. After 18 months a large project with no visible business effect is cancelled.

Distribution is slow (overnight batch). Operational systems get updates a day later, recreating divergences.

Identity resolution is too strict — duplicates slip through. Or too loose — different people get merged.

Operating model

Owner — Chief Data Officer or Head of Master Data. A cross-functional role with mandate to cross business domains.

Teams:

• MDM platform engineering
• Data stewards per domain (customer steward, product steward, dealer steward)
• Data quality (monitoring, alerts, root cause)

Routine — weekly data quality review per domain, quarterly business review with domain owners.

What is measured

Match rate — what share of entities is automatically deduplicated without stewardship intervention.

Distribution lag — how long an update takes to reach the consuming system.

Conflict resolution time — how long it takes to resolve a conflict between sources.

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

How SamaraliSoft engages

MDM Blueprint — 8-10 weeks. Domain prioritisation, current SOR landscape, target architecture design, identity resolution approach, governance, platform choice (Informatica, Reltio, build). Pilot — usually one domain (customer or product) with 3-5 consumer systems.

Related

• /en/architecture/telecom-cdp-architecture/ — CDP as customer master consumer
• /en/architecture/telecom-event-bus-architecture/ — event bus for distribution
• /en/insights/telecom-data-quality/ — data quality
• /en/architecture/telecom-data-platform/ — data platform