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

CSPs modernisieren ihre Abläufe, um die zunehmende Komplexität von Netzwerken und Services zu bewältigen und gleichzeitig Kosten, Zuverlässigkeit, Serviceagilität, Automatisierung und Kundenerlebnis zu verbessern.

Viele Betriebsumgebungen enthalten fragmentierte Assurance-, Bestands-, Service-Orchestrierungs- und Fulfillment-, Aktivierungs-, Ticketing-, Domain-Orchestrierungs- und Business-Support-Systeme (BSS). Diese Fragmentierung erhöht den manuellen Aufwand, verlangsamt die Servicebereitstellung und die Behebung von Incidents und erschwert es, die Automatisierung domänenübergreifend konsistent zu skalieren.

Modernisierung konzentriert sich daher zunehmend darauf, ein kohärenteres und automatisiertes Betriebsmodell für den Servicelebenszyklus zu schaffen, anstatt isolierte Tools separat zu optimieren.

Häufige Warnsignale sind hoher manueller Aufwand, fragmentierte Daten, langsame Incident-Behebung, mangelnde Transparenz zu 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 Auftragsfehlerquoten, vermeidbare Technikereinsätze, doppelte Tools sowie Integrationen, deren Änderung teuer 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 einheitlichen Lebenszyklus zu unterstützen.

Assurance-, Bestands-, Serviceorchestrierungs- und Fulfillment-, Aktivierungs-, Ticketing-, Domain-Orchestrierungs- und BSS-Umgebungen können jeweils Teilkontext enthalten. Dies kann zu doppelter Arbeit, benutzerdefinierten Integrationen, manuellen Übergaben, uneinheitlichen Betriebsansichten und geringerer Agilität führen.

Da Services immer mehr Domains und Anbieter umfassen, können die Kosten für deren Koordination schneller steigen als die Kosten jedes einzelnen Tools.

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

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

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

Die Reduzierung der Mean Time to Repair (MTTR) wird schwierig, wenn Betriebsteams Netzwerkereignisse nicht schnell mit der Ursache, den Auswirkungen auf Services und Kunden sowie dem geeigneten Behebungspfad in Verbindung bringen können.

Informationen zu Fehlern, Performance, Topologie, Bestand und Services können über verschiedene Systeme verteilt sein. Ohne korrelierten Kontext können Teams mehr Zeit damit verbringen, Symptome zu untersuchen und Prioritäten festzulegen, bevor sie Korrekturmaßnahmen ergreifen.

Schnellere Erkennung, Serviceauswirkungsanalyse, Ursachenanalyse, Behebung und Verifizierung sind daher zentrale Zuverlässigkeitsziele.

Hohe Ereignisvolumina binden 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, können Teams wiederholt Symptome untersuchen, unnötige Tickets erstellen und Vorfälle eskalieren, die automatisch hätten gefiltert oder priorisiert werden können.

Die Reduzierung von Ereignisrauschen ist daher sowohl ein Zuverlässigkeits- als auch ein Betriebseffizienzziel.

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

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 zunehmend höhere Automatisierungsgrade anstreben, gewinnt das Vertrauen in die Beziehungen zwischen Services und Ressourcen an Bedeutung.

Vertrauenswürdiger Kontext ist daher eine geschäftliche Voraussetzung für die Skalierung der Automatisierung und nicht nur ein Aspekt des Bestandsmanagements.

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

5G, private Netzwerke, Network Slicing, Cloud Computing, APIs, Enterprise-Konnektivität und Network as a Service können koordinierte Planung, 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 Netzwerkfähigkeit bereits vorhanden ist.

Das Kundenerlebnis hängt zunehmend davon ab, wie schnell der Betrieb betroffene Services identifizieren, die richtige Reaktion priorisieren, den Service wiederherstellen und die Wiederherstellung verifizieren kann.

Ein Netzwerkereignis kann je nach betroffenen Kunden, Services, SLAs oder kommerziellen Verpflichtungen sehr unterschiedliche geschäftliche Auswirkungen haben. Operations-Teams, die technische Bedingungen mit Service- und Kundenkontext verknüpfen können, sind besser in der Lage, nach Auswirkungen statt allein nach Alarmpriorität zu priorisieren.

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

Die OSS-Modernisierung sollte an messbare Verbesserungen bei Kosten, Zuverlässigkeit, Service-Agilität, Automatisierung und Auswirkungen auf Kunden geknüpft sein.

Relevante KPIs können Aktivierungszykluszeit, Rate fehlgeschlagener Aufträge, Automatisierungsgrad, Event-to-Ticket-Verhältnis, mittlere Erkennungszeit, MTTR, SLA-Compliance, kundenrelevante Vorfälle, Techniker-Einsätze, 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 allgemeine Aussagen.

Ein modernes Telekommunikations-OSS ist die operative Softwareumgebung, die zum Entwerfen, Bereitstellen, Aktivieren, Überwachen, Absichern und Warten von Netzwerken und Services eingesetzt wird.

Ein modernes OSS umfasst in der Regel Service-Design, Bestands- und Topologieverwaltung, Orchestrierung, Aktivierung, Assurance, Observability und Automatisierung, die alle zusammenarbeiten, um Closed-Loop-Operations voranzutreiben. Diese Funktionen müssen über Multi-Vendor- und Multi-Domain-Servicelebenszyklen 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 Service Design, Auftrags- und Serviceorchestrierung, Aktivierung, Bestandsverwaltung und Topologie, Assurance und Observability sowie KI-gestützte Fehlerbehebung.

CSPs können ausgewählte Funktionen bereitstellen und die Nutzung ausweiten, wenn sich ihre betrieblichen Prioritäten und ihr Reifegrad weiterentwickeln. Das Portfolio ist darauf ausgelegt, eine schrittweise Modernisierung zu unterstützen, statt vorauszusetzen, dass jede OSS-Funktion gleichzeitig umgestellt wird.

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

Das Portfolio umfasst Servicekatalog und -design, Auftrags- und Servicemanagement, Orchestrierung, Aktivierung und Netzwerkkonfiguration, Bestandsverwaltung und Topologie, Netzwerkerkennung und -abgleich, Assurance und Observability, Serviceauswirkungsanalyse, Entscheidungsfindung und Fehlerbehebung sowie Verifizierung nach der Maßnahme.

Unified Operations umfasst Oracle Communications-Produkte mit unterschiedlichen Rollen über den gesamten Servicelebenszyklus hinweg.

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

Ein CSP kann einen Schwerpunktbereich modernisieren, dabei bestehende nützliche Investitionen schützen und im Laufe der Zeit auf weitere Funktionsbereiche ausweiten. Die Ziel-Integrationsarchitektur 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 Abläufe. Die richtige Reihenfolge hängt von der bestehenden Architektur, den geschäftlichen Prioritäten, der betrieblichen Reife, der Risikotoleranz und dem Zielbetriebsmodell ab.

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

Einzellösungen können innerhalb einzelner Funktionen effektiv sein, doch Kundenergebnisse erstrecken sich häufig über Assurance-, Inventory-, Orchestrierungs-, Aktivierungs- und BSS-Prozesse. Unified Operations wurde entwickelt, um Kontext, Beobachtung, Entscheidungsfindung, Ausführung und Verifizierung über betriebliche Grenzen hinweg zu verbinden.

Unified Operations bietet OSS-Grundlagen, die einen schrittweisen Übergang von funktionaler Automatisierung hin zu zunehmend koordinierten und Closed-Loop-Operations 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, Domains, Prozesse und Risikostufen anwenden, statt Autonomie als Transformation in einem einzigen Schritt zu betrachten.

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

Es unterstützt Festnetz-, Mobilfunk-, Transport-, Core-, 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 außerdem 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.

Zu den typischen Stakeholdern zählen CTOs, CIOs, COOs, Führungskräfte für Netzwerk- und Servicebetrieb, OSS-Transformationsteams, Verantwortliche für Fulfillment und Assurance, Inventory Owner, Automatisierungsteams, Führungskräfte für Customer Experience sowie Finanz-Stakeholder.

Unified Operations verbindet Servicedesign, Orchestrierung, Aktivierung, Betriebskontext, Assurance, Entscheidungsfindung, Fehlerbehebung und Verifizierung als ergänzende Lifecycle-Funktionen.

Servicemodelle definieren wiederverwendbare Intents; Orchestrierung koordiniert die erforderlichen Arbeiten; 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 Lifecycle-Kontinuität bildet die Grundlage sowohl für die Fulfillment-Automatisierung als auch für zunehmend autonome Betriebsabläufe.

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

Ein nützliches Betriebsmodell ist: Erkennen → Verstehen → Entscheiden → Handeln → Überprüfen. Assurance und Observability erkennen Zustände; Inventar, 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 die Serviceintegrität 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, Service-Impact-Analysen, Ursachenanalysen, Digital-Twin-Grundlagen, KI-generierte Empfehlungen und Closed-Loop-Remediation. Die Aufrechterhaltung der Bestandsgenauigkeit durch den Abgleich der ermittelten Netzwerkrealität mit Bestandsdatensätzen kann das Vertrauen weiter stärken.

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

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

Es kombiniert Kontextinformationen wie Bestand, Topologie, Störungen, Performance, Kapazität, Datenverkehr und Servicebeziehungen. Dies hilft Teams und automatisierten Workflows, Incidents und Abhilfemaßnahmen basierend auf den Auswirkungen auf Services und Geschäft zu priorisieren – statt allein nach dem Schweregrad des Problems.

Ein schnelleres Verständnis der Auswirkungen kann außerdem Untersuchungszeiten verkürzen und in Kombination mit Ursachenanalyse und kontrollierter Ausführung 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.

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

Funktionen für digitale Zwillinge und Was-wäre-wenn-Analysen sollten gemäß der jeweiligen 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 Trouble-to-Resolve-Bereich erheblichen Mehrwert bei Anomalieerkennung, Ursachenanalyse, Prognosen, Priorisierung, Empfehlungen und Workflows zur Fehlerbehebung liefern, muss jedoch auf einem vertrauenswürdigen betrieblichen Kontext basieren.

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

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

KI-Agenten können betriebliche Kontexte 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 die nächsten Schritte zu koordinieren. Sie machen Ausführungskontrollen, Prüfbarkeit, erforderliche Genehmigungen, Rollback oder Überprüfungen nach der Aktion nicht überflüssig.

Agentic-Funktionen sollten schrittweise eingeführt und an der spezifischen Produkt-, Deployment- und Roadmap-Verfügbarkeit ausgerichtet 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 Service-Design, Auftragszerlegung, Orchestrierung, Bestandszuweisung, Aktivierung, Konfiguration, Statusverwaltung und Assurance-Prüfungen über mehrere Systeme und Domains hinweg umfassen.

Gemeinsamer Service-Intent und operativer Kontext reduzieren routinemäßige Übergaben und ermöglichen es, menschliche Eingriffe auf Ausnahmen zu konzentrieren.

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

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

Die gleichen Grundlagen des Service-Lebenszyklus, die für die Orchestrierung verwendet werden, können daher für die Fehlerbehebung wiederverwendet werden.

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

Unified Operations bietet die OSS-Funktionen, die für das Design, die Orchestrierung, Aktivierung, Sicherung, Fehlerbehebung und Verifizierung von Netzwerk- und Serviceabläufen erforderlich sind. Digital Business Experience erweitert diesen betrieblichen Kontext auf kunden- und geschäftsorientierte Bereiche und unterstützt CSPs dabei, Netzwerk- und Servicebedingungen mit Kundenpriorität, SLA-Risiken, Umsatzauswirkungen, Produktzusagen und Kundenservice-Interaktionen in Beziehung zu setzen.

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

Diese Ausrichtung ist besonders relevant für moderne Services wie Network-as-a-Service, 5G-Monetarisierung, SLA-gestützte Enterprise-Services und autonome Betriebsszenarien, in denen geschäftliche Zielsetzungen in operative Prozesse einfließen müssen.