Healing the OSS Wounds in the MSO

Given the current structure of most OSS, often repeated tasks — such as work order decomposition and management, service monitoring and inventory management — are hard to complete efficiently. It is little wonder that existing OSS can barely support the deployment of new services (such as flexible high-speed data, advanced VoD systems and Ethernet over DOCSIS,) which require “one-stop” visibility into the network. Nor does the OSS support innovations aimed at business customers (such as VoIP, QoS and CoS-based services) that require advanced functionality.

Transformed OSS promises significant, measurable and sustainable business benefits to the industry, such as:

• Better troubleshooting capabilities
• Proactive communication with customers
• Better, more productive workforce scheduling
• Renewed control of the business (even those parts that have been outsourced)
• Freedom to focus energies on new markets, products, services and growth

OSS Transformation: Heal the Wound

The transformation of OSS begins with a better understanding of the current environment. In designing an ideal structure for OSS, the MSO should determine the size and shape of the OSS that would best fit the company’s business objectives, and then use eTOM and SOA to actualize that vision.

While the MSO may have attempted some standardization over the years, many elements of the OSS are deployed by product category (voice, video and data) and/or by market. At the network level, many functions also are duplicated by device or service type. For example, separate provisioning systems for broadcast video and VoD (for the service itself and the service instance) are common.

The result of this hodge-podge deployment of OSS is a very complex systems structure that requires multiple interfaces, both automated and manual, to operate. Parallel processes are needed to handle fallout resulting from shortcomings in the provisioning and assurance processes — an expensive band-aid. And there are other costs from poor OSS integration and structure that necessitate additional training, as well as resulting in a high-error on-the-job rate, poor morale and increased workforce churn. The impact on customer satisfaction should not be underestimated either. Wouldn’t capital be better used on fixing the OSS structure than building parallel processes that suggest breakdowns are inevitable? Essentially, isn’t it better to get it right the first time than apply hundreds of band-aids to a broken structure?

A transformed OSS should be based on a standards-based, modular SOA, which allows for important abstractions of common data elements from the billing system, of the business rules for data mapping from hard-coded interfaces and of the business process management layers.

The scalability of the SOA architecture not only corrects the defects of the current model by supporting new and enhanced functionality, it also enables MSOs to offer communication services to commercial customers. Being flexible is important when demand is hard to predict and when competitors can change the game overnight.