+150 XP

Master Data Management über OSS, BSS und Netzinventar hinweg

# Master Data Management über OSS, BSS und Netzinventar hinweg

Ein einzelner Teilnehmer bei einem mittelgroßen europäischen Netzbetreiber kann als vierzehn verschiedene Kundendatensätze existieren: einer im Billing-System, einer im CRM (Customer Relationship Management), einer in der Fraud-Engine, einer in jedem regionalen Bestand aus einer Fusion, deren Migration nie abgeschlossen wurde. Bitten Sie diesen Kunden, seinen Tarif zu upgraden und eine zweite Leitung zu kündigen, und es besteht eine reale Chance, dass die Änderung auf dem falschen Datensatz landet. Das ist kein hypothetischer Fall. Es ist der Alltag der meisten Telekom-IT-Landschaften, und genau deshalb ist Master Data Management (MDM) eine der wirksamsten und am wenigsten glamourösen Disziplinen der Branche.

Warum die Datenlandschaft im Telekombereich zerfällt

Netzbetreiber arbeiten mit drei historisch getrennten Stacks:

  • OSS (Operations Support Systems): Netzinventar, Service Provisioning, Fault- und Performance-Management. Also: welcher Mobilfunkstandort versorgt welche Adresse, welches Equipment steht in welcher Vermittlungsstelle.
  • BSS (Business Support Systems): Billing, CRM, Order Management, Revenue Assurance. Also: was dem Kunden berechnet wird, welchen Tarif er hat.
  • Netzinventar / Asset-Register: physische und logische Asset-Datensätze, von Faserstrecken über Funkeinheiten bis zu IP-Adressen.

Diese Systeme wurden von unterschiedlichen Anbietern zu unterschiedlichen Zeiten gebaut, oft nach Fusionen (T-Mobile und Sprint, Vodafone und verschiedene nationale Einheiten, mehrere Konvergenzdeals zwischen Kabel und Telko). Jedes System hat seinen eigenen Identifier für „dasselbe“ Objekt erfunden: einen Kunden, eine SIM, einen Router, einen Mobilfunkmast. Selten gibt es einen einzigen führenden Schlüssel, der sich durch alle hindurchzieht.

Die zentralen Stammdatendomänen

Vier Datendomänen sind im Telekom-MDM am wichtigsten:

1. Kunden-/Party-Daten: Name, Adresse, Steuer-ID, Billing-Account, Haushaltsverknüpfung.

2. Produkt-/Angebotsdaten: Tarife, Bundles, Promotions, SKUs (Stock Keeping Units) über Consumer- und Enterprise-Kataloge hinweg.

3. Asset-/Gerätedaten: Endgeräte, SIMs, IMEI (International Mobile Equipment Identity, eine eindeutige Geräteseriennummer), CPE (Customer Premises Equipment) wie Router.

4. Netzressourcen-Daten: Mobilfunkstandorte, Antennen, Ports, Circuits, IP-Adressblöcke, Faserabschnitte.

Das Abstimmungsproblem zeigt sich an den Schnittstellen. Ein einzelner „Service“ (etwa ein Festnetz-Breitbandanschluss) berührt Kundendaten (wer zahlt), Produktdaten (welcher Tarif), Asset-Daten (welcher Router) und Netzdaten (welcher Port in welchem Straßenverteiler). Wenn eine ID zwischen den Systemen nicht übereinstimmt, kann ein Techniker zur falschen Adresse geschickt werden, oder ein Kunde wird für eine abgebaute Leitung abgerechnet.

Was „Golden Record“-Strategien tatsächlich leisten

Ein Golden Record ist die einzige verlässliche Version einer Entität, aufgebaut durch Matching, Merging und Survivorship widersprüchlicher Attribute aus den Quellsystemen.

Typische Architektur:

  • Ingest: Datensätze aus CRM, Billing, OSS-Inventar und Provisioning-Systemen ziehen.
  • Match: probabilistisches oder deterministisches Matching (z. B. über Name plus Adresse plus Telefonnummer, fuzzy-gematcht für Tippfehler), um wahrscheinliche Duplikate zu finden.
  • Merge: „Survivorship Rules“ anwenden (welche Quelle gewinnt für welches Feld: beim Adressfeld gewinnt üblicherweise das Billing-System, bei der Geräteseriennummer das Netzinventar).
  • Distribute: den Golden Record über APIs oder Event-Streams zurückspielen, damit die operativen Systeme synchron bleiben und nicht erneut auseinanderlaufen.

In diesem Feld aktiv sind unter anderem Informatica, IBM InfoSphere und Oracle für allgemeines MDM, dazu telekomspezifische Inventarlösungen und TM-Forum-konforme Plattformen. Das TM Forum (ein globaler Branchenverband der Telekommunikation) veröffentlicht die Open Digital Architecture und das Information Framework (SID), ein breit genutztes Referenzdatenmodell, das standardisiert, wie Entitäten wie „Customer“, „Product“ und „Resource“ strukturiert sein sollten. Die meisten Tier-1-Betreiber mappen ihre MDM-Vorhaben gegen SID, statt Schemata von null zu erfinden.

Ein vereinfachtes Matching-Snippet

Deterministische Matching-Logik ist oft so einfach wie das Folgende (illustrativer Pseudocode, nicht produktionsreif):

python
def is_likely_duplicate(record_a, record_b):
    score = 0
    if record_a["tax_id"] == record_b["tax_id"]:
        score += 50
    if normalize(record_a["address"]) == normalize(record_b["address"]):
        score += 30
    if record_a["phone"][-8:] == record_b["phone"][-8:]:
        score += 20
    return score >= 60  # Schwellenwert für Auto-Merge-Kandidat

Echte MDM-Plattformen nutzen anspruchsvolleres probabilistisches Matching (z. B. die Logik des Fellegi-Sunter-Modells), aber die Grundidee, gewichtete Evidenz über mehrere Felder, ist dieselbe.

Datenqualitätsmetriken, die MDM-Programme steuern

Betreiber verfolgen ein konsistentes Set von Datenqualitätsdimensionen, meist als Prozentwerte auf einem Governance-Dashboard berichtet:

  • Completeness: % der befüllten Pflichtfelder (z. B. % der Kundendatensätze mit gültiger Rechnungsadresse).
  • Uniqueness: Duplikatrate, oft ausgedrückt als Duplikate pro 1.000 Datensätze (z. B. werden in Legacy-CRM-Systemen der Telekombranche vor einem MDM-Cleanup häufig geschätzte 3 bis 8 Prozent Duplikatrate genannt, als Branchenschätzung, nicht als allgemeingültiger Wert).
  • Accuracy: % der Datensätze, die einer verlässlichen externen Referenz entsprechen (z. B. Adresse gegen eine nationale Postdatenbank validiert).
  • Consistency: % der zusammengehörenden Entitäten, die für dasselbe Attribut in zwei oder mehr Systemen identische Werte tragen (z. B. Kundenname in CRM und Billing identisch geschrieben).
  • Timeliness: Verzögerung zwischen einer realen Änderung (Kunde zieht um, Gerät getauscht) und ihrer Abbildung in allen Systemen, oft in Stunden oder Tagen gemessen.

Rechenbeispiel: Nehmen wir an, ein Betreiber hat 10 Millionen Kundenkonten. Ein Quartals-Audit findet 420.000 Datensätze, bei denen die CRM-Adresse von der Billing-Adresse abweicht. Das ergibt eine Consistency-Rate von:

(10.000.000 − 420.000) / 10.000.000 = 95,8 % Consistency

Ein Betreiber, der ein Governance-Ziel von 98 % Consistency für regulierte Felder setzt (die Rechnungsadresse ist für Steuer- und Rechnungs-Compliance relevant), würde das als Lücke mit Remediation-Bedarf markieren und die Domänen mit den höchsten Folgekosten priorisieren: Billing-Streitfälle, fehlgeschlagene Provisioning-Aufträge, falsch geroutete Servicetechniker.

Governance-Strukturen, die das dauerhaft machen

Technologie allein bringt Stammdaten nicht in Ordnung. Governance tut das. Gängige Strukturen:

  • Data-Stewardship-Rollen: benannte Owner je Domäne (ein „Customer Data Steward“, ein „Network Asset Data Steward“), die für die Qualitätsmetriken ihrer Domäne verantwortlich sind.
  • Data Governance Council: bereichsübergreifendes Gremium (IT, Network Ops, Marketing, Compliance), das über Survivorship Rules entscheidet und Schema-Änderungen freigibt.
  • Change-Data-Capture-(CDC-)Pipelines: technischer Mechanismus, der sicherstellt, dass nach einem Update des Golden Record alle Downstream-Systeme die Änderung erhalten und nicht erneut auseinanderlaufen.

Regulatorischer Druck verstärkt das. Unter der DSGVO (Datenschutz-Grundverordnung, das EU-Datenschutzrecht) ist das Recht eines Kunden auf Löschung oder Datenportabilität nicht durchsetzbar, wenn der Betreiber nicht alle zu dieser Person gehörenden Datensätze über ein Dutzend fragmentierte Systeme hinweg identifizieren kann. Das hat mehrere europäische Betreiber dazu gebracht, MDM als Compliance-Programm zu behandeln und nicht nur als Effizienzprojekt.

Wissenscheck

1. Warum landet ein einzelner Teilnehmer oft mit mehreren, inkonsistenten Kundendatensätzen über die Systeme eines Netzbetreibers hinweg?

2. Was ist die zentrale Unterscheidung zwischen OSS und BSS in einer Telekom-IT-Landschaft?

3. Ein mittelgroßer Betreiber will das Risiko senken, dass ein Tarifwechsel oder eine Kündigung auf dem falschen Kundendatensatz landet. Welches grundlegende Problem spiegelt das gemäß der Darstellung in der Lektion wider?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE richtigen Antworten dazu, warum Fusionen und Übernahmen die Fragmentierung von Telekom-Stammdaten verschärfen.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE richtigen Antworten zu den zentralen Stammdatendomänen, die für Telekom-MDM relevant sind.

Wählen Sie alle richtigen Antworten aus.

Benchmarks und wie Betreiber den ROI messen (den datenseitigen, nicht Finanzkennzahlen)

MDM-Programme werden an operativen und Datenmetriken beurteilt, nicht nur an Kosteneinsparungen:

  • Duplicate Reduction Rate: z. B. Senkung der Teilnehmer-Duplikatrate von geschätzt 6 % auf unter 1 % innerhalb von 18 Monaten (Programmschätzung, variiert stark je Betreiber).
  • Order Fallout Rate: % der Aufträge, die am automatisierten Provisioning wegen Datenabweichungen scheitern (abweichende Adresse, unbekannte Asset-ID). Den Fallout von zweistelligen auf niedrige einstellige Werte zu senken, ist ein häufig genanntes Ziel in OSS-Modernisierungsprogrammen.
  • Mean Time to Reconcile: wie lange es dauert, einen markierten Datenkonflikt zwischen zwei Systemen aufzulösen, in Tagen erfasst.
  • API-basierte Synchronisationsabdeckung: % der Quellsysteme, die über Echtzeit-Event-Streams integriert sind, gegenüber klassischem nächtlichem Batch-Abgleich. Echtzeitabdeckung ist die Richtung für die meisten Tier-1-Betreiber auf dem Weg zu 5G-Standalone-Core-Architekturen, in denen Network Slices und dynamische Ressourcenzuweisung keine veralteten Inventardaten tolerieren.

Wichtigste Erkenntnisse

  • Netzbetreiber betreiben fragmentierte OSS-, BSS- und Netzinventarsysteme, jedes mit eigenen Identifiern für denselben Kunden, dasselbe Produkt oder Asset, was chronische Abstimmungsprobleme erzeugt, besonders nach Fusionen.
  • MDM-Programme bauen „Golden Records“ über Matching, Merging und Survivorship Rules, zunehmend standardisiert gegen Frameworks wie das SID-Modell des TM Forum.
  • Datenqualität wird über konkrete, prüfbare Metriken verfolgt: Completeness, Uniqueness (Duplikatrate), Accuracy, Consistency und Timeliness, jeweils als messbarer Prozentwert oder Verzögerung ausgedrückt.
  • Governance (Stewardship-Rollen, bereichsübergreifende Councils, CDC-Pipelines) verhindert das erneute Auseinanderlaufen nach dem Cleanup, und die DSGVO-Compliance gibt europäischen Betreibern einen rechtlichen, nicht nur operativen Grund zu investieren.
  • Programmerfolg wird mit operativen Benchmarks gemessen: Duplicate Reduction Rate, Order Fallout Rate und Mean Time to Reconcile, alle Zahlen sollten als Schätzungen behandelt werden, sofern sie nicht aus offengelegten Programmergebnissen eines bestimmten Betreibers stammen.

Zurück

Datenqualitätsdimensionen für Abonnenten- und Netzdaten

Weiter

Benchmarking von Netz- und Service-KPIs, die das Leadership verfolgt