Why Telecom Transformations Stall (And It’s Not the SI’s Fault)

Over the past few weeks, I’ve been sitting down with department heads across the telecom space. Not surface-level check-ins but real, in-depth conversations about what’s actually plaguing their thoughts at night.

And I’ve noticed a pattern that keeps showing up.

Every major telecom operator is in the middle of some form of transformation program. 

KPN has its own. VodafoneZiggo, Odido, and DELTA Fiber are all running large-scale business and IT initiatives, typically led by global systems integrators (SIs) at the helm.

On paper, everything looks solid.

Clear scope. Clear budgets. Clear timelines.

In reality? 

There’s always a layer of work that sits outside of that scope. And that’s where things start to break down. 

The work no one owns

Across nearly every conversation, the same issue comes up:

There’s critical work that no one owns.

It’s not in the SI contract. It’s not formally prioritised internally. However, it still needs to get done. And so it lands on already stretched internal teams.

That’s where telcos get stuck, and believe me, I’ve seen it firsthand. 

The three gaps I keep seeing

1. Network automation that never gets prioritized

The SI is focused on hitting major milestones. That’s what they’re contracted to do. Meanwhile, your engineers are still manually scripting the same network configurations week after week.

Automation is always “coming in phase two.” But phase two keeps moving.

The cost? 

Slower operations, more room for human error, and engineers burning out on repetitive work that should already be automated. 

2. Real-time data streaming as an afterthought

OSS environments generate massive volumes of data. But getting that data where it needs to go, in real time, is rarely treated as a core requirement during transformation.

So you end up with batch processes. Alerts come in late. Visibility is partial.

And the cost? 

Delayed incident response, poorer customer experience, and network capacity that isn’t fully utilised. 

3. Out-of-scope work that becomes critical

This is the one no one plans for.

The SI delivers exactly what’s in the contract. But what about the security vulnerabilities flagged last quarter? 

The monitoring integrations that were missed in the initial requirements? 

The test management support needed during an unplanned upgrade?

None of it disappears.

And the cost?

 Internal teams absorb the workload, projects slow down, and technical debt quietly builds in the background. 

The illusion of being data-driven

Over the past decade, telecom organizations have invested heavily in monitoring tools, OSS platforms, data lakes, and analytics environments. Streaming telemetry is widely available from routers, switches, mobile infrastructure, and IoT ecosystems.

On the surface, this creates the impression of a data-driven operation.

But in reality, much of this data is:

  • Stored in silos rather than shared across systems
  • Visualized in dashboards but not operationalized
  • Fragmented across multiple vendors and platforms

 

This leads to a critical disconnect. Operators have access to insights, but not the ability to act on them when it matters most. 

The core problem is telemetry without action.

Most telecom environments still operate on a reactive workflow:

Telemetry → Dashboard → Manual action

While this model worked in the past, it is no longer sufficient for modern, high-scale networks.

And the consequences are significant. Delayed incident response, manual and time-consuming troubleshooting, limited cross-domain visibility, and increased risk of service disruption.

In large-scale environments, even a few-minute delay can affect thousands of customers, violate SLAs, and disrupt connected systems. The issue isn’t a lack of data. It’s the inability to convert data into immediate, automated decisions.

Why most telecom networks fail to act on real-time data

So why does this gap persist?

The answer lies in a combination of technical and organizational challenges:

1. Fragmented system landscapes

Telecom environments comprise multiple systems that manage access networks, transport infrastructure, IoT platforms, and service assurance. These systems often operate independently, making real-time coordination difficult. 

2. Data silos across the organization

Critical data is spread across OSS/BSS platforms, CRM systems, network logs, and IoT data streams. Without integration, forming a unified operational view becomes nearly impossible. 

3. Legacy architectures

 Many telecom systems were not designed for real-time processing. Batch-based workflows, polling mechanisms, and delayed pipelines prevent organizations from responding at the speed of their data demands. 

4. The dashboard trap

 Dashboards create visibility, but not action. 

Many operators rely heavily on visualization tools, assuming that insight alone will drive better outcomes. In reality, dashboards often introduce delays by requiring manual interpretation and response. 

This is ultimately why most telecom networks fail to act on real-time data. Not because the data is unavailable, but because the systems and processes are not built for real-time execution.

The missing link: From data to action

To overcome these challenges, telecom operators must shift from passive data consumption to active, real-time decision-making.

A modern operational model looks more like this:

Telemetry → Streaming Platform → Analytics / AI → Decision → Action

In this model, data is not just collected. It’s continuously processed, analyzed, and acted upon in real time.

This enables immediate anomaly detection, automated incident response, real-time root cause analysis, and continuous network optimization. Instead of waiting for engineers to interpret dashboards, systems can trigger actions automatically, reducing response times from minutes to milliseconds. 

What I’ve learned at Evoura

We’re based in Amsterdam and work exclusively with telecom operators. We don’t compete with the big SIs, and that’s intentional.

Instead, we focus on the work that falls between the cracks. 

The things that don’t make it into the original scope, but still determine whether a transformation actually succeeds. 

From the conversations I’ve had and the work we’ve done, that typically looks like:

  • Turning manual network administration into automated, proactive workflows
  • Enabling real-time data streaming to improve monitoring and incident response times
  • Strengthening OSS and security environments through targeted hardening
  • Supporting test management during complex OSS upgrade projects
  • Designing event-driven architectures that turn data into immediate action 

We work the way we do. Design. Build. Run. All the way through. 

The bottom line

Your SI is doing their job. But their job isn’t everything.

And the out-of-scope work? 

It doesn’t go away. It just gets pushed onto your team. 

If there’s one thing I’ve taken from these conversations, it’s this:

The success of a transformation isn’t just defined by what’s in scope; it’s defined by how you handle everything that isn’t. 

If you have network automation, real-time streaming, or OSS/BSS work that isn’t getting the attention it deserves, and you don’t want to wait for “phase two…”