Large carriers (let’s call them T1’s) tend to approach OSS procurement projects very differently from small to medium sized carriers (let’s call them T2’s). This is mostly driven by budget, or more to the point, how the budget frames the thinking. We’ll also show you how drawing on ideas from the T2 approach can actually make T1 OSS projects more cost-effective, timely and less risky.
A T1 budget is generally large enough to start with the mindset of “it’s software, we can make it do exactly what we want.”
A T2 budget is generally much smaller, which leads to a distinctly different mindset that’s something like, “we need to find something that’s available and find workarounds if it can’t do everything.”
These are vastly different starting points and the corresponding procurement journeys are also vastly different as a result. The following table helps to tell the story:
Do you notice how the big budget and unconstrained thinking that appear in the upper rows can actually lead to more reds (undesirable traits) subsequently appearing in the T1 column? Sometimes an OSS budget is too big because it can foster profligacy and hinder constraint-based creative thinking. These same factors have also helped to drive traditional OSS procurement approaches for decades – from a time past when telcos had the profitabilities (and monopolies) that allowed gold-plated solutions to be built to cater for every whim.
Times have changed and are changing further, which led the TM Forum to propose a desire to “Kill the RFP” because the approach is no longer working for carrier or supplier groups. It doesn’t work for T1’s and certainly doesn’t work for any T2’s that attempt to follow the ways of the big operators. We’ve deeply contemplated a better way too in our previous “Kill the RFP” series of articles.
The table above is obviously generic in nature, so it doesn’t perfectly capture the traits of OSS procurement events for all T1 or T2. However, it clearly highlights (to me at least) that T1’s should be taking elements from the way T2’s select and commission OSS. That’s why we’ve developed a procurement approach that seeks to provide the best of both worlds. If you’d like to hear about how we approach it, leave us a note and we’ll send, then walk you through our procurement-led transformation framework.
The other knock-on effect of having a simpler OSS/BSS stack is not just during the procurement process, but also a reduction in complexity in ongoing operations, as we describe in “the pyramid of OSS pain.” Less complexity in the OSS, less complexity in down-stream operations like contact centres, NOCs, etc.
.
Over the years, I’ve often referred to The Corkscrew Analogy or Momentum Spiral to describe a mindset of incremental improvement that’s needed to keep an
We’ve embarked on a journey of trying to plan for the future of OSS/BSS, not by predicting the future, but by seeking ways to be
As discussed in the previous article, “Future Scenario Planning: Have you given up on doing an OSS transformation? (part 1)” part of the fun of
Earlier in the week, a friend mentioned he was reading “Alchemy” by Rory Sutherland. It’s not an OSS book per se, but does provide some
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
2 Responses
Absolutely a great perspective and a great summary! Not sure if we can add and so where, the SDN/NFVs (VNFs) and the whole Virtualization and Distributed/Segmentation technology part of it, which has become the ubiquitous in the Technology world. In reference to the last 2 sentences…i.e., “That’s why we’ve developed a procurement approach that seeks to provide the best of both worlds. If you’d like to hear about how we approach it, leave us a note and we’ll send, then walk you through our procurement-led transformation framework.” Yes, I am interested, please do send me that and i will be very appreciative of that, and then yes, we can talk further after that.
Hi Ravi,
Thanks very much for your kind words.
That’s a great point about differences in “software-isation” of the network. Virtualisation certainly increases the modularity, segmentation, flexibility of centralised / decentralised architectures and has many other ramifications. It certainly touches on multiple different rows in the current framework (eg modularity, integration tax, flexibility, complexity, procurement process, TCO, etc), albeit not explicitly.
I’m even considering whether there’s a new row that suggests the types of network under management, but am slightly vexed. I’m tending towards the T1 column being more sophisticated in their adoption of network virtualisation, but then there are certainly a lot of outliers to this statement on both the T1 and T2 side of the divide.
I’d love to get your thoughts (and the thoughts of other readers) about how best articulate this… or whether there’s even a separate table that looks at the differences in relation to virtualised vs traditional network types?
I’ll send details of the transformation framework via DM Ravi. Thanks for you note!