What my Chiropractor Taught me about the Future of Telco
I recently went to my chiropractor with wrist pain. I assumed it was from years of playing tennis and typing on keyboards. That seemed fairly
Telco orders are a lot like falling in love. But, just like a Hollywood rom-com, there are always hilarious twists, awkward misunderstandings, hot exes and unexpected baggage along the way. Will this partnership end happily ever after – or in therapy and divorce?
Our story begins with two hopeful romantics: the customer and the operator (I’m sure you’ve met them).
The customer’s found someone who seems to understand them. The operator’s made all the right promises. The chemistry’s on fire. The contract’s signed.
What could possibly go wrong?
.
Every great romance begins with a promise.
In telecom, that promise lands in Customer Order Management, or COM. COM captures what the customer’s actually bought – the product, options, locations, dates and expectations that define the new relationship.
At this point, everything still looks wonderful.
The customer wants the service. The operator wants to provide it. COM enthusiastically says: “We can make this work.”
There’s just one small problem.
Nobody’s met the OSS family yet.
.
Enter Service Order Management – SOM.
If COM captures the romantic promise, SOM’s got to work out what that promise actually means operationally. It translates the order into the services that need to be delivered and starts coordinating the different activities required to make them happen.
This is also where orchestration enters the story.
Orchestration’s effectively our rom-com organiser – working out who needs to do what, in which sequence, while keeping track of dependencies and trying desperately to stop everyone talking over each other (which reminds me of the first date principle).
Suddenly our simple love story got a whole lot messier – there are now dependencies, sequencing, multiple systems and commitments nobody remembers making.
Still, SOM’s optimistic.
“Relationships take work.” (don’t they ever!!)
.
Then ROM turns up.
Resource Order Management deals with the network and technology resources needed to make the promised service real.
COM knows what the customer wants. SOM knows what services need to be delivered. ROM asks the questions everyone’s been avoiding.
Is the capacity available? Is the equipment there? Can the network support it? What actually needs configuring?
This is also where provisioning comes in – the actual activation and configuration needed to turn architectural intent into a working service on the network (ie the devices and connectivity that makes up the network).
ROM isn’t trying to ruin the romance. ROM just believes compatibility should’ve probably been checked before anyone started discussing a long-term commitment.
.
This is the twist in every rom-com. Just as everything seems to be coming together, the door opens and Jennifer Aniston walks in and jaws drop (or at least mine does).
She’s the legacy OSS.
She’s familiar. She knows the business. She knows shortcuts nobody else understands. She still holds some absolutely critical information and, annoyingly, everyone knows her number. Everyone has some sort of soft-spot for her.
However, she’s also carrying 15 years of unresolved baggage… but is so attractive that people can sometimes overlook the drawbacks.
The new architecture knows getting involved again is probably a mistake. But somehow, at 2 a.m., somebody’s still calling that old provisioning platform because “it’s the only thing that knows how this orchestration plan works”.
Legacy systems are rarely useless, which is precisely why they’re so hard to leave. The danger comes when every new fulfilment journey gets forced back through yesterday’s processes, integrations and operational assumptions.
.
Eventually, someone’s got to save the relationship.
An order gets stuck. A dependency fails. One system insists everything’s fine while another has absolutely no idea what anyone’s talking about (that’s me).
Enter manual intervention – the couples therapist of telecom fulfilment.
Operations teams reconcile data, restart workflows, chase dependencies and translate between systems until the order starts moving again.
Therapy can save a relationship. But if every date requires an emergency counselling session, there’s probably a deeper problem. She’s just not that in to you.
The same applies to order management.
The goal isn’t simply to automate more. It’s to give COM, SOM and ROM clear responsibilities, orchestrate effectively between them, expose problems early and make exceptions genuinely exceptional.
Because ultimately:
COM, SOM and ROM aren’t the love story. The customer and the operator are.
Order fulfilment’s merely the rom-com plot that determines whether their first exciting promise turns into a long and happy relationship – or whether, ten days later, somebody’s wondering why their service never called and the other churns, looking for new romance.
If you want to find a new partner, don’t forget to swipe left/right over on our OSS/BSS vendor directory.
At PAOSS, we are the OSS matchmakers, so we’d be delighted to set you up with the best-fit one for your unique personality (using our very sexy inverted pyramid approach to avoid the three forevers of OSS dating).
I recently went to my chiropractor with wrist pain. I assumed it was from years of playing tennis and typing on keyboards. That seemed fairly
One of my favourite OSS books, that isn’t an OSS book at all, is Insanely Simple: The Obsession That Drives Apple’s Success by Ken Segall Ken
We invest heavily in production environments (aka Arnie) and in reactive network fault-fix measures. Most OSS teams think of non-prod (aka Danny) as somewhere to
Telecom architects often jump to the conclusion that more capability means better performance. Add another feature, another platform, another integration, another automation layer and the