OSS ROIC (part 4) – The technology dilemma

In our company there’s still a bit of the ‘build and customers will come’ mentality, but those days are gone. If we build the wrong thing in the wrong place or at the wrong price, the customers won’t follow. So, rather than letting technology drive our capex decisions, we need to adopt a more commercial approach.”
An un-named executive
in this report.

Are you surprised by the left-most column in the graph above? I was…. but I wasn’t.

The simple fact from the graph and the earlier blogs this week (part 1, part 2, part 3) show that the big telcos (in general) aren’t aligning capex planning with business objectives as much as they are driven by shiny new tech. This is clearly the wrong investment criteria (although as an Engineer it pains me to say that :D)

This has been great for the OSS industry as a whole, gaining access to customer capex with minimal accountability for business objectives or return on invested capital (ROIC). I can understand the lack of accountability, because OSS is generally seen as providing intangible value.

But I believe the comment by the unnamed executive above gives a hint to what’s around the corner for OSS. The diminishing margins being generated across the maturing Telco industry means capex accountability will become increasingly scrutinised by the sponsors that sign off Telco technology projects. I expect that this will come into stark view when the massive transformational projects like network virtualisation put their hands out for big piles of cash.

To quote the same report above, “Most of the telecoms operators in our survey distinguish between ‘business-as-usual’ capex (sometimes called ‘baseline’ or ‘production’ capex) and ‘project’ capex (also known as ‘innovation’ or ‘growth’ capex). But though project capex typically represents just 20-30% of an operator’s total capex, it receives 80-90% of the capex committee’s attention. Business-as-usual capex, by contrast, is treated in a far less sophisticated way. The networks generally submit requests for RAN consolidation, core upgrades, additional carriers or whatever else they need to support an increase in traffic. But … these capex proposals are effectively ‘technical costing’ papers based on the assumption that the additional traffic will be profitable…But it rarely asks—let alone gets answers to—the obvious questions about baseline capex. Is the extra traffic part of a profitable service? Is it being generated by profitable customers? Will it produce a positive ROI?

This seems to pose an interesting dilemma for technology vendors (including OSS vendors):

  • Do I continue to develop sexy tech and hope the telcos keep finding a way to invest with loose financial justifications in place; or
  • Do I find a way to lead the industry with paradigms built on cost justification (such as the examples shown in blog part 3)

The first dot-point represents the status quo and the easier solution. However, the second option could potentially represent a competitive advantage (assuming the executive commentary in the report quoted above is accurate) at least until the rest of the industry figures out a way to catch up.

I’d love to hear your thoughts on whether this capex nexus can be broken.

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

Share:

Most Recent Articles

No telco wants to buy an OSS/BSS

When you’re a senior exec in a telco and you’ve been made responsible for allocating resources, it’s unlikely that you ever think, “gee, we really

2 Responses

  1. Very good and thought provoking article, being eitgercthe vendor or the customer, we each need to rethink our priorities at times. Thanks.

  2. Hi Laurence,

    True!

    Whether we like it or not, I suspect we’re going to be increasingly encouraged to do it by executive sponsors (and shareholders), so we should be getting ready for it ahead of those rising pressures.

    Rgds
    Ryan

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.