Unified Orchestration and Assurance : un système de support des opérations cloud natif (OSS)

Les CSP modernisent leurs opérations pour gérer la complexité croissante des réseaux et des services, tout en améliorant les coûts, la fiabilité, l’agilité des services, l’automatisation et l’expérience client.

De nombreux environnements d’exploitation comportent des systèmes fragmentés d’assurance, d’inventaire, d’orchestration et d’exécution des services, d’activation, de gestion des tickets, d’orchestration des domaines et de support métier (BSS). Cette fragmentation augmente le travail manuel, ralentit la fourniture de services et la résolution des incidents, et complique la mise à l’échelle cohérente de l’automatisation entre les domaines.

La modernisation vise donc de plus en plus à créer un modèle opérationnel de cycle de vie des services plus cohérent et automatisé, plutôt qu’à optimiser séparément des outils isolés.

Les signes d’alerte courants incluent des efforts manuels importants, des données fragmentées, une résolution lente des incidents, une faible visibilité sur l’impact des services, de longs cycles d’activation et des difficultés à faire évoluer l’automatisation.

Parmi les autres indicateurs figurent un bruit excessif des événements du centre d’exploitation réseau (NOC), un inventaire non fiable, un taux élevé d’échecs de commandes, des interventions sur site évitables, des outils dupliqués et des intégrations coûteuses ou risquées à modifier.

Le signal le plus important est généralement une contrainte opérationnelle récurrente qui génère un impact mesurable sur les coûts, les délais, la fiabilité, la qualité de service ou l’expérience client.

Les environnements OSS fragmentés obligent les équipes opérationnelles à rapprocher les données, les workflows et les décisions entre des systèmes qui n’ont pas été conçus pour fonctionner ensemble afin de prendre en charge un cycle de vie unique.

Les environnements d’assurance, d’inventaire, d’orchestration et d’exécution des services, d’activation, de gestion des tickets, d’orchestration de domaine et BSS peuvent chacun contenir un contexte partiel. Cela peut entraîner des tâches redondantes, des intégrations personnalisées, des transferts manuels, des vues opérationnelles incohérentes et une agilité réduite.

À mesure que les services couvrent davantage de domaines et de fournisseurs, le coût de leur coordination peut augmenter plus vite que celui de n’importe quel outil individuel.

Un taux élevé d’échecs et une activation lente résultent souvent de flux de commande fragmentés, de données incohérentes, de dépendances complexes, d’intégrations fragiles et d’une faible visibilité sur les systèmes d’exécution.

Les commandes télécoms peuvent couvrir les couches client, service et technique dans plusieurs domaines. Lorsque les modèles de services, l’inventaire, l’orchestration, l’activation et la gestion des statuts ne sont pas coordonnés, les exceptions et les reprises manuelles augmentent.

Réduire ces transferts est donc un objectif métier clé pour la modernisation des OSS.

Réduire le temps moyen de réparation (MTTR) devient difficile lorsque les équipes d’exploitation ne peuvent pas relier rapidement les événements réseau à la cause racine, à l’impact sur les services, à l’impact sur les clients et au plan de remédiation approprié.

Les informations sur les pannes, les performances, la topologie, l’inventaire et les services peuvent être réparties entre différents systèmes. Sans contexte corrélé, les équipes peuvent passer davantage de temps à analyser les symptômes et à déterminer les priorités avant de prendre des mesures correctives.

Une détection plus rapide, l’analyse de l’impact sur les services, l’analyse des causes profondes, la résolution et la vérification constituent donc des objectifs essentiels de fiabilité.

Des volumes élevés d’événements mobilisent l’attention des opérateurs et compliquent l’identification du faible nombre de conditions qui menacent réellement les services ou les clients.

Lorsque les alarmes sont mal corrélées avec la topologie, les relations de service ou la cause racine probable, les équipes peuvent enquêter à plusieurs reprises sur les symptômes, créer des tickets inutiles et faire remonter des incidents qui auraient pu être filtrés ou hiérarchisés automatiquement.

La réduction du bruit des événements constitue donc un objectif à la fois de fiabilité et d’efficacité opérationnelle.

L’automatisation et l’IA ont besoin d’un contexte opérationnel fiable pour comprendre quelles ressources, quels services, quelles dépendances et quels clients peuvent être affectés par une décision.

Si l’inventaire ou la topologie est incomplet ou obsolète, l’analyse de l’impact sur les services, l’orchestration, les recommandations d’IA et la remédiation en boucle fermée peuvent être moins fiables. À mesure que les opérateurs évoluent vers des niveaux d’automatisation plus élevés, la confiance dans les relations entre les services et les ressources gagne en importance.

Le contexte fiable est donc un prérequis métier pour faire évoluer l’automatisation, et pas simplement une question de gestion de l’inventaire.

Les nouvelles capacités réseau ne créent de la valeur que lorsque les CSP peuvent les transformer rapidement en services reproductibles et les exploiter de manière fiable à grande échelle.

La 5G, les réseaux privés, le network slicing, le cloud computing, les API, la connectivité d’entreprise et le réseau en tant que service peuvent nécessiter une conception, une orchestration, une activation, un inventaire, une assurance et une gestion des SLA coordonnés.

Les longs cycles de conception au lancement ou de commande à l’activation peuvent donc limiter la monétisation, même lorsque la capacité réseau sous-jacente existe déjà.

L’expérience client dépend de plus en plus de la rapidité avec laquelle les opérations peuvent identifier les services affectés, hiérarchiser la réponse appropriée, rétablir le service et vérifier la reprise.

Un événement réseau peut avoir un impact commercial très différent selon les clients, les services, les SLA ou les engagements commerciaux concernés. Les équipes d’exploitation capables de relier les conditions techniques au contexte des services et des clients sont mieux placées pour établir les priorités en fonction de l’impact, plutôt que de la seule gravité des alertes.

Cela peut favoriser une restauration plus rapide, réduire les défaillances visibles par les clients et renforcer la confiance dans les SLA.

La modernisation des OSS doit être associée à des améliorations mesurables en matière de coûts, de fiabilité, d’agilité des services, d’automatisation et d’impact client.

Les KPI pertinents peuvent inclure le temps de cycle d’activation, le taux d’échec des commandes, le taux d’automatisation, le ratio événements/tickets, le temps moyen de détection, le MTTR, le respect des SLA, les incidents ayant un impact sur les clients, les déplacements de techniciens, le délai de génération de revenus et le coût de service.

Les CSP doivent utiliser leur processus actuel pour établir une référence avant de définir des objectifs d’amélioration, afin que le dossier d’analyse reflète l’environnement réel plutôt que des affirmations générales.

Un OSS télécom moderne est l’environnement logiciel opérationnel utilisé pour concevoir, fournir, activer, surveiller, assurer et maintenir les réseaux et les services.

Un OSS moderne inclut généralement la conception des services, l’inventaire et la topologie, l’orchestration, l’activation, l’assurance, l’observabilité et l’automatisation, qui fonctionnent ensemble pour favoriser des opérations en boucle fermée. Ces fonctionnalités doivent fonctionner sur l’ensemble des cycles de vie des services multifournisseurs et multidomaines, plutôt que de rester cloisonnées par fonction ou par domaine réseau.

Oracle Unified Operations est le portefeuille OSS modulaire d’Oracle conçu pour aider les CSP à accélérer leur transition vers des opérations autonomes. Cela inclut la conception des services, l’orchestration des commandes et des services, l’activation, l’inventaire et la topologie, l’assurance et l’observabilité, ainsi que la remédiation assistée par l’IA.

Les CSP peuvent déployer certaines fonctionnalités et étendre leur adoption à mesure que leurs priorités opérationnelles et leur maturité évoluent. Le portefeuille est positionné pour soutenir une modernisation progressive plutôt que d’exiger que chaque fonction OSS change simultanément.

Unified Operations couvre les principales capacités opérationnelles nécessaires pour concevoir, fournir, exploiter et garantir les services télécoms tout au long de leur cycle de vie.

Le portefeuille couvre le catalogue et la conception des services, la gestion des commandes et des services, l’orchestration, l’activation et la configuration réseau, l’inventaire et la topologie, la découverte et le rapprochement du réseau, l’assurance et l’observabilité, l’analyse de l’impact sur les services, la prise de décision et la remédiation, ainsi que la vérification post-action.

Unified Operations comprend des produits Oracle Communications qui jouent des rôles distincts tout au long du cycle de vie des services.

Oui. Unified Operations peut être introduit parallèlement aux environnements OSS, réseau, d’orchestration de domaine, de gestion des tickets, d’assurance, d’inventaire, d’activation et BSS existants.

Un CSP peut moderniser un domaine prioritaire tout en préservant les investissements existants utiles, puis s’étendre progressivement à d’autres domaines fonctionnels. L’architecture d’intégration cible dépend de l’environnement client, des cas d’utilisation sélectionnés et des systèmes qui restent en service.

Oui. Un CSP peut moderniser un seul domaine opérationnel, combiner plusieurs priorités ou coordonner une transformation plus large du cycle de vie des services.

Les points d’entrée courants incluent l’assurance et l’observabilité, l’inventaire et la topologie, l’orchestration, l’activation, ainsi que certains cas d’utilisation des opérations autonomes. La séquence appropriée dépend de l’architecture existante, des priorités métier, de la maturité opérationnelle, de la tolérance au risque et du modèle opérationnel cible.

Unified Operations s’articule autour de la coordination et de l’automatisation sur l’ensemble du cycle de vie des services, plutôt que d’une automatisation limitée à un seul outil, une seule technologie ou un seul domaine réseau.

Les outils ponctuels peuvent être efficaces au sein de fonctions individuelles, mais les résultats pour les clients couvrent souvent les processus d’assurance, d’inventaire, d’orchestration, d’activation et de BSS. Unified Operations est conçu pour connecter le contexte, l’observation, la prise de décision, l’exécution et la vérification au-delà des frontières opérationnelles.

Unified Operations fournit des bases OSS capables de soutenir une transition progressive de l’automatisation fonctionnelle vers des opérations de plus en plus coordonnées et en boucle fermée.

Le portefeuille réunit un contexte opérationnel fiable, l’assurance et l’observabilité, l’orchestration, l’activation, la prise de décision, la remédiation et la vérification. Les CSP peuvent appliquer progressivement ces capacités à des services, domaines, processus et niveaux de risque définis, plutôt que de considérer l’autonomie comme une transformation en une seule étape.

Oui. Unified Operations est conçu pour les environnements télécoms qui couvrent plusieurs fournisseurs, technologies, domaines et systèmes opérationnels.

Elle peut prendre en charge les environnements fixes, mobiles, de transport, de cœur de réseau, de réseau d’accès radio (RAN), cloud, de mise en réseau définie par logiciel (SDN), edge, physiques, virtuels et cloud native, tout en s’intégrant aux systèmes existants. L’architecture est également conçue pour compléter, le cas échéant, les approches alignées sur TM Forum, les fonctionnalités définies par le 3GPP, les initiatives GSMA et CAMARA, ainsi que les modèles de cycle de vie de type MEF.

Unified Operations s’adresse principalement aux CSP et aux opérateurs réseau qui gèrent des cycles de vie de services complexes sur plusieurs systèmes, technologies, domaines et fournisseurs.

Les parties prenantes typiques incluent les CTO, CIO, COO, responsables des opérations réseau et services, équipes de transformation OSS, responsables du fulfillment et de l’assurance, propriétaires de l’inventaire, équipes d’automatisation, responsables de l’expérience client et parties prenantes financières.

Unified Operations relie la conception des services, l’orchestration, l’activation, le contexte opérationnel, l’assurance, la prise de décision, la remédiation et la vérification en tant que capacités complémentaires du cycle de vie.

Les modèles de service définissent une intention réutilisable ; l’orchestration coordonne les tâches requises ; l’activation exécute les changements réseau ou IT ; l’inventaire et la topologie fournissent le contexte des ressources de service ; l’assurance observe les conditions ; la prise de décision sélectionne une réponse ; et la vérification confirme le résultat.

Cette continuité du cycle de vie constitue la base à la fois de l’automatisation de l’exécution et d’opérations de plus en plus autonomes.

L’automatisation en boucle fermée relie la détection, la compréhension, la prise de décision, l’exécution et la vérification dans un processus opérationnel gouverné unique.

Un modèle opérationnel utile est : Détecter → Comprendre → Décider → Agir → Vérifier. L’assurance et l’observabilité détectent les conditions ; l’inventaire, la topologie et les relations de service fournissent le contexte ; l’analytique, l’IA, les politiques ou les règles facilitent la décision ; l’orchestration ou l’activation exécute l’action ; et l’assurance vérifie si l’état de santé du service s’est amélioré.

La vérification distingue une boucle fermée complète d’une automatisation qui se contente d’appliquer une modification sans en confirmer le résultat.

L’inventaire et la topologie aident les workflows d’automatisation à comprendre les ressources, les services, la connectivité, les dépendances et les relations concernés par une décision opérationnelle.

Ce contexte permet l’orchestration, l’analyse de l’impact sur les services, l’analyse des causes racines, les fondements des jumeaux numériques, les recommandations générées par l’IA et la remédiation en boucle fermée. Maintenir l’exactitude de l’inventaire en rapprochant la réalité du réseau découverte avec les enregistrements d’inventaire peut renforcer davantage la confiance.

Sans contexte suffisamment fiable, les décisions automatisées peuvent être plus difficiles à évaluer et à gouverner.

L’analyse d’impact sur les services identifie les services, clients, sites ou engagements métier susceptibles d’être affectés par un problème réseau ou opérationnel.

Elle combine le contexte tel que l’inventaire, la topologie, les pannes, les performances, la capacité, le trafic et les relations de service. Cela aide les équipes et les workflows automatisés à hiérarchiser les incidents et les mesures correctives en fonction de l’impact sur les services et l’activité, plutôt que de la seule gravité du problème.

Une compréhension plus rapide de l’impact peut également raccourcir les délais d’investigation et contribuer à réduire le MTTR lorsqu’elle est associée à l’analyse des causes racines et à une exécution contrôlée.

Un jumeau numérique est une représentation numérique des ressources réseau et de service, des relations, de la topologie et de l’état opérationnel, utilisée pour comprendre les dépendances et l’impact potentiel.

L’analyse de simulation peut utiliser ce contexte pour évaluer l’effet probable d’un changement proposé avant son exécution, comparer les options de correction et identifier les services ou dépendances affectés. Cela peut favoriser des décisions opérationnelles plus éclairées et mieux maîtrisées.

Les fonctionnalités de jumeau numérique et de simulation de scénarios doivent être positionnées en fonction de la disponibilité pertinente du produit, du déploiement et de la feuille de route.

L’IA peut soutenir les opérations télécoms dans des processus tels que la planification et la conception, de la commande à l’activation, et de l’incident à la résolution. Par exemple, dans le domaine de la résolution des problèmes, l’IA peut apporter une valeur significative aux workflows de détection des anomalies, d’analyse des causes racines, de prédiction, de priorisation, de recommandations et de remédiation, mais elle doit s’appuyer sur un contexte opérationnel fiable.

Les données pertinentes peuvent inclure les informations sur les pannes et les performances, l’état des services, l’inventaire, la topologie, le contexte client et SLA, l’historique des workflows, les tickets et les résultats des actions correctives. Les données exactes dépendent du cas d’utilisation.

L’IA doit être introduite progressivement autour de processus bien définis, avec une gouvernance, des résultats mesurables et une responsabilité opérationnelle claire.

Les agents d’IA peuvent interpréter le contexte opérationnel, recommander des actions et coordonner les tâches entre les systèmes, conformément aux politiques et contrôles définis.

Contrairement à l’automatisation traditionnelle, qui suit principalement des workflows prédéfinis, les agents peuvent prendre des décisions intelligentes fondées sur des modèles analytiques et le contexte afin d’aider à interpréter les conditions ou à coordonner les prochaines étapes. Ils n’éliminent pas la nécessité de contrôles d’exécution, d’auditabilité, d’approbations le cas échéant, de retour arrière ou de vérification post-action.

Les capacités agentiques doivent être introduites progressivement et alignées sur la disponibilité spécifique des produits, du déploiement et de la feuille de route.

L’automatisation de la commande à l’activation relie les processus nécessaires pour passer d’une commande client ou de service à un service activé et opérationnel.

Le flux peut inclure la conception de services réutilisables, la décomposition des commandes, l’orchestration, l’affectation des ressources d’inventaire, l’activation, la configuration, la gestion des statuts et les contrôles d’assurance sur plusieurs systèmes et domaines.

L’intention de service partagée et le contexte opérationnel réduisent les transferts courants et permettent de concentrer l’intervention humaine sur les exceptions.

L’automatisation de la résolution des incidents relie la détection et l’analyse des problèmes au diagnostic, à l’exécution des mesures correctives et à la vérification du résultat opérationnel.

L’assurance détecte la condition ; l’inventaire, la topologie et l’impact sur le service établissent le contexte ; l’analytique, l’IA, les politiques ou les règles appuient la décision ; l’orchestration ou l’activation exécute la réponse ; et l’assurance post-action vérifie la reprise.

Les mêmes bases du cycle de vie des services utilisées pour l’orchestration peuvent donc être réutilisées pour la remédiation.

Unified Operations et Digital Business Experience relient l’exécution opérationnelle au contexte client, produit, commande, monétisation et assistance.

Unified Operations fournit les fonctionnalités OSS nécessaires pour concevoir, orchestrer, activer, assurer, corriger et vérifier les opérations réseau et de service. Digital Business Experience étend ce contexte opérationnel aux domaines orientés client et métier, aidant les CSP à relier les conditions du réseau et des services à la priorité client, à l’exposition aux SLA, à l’impact sur le chiffre d’affaires, aux engagements produits et aux interactions avec le service client.

Rapprocher ces environnements peut aider les opérations à passer d’une prise de décision centrée sur le réseau et les services à une prise de décision centrée sur les clients et l’activité. Par exemple, les décisions de remédiation ou liées à l’impact client peuvent tenir compte non seulement de la gravité technique et de service, mais aussi des clients affectés, des services qu’ils utilisent, des engagements de SLA et des priorités métier plus larges.

Cet alignement est particulièrement pertinent pour les services modernes tels que le réseau en tant que service, la monétisation de la 5G, les services d’entreprise adossés à des SLA, et les scénarios d’opérations autonomes où l’intention métier doit se transmettre aux processus opérationnels.