A rarely-used twist on cost-out OSS business cases

How many OSS business cases have you seen that are built around cost reduction? Most of them???

Now let me ask the same question, but with one extra word included and see whether it completely inverts your answer. How many OSS business cases have you seen that are built on capital cost reduction? None of them?? Almost every “cost-out” business case is built on operational cost reduction (eg head-count reduction) – OPEX, not CAPEX – right?

I’ve seen two particularly remarkable examples of OSS projects delivering unexpectedly rapid financial returns, neither for the reasons that would normally appear in an OSS business case. One involved discovering equipment that was already purchased and installed. The other involved discovering services that nobody realised weren’t being billed. More on those shortly. Needless to say, both related to “data fix” problems.

So, you may ask, what does a CAPEX-reduction business case get built around? The benefits tend to be a little more obscure, but let’s see if they might work for you:

1. The first is probably also the most obvious – speed and cost of deployment. Not of the OSS itself, but all of the projects and micro-projects that the OSS helps to manage. If your OSS can systematically reduce deployment time and/or cost, then you get significant cost out
2. Asset utilisation – if you can find better ways to spread the load across your assets, then there’s less to spend on asset augmentation
3. Asset identification – You might be surprised at how many assets go missing and not necessarily through pilfering.I advised on an OSS project where the payback period on an entire OSS implementation (worth multiple millions of dollars), was only a couple of months. Not years. Months!The operator had been preparing to purchase several very expensive pieces of network equipment to augment capacity. A perfectly reasonable decision if the network needs expanding. But our OSS project uncovered something rather extraordinary.The operator already owned some of the very equipment it was about to purchase. These devices weren’t sitting forgotten in a warehouse somewhere. They had already been purchased, tested, physically installed and connected into the network. The operator was even paying ongoing maintenance charges on them.

   There was just one small problem. No services had ever been activated through them! Nobody seemed to realise they existed anymore. They’d become stranded assets.

   In other words, the operator was about to spend substantial amounts of capital buying additional capacity when it already had expensive equipment sitting unused in its network.

   Once discovered, the previously stranded equipment provided an unexpected financial windfall. The avoided expenditure was sufficiently large that the payback period on the entire OSS project was only a couple of months.

   The business case behind our project no longer needed to rely on reduced headcount or operational efficiency improvements of automations, though it delivered those too.

   And here’s the challenge for those preparing OSS business cases. How do you forecast the financial value of assets that you don’t even know are missing?

   You probably can’t quantify it reliably in advance. But you can deliberately go looking for it and/or include discovery, reconciliation and asset-utilisation analysis in your project scope to uncover these opportunities.

   FWIW, I’ve discussed the wider implications in Stranded Assets and OSS ROIC (part 6) – Oops. I forgot one… Sort of.

4. Cost justification of assets – to use historical and projected information to optimise new build (ie equipment purchase, deployment time, etc)
5. Life-cycle optimisation – better management of spares and equipment / network lifespans
6. Leakage identification – another slightly different twist on #2, whereby leakage reduction allows delays in CAPEX allocation. And there’s another interesting financial twist worth mentioning.In a separate, multi-million-dollar OSS implementation, an inventory audit and reconciliation against billing records uncovered thousands of services that had been provisioned in the network but weren’t being billed.Some had apparently been provisioned outside the normal billing mechanisms, including fraudulent cash-in-hand arrangements to the benefit of some of the operator’s staff.The result of fixing this problem? A payback period of just 2–3 months on a project costing several million US dollars!

   The customer was understandably ecstatic, although apparently very concerned by just how quickly the project had paid for itself. You can read the full story in An alternative profit.

   That’s not CAPEX reduction, of course. It’s revenue leakage identification. But it highlights the broader point that OSS and BSS investments can unlock financial benefits nobody thought to include in their original business cases.

   For more on how these discrepancies arise, see Reconciling services.

Now, in the unlikely event that this has opened up a new line of thinking for you, what other examples of CAPEX-out measures can you think of in your OSS / network?