Finding the metrics to invert the OSS iceberg

Invert the iceberg – show just how much capability is hidden under the surface by mapping how dependant the organisation’s positive outcomes are on its OSS (OSS as the puppet-master). All the sexy stuff (eg 5G, IoT, network virtualisation, etc) can only be monetised if our OSS pull all the strings to make them happen.”
Yesterday’s post.

Have you noticed that network teams and network vendors tend to be far better at eliciting excitement from executive sponsors than those in charge of OSS? There is always far more interest in 5G, IoT, network virtualisation, etc than in the systems that support them. Do you think this is from the differences in messaging used? For example, networks are always about being a platform for new services, extra speeds, new revenues, increased functionality, etc. Networks are undoubtedly complex machines, but the metrics above are easily understood by execs, customers and almost anyone else who is involved in producing or consuming comms services.

BSS also have their metrics that are easily understood by those who don’t comprehend the underlying complexity of BSS. Metrics such as ARPU (Average Revenue Per User), Total Revenue Billed, Cost per Bill, etc.

But in OSS, what are our standard metrics? Are any of them stapled to the lifeblood of any business (ie money)? We talk about number of services activated, number of faults resolved*, mean-time-to-repair, etc. These are all back-end metrics that don’t elicit much interest from anyone who isn’t in ops… unless something goes wrong like activation rates dipping, fault resolution times spiking.

What if we were to flip metrics like the following to better uncover the hidden part of the iceberg:

  • services activated -> value of services activated (based on revenues generated)
  • number of faults resolved -> customer satisfaction impact
  • mean-time-to-repair -> amount of revenue assured (ie prevention of loss, particularly against any SLAs existing on the service/s)

For event management and activation processes, it probably won’t take much to identify metrics with greater perceived value. For other systems like performance, trouble ticketing, work-force management, even inventory, we’ll have to be a bit more creative.

* Has there ever been a more “shoot the messenger” metric in service providers? Problems arise in the network, but the OSS cops the flack because they’re the reporters of the problems.

Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

Leave a Reply

Your email address will not be published. Required fields are marked *