“There are two questions to ask during the capex planning process that get to the heart of the issue. First, should a particular investment be made at all? The majority of operators have a long tail of marginally profitable—or downright unprofitable—products, networks, customers, channels and segments. A request for additional investment in such assets is an obvious point at which to consider terminating, migrating or consolidating them. Yet telecoms operators are notoriously slow to prune their product portfolios and rarely use investment cases as an opportunity to review the basic assumptions underpinning the different parts of their business.
The most common reason for skipping this step is simply lack of good information; without reliable facts, capex proposals and challenges become politicised, arbitrary and inefficient. In our experience, the antidote to such flawed decision making is the creation of a robust fact base regarding the (post-capital) economic profitability of products, network, customers, channels and segments. That delivers two advantages: not only is capital diverted away from low-growth, marginally profitable activities, but the business case for network and system convergence is also strengthened.”
Report entitled, “We need to talk about CAPEX – Benchmarking best practice in telecom capital allocation.”
The initial question above can be equally asked of both ends of the OSS market – to the operators and the vendors. Do you have a long tail of marginally profitable—or downright unprofitable—products, networks, customers, channels and segments? Or more importantly, do you have a way of measuring your long tail?
I’ve seen OSS vendors investing money and effort into products that might seem appealing and are delivered to customers as part of a product bundle, but are never used by customers.
For carriers, the question has to be posed long before ever reaching the OSS. If the products, networks, customers channels and segments are unprofitable and were culled by other business units, then OSS teams would never need to build, manage and maintain the operational systems required to support them.
Ruthless simplification within an OSS division should be occurring before the OSS team is even involved. But if not, then it’s the responsibility of the OSS team to use the information at its disposal (in OSS and BSS/billing tools) to quantify what’s working and what’s not.
The bigger implication though… the savings from culling these unprofitable elements will be needed for funding the “big bets” on nascent technologies such as network virtualisation (if it proves itself to deliver valuable outcomes of course)