The diagram below is a crass over-simplification of where the source of OSS pain (ie complexity) tends to originate from.
If an organisation has complexity in the upper-most layer (ie products), then this is bound to flow downstream, amplifying along the way and culminating in increased complexity at support systems like OSS/BSS.
If there are many products, with many different variants of features, bundles, offers, incentives, credits, etc, then all of these need to be supported by front of house people (eg sales), who then need systems to record their processes and details in. The greater the number of processes and systems required to support them, the greater the likelihood of fall-outs, not to mention integration effort and data grooming.
I can understand that the products / marketing department (or equivalent) needs to justify their existence by creating the momentum of newness in the marketplace. That’s what drives the revenues that indirectly fund the OSS projects that we have the opportunity to work on.
However, I suspect there is little thought into whether creating a new product that is seen as being successful (eg generating an extra $1 of ARPU compared to other existing products), actually considers the downstream costs to the organisation.
Also, to follow on from yesterday’s blog about what to focus on when selecting a new OSS, I always try to build simplification efforts into the migration planning (eg subtraction projects). Start from the top and seek simplification at every level downstream, shrinking the shoulders of the pyramid of pain.
One final thought. There are many entry points into the pyramid of pain where you could start the pain reduction process:
Have you ever had an OSS or BSS project that’s impacted by poor data quality? The problem of data integrity gets raised on almost every
“One of my favorite things about designing software is designing the defaults. The defaults define the experience for everyone out of the box. And, therefore,
Have you ever been tasked with mapping out the processes for the telco you work for? Either as a way of documenting current state, or
In the last week alone, I’ve had two potent reminders that the world of OSS is simply (pun intended) too complex. This manifests in many
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.
