The journey for OSS Transformation can take many paths. We’ve identified five flavors, based on the needs and constraints of different Service Providers. Each flavor of OSS transformation has distinct challenges. The end result may be the same, but the choice will depend on starting point, budget and business priorities. In all cases, having a clear vision of the endpoint and the path to get there will make the difference between success and failure.

The five flavors of OSS-T are:

1. Complete BSS and OSS Transformation

Only a few of the world’s largest operators can justify this full-scale, multi-year project. It is necessary when the existing systems estate is an impediment to efficient business operations. In parallel, there will be a massive rationalization of the myriad BSS and OSS software systems used to control the network.

Only the most scalable, robust and complete product sets can do the job. There are but a handful of vendors with both BSS and OSS in their portfolio – and even fewer with the ability to deliver a coherent, unified approach to the overall BSS-OSS architecture.

2. Complete OSS transformation

This is a total replacement of all back office operational systems for planning, fulfilment and assurance. Like all full-scale projects, a complete OSS transformation requires a scalable, robust and complete software product set. Greater integration capability is needed for possible interoperation with a variety of existing BSS systems. Adherence to standards, in particular SOA and MTOSI, provides a route to integration. But just as important is proven delivered integration and a productized approach to building integration via ‘adapters’ that can be managed as part of the suite for lower TCO.

3. Service transformation

The third option is to introduce an OSS for a new service across all OSS functions – in effect, a vertical integrated stack of process-driven products to, for example, automate DSL fulfillment.

Done properly, the introduction of a new service can be used as a mechanism to introduce a new OSS architecture that can later be used as the target architecture for complete OSS transformation – expanding scope as new services are added, thus enabling the operator to meet tactical and strategic objectives simultaneously in an evolutionary way. This approach is preferred by newer operators who have less of an issue with legacy systems.

The danger here is that OSS software that is highly targeted to delivering a service, such as DSL, is not suitable for delivering additional services. Moreover, a package highly configured for a single service is also often constrained to deliver one process only, such as fulfillment, and is not suitable for use as the basis for all operational processes. This software then becomes a vehicle for the proliferation of further OSS fragmentation rather than a consolidating force.

4. Process consolidation

Introducing software to consolidate processes across OSS systems can preserve and stabilize an architecture in preparation for more extensive change. Executed properly, this process consolidation layer can be used as a mechanism for introducing a new OSS architecture, which can later be used as the target architecture for a complete OSS transformation – expanding scope gradually so an operator can meet tactical and strategic objectives simultaneously in an evolutionary way.

This approach is preferred by larger incumbent operators. By virtue of the size and complexity of their legacy systems estate, they need a tactical solution that enables access and re-use of existing data and functionality, while preparing for migration to a next-generation OSS. In many cases, this approach will take place alongside a full-scale BSS-OSS transformation, giving an operator the ability to meet requirements for new services from existing infrastructure, and supplying ‘breathing space’ while the next-generation infrastructure is developed offline.

5. Inventory consolidation

With this alternative, a series of disintegrated, sub-scale or just old-fashioned inventories can be replaced by an integrated, modern, extendable inventory, creating a single point of reference for all network- and service-related data.

Inventory consolidation allows an operator to really understand what they have in place. Fragmentation often prevents having a clear picture of the transformation required – what resources are in use and how services relate to them. Gaining visibility is an important first step. In the short term, operators achieve tactical improvements through inventory consolidation, enabling them to significantly reduce operating costs and increase operational efficiency.

Regardless of the approach taken, there are substantial ongoing benefits from OSS transformation which reduce the overall Total Cost of Ownership (TCO) for the service provider overall.