Das Betriebssystem für Telekommunikationsanbieter

Telekommunikationsanbieter verkaufen heute mehr Arten von Diensten als noch vor zehn Jahren: Glasfaser und Mobilfunk, TV, VoIP, Zusatzleistungen von Partnern wie Sicherheitssoftware, jeweils mit eigenem Provisionierungsschritt und eigener Preisgestaltung. Der Umsatz hat sich von Sprache und SMS hin zu Daten verlagert, und das Back-Office muss mit jedem neuen Bündel Schritt halten. Für regionale ISPs, MVNOs und Reseller liegt die eigentliche Schwierigkeit selten im Netz. Sie liegt in den Tools dahinter. Die Software dahinter ist ein wachsender Markt: Straits Research beziffert den weltweiten OSS/BSS-Markt für 2026 auf 27,12 Mrd. USD und erwartet bis 2034 78,95 Mrd. USD, ein jährliches Wachstum von 14,29 % (Straits Research, 2026).

Grosse Anbieter können mehrjährige Transformationsprogramme finanzieren. Kleinere Anbieter landen stattdessen oft bei einem Flickenteppich: die Abrechnung in einem System, das CRM in einem anderen, Provisionierungsskripte auf einem Server und Tabellen dazwischen. Dieselben Kunden- und Produktdaten liegen an mehreren Orten, und jemand im Team hält sie von Hand synchron.

Dieser Artikel erklärt, was mit einem „Betriebssystem“ für das BSS gemeint ist, warum die Konsolidierung auf einer Plattform für kleine und mittlere Anbieter wichtig ist, welche Prinzipien dahinterstehen und wie METAVSHN sie umsetzt.

Das Flickenteppich-Problem

Die IT-Landschaften von Telekommunikationsanbietern sind nicht über Nacht komplex geworden. Über die Jahre kamen ein Abrechnungstool, ein CRM, Netzwerkmanagement und Auftragsabwicklung hinzu, jeweils ausgewählt, um das Problem einer einzelnen Abteilung zu lösen. Die Integration wurde auf später verschoben oder mit Skripten erledigt. Das Ergebnis ist ein Geflecht aus Punkt-zu-Punkt-Verbindungen und sich überschneidenden Datenbanken.

Bei einem ISP oder MVNO zeigt sich das jeden Tag. Mitarbeitende erfassen denselben Kunden in mehreren Systemen. Ein neuer Tarif oder ein neuer Partner bedeutet Änderungen an mehreren Stellen. Manuelle Abstimmung führt zu Rechnungsfehlern und Verzögerungen bei der Provisionierung. Und monolithische Altsysteme tun sich schwer mit datenzentrierten Diensten und Online-Anmeldeprozessen, weil sie für ein langsameres, einfacheres Produktangebot gebaut wurden.

Fragmentierte Daten bremsen auch die Automatisierung. Jeder Prozess, der eine vollständige Sicht auf einen Kunden, seine Dienste und seine Rechnungen benötigt, muss diese Sicht zuerst zusammensetzen. Jedes System über eine eigene API zugänglich zu machen, löst das für sich allein nicht: Punkt-zu-Punkt-Schnittstellen sind für jeweils einen Aufrufer gebaut, nicht dafür, dieselbe Änderung an alle Systeme zu verteilen, die sie benötigen. Das Telekom-Team von Microsoft beschreibt dasselbe Problem: OSS- und BSS-Umgebungen sind fragmentiert geblieben, was eine einheitliche Sicht auf Kunden, Netz und Geschäft verhindert (Microsoft, 2025).

McKinsey beschreibt digitale Transformation als grundlegenden Umbau der Arbeitsweise eines Unternehmens, mit dem Ziel, Technologie laufend und im grossen Massstab einzusetzen (McKinsey, 2023). Liegen die Kerndaten in mehreren Tools, beginnt jeder dieser Einsätze damit, zuerst die Daten abzugleichen.

Was ist ein BSS-Betriebssystem?

Ein Business Support System (BSS) steuert die kommerzielle Seite eines Telekommunikationsbetriebs: Produktkatalog, Angebotserstellung, Tarifierung, Rechnungsstellung, Zahlungen, Partnerprovisionen und Kundenservice. Ein Operations Support System (OSS) steuert die Netzseite: Provisionierung, Alarme, Performance und Inventar. Beide sind oft getrennt voneinander gewachsen, und genau daher stammt der Flickenteppich. Ein BSS-Betriebssystem ersetzt ihn durch eine Plattform, ein Datenmodell und einheitliche Schnittstellen.

Die Idee baut auf Standards des TM Forum auf. Sein Information Framework, auch Shared Information/Data Model (SID) genannt, ist ein Referenzmodell und ein gemeinsames Vokabular für die Geschäftsentitäten eines Telekommunikationsanbieters. Es ist unabhängig von Plattform, Sprache und Protokoll und gliedert die Domäne in Bereiche wie Market & Sales, Customer, Product, Service und Resource, sodass jede Entität nur einmal definiert wird.

Die Open Digital Architecture (ODA) des TM Forum ergänzt SID um einen Bauplan, nach dem sich der Betrieb aus Komponenten mit offenen APIs zusammensetzen lässt. So können einzelne Teile hinzugefügt oder ersetzt werden, ohne den gesamten Stack neu aufzubauen. Ein BSS, das beiden folgt, wird zur massgeblichen Datenquelle für Kunden, Produkte, Abonnements, Aufträge, Rechnungen und Zahlungen.

Ereignisgesteuerte Architektur und typisierte Konnektoren

Herkömmliche Integration beruht darauf, dass sich Systeme gegenseitig direkt aufrufen. Das funktioniert für eine einzelne Anfrage, schafft aber fragile Abhängigkeiten und erschwert die Verteilung in Echtzeit. In einer ereignisgesteuerten Architektur wird jedes Geschäftsereignis einmal an einen zentralen Broker veröffentlicht, und jedes berechtigte System, für das es relevant ist, abonniert es. Eine Änderung erreicht viele Systeme, der Ablauf lässt sich gut nachverfolgen, und Altsysteme können weiterlaufen, während neue Komponenten Schritt für Schritt hinzukommen.

Typisierte Konnektoren geben jeder Domäne einen stabilen Vertrag: Service-Aktivierung, Abrechnung, Hardware-Logistik, Identitätsprüfung. Der Konnektor enthält die Logik für die Kommunikation mit einem bestimmten Partner. Wenn Sie den Wholesale-Partner oder den Zahlungsanbieter wechseln, tauschen Sie den Konnektor aus, und die Geschäftslogik bleibt unverändert. Zusammen mit einem kanonischen Datenmodell wird jede Integration damit planbar, statt jedes Mal zu einem neuen Projekt zu werden.

Cloud-nativ und komponierbar

Modulare, cloud-native Architekturen mit wiederverwendbaren Komponenten und offenen APIs sind heute der übliche Weg, OSS/BSS aufzubauen. Unabhängige Dienste, zum Beispiel Rating, Mediation oder das Kundenportal, lassen sich einzeln bereitstellen und skalieren. Continuous Delivery macht kleine, häufige Releases zudem sicherer als grosse Upgrades.

Warum sollten Sie Ihr BSS auf einer Plattform konsolidieren?

• Schnellere Lancierungen: Wenn Katalog, Angebotserstellung, Provisionierung und Abrechnung ein gemeinsames Datenmodell nutzen, ist ein neues Angebot ein Katalogeintrag und kein abteilungsübergreifendes Projekt. China Telecom hat nach eigenen Angaben mit einem cloud-nativen BSS auf Basis der Open Digital Architecture und der Open APIs des TM Forum die Zeit bis zur Lancierung eines neuen Dienstes von zwei Monaten auf drei Tage verkürzt (TM Forum, 2020).
• Weniger operativer Aufwand: Weniger Tools bedeuten weniger Übergaben, weniger Kopien derselben Daten und weniger Lieferanten, die koordiniert werden müssen. Mit ereignisgesteuerter Integration modernisieren Sie einen Teil nach dem anderen.
• Sauberere Abrechnung: Eine einzige massgebliche Datenquelle speist die Rechnungsstellung und den Buchhaltungsexport. Es gibt weniger abzustimmen und weniger Rechnungen zu korrigieren.
• Klareres Kundenerlebnis: Korrekte Rechnungen und ein Self-Service-Portal, das dieselben Daten zeigt wie Ihr Back-Office, verringern Beanstandungen und Supportanfragen.
• Daten, auf denen Sie aufbauen können: Reporting, Automatisierung und jeder Assistent oder Agent, den Sie später anbinden, lesen aus einem konsistenten Modell statt aus mehreren unvollständigen Kopien.
• Sicherheit und Compliance im Kern: Zugriffsrechte, Audit-Logs und Identitätsprüfungen werden einmal für die gesamte Plattform festgelegt, nicht pro Tool.

Prinzipien eines Telekom-Betriebssystems

1. Kanonisches Datenmodell: Verwenden Sie ein Informationsmodell der Branche wie TM Forum SID. Kunde, Produkt, Abonnement, Auftrag, Rechnung und Zahlung werden einmal definiert und überall referenziert.
2. Typisierte Konnektoren und offene APIs: Geben Sie jeder Domäne einen Konnektor mit stabilem Vertrag und nutzen Sie TM Forum Open APIs, wo es sie gibt. So lassen sich Partner wechseln, ohne die Geschäftslogik anzufassen.
3. Ereignisgesteuertes Rückgrat: Veröffentlichen Sie Domänenereignisse wie order.created, subscription.activated oder invoice.sent an einen Broker, den jedes berechtigte System abonnieren kann.
4. Unabhängige Dienste: Teilen Sie die Plattform in Dienste auf, die sich getrennt bereitstellen und skalieren lassen.
5. Reporting und Automatisierung auf denselben Daten: Erkennen Sie Umsatzverluste, markieren Sie ungewöhnliche Nutzung und automatisieren Sie wiederkehrende Schritte direkt auf Basis des kanonischen Modells, nicht anhand von Exporten.
6. Konfiguration statt Individualentwicklung: Workflows und Produkte sollten sich per Konfiguration ändern lassen, damit ein neuer Dienst kein Entwicklungsprojekt erfordert.

Den Umstieg beginnen

Grosse Veränderungsprogramme verfehlen oft ihre Ziele. Eine Studie der BCG aus dem Jahr 2020, gestützt auf eine Befragung von 825 Führungskräften, kam zum Ergebnis, dass 70 % der digitalen Transformationen ihre Ziele verfehlen (BCG, 2020).

Back-Office-Systeme abzulösen ist eine grosse Veränderung, und Projekte, die alte Systeme nur umhüllen, ohne das Datenmodell zu bereinigen, halten selten, was sie versprochen haben. So senken Sie das Risiko:

1. Systeme erfassen: Dokumentieren Sie jedes System, das Kunden-, Produkt- und Netzdaten berührt, und halten Sie fest, wo dieselben Daten doppelt gespeichert sind.
2. Auf ein kanonisches Modell abbilden: Richten Sie Ihre Entitäten an SID aus, noch bevor Sie etwas abschalten. Erst ein gemeinsames Vokabular macht die späteren Schritte möglich.
3. Ereignisse vor dem Systemwechsel einführen: Legen Sie zuerst eine Ereignisschicht über die bestehenden Systeme, damit alte und neue Systeme während der Migration in dasselbe Rückgrat veröffentlichen können.
4. In Phasen einführen: Beginnen Sie mit der Abrechnung und dem Produktkatalog und ergänzen Sie danach Provisionierung, Partnerabrechnungen und das Kundenportal.
5. Offene Standards nutzen: TM Forum Open APIs und ODA-Komponenten verringern die Abhängigkeit von einzelnen Lieferanten und beschleunigen das Onboarding von Partnern.
6. An das Team denken: Neue Tools verändern, wie Menschen arbeiten. Beziehen Sie die Personen, die Abrechnung und Support betreiben, vom ersten Schritt an ein.

METAVSHN: eine Plattform für regionale Anbieter

METAVSHN ist nach den oben beschriebenen Prinzipien gebaut. Kunden-, Produkt-, Abonnement- und Auftragsdaten teilen sich ein Modell, das TM Forum SID folgt. Typisierte Konnektoren übernehmen Service-Aktivierung, Abrechnung, Hardware-Logistik und Identitätsprüfung, sodass sich Partner austauschen lassen, ohne die Geschäftslogik neu zu schreiben. Domänenereignisse werden über Webhooks versendet, damit Buchhaltung, Support-Tools und Analytics ohne Polling synchron bleiben.

Die Plattform ist für regionale ISPs, MVNOs und Telekommunikations-Reseller gemacht, die Tabellen und Buchhaltungstools entwachsen sind, aber keine Tier-1-BSS-Suite benötigen. Weil sie modular aufgebaut ist, können Sie sie in Phasen einführen: Neue Tarife werden zu Katalogeinträgen, dasselbe Modell speist Ihr Buchhaltungssystem, und Ihre Kundinnen und Kunden nutzen ein Self-Service-Portal, das auf denselben Daten aufbaut. Das SID-basierte Datenmodell finden Sie bei der Billing-Engine, die verfügbaren Konnektoren im Integration Hub und Angaben zu Hosting und Sicherheit in der Enterprise Suite.

Fazit

Datenzentrierte Dienste, mehr Partnerprodukte und höhere Erwartungen an Self-Service verlangen ein Back-Office, das auf einem einzigen Datenmodell aufbaut. Ein Flickenteppich aus Tools lässt sich am Laufen halten, doch mit jedem neuen Produkt und jedem neuen Partner wird er teurer.

Ein Telekom-Betriebssystem auf Basis eines kanonischen Datenmodells, typisierter Konnektoren, Ereignisse und unabhängiger Dienste beseitigt diese Kosten: Lancierungen gehen schneller, die Abrechnung wird sauberer, und Ihr Team muss keine Daten mehr zwischen Tools kopieren.

Für regionale ISPs, MVNOs und Reseller ist METAVSHN ein Weg, schrittweise dorthin zu gelangen, auf einer in der Schweiz gehosteten Plattform, die den Standards des TM Forum folgt.

Quellen

Alle Quellen abgerufen am 3. Oktober 2026.

1. Straits Research, „OSS BSS Market Size, Share & Trends Analysis Report (2026–2034)“, zuletzt aktualisiert am 24. August 2026. straitsresearch.com/report/oss-bss-market
2. Monte Hong, Microsoft, „The transformative impact of AI and generative AI on OSS and BSS in telecommunications“, 8. April 2025. microsoft.com
3. McKinsey & Company, „What is digital transformation?“, McKinsey Explainers, Juni 2023. mckinsey.com
4. TM Forum Inform, „China Telecom's BSS 3.0 turbo-charges agility, reducing time to market from months to days“, 31. März 2020. inform.tmforum.org
5. Patrick Forth, Tom Reichert, Romain de Laubier und Saibal Chakraborty, Boston Consulting Group, „Flipping the Odds of Digital Transformation Success“, 29. Oktober 2020. bcg.com