Standard Operating Procedures (SOP) have been pivotal in codifying and standardising the use cases of service providers for many years. The theory goes that if you can standardise a process, then you can produce repeatably high quality and streamline it in a cycle of continual improvement.
The repeatability objective is one* of two primary recollections from a book that I read many years ago called The E-Myth Revisited by Michael Gerber. It’s one of the best selling business books of all time and had a significant impact on inherent repeatability within a business. It is an objective that is still highly relevant to the OSS industry, in part represented by the “automate everything” mantra that pervades today.
There’s only one slight problem with the concept of a SOP – I tend to find that there is no standard operating procedure. Our inability to control complexity, in OSS and other parts of the service provider business model, has created a multitude of variants for any given product line. The greater the number of variants there are in a process flow, the harder it is to maintain a standard. You’ve all seen the processes I talk about haven’t you – the ones with complex conditional paths, off-page references to side flows, many hand-overs and hand-backs between swim-lanes, incomplete mappings, etc.
With the changing digital supply chain predicted by John Reilly in his work on The Value Fabric, the number of swimming lanes as well as the more transient nature of process state change represented by network virtualisation and the touchpoint explosion, it’s obvious that associated process complexity is only going to amplify.
This becomes extremely challenging for the traditional OSS / BSS, where standardised workflows are the building blocks upon which automations are constructed.
More on the alternatives tomorrow.
* BTW, the other recollection from The E-Myth is the mindset difference between the predominant Technicians (creating a job for oneself) vs Entrepreneurs (creating a self-sustaining business).
Making your OSS easy to use isn’t about adding more “easyness” – it’s about subtracting what sucks. “To make your stuff “easier to use” you
During my first forays into OSS, over a period of 6+ years, I averaged 85 hours a week whilst being paid for a 40 hour
The call came in at 5:43am. “The routers are acting up again down at 1313 Packetloss Lane” the night supervisor whispered, as if afraid the
Telco appears to be an increasingly tough industry. Demand for connectivity continues to soar, yet profitability and differentiation are becoming ever more difficult to achieve.
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.
