This is a draft version! Do not share the link externally!
Transforming Operations Support Systems: Building the Profitability Engine of the Autonomous Telco
As telecom operators face structural margin pressure and rising complexity, BCG Platinion is helping players redesign their Operations Support Systems architecture and turn operational control into a strategic profitability engine.
Why OSS transformation defines the autonomous telco
For decades, Operations Support Systems (OSS) were treated as technical infrastructure: indispensable, complex, but largely absent from strategic discussions. Quietly they provision services, reconcile network states, process alarms, and maintain operational continuity. Critical, yes. Strategic? Rarely.
In contrast, Business Support Systems (BSS) have dominated transformation agendas. Billing modernization, CRM consolidation, digital customer journeys, monetization engines, and product catalog harmonization were the core levers of competitiveness.
But breaking commercial bottlenecks is no longer the leading concern - operational bottlenecks have taken precedence as complexity and the pressure to adopt AI systems increases.
Structural factors also underline the need for OSS transformation:
(icon) Returns on invested capital have fallen below the cost of capital1
(icon) Revenue growth is constrained, while capital intensity continues to rise2
Telco operators are well equipped to design and sell modular, software-defined products, but are less effective at activating, maintaining, and scaling them. Architectural inefficiencies can no longer be offset by procurement optimization or workforce reductions, while operational complexity has increased significantly.
As decision-making increasingly shifts toward AI-driven systems, structured and governed operational data becomes non-negotiable. AI requires real-time observability, deterministic execution, and closed-loop control.
These are not peripheral capabilities — they are architectural properties anchored in the OSS. In this context, OSS is no longer technical infrastructure. It becomes the control system of the autonomous telco.
Structural constraints must become strategic levers
Transforming OSS is not primarily about replacing systems. It is about redefining the architectural logic that translates commercial intent into predictable network execution. To unlock this potential, operators must redesign how OSS translates business intent into network execution.
Rather than a collection of tools, the target architecture is a layered control model that enables business applications, orchestration capabilities, inventory intelligence, assurance mechanisms, and network resources to operate as part of a coherent, decoupled structure.
In legacy environments, this logic is blurred:
(icon) Business, service systems, and network domains are tightly coupled through proprietary interfaces and batch-based synchronization
(icon) Automation is frequently retrofitted onto unstable foundations, reinforcing complexity rather than resolving it
(icon) Inventory data is fragmented across domains, orchestration is embedded within silos, and assurance tools operate in parallel (rather than in coordination)
This logic was designed for stability and manual supervision, not for real-time orchestration, cross-domain intelligence, or autonomous execution.
The target state follows a fundamentally different principle:
(icon) Commercial applications (e.g ., Configure, Price, Quote (CPQ), product inventories and business channels) define intent at the top of the stack
(icon) End-to-end assurance functions, powered by a Network Data Hub, ensure real-time observability and closed-loop correction
(icon) A unified Service Order Management layer acts as the control plane, decomposing services and orchestrating execution
(icon) Harmonized inventory capabilities provide a single, consistent view of service and resource states
With this control architecture in place, network resources - from fixed, mobile, core, and edge domains are executed via standardized orchestration and activation layers. To convert a fragmented OSS landscape into a coherent control system capable of supporting autonomous network operations, structured progression is required.
Building next-generation OSS telco architecture
Successful OSS transformations are not executed as isolated modernization initiatives. They follow a deliberate architectural progression built on four steps:
Step 1: Harmonization of inventory management
Step 2: Automation of fulfillment processes
Step 3: Implementation of end-to-end (E2E) service assurance
Step 4: Operation of autonomous network
Together, these steps reveal a structured maturity path that heads toward higher levels of autonomous network operations. Skipping foundational steps does not create acceleration; it introduces instability, higher failure rates, and compounding integration complexity.
Together, these steps reveal a structured maturity path that heads toward higher levels of autonomous network operations. Skipping foundational steps does not create acceleration; it introduces instability, higher failure rates, and compounding integration complexity.
(pyramid 1)
Harmonize inventory management
The success of every OSS transformation hinges on data integrity, yet inventory fragmentation remains one of the most underestimated structural constraints in telecom operations.
Across most operators, inventory spans both service and resource layers – from logical service configurations to the underlying physical and virtual network assets. Over time, these have been distributed across multiple systems in fixed, mobile, core, and enterprise domains, each shaped by proprietary models and local engineering logic.
Therefore, harmonizing inventories across domains and abstraction layers is not merely a consolidation effort; it requires rethinking how products, services, and resources relate to one another. A consistent Product–Service–Resource (P-S-R) model separates commercial intent from logical services and the network resources that enable them.
This modularization must start at the resource layer - only when physical, logical, and virtualized assets are modeled coherently across domains can services be decomposed and orchestrated predictably.
But modularization alone does not resolve fragmentation, true harmonization is a unified information model that spans products, services, and resources.
(pyramid icon)
Automate fulfilment processes
For many operators, service fulfillment spans multiple systems and segments – often requiring separate stacks with distinct service definitions and governance models.
Order management, orchestration, activation, and service inventory have developed independently, reflecting organizational boundaries rather than architectural coherence. This has led to structural inconsistency, slowing time to market and limiting maturity.
A modern fulfillment architecture establishes Service Order Management as a unified control plane. Spanning both segments and technologies, it translates commercial intent into standardized service logic and coordinates lifecycle execution end-to-end. This calls for harmonized models and the strict reuse of modular building blocks.
Cross-domain orchestration extends this logic across fixed, mobile, core, transport, and cloud environments. By applying a P-S-R hierarchy, orchestration separates end-to-end decision ownership from domain-level execution, preserving consistency without creating bottlenecks.
Execution at scale depends on a resilient activation layer capable of handling high provisioning volumes across hybrid infrastructures.
When fulfillment becomes predictable and programmable across segments, the network can be exposed as a platform - facilitating ecosystem integration and laying the foundations for closed-loop assurance.
(pyramid icon)
Implement end-to-end service assurance
For many players, legacy assurance landscapes are fragmented across fault, performance, topology, and ticketing systems. Vendor-specific tools provide domain visibility, yet cross-domain correlation is limited.
Configuration management database and geographic information system data are often incomplete, and automation remains script-based rather than systemic. Because of these factors, root cause analysis depends heavily on expert intervention, and AI initiatives struggle due to inconsistent data foundations.
Progressing towards greater autonomy requires architectural consolidation around a Network Data Hub (NDH). The NDH aggregates telemetry, configuration states, performance metrics, and event data across domains through standardized, streaming-based interfaces. By normalizing and governing this data within a unified model, it establishes a single source of truth for service and network observability.
This integration enables closed-loop assurance. Detection, analysis, decision, and remediation become part of a continuous cycle, and service degradation triggers orchestration adjustments automatically. Predictive fault management replaces reactive ticket handling, and observability shifts from infrastructure monitoring to service-centric intelligence.
As maturity increases, digital twin capabilities extend this model. Network changes can be simulated using technology before execution, and intent compliance can be monitored continuously across service and resource layers. Cloud-native deployment further strengthens scalability and resilience while maintaining governance and data ownership guardrails.
This consolidation is a fundamental step in the shift from reactive supervision to predictive, intent-aware control – forming the basis for autonomous network operations.
(pyramid icon)
Operate autonomous networks
Autonomous network operation marks the culmination of the transformation journey. At this stage, automation no longer supports operations; it defines them.
Telco operators that reach this point will see networks evolve into cloud-native software platforms, where virtualized and containerized functions replace hardware-centric architectures. But infrastructure modernization alone does not create autonomy. The operating model must shift toward a fully machine-consumable environment.
A headless, API-first OSS architecture is essential to this. Provisioning, topology, and lifecycle capabilities are exposed through standardized interfaces, enabling orchestration engines and AI systems to interact directly with operational layers. At the center sits the AIOps platform, continuously ingesting telemetry information from the Network Data Hub, and translating analysis into automated decisions and corrective actions.
As maturity increases, agentic AI interprets service intent, coordinates cross-domain workflows, and validates outcomes within defined policy guardrails. At the same time, continuous improvement is enabled by CI/CD-driven lifecycle management, facilitating rapid updates without compromising stability.
Together, these capabilities enable networks to act on business and service intent with minimal human intervention. Ultimately, the OSS becomes the operational intelligence of the organization.
A fork in the road – from legacy to autonomous telco
Telecom operators are at a structural inflection point. They can continue to incrementally optimize fragmented legacy environments and accept gradual margin erosion. Or they can redesign their operational core and treat the network as software.
AI transformation at the commercial layer ultimately depends on the ability to translate intent into automated, deterministic, intelligent execution at scale – OSS transformation is the key.
The four critical building blocks covered in this article transform the network from infrastructure into a profitability engine:
(icon) Harmonized inventory establishes trust
(icon) Automated fulfillment establishes control
(icon) Closed-loop assurance establishes stability
(icon) AI-driven autonomy establishes intelligence
The question is no longer whether OSS should be transformed – but how quickly operators can execute that transformation.
Faced with this urgency, many default to searching for solutions in standard software platforms. While this instinct is understandable, it often addresses individual symptoms rather than underlying structural constraints.
Effective OSS transformation begins with a clear assessment of the current landscape, existing capabilities, and architectural gaps. On this basis, a target architecture and coherent technology strategy can be defined to guide subsequent platform and vendor decisions.
Footnotes:
1. Rastogi, V., Franck Luisada, Elbert, V., Wilms, M., Bamberger, S., Khanna, P., & Farag, H. (2025, February 27). Returns May Be Declining, but Opportunity Is Calling. BCG Global. https://www.bcg.com/publications/2025/boosting-value-creation-in-telcos.
2. Annual reports from leading EMESA telecom operators show that service revenue growth remained largely flat between 2022 and 2025 while capital expenditure remained elevated due to sustained fiber rollout, 5G deployment, and mandated high-risk vendor replacement, keeping CapEx-to-revenue ratios at 13–19% and widening the gap between investment and free cash flow generation.
