Einheitliche Orchestrierung und Sicherstellung– ein Cloud-natives Betriebsunterstützungssystem (OSS)

CSPs modernisieren ihre Abläufe, um die zunehmende Netzwerk- und Servicekomplexität zu bewältigen und gleichzeitig Kosten, Zuverlässigkeit, Serviceagilität, Automatisierung und Kundenerlebnis zu verbessern.

Viele Betriebsumgebungen umfassen fragmentierte Systeme für Assurance, Bestandsmanagement, Service-Orchestrierung und -Bereitstellung, Aktivierung, Ticketing, Domain-Orchestrierung und Business Support Systems (BSS). Diese Fragmentierung erhöht den manuellen Aufwand, verlangsamt die Servicebereitstellung und die Behebung von Incidents und erschwert es, die Automatisierung konsistent über verschiedene Domänen hinweg zu skalieren.

Die Modernisierung konzentriert sich daher zunehmend auf die Schaffung eines kohärenteren und stärker automatisierten Betriebsmodells für den Servicelebenszyklus, anstatt isolierte Tools separat zu optimieren.

Typische Warnsignale sind hoher manueller Aufwand, fragmentierte Daten, langsame Störungsbehebung, mangelnde Transparenz über Serviceauswirkungen, lange Aktivierungszyklen und Schwierigkeiten bei der Skalierung der Automatisierung.

Weitere Indikatoren sind übermäßiges Ereignisrauschen im Network Operations Center (NOC), nicht vertrauenswürdige Bestandsdaten, hohe Auftragsabbrüche, vermeidbare Technikereinsätze vor Ort, doppelte Tools sowie Integrationen, deren Änderung kostspielig oder riskant ist.

Das wichtigste Signal ist in der Regel eine wiederkehrende betriebliche Einschränkung, die messbare Kosten, Verzögerungen, Auswirkungen auf Zuverlässigkeit, Servicequalität oder Kunden verursacht.

Fragmentierte OSS-Umgebungen zwingen Betriebsteams dazu, Daten, Workflows und Entscheidungen über Systeme hinweg abzugleichen, die nicht dafür konzipiert wurden, gemeinsam einen einzigen Lebenszyklus zu unterstützen.

Assurance-, Inventar-, Service-Orchestrierungs- und Fulfillment-, Aktivierungs-, Ticketing-, Domain-Orchestrierungs- und BSS-Umgebungen können jeweils Teile des Kontexts enthalten. Dies kann zu Doppelarbeit, kundenspezifischen Integrationen, manuellen Übergaben, uneinheitlichen operativen Ansichten und geringerer Agilität führen.

Da sich Services über immer mehr Domänen und Anbieter erstrecken, können die Kosten für ihre Koordination schneller steigen als die Kosten eines einzelnen Tools.

Hohe Fehlerquoten und langsame Aktivierung resultieren häufig aus fragmentierten Auftragsabläufen, inkonsistenten Daten, komplexen Abhängigkeiten, anfälligen Integrationen und mangelnder Transparenz über Fulfillment-Systeme hinweg.

Telekommunikationsaufträge können sich über Kunden-, Service- und technische Ebenen in mehreren Domänen erstrecken. Wenn Servicemodelle, Bestandsverwaltung, Orchestrierung, Aktivierung und Statusmanagement nicht koordiniert sind, nehmen Ausnahmen und manuelle Nacharbeiten zu.

Die Reduzierung dieser Übergaben ist daher ein zentrales Geschäftsziel bei der Modernisierung von OSS.

Die Reduzierung der mittleren Reparaturzeit (MTTR) wird schwierig, wenn Betriebsteams Netzwerkereignisse nicht schnell mit der Grundursache, den Auswirkungen auf Services und Kunden sowie dem geeigneten Behebungspfad verknüpfen können.

Fehler-, Performance-, Topologie-, Bestands- und Serviceinformationen können auf verschiedene Systeme verteilt sein. Ohne korrelierten Kontext verbringen Teams möglicherweise mehr Zeit damit, Symptome zu untersuchen und Prioritäten festzulegen, bevor sie Korrekturmaßnahmen ergreifen.

Schnellere Erkennung, Analyse der Serviceauswirkungen, Ursachenanalyse, Behebung und Verifizierung sind daher zentrale Zuverlässigkeitsziele.

Hohe Ereignisvolumina beanspruchen die Aufmerksamkeit der Operatoren und erschweren es, die wenigen Bedingungen zu identifizieren, die tatsächlich Services oder Kunden gefährden.

Wenn Alarme nur unzureichend mit Topologie, Servicebeziehungen oder der wahrscheinlichen Ursache korreliert werden, untersuchen Teams möglicherweise wiederholt Symptome, erstellen unnötige Tickets und eskalieren Incidents, die automatisch hätten gefiltert oder priorisiert werden können.

Die Reduzierung von Ereignisrauschen ist daher sowohl ein Ziel der Zuverlässigkeit als auch der betrieblichen Effizienz.

Automatisierung und KI benötigen einen zuverlässigen operativen Kontext, um zu verstehen, welche Ressourcen, Services, Abhängigkeiten und Kunden von einer Entscheidung betroffen sein könnten.

Wenn Bestands- oder Topologiedaten unvollständig oder veraltet sind, können Serviceauswirkungsanalyse, Orchestrierung, KI-Empfehlungen und Closed-Loop-Remediation weniger zuverlässig sein. Da Betreiber höhere Automatisierungsgrade anstreben, wird das Vertrauen in die Beziehungen zwischen Services und Ressourcen immer wichtiger.

Vertrauenswürdiger Kontext ist daher eine geschäftliche Voraussetzung für die Skalierung der Automatisierung und nicht einfach nur eine Frage der Bestandsverwaltung.

Neue Netzwerkfunktionen schaffen nur dann Mehrwert, wenn CSPs sie schnell in wiederholbare Services umwandeln und zuverlässig in großem Maßstab betreiben können.

5G, private Netzwerke, Network Slicing, Cloud Computing, APIs, Unternehmenskonnektivität und Network as a Service können koordiniertes Design, Orchestrierung, Aktivierung, Bestandsverwaltung, Assurance und SLA-Management erfordern.

Lange Design-to-Launch- oder Order-to-Activate-Zyklen können daher die Monetarisierung einschränken, selbst wenn die zugrunde liegende Netzwerkfunktionalität bereits vorhanden ist.

Die Kundenerfahrung hängt zunehmend davon ab, wie schnell der Betrieb betroffene Services identifizieren, die richtige Reaktion priorisieren, den Service wiederherstellen und die Wiederherstellung überprüfen kann.

Ein Netzwerkereignis kann je nach betroffenen Kunden, Services, SLAs oder geschäftlichen Verpflichtungen sehr unterschiedliche Auswirkungen auf das Geschäft haben. Vorgänge, die technische Bedingungen mit Service- und Kundenkontext verknüpfen können, sind besser in der Lage, Prioritäten nach Auswirkungen statt allein nach Alarmschweregrad zu setzen.

Dies kann eine schnellere Wiederherstellung, weniger für Kunden sichtbare Ausfälle und mehr Vertrauen in SLAs ermöglichen.

OSS-Modernisierung sollte mit messbaren Verbesserungen bei Kosten, Zuverlässigkeit, Serviceflexibilität, Automatisierung und Kundenauswirkungen verknüpft sein.

Relevante KPIs können Aktivierungszykluszeit, Auftragsabbruchrate, Automatisierungsgrad, Ereignis-zu-Ticket-Verhältnis, mittlere Erkennungszeit, MTTR, SLA-Einhaltung, kundenrelevante Störungen, Technikereinsätze vor Ort, Time-to-Revenue und Servicekosten umfassen.

CSPs sollten ihren aktuellen Prozess nutzen, um vor der Festlegung von Verbesserungszielen eine Ausgangsbasis zu schaffen, damit der Business Case die tatsächliche Umgebung widerspiegelt und nicht auf verallgemeinerten Aussagen beruht.

Ein modernes Telekommunikations-OSS ist die operative Softwareumgebung, mit der Netzwerke und Services konzipiert, bereitgestellt, aktiviert, überwacht, abgesichert und gewartet werden.

Ein modernes OSS umfasst in der Regel Service Design, Inventory und Topology, Orchestrierung, Aktivierung, Assurance, Observability und Automatisierung, die alle zusammenwirken, um Closed-Loop-Betriebsabläufe zu ermöglichen. Diese Funktionen müssen über anbieter- und domänenübergreifende Service-Lebenszyklen hinweg funktionieren, anstatt nach Funktion oder Netzwerkdomäne isoliert zu bleiben.

Oracle Unified Operations ist das modulare OSS-Portfolio von Oracle, das CSPs dabei unterstützt, ihren Weg zu autonomen Betriebsabläufen zu beschleunigen. Es umfasst Servicedesign, Auftrags- und Service-Orchestrierung, Aktivierung, Bestand und Topologie, Assurance und Observability sowie KI-gestützte Problembehebung.

CSPs können ausgewählte Funktionen bereitstellen und die Nutzung ausweiten, während sich ihre operativen Prioritäten und ihr Reifegrad weiterentwickeln. Das Portfolio ist darauf ausgelegt, eine schrittweise Modernisierung zu unterstützen, anstatt zu verlangen, dass alle OSS-Funktionen gleichzeitig geändert werden.

Unified Operations umfasst die wichtigsten operativen Funktionen, die erforderlich sind, um Telekommunikationsservices über ihren gesamten Lebenszyklus hinweg zu entwickeln, bereitzustellen, zu betreiben und sicherzustellen.

Das Portfolio umfasst Servicekatalog und -design, Auftrags- und Servicemanagement, Orchestrierung, Aktivierung und Netzwerkkonfiguration, Bestand und Topologie, Netzwerkerkennung und -abgleich, Assurance und Observability, Serviceauswirkungsanalyse, Entscheidungsfindung und Fehlerbehebung sowie die Verifizierung nach erfolgten Maßnahmen.

Unified Operations umfasst Oracle Communications-Produkte mit unterschiedlichen Rollen im gesamten Servicelebenszyklus.

Ja. Unified Operations kann neben bestehenden OSS-, Netzwerk-, Domain-Orchestrierungs-, Ticketing-, Assurance-, Bestands-, Aktivierungs- und BSS-Umgebungen eingeführt werden.

Ein CSP kann einen priorisierten Bereich modernisieren, dabei vorhandene nützliche Investitionen schützen und im Laufe der Zeit auf weitere Funktionsbereiche ausweiten. Die Zielintegrationsarchitektur hängt von der Kundenumgebung, den ausgewählten Anwendungsfällen und den weiterhin betriebenen Systemen ab.

Ja. Ein CSP kann einen einzelnen Betriebsbereich modernisieren, mehrere Prioritäten kombinieren oder eine umfassendere Transformation des Servicelebenszyklus koordinieren.

Typische Einstiegspunkte sind Assurance und Observability, Bestand und Topologie, Orchestrierung, Aktivierung sowie ausgewählte Anwendungsfälle für autonome Betriebsabläufe. Die richtige Reihenfolge hängt von der vorhandenen Architektur, den Geschäftsprioritäten, der betrieblichen Reife, der Risikotoleranz und dem angestrebten Betriebsmodell ab.

Unified Operations ist auf Koordination und Automatisierung über den gesamten Servicelebenszyklus hinweg ausgerichtet, statt auf Automatisierung, die auf ein einzelnes Tool, eine einzelne Technologie oder eine einzelne Netzwerkdomäne beschränkt ist.

Punktlösungen können in einzelnen Funktionen effektiv sein, doch Kundenergebnisse erstrecken sich häufig über Assurance-, Bestands-, Orchestrierungs-, Aktivierungs- und BSS-Prozesse. Unified Operations wurde entwickelt, um Kontext, Beobachtung, Entscheidungsfindung, Ausführung und Verifizierung über operative Grenzen hinweg miteinander zu verbinden.

Unified Operations bietet OSS-Grundlagen, die einen schrittweisen Übergang von funktionaler Automatisierung hin zu zunehmend koordinierten Closed-Loop-Abläufen unterstützen.

Das Portfolio vereint vertrauenswürdigen operativen Kontext, Assurance und Observability, Orchestrierung, Aktivierung, Entscheidungsfindung, Fehlerbehebung und Verifizierung. CSPs können diese Funktionen schrittweise auf definierte Services, Domänen, Prozesse und Risikostufen anwenden, anstatt Autonomie als Transformation in einem einzigen Schritt zu betrachten.

Ja. Unified Operations ist für Telekommunikationsumgebungen konzipiert, die mehrere Anbieter, Technologien, Domänen und Betriebssysteme umfassen.

Es unterstützt Festnetz-, Mobilfunk-, Transport-, Kernnetz-, Funkzugangsnetz- (RAN), Cloud-, Software-Defined-Networking- (SDN), Edge-, physische, virtuelle und cloudnative Umgebungen und lässt sich gleichzeitig in bestehende Systeme integrieren. Die Architektur ist zudem darauf ausgelegt, TM Forum-konforme Ansätze, 3GPP-definierte Funktionen, GSMA- und CAMARA-Initiativen sowie Lebenszyklusmodelle im MEF-Stil dort zu ergänzen, wo dies relevant ist.

Unified Operations ist besonders relevant für CSPs und Netzbetreiber, die komplexe Service-Lebenszyklen über mehrere Systeme, Technologien, Domänen und Anbieter hinweg verwalten.

Typische Stakeholder sind CTOs, CIOs, COOs, Führungskräfte für Netzwerk- und Servicebetrieb, OSS-Transformationsteams, Verantwortliche für Fulfillment und Assurance, Inventory-Verantwortliche, Automatisierungsteams, Verantwortliche für Customer Experience sowie Finanz-Stakeholder.

Unified Operations verbindet Servicedesign, Orchestrierung, Aktivierung, betrieblichen Kontext, Assurance, Entscheidungsfindung, Behebung und Verifizierung als komplementäre Lebenszyklusfunktionen.

Servicemodelle definieren wiederverwendbaren Intent; Orchestrierung koordiniert die erforderlichen Aufgaben; Aktivierung führt Netzwerk- oder IT-Änderungen aus; Bestand und Topologie liefern den Kontext für Serviceressourcen; Assurance überwacht Bedingungen; Entscheidungsfindung wählt eine Reaktion aus; und Verifizierung bestätigt das Ergebnis.

Diese Kontinuität über den gesamten Lebenszyklus bildet die Grundlage sowohl für die Automatisierung der Bereitstellung als auch für zunehmend autonome Abläufe.

Closed-Loop-Automatisierung verbindet Erkennung, Verständnis, Entscheidungsfindung, Ausführung und Verifizierung in einem einzigen gesteuerten Betriebsprozess.

Ein nützliches Betriebsmodell ist Erkennen → Verstehen → Entscheiden → Handeln → Überprüfen. Assurance und Observability erkennen Zustände; Bestand, Topologie und Servicebeziehungen liefern Kontext; Analysen, KI, Richtlinien oder Regeln unterstützen die Entscheidung; Orchestrierung oder Aktivierung führt die Aktion aus; und Assurance überprüft, ob sich der Servicezustand verbessert hat.

Die Verifizierung unterscheidet einen vollständig geschlossenen Regelkreis von einer Automatisierung, die lediglich eine Änderung vornimmt, ohne das Ergebnis zu bestätigen.

Bestands- und Topologiedaten helfen Automatisierungs-Workflows, die von einer betrieblichen Entscheidung betroffenen Ressourcen, Services, Konnektivität, Abhängigkeiten und Beziehungen zu verstehen.

Dieser Kontext unterstützt Orchestrierung, Serviceauswirkungsanalyse, Ursachenanalyse, Digital-Twin-Grundlagen, KI-generierte Empfehlungen und Closed-Loop-Fehlerbehebung. Die Sicherstellung der Bestandsgenauigkeit durch den Abgleich der ermittelten Netzwerkrealität mit den Bestandsdaten kann das Vertrauen weiter stärken.

Ohne ausreichend vertrauenswürdigen Kontext können automatisierte Entscheidungen schwieriger zu bewerten und zu steuern sein.

Die Serviceauswirkungsanalyse ermittelt, welche Services, Kunden, Standorte oder geschäftlichen Verpflichtungen von einer Netzwerk- oder Betriebsbedingung betroffen sein können.

Es kombiniert Kontextinformationen wie Bestand, Topologie, Störungen, Performance, Kapazität, Datenverkehr und Servicebeziehungen. So können Teams und automatisierte Workflows Vorfälle und Behebungsmaßnahmen basierend auf den Auswirkungen auf Services und Geschäft priorisieren – und nicht allein nach dem Schweregrad des Problems.

Ein schnelleres Verständnis der Auswirkungen kann in Kombination mit Ursachenanalyse und kontrollierter Ausführung auch die Untersuchungszeiten verkürzen und eine niedrigere MTTR unterstützen.

Ein digitaler Zwilling ist eine digitale Darstellung von Netzwerk- und Serviceressourcen, Beziehungen, Topologie und Betriebszustand, die verwendet wird, um Abhängigkeiten und potenzielle Auswirkungen zu verstehen.

Die Was-wäre-wenn-Analyse kann diesen Kontext nutzen, um die voraussichtlichen Auswirkungen einer vorgeschlagenen Änderung vor der Ausführung zu bewerten, Behebungsoptionen zu vergleichen und betroffene Services oder Abhängigkeiten zu identifizieren. Dies kann fundiertere und kontrolliertere operative Entscheidungen unterstützen.

Digital-Twin- und Was-wäre-wenn-Funktionen sollten entsprechend der relevanten Produkt-, Bereitstellungs- und Roadmap-Verfügbarkeit positioniert werden.

KI kann Telekommunikationsabläufe über Prozesse wie Planung und Design, Auftrag bis Aktivierung sowie Störung bis Behebung hinweg unterstützen. Beispielsweise kann KI im Bereich Trouble-to-Resolve einen erheblichen Mehrwert bei Anomalieerkennung, Ursachenanalyse, Prognosen, Priorisierung, Empfehlungen und Behebungs-Workflows liefern – sie muss jedoch auf einem vertrauenswürdigen betrieblichen Kontext basieren.

Relevante Daten können Fehler- und Leistungsinformationen, Servicestatus, Bestand, Topologie, Kunden- und SLA-Kontext, Workflow-Verlauf, Tickets und Ergebnisse von Fehlerbehebungen umfassen. Die genauen Daten hängen vom Anwendungsfall ab.

KI sollte schrittweise in klar definierten Prozessen eingeführt werden – mit Governance, messbaren Ergebnissen und eindeutiger operativer Verantwortung.

KI-Agenten können betrieblichen Kontext interpretieren, Maßnahmen empfehlen und Aufgaben systemübergreifend innerhalb definierter Richtlinien und Kontrollen koordinieren.

Im Gegensatz zu herkömmlicher Automatisierung, die in erster Linie vordefinierten Workflows folgt, können Agenten auf Basis analytischer Modelle und des Kontexts intelligente Entscheidungen treffen, um Bedingungen zu interpretieren oder nächste Schritte zu koordinieren. Sie machen Ausführungskontrollen, Prüfbarkeit, erforderliche Genehmigungen, Rollback oder Verifizierung nach der Aktion nicht überflüssig.

Agentenbasierte Funktionen sollten schrittweise eingeführt und auf die Verfügbarkeit bestimmter Produkte, Deployments und Roadmaps abgestimmt werden.

Die Order-to-Activate-Automatisierung verbindet die Prozesse, die erforderlich sind, um von einem Kunden- oder Serviceauftrag zu einem aktivierten und betriebsbereiten Service zu gelangen.

Der Ablauf kann wiederverwendbares Servicedesign, Auftragszerlegung, Orchestrierung, Bestandszuweisung, Aktivierung, Konfiguration, Statusverwaltung und Assurance-Prüfungen über mehrere Systeme und Domains hinweg umfassen.

Gemeinsame Serviceabsicht und operativer Kontext reduzieren routinemäßige Übergaben und ermöglichen es, menschliche Eingriffe auf Ausnahmefälle zu konzentrieren.

Trouble-to-Resolve-Automatisierung verbindet Problemerkennung und -analyse mit Diagnose, Durchführung von Abhilfemaßnahmen und Überprüfung des operativen Ergebnisses.

Assurance erkennt den Zustand; Bestand, Topologie und Serviceauswirkung stellen den Kontext her; Analysen, KI, Richtlinien oder Regeln unterstützen die Entscheidung; Orchestrierung oder Aktivierung führt die Reaktion aus; und die Assurance nach der Aktion verifiziert die Wiederherstellung.

Die gleichen Grundlagen des Servicelebenszyklus, die für die Orchestrierung verwendet werden, können daher für die Problembehebung wiederverwendet werden.

Unified Operations und Digital Business Experience verbinden die operative Ausführung mit dem Kontext von Kunden, Produkten, Aufträgen, Monetarisierung und Betreuung.

Unified Operations bietet die OSS-Funktionen, die erforderlich sind, um Netzwerk- und Servicebetrieb zu planen, zu orchestrieren, zu aktivieren, sicherzustellen, zu beheben und zu verifizieren. Digital Business Experience erweitert diesen betrieblichen Kontext auf kunden- und geschäftsorientierte Bereiche und hilft CSPs, Netzwerk- und Servicebedingungen mit Kundenpriorität, SLA-Risiken, Umsatzauswirkungen, Produktzusagen und Kundenservice-Interaktionen in Beziehung zu setzen.

Die engere Zusammenführung dieser Umgebungen kann Betriebsabläufe dabei unterstützen, von netzwerk- und servicezentrierten Entscheidungen hin zu kunden- und geschäftszentrierten Entscheidungen überzugehen. Beispielsweise können Entscheidungen zu Abhilfemaßnahmen oder Kundenauswirkungen nicht nur den technischen Schweregrad und den Service-Schweregrad berücksichtigen, sondern auch, welche Kunden betroffen sind, welche Services sie nutzen, welche SLA-Verpflichtungen bestehen und welche übergeordneten Geschäftsprioritäten gelten.

Diese Abstimmung ist besonders relevant für moderne Services wie Network as a Service, 5G-Monetarisierung, SLA-gestützte Unternehmensservices und Szenarien für autonome Betriebsabläufe, in denen die geschäftliche Zielsetzung in operative Prozesse einfließen muss.