Vendor consolidation won’t fix your BSS problem

• Share via Facebook
• Share via Linkedin
• Share via Twitter
• Copy URL

Everybody thinks vendor consolidation is the default answer to solving BSS complexity. Last month, I was on a call with a telco CIO who’d just inherited 20 entities across multiple countries: mobile, fiber, towers, data centers. All acquired. All running different systems from a mishmash of vendors.

His plan? Exactly what you’d expect. Run an RFP. Select a full-stack BSS vendor. Consolidate as much as possible. A multi-year transformation to harmonize and modernize.

To explain why, he pulled up a slide listing his four biggest BSS challenges (figure 1):

Then he walked me through the reality behind it:

“I have one BSS in this country, an in-house BSS in another, something out of support in a third. My charger is Nokia here, Ericsson there, Huawei in two other places.”

I get why consolidation feels like the answer. Fewer vendors means fewer integrations. Fewer integrations means less chaos. One data model. One way of doing things.

It sounds like a good solution. It isn’t.

So I asked him one question:

After consolidation, will those four problems actually go away? Or will you still have the same problems—just with fewer vendors?

He paused. Then asked if it was okay to smoke a cigarette.

Here’s the truth: he didn’t have a vendor problem. He had a language problem. And you can’t fix a language problem with customizations and integrations.

Your systems don’t speak the same language

The root problem isn’t the number of vendors. It’s embedded data and interpretation of the meaning of that data – AKA, the semantics.

Here’s what I mean. “Subscriber” means one thing in billing (an account), another in CRM (a person), another in network inventory (a device). “Activation” triggers different processes depending on which system initiates it. Your product catalog defines products differently than your order management platform.

This inconsistency isn’t accidental. It’s structural. Even within a single vendor’s suite, modules define the same concepts differently. Billing and CRM don’t automatically agree on what a “customer” is. Translation is still required.

And consolidation never fixes the full picture. You will always have systems outside your BSS: network, ERP, partner platforms, finance, whatever. Those systems aren’t going away. After your multi-year transformation, they still won’t speak the same language as your shiny, new consolidated BSS.

So the chaos doesn’t disappear. It just gets slightly smaller.

This is where most BSS change programs spend most of their time and money: translating meaning, mapping fields, writing code that says, “This thing over here means the same thing as that thing over there.” It’s testing, breaking, fixing, repeating, project after project.

You can keep paying consultants to translate over and over again. Or, you can fix the language problem once and forever.

The universal translator you need

Fixing a language problem requires a translation layer. This is not middleware that claims to simplify things while quietly adding more complexity, but a layer that speaks business language on one side and system language on the other.

This is what the Totogi telco ontology inside BSS Magic is built to do.

It extends TM Forum’s Information Framework (SID) into a true universal translator—encoding what a “subscriber” actually is, how a “bundle” relates to a “service,” which rating rules apply where, and how those concepts relate across systems. More than a data structure, it builds the semantic mapping you need to extract the insights you’re looking for.

And the best part? It works with what you already have. Amdocs? Fine. Netcracker? No problem. That sketchy in-house system your predecessor built in 2003? Still works. It doesn’t replace your BSS. It works with it. And it doesn’t stop at BSS. It spans OSS, network, and anything else you want to connect. 

It becomes the translator for your entire business.

What changes

For the CIO with 20 entities using a translation layer like the one in BSS Magic, the ontology maps relationships across every platform, every OpCo, every vendor: Nokia, Ericsson, and ancient homegrown systems nobody wants to touch. The complexity doesn’t disappear, but it’s abstracted away. You talk to your systems without having to know the implementation details or data structures. 

By capturing business logic in the ontology instead of encoding in customizations and integrations, you open your telco up to a whole new world of possibilities.

• Natural language becomes executable. “Identify subscribers with churn risk above 70%, filter by premium tier, match with retention offers within margin guidelines.” That’s not a requirements document that takes six months to code up. It’s a query executives can execute themselves. You’re not speeding up the old development cycle. You’re eliminating it.

• You get value now without swapping systems—and swapping later becomes trivial. The ontology sits on top of your existing stack. You’re not betting on a risky rip-and-replace. But here’s the kicker: when you DO decide to retire that ancient billing system, the ontology already knows what “subscriber” and “rate plan” mean. The new system just plugs in. Migration goes from an 18-month nightmare to a configuration exercise.

• Every capability compounds. Each application you bring into the ontology enriches it. The retention engine adds churn logic. The fraud system adds risk patterns. The partner portal adds channel definitions. Your semantic layer gets extended with every use case. Competitors can’t replicate these compounding effects. 

The ontology becomes your AI moat.

Your AI moat

Every telco is looking for ways to leverage AI. But AI can’t scale across your telco when “subscriber” has 17 different meanings across your systems. When context is semantically inconsistent, AI doesn’t fail quietly. It hallucinates. That’s not because the models are bad, but because the business context is broken.

OpenAI and Anthropic will keep making models smarter. Those gains flow to everyone equally. Your competitors will use the same models, the same RAG tools, the same talent pool. What they can’t replicate is your semantic consistency.

This means the only defensible AI moat in enterprise is a context layer that teaches AI how your business actually works. That’s the ontology. And once you build it, every AI application you build on it compounds its value.

The consolidation approach says: spend three years harmonizing systems, then do AI.

The translation-layer approach says: fix semantic consistency now—and your AI works immediately, across everything you already have.

Start asking the right question

Stop asking, “Which vendor should we consolidate on?”
Start asking, “How do we fix the language problem in our business?”

That CIO realized he didn’t have a vendor problem—he had a language problem. And once he saw a completely different way to solve it, consolidation stopped being the center of the strategy.

If you’re staring down a consolidation project—or you’re mid-transformation and wondering why the problems aren’t getting smaller—you don’t have to wait three years to see results. Come find me at MWC Barcelona, March 2-5 in Hall 2, Stand 2G51. I’ll show you exactly what we showed him.

Recent Posts

1. All I want for Christmas are these 5 things from telcos
2. Why your agentic AI strategy will fail
3. Move over, Moore. It’s Huang time.
4. Düsseldorf changed everything for BSS
5. Why your BSS vendor won’t build AI-native

---

---

Get my FREE insider newsletter, delivered every two weeks, with curated content to help telco execs across the globe move to the public cloud.