Using a complete re-framing to reduce the OSS Buyer / Seller chasm (part 3)

This is the third part of a series that looks into the chasm that exists between OSS/BSS buyers (eg carriers, ISPs, utilities, etc) and sellers (OSS/BSS product vendors). In part 2 we pondered whether it’s possible to target a 10x reduction in operational costs.

We’ll take a closer look into what this means with the help of a sensational piece of investigative work and data visualisation from the team at Omdia, as shown below. You can find a more detailed description of their work on the, “Introduction to Omdia’s Global Telecoms Opex Tracker,” page.

As you can see, only the items highlighted in yellow are really feasible for OPEX / cost reduction through more efficient operations. Of course there are still other opportunities (eg better spectrum utilisation and other network asset utilisation could bring down network infrastructure costs, etc) but we’ll simply focus on the highlighted components.

With an Omdia subscription, you can access a detailed cost and percentage breakdown of the global spend numbers.

Since most of you won’t have access to information behind the paywall, I’ve prepared the following table using a rough visual estimation from the Sankey diagram above (starting with an assumption of a 50/5o split of network and non-network OPEX).

Column A shows the components of the Sankey, whilst column B has my very rough estimate of percentage breakdowns (and shows colour-coding to match the diagram above):

Then columns C and D is where we get to the crux of things.

Column C shows a hypothetical $100M OPEX budget for a hypothetical carrier that just happens to approximately mirror the Omdia OPEX flows. [Just an aside here, but I wonder whether the outsourcing / in-house split of 10% / 5% could be 5% / 10% depending on different carrier approaches?]

The red boxes within column D show where an OSS/BSS-driven 10x OPEX reduction could make a difference (matching the yellow circles in the Sankey diagram). If a 10x reduction could be achieved on these factors, total OPEX comes down to around $70m instead of $100m. Is that enough to make a hypothetical telco profitable? Is it enough to save the industry? It’s a pretty good starting point.

However, it’s a bit of a crazy exercise. As you can clearly see from the red boxes in column D, it’s barely fathomable to achieve a 10x reduction across any of these factors is it? Despite still spending $70M on OPEX, there’s only enough labour cost to support a skeleton crew.

The point of this exercise is to show that we can’t deliver profitability for the telco industry with incremental thinking. Operations teams have already been incrementally stripped back for years and you could argue that there’s nothing left to strip back. Yet the industry is still only just holding on.

This situation actually requires an entirely different approach to building OSS/BSS tools and operations models than we’ve done before.

We can’t be thinking of building features at the blue far right end of the long-tail diagram below. We have to be thinking of vastly improving within the red-shaded left end of the long-tail diagram. Or even more importantly, to be thinking of totally lateral new ideas in the green arrow to really move the needle. [see this article for a description about the long-tail if clarification is needed]


We’ve incrementally built our products in line with the long-tail diagram. The features that move the needle (in the red shaded box) were built decades ago, so we then just kept on extending the blue arrow. And most OSS/BSS RFP processes just reinforce adding lots of relatively meaningless features (ie the vendor with the most features and the lowest cost wins the deal). This doesn’t incentivise the appropriate part of the chart.

The approaches we use to bring buyers and sellers together to form valuable partnerships needs to focus on making the red-shaded functionality better and more efficient. But we also need to look to the green box for new ways to do things exponentially better.

One place to start is by looking at the buyer / seller chasm through the lens of the 13 friction continuum graph we’ve presented in an earlier article. The buyer / seller chasm exists because we’re arguably closer to the left side of these continuums rather than the right end in most cases.

As Jeff Bezos famously said, “Your margin is my opportunity.”

We can extend on this to read, “Your OPEX is our opportunity.”

Furthermore, to decrease the size of the chasm, we also need to find better ways than proxies like the Gartner Quadrant to help with the match-making process of bringing buyers and sellers together.

We’ll take a deeper dive into some ideas in the next article, but I’d love to get your inputs to flesh these ideas out further of course!

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions


Most Recent Articles

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.