NFV has the potential to amplify the OSS pyramid of pain

In two recent posts, we’ve discussed the changing world order of OSS with NFV as a catalyst, and highlighted the challenges posed by maintaining legacy product offerings (the pyramid of OSS pain).

These two paradigms (and others such as the touchpoint explosion) are dragging traditional service providers closer to a significant crossroad.

Network virtualisation will lead to a new array of products to be developed, providing increased potential for creativity by product and marketing departments. Unless carefully navigated, this could prove to have a major widening effect on The OSS pyramid of pain. NFV will make it easier for administrators to drop new (virtual) devices into the network at will. More devices mean more interoperability ramifications.

If network virtualisation can’t be operationalised by a service provider, then it’s likely that the finger of blame will be pointed at the OSS‘s inability to cope with change, even though the real culprit is likely to exist further upstream, at product / feature level.

I’ve heard the argument that traditional service providers are bound in chains by their legacy product offerings when compared with the OTT players like Google, Facebook, etc. To an extent this is true, but I’d also argue that the OTT players have been more ruthless in getting rid of their non-performers (think Google Buzz and Reader and many more, Facebook’s SuperPoke and Paper, etc), not to mention building architectures to scale up or tear down as required.

The main point of difference between the service provider products remaining in service and the discontinued OTT products is revenue. For service providers, their products are directly revenue-generating whereas the OTT players tend to harvest their revenues from other means (eg advertising on their flagship products). But this is only part of the story.

For traditional service providers, product revenue invariably takes precedence over product lifecyle profitability. The latter would take into account the complexity costs that flow down through the other layers of the pyramid of pain, but this is too hard to measure. I would hazard a guess that many surviving service provider products are actually profitability cannibalisers (as per the whale curve) when the total product lifecycle is tallied up.

The cross-roads mentioned above provide two options:

  1. Continue on the current path where incremental projects are prioritised based on near-immediate payback on investment
  2. Undertake ruthless simplification at all levels of the pyramid of pain, a pruning effect from which new (profitability) growth can appear in a virtualised networking world

But clearly I’m not a CFO, or even an accountant. Do you think you can describe to me why they’ll chose option 1 every time?

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

2 thoughts on “NFV has the potential to amplify the OSS pyramid of pain

  1. I’m currently doing a project in India where ruthless simplification is the only viable solution for my customer. Reducing the number of products in their catalog, pruning the service types based on top orders generated (mainly new connects), and leaving out legacy service types which are not having any new orders, plan on migrate legacy service types and customers to new technologies, and focus on process study (by traversing tge pyramid of pain) for the most relevant services to automate or simplify it to produce new business Kpi which can take out costs and recognise revenues earlier than current

  2. Hi Steelysan

    Great story!

    Are you able to share a little more about this success story?

    Eg
    Who prepared the case for ruthless simplification (service provider internally, vendor / integrator, external consultant)?

    What aspects made it most compelling to the customer? Alternatively, do you know what blockers needed to be overcome and how?

    Are you working to any simplicity KPIs or flow-down KPIs like O2A times, NPS scores, etc?

Leave a Reply

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