+150 XP

Datenqualitätsdimensionen für Abonnenten- und Netzdaten

# Datenqualitätsdimensionen für Abonnenten- und Netzdaten

Ein einzelner Abonnent kann in den Systemen eines Telekommunikationsanbieters elfmal existieren: einmal im CRM (Customer Relationship Management), zweimal im Billing mit leicht abweichender Schreibweise, dreimal im HLR (Home Location Register, die Datenbank, die festhält, in welchem Netz ein Mobilfunkabonnent registriert ist), und weitere Male in Legacy-Prepaid-Plattformen, die niemand vollständig abgeschaltet hat. Multipliziert mit mehreren zehn Millionen Abonnenten wird aus dem Durcheinander ein Governance-Problem mit echten finanziellen und regulatorischen Folgen, von falsch zugestellten Rechnungen bis zu fehlgeschlagenen Anfragen zur Telekommunikationsüberwachung.

Diese Lektion gibt Ihnen ein praxistaugliches Framework, um Telekommunikationsdaten anhand von fünf Dimensionen zu bewerten, mit den konkreten Datensatztypen, in denen jeder Fehlermodus auftritt.

Warum Telekommunikationsdaten auf besondere Weise brechen

Netzbetreiber arbeiten mit einem dichteren Geflecht voneinander abhängiger Systeme als die meisten Branchen: OSS (Operations Support Systems, Verwaltung der Netzinfrastruktur), BSS (Business Support Systems, Verwaltung von Kunden und Abrechnung) sowie Datenbanken von Netzelementen, die nahezu in Echtzeit aktualisiert werden.

Wichtige Datensätze, denen Sie begegnen:

  • HLR/HSS: HLR für 2G/3G, HSS (Home Subscriber Server) für 4G/LTE, speichert Abonnentenidentität, Standort und Diensteberechtigung.
  • CRM-Datensätze: Name, Adresse, Kontaktpräferenzen, Kontostatus.
  • Billing-/CDR-Systeme: CDRs (Call Detail Records) erfassen jeden Anruf, jede SMS und jede Datensitzung für Tarifierung und Fakturierung.
  • MSISDN: die Mobile Station International Subscriber Directory Number, im Kern die Rufnummer, ist der Join Key über nahezu all diese Systeme hinweg, und genau deshalb verursachen doppelte oder neu zugewiesene MSISDNs Kettenfehler.
  • Netzinventar/Asset-Register: Standorte von Mobilfunkstationen, Equipment-IDs, Frequenzzuweisungen.

Weil diese Systeme in verschiedenen Jahrzehnten von verschiedenen Anbietern gebaut wurden, teilen sie selten eine einzige Source of Truth. Das ist die Grundursache der meisten Qualitätsprobleme weiter unten.

Die fünf Dimensionen in der Anwendung

Completeness

Sind die erforderlichen Felder gefüllt? Ein CRM-Datensatz ohne Rechnungsadresse verhindert keinen Verbindungsaufbau, blockiert aber regulatorische Pflichten wie Portierungsanfragen bei Rufnummernmitnahme oder Adressabfragen für Notrufdienste (in den USA entspricht das den FCC-E911-Standortanforderungen).

Schnellprüfung: Anteil der Abonnentendatensätze, bei denen alle Pflichtfelder gefüllt sind.

$$\text{Completeness rate} = \frac{\text{Datensätze mit allen Pflichtfeldern gefüllt}}{\text{Datensätze insgesamt}} \times 100$$

Beispiel: Wenn 4,7 Millionen von 5 Millionen Postpaid-Datensätzen vollständige Adressfelder haben, liegt die Completeness bei 94 Prozent. In der Praxis gilt bei regulatorisch relevanten Feldern alles unter etwa 95 Prozent als sanierungsbedürftig, wobei die Schwellen je Betreiber und Anwendungsfall variieren.

Accuracy

Ist der Wert korrekt, nicht nur vorhanden? Ein gefülltes Adressfeld mit „123 Main St“, obwohl der Abonnent vor zwei Jahren umgezogen ist, ist vollständig, aber falsch. Accuracy-Fehler sind am schwersten automatisch zu erkennen, weil das Feld strukturell in Ordnung aussieht.

Häufiger Accuracy-Fehler in der Telekommunikation: CDR-Fehltarifierung, bei der ein Anruf wegen eines veralteten Rate-Plan-Flags im Billing dem falschen Tarif zugeordnet wird. Das führt direkt zu Revenue Leakage, also zu Umsatz, den ein Betreiber erwirtschaftet, aber nicht korrekt abrechnet. Das TM Forum, das wichtigste Standardisierungsgremium der Branche für OSS/BSS, veröffentlicht Revenue-Assurance-Frameworks genau deshalb, weil dieses Problem endemisch ist.

Timeliness

Telekommunikationsdaten haben eine Haltbarkeit, die für Netzzustände in Sekunden und für Billing-Zustände in Tagen gemessen wird. Ein HLR-Eintrag, der einen Abonnenten an einem Funkmast zeigt, den er vor zwanzig Minuten verlassen hat, führt zu abgebrochenem Call Routing und fehlgeschlagener SMS-Zustellung.

Timeliness wird üblicherweise als Data Latency gemessen: der Abstand zwischen dem Eintreten eines Ereignisses und seiner Abbildung im System of Record.

  • Netzzustand (Standort, aktive Session): benötigt Latenzen im Sub-Sekunden- bis Wenige-Sekunden-Bereich.
  • Billing-/Nutzungsdaten: typischerweise Batch-verarbeitet, oft innerhalb von 24 bis 48 Stunden, bei Prepaid-Guthabenprüfungen teils nahezu in Echtzeit.
  • CRM-Profilaktualisierungen (Adressänderung): Tage sind meist tolerierbar, Monate nicht.

Ein veralteter HSS-Eintrag, der einen Abonnenten noch als aktiv auf einem abgeschalteten Network Slice führt, ist ein Timeliness-Fehler mit direkter Auswirkung auf die Customer Experience.

Consistency

Stimmen dieselben Sachverhalte über Systeme hinweg überein? Das ist der klassische Schmerzpunkt in der Telekommunikation: Die Adresse eines Abonnenten lautet im CRM „Apt 4B“, im Billing „Apartment 4-B“ und im Feld des Fraud-Detection-Systems steht nichts. Keines davon ist technisch falsch, aber sie lassen sich nicht zuverlässig joinen oder vergleichen.

Consistency-Probleme verstärken sich bei Merger-Integrationen. Wenn ein Betreiber einen anderen übernimmt (zum Beispiel T-Mobiles Übernahme von Sprint in den USA, abgeschlossen 2020), ist die Zusammenführung zweier kompletter BSS/OSS-Stacks, jeder mit eigenen MSISDN-Formatkonventionen, Adressschemata und CDR-Strukturen, ein mehrjähriges Data-Governance-Projekt und keine Migration über ein Wochenende.

Eine einfache Consistency-Prüfung in der Praxis:

sql
SELECT crm.msisdn, crm.address, billing.address
FROM crm
JOIN billing ON crm.msisdn = billing.msisdn
WHERE crm.address <> billing.address;

Jede zurückgegebene Zeile ist eine Consistency-Ausnahme, die eine Abgleichlogik erfordert (Fuzzy Matching, standardisierte Adressbibliotheken oder manuelle Prüfung).

Uniqueness

Ist jede real existierende Entität genau einmal abgebildet? Doppelte MSISDNs sind der kanonische Uniqueness-Fehler in der Telekommunikation: dieselbe Nummer erscheint unter zwei verschiedenen Kunden-IDs, häufig nach einem SIM-Swap, einer Portierung oder einer Systemmigration, bei der die Deduplizierung fehlschlug.

Duplikate verzerren fast jede nachgelagerte Kennzahl: Churn Rate, ARPU (Average Revenue Per User) und die Zahl aktiver Abonnenten. Meldet ein Betreiber 30 Millionen Abonnenten, sind aber 900.000 MSISDNs systemübergreifend doppelt vorhanden, liegt die echte Basis näher bei 29,1 Millionen, eine Überzeichnung von 3 Prozent, die sowohl die interne Planung als auch, bei externer Offenlegung, Investoren und Regulierer in die Irre führt.

$$\text{Duplicate rate} = \frac{\text{doppelte MSISDN-Datensätze}}{\text{MSISDN-Datensätze insgesamt}} \times 100 = \frac{900{,}000}{30{,}000{,}000} = 3\%$$

Wissenscheck

1. Warum sammeln Netzbetreiber tendenziell mehrere, inkonsistente Datensätze für denselben Abonnenten über Systeme hinweg an?

2. Warum ist die Rolle der MSISDN als Join Key über Systeme hinweg für die Datenqualität besonders riskant?

3. Die Rechnungsadresse eines Abonnenten ist in einem System korrekt formatiert und einheitlich geschrieben, entspricht aber nicht mehr seinem tatsächlichen Wohnort. Welches zugrunde liegende Datenqualitätsproblem zeigt das am besten?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE richtigen Antworten dazu, warum fragmentierte Abonnentendatensätze für Netzbetreiber echte finanzielle und regulatorische Folgen haben.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE richtigen Antworten zu den Systemen und Datensätzen, die als Quellen von Datenqualitätsproblemen in der Telekommunikation beschrieben werden.

Wählen Sie alle richtigen Antworten aus.

Governance-Metriken und Benchmarks

Betreiber verfolgen typischerweise einen Data Quality Score (DQS), einen über die fünf Dimensionen gewichteten Sammelwert, der auf Dataset-Ebene berichtet wird (zum Beispiel separat für CRM, Billing und Netzinventar).

Grobe branchenübliche Benchmarks (als Schätzwerte zu behandeln, nicht als geprüfte Zahlen, da kein Regulierer eine Offenlegung universell vorschreibt):

  • Betreiber in etablierten Märkten (USA, Westeuropa) zielen bei regulatorisch kritischen Feldern (Rechnungsadresse, Notrufstandortdaten) oft auf Completeness und Accuracy über 95 bis 98 Prozent.
  • Bei doppelten MSISDNs wird nach der Bereinigung generell ein Wert unter 1 bis 2 Prozent erwartet; Quoten über 5 Prozent lösen typischerweise ein eigenes Remediation-Programm aus.
  • Latenz-SLAs (Service Level Agreements) für Netzzustandsdaten (HLR/HSS-Updates) werden üblicherweise in Sekunden festgelegt, Billing-Latenz-SLAs in Stunden.

In Europa verlangt die DSGVO (Datenschutz-Grundverordnung) in Artikel 5 Abs. 1 lit. d ausdrücklich, dass personenbezogene Daten „sachlich richtig und erforderlichenfalls auf dem neuesten Stand“ sein müssen, wodurch Datenqualität zu einer unmittelbaren rechtlichen Compliance-Frage wird und nicht bloß zu einer operativen Annehmlichkeit. In den USA verlangen die CPNI-Regeln der FCC (Customer Proprietary Network Information) von Betreibern ebenfalls, präzise Schutzmaßnahmen für Abonnentendaten aufrechtzuerhalten, was die Qualitätsdisziplin indirekt stärkt.

🎬 [VIDEO: „What is Data Quality? (And Why It Matters)“ - youtube.com - suchen Sie nach TM Forum oder IBM-Data-Quality-Erklärkanälen für einen knappen Durchgang der Kerndimensionen angewendet auf Unternehmensdaten]

Das Framework anwenden

Ein praxistauglicher Audit-Workflow:

1. Dataset auswählen (CRM, Billing, HLR/HSS-Extrakt).

2. Jede der fünf Dimensionen mit einer einfachen Prozentkennzahl bewerten.

3. Nach Business-Kritikalität gewichten (Billing-Accuracy zählt mehr als ein Marketing-Opt-in-Flag).

4. Remediation-Schwellen und Verantwortliche festlegen (Data-Governance-Teams, die häufig an eine Chief-Data-Officer-Rolle berichten, wie sie bei großen Betreibern wie Vodafone und AT&T zunehmend üblich ist).

Key Takeaways

  • Bewerten Sie Telekommunikations-Datasets anhand von fünf Dimensionen: Completeness, Accuracy, Timeliness, Consistency, Uniqueness. Jede hat eine eigene Grundursache und eine eigene Lösung.
  • MSISDN-Duplikate und abweichende Adressen zwischen CRM und Billing sind die zwei häufigsten Fehler in der Praxis; beide verzerren Abonnentenzahlen und Billing-Accuracy.
  • Timeliness-Anforderungen unterscheiden sich stark je System: Sekunden für den Netzzustand in HLR/HSS, Stunden bis Tage für Billing und CRM.
  • DSGVO (EU) und CPNI-Regeln (USA) machen Datenrichtigkeit zu einer Compliance-Anforderung, nicht zu einer operativen Vorliebe.
  • Einfache prozentbasierte Kennzahlen (Completeness Rate, Duplicate Rate) genügen, um ein Governance-Programm zu starten; Raffinesse kommt später.