Lessons from a Solent University Project that gives me hope for OSS/BSS
Telco keeps worrying about a skills shortage. But a group of Solent University students just reminded me that the talent is still there. We just
In the the last month or so 8 different carriers, from a variety of places around the planet, have reached out to us to discuss their ambitions for reaching AN Level 4. There’s clearly a major groundswell behind it.
The thing about AN Level 4 is it sounds like a clear destination. But it doesn’t really work like that!
This one clear, simple number hides the hard part – unless there’s a single project that can take you all the way to that destination, which seems unlikely, how do you actually get to Level 4?
How do you decide which of the hundreds of required steps should happen first or in which sequence? Which workflows, systems, data sets, teams and suppliers need to change, and in what order?
Without that detail, Level 4 is no more tangible than drawing a rocket ship and expecting it to take you to the moon without any rocket-building knowledge, plans, or the SpaceX factory at your disposal.
JFK set the wheels in motion in 1961, establishing the ambition for America to go to the moon before the decade was out. But the Apollo programme still needed around 400,000 people to put Neil Armstrong on the moon in 1969.
Autonomous networking has the same problem. The target of AN Level 4 matters, but the build plan matters more.
AN Level 4 is the moonshot ambition. In this article, we’ll explain the framework we use here at PAOSS to help carriers build the rocket that gets them there.
This diagram shows the high level approach we use. But as you see, step 1.3 is part of a larger plan. We first need to move from current state (1.2) to the desired future state (Level 4) through to detailed implementation planning and future delivery.
The problem is that AN Level 4 isn’t a mission plan. It isn’t even the full extent of step 1.3 in the diagram
I have nothing against setting AN Level 4 as a target. It gives executives, network teams, OSS/BSS leaders and transformation sponsors a common goal. It says, “we want to move beyond what we do today and towards more autonomous, intelligent and coordinated operations.”
But it doesn’t answer important questions such as whether:
That’s why our approach simply treats AN Level 4 as a target, one that is heavily supported by a framework that generates evidence, scenarios, gaps, priorities and implementation artefacts.
We’ll show you more in this article.
.
For readers less familiar with the terminology, Autonomous Network levels are a TM Forum maturity scale running from Level 0 to Level 5 – from manual operations through to fully autonomous networks. Refer here to TM Forum IG 1252 for a much deeper breakdown of levels.
| Level | Plain-English meaning | What changes |
|---|---|---|
| L0 | Manual operations | Humans perform the work |
| L1 | Assisted operations | Tools help, but people still drive the process |
| L2 | Partial autonomy | Some tasks are automated in selected scenarios |
| L3 | Conditional autonomy | Closed-loop automation works under defined conditions |
| L4 | High autonomy | Systems can use AI, prediction and closed-loop management across more complex scenarios |
| L5 | Full autonomy | The network operates autonomously across services, domains and lifecycle stages |
Level 4 is often described as a “highly autonomous” state, where the network can use intent-driven, predictive analysis, AI modelling and continuous learning to support closed-loop operations. Lots of buzzwords there right?
But the important nuance is that AN Levels are usually assessed per scenario, not as a single blanket score for the entire operator.
A carrier might be close to Level 4 in RAN energy optimisation, but much lower in change management, fulfilment or cross-domain assurance. That’s why Level 4 needs to be translated into specific scenarios, capabilities and delivery steps before it helps form a practical transformation plan.
AN Level 4 cannot remain the abstract industry phrase it seems to be today. It needs to become a practical description of what needs to change inside your own operating environment.
What should be more autonomous exactly? Fault management? Service assurance? Change management? Energy optimisation? Network planning? Order fulfilment? Customer experience assurance? Cross-domain coordination? The list goes on.
For one operator, the priority might be reducing manual alarm handling in the RAN. For another, it might be improving IP network quality optimisation. For another, it might be closed-loop change or faster service activation. The target level may be the same, but the path to value will be different.
The diagram above is useful because it shows the three lenses of AN maturity assessment described by TM Forum:
But these assessment mechanisms are only a snapshot in time. They’re helpful for steps 1.2 and 1.3 in the earlier framework. But they don’t help you choose what to do next.
.
Before deciding how to get to Level 4, you need evidence of where you are today.
That means assessing the current OSS/BSS environment, workflows, personas, data flows, integrations, applications, operational volumes, service activation performance, alarm volumes, SLAs and automation maturity. It also means understanding the constraints – legacy systems, supplier dependencies, process fragmentation, budget, available resources, intended timelines, regulatory obligations, organisational boundaries and more.
A current-state maturity baseline becomes invaluable.
In the PAOSS approach, the TM Forum AOMM assessment is used to create an enterprise-level view across technology, operations, data, culture, strategy and related domains. The purpose is not to create a decorative maturity score. The purpose is to create a defensible baseline that can support investment, sequencing, project and governance decisions.
The scoreboard below provides a sample AOMM assessment roll-up with as-is (current-state, or step 1.2) and to-be (future state, or step 1.3).
.
One of the traps in autonomous network planning is assuming the organisation has a single maturity level.
In reality, maturity is uneven. One domain may already have strong automation. Another may depend on manual workarounds. One process may have good data quality. Another may rely on spreadsheets, swivel-chair operations and tribal knowledge.
That’s why enterprise maturity and scenario maturity need to be separated.
AOMM helps assess the wider operating model. ANLET-style scenario assessment helps identify what is happening in specific operational scenarios. This prevents the roadmap from becoming too generic.
It also helps avoid spending money evenly across the estate when the value is concentrated in a smaller number of high-impact areas or domains.
.
Autonomy should NOT be pursued everywhere at once.
The better approach is to identify the scenarios that can move the dial fastest. These might improve efficiency, reduce cost, increase resilience, improve customer experience, shorten cycle times, reduce operational risk, increase capacity to handle higher service volumes, etc.
In practical terms, this means asking which scenarios deserve priority. Which have the highest pain today? Which have the highest cost of delay? Which are most feasible? Which create reusable capabilities for later phases?
.
Once the priority scenarios are clear, the next question is how to build the capabilities to support those scenarios.
This is where the detailed analysis work begins. Each scenario depends on systems, integrations, data sets, workflows, rules, policies, assurance processes, fulfilment processes, volumetrics, orchestration capability, observability, operational governance and supplier behaviour.
For example, a closed-loop assurance scenario may need trusted topology, real-time telemetry, alarm correlation, service impact analysis, policy rules, workflow automation and clear human escalation paths. If one of those foundations is weak, the autonomy ambition becomes fragile.
However, we’ll dive further into the detailed planning for these shortly.
.
The AOMM Scorecard above (the “to-be state” columns) helps to show where we want to get to at a slightly more detailed level. The detailed breakdown behind AOMM plus ANLET assessments help provide some guidance on the target state.
We should also point out that we might not just have one target state (one “to-be” column). We might actually have a series of target states (eg Year 1, Year 2, Year 3 or similar).
.
The gap analysis compares the current-state evidence with the desired future state.
The AOMM scorecard exposes the capability gaps, process gaps, data gaps, technology gaps, governance gaps, operating model gaps and supplier gaps that must be addressed.
The value of this step is clarity. It turns “we want Level 4” into “these are the specific missing capabilities that stop us from getting there.”
The steps that follow show how AOMM and ANLET gap assessments are turned into prioritised initiatives, phasing and implementation artefacts.
.
Using the gap assessment as a guide, we then establish a long list of possible initiatives that could help to move the assessment from as-is to to-be state. These transformation initiatives could fall into many different categories including:
At this stage, the initiatives haven’t been sized or scaled. It’s more like a brainstorm list of things that could move the AN needle.
.
The next step is prioritisation to ensure only the most impactful initiatives are funded.
We use the RIAT (Rapid Impact Assessment tool) to assess initiatives by:
This helps separate quick wins from foundational enablers, strategic campaigns from tactical fixes, and high-value initiatives from low-impact noise.
.
Individual initiatives then tend to be grouped into coherent delivery campaigns or projects.
These could include OSS replacement / uplift, data readiness, assurance automation, workflow redesign, inventory improvement, orchestration uplift, governance uplift or so many other projects.
Campaigns are easier to sponsor, fund and manage than hundreds of disconnected actions. They also help show how early work enables later maturity gains.
.
The final step is turning the roadmap of campaigns / projects into something delivery teams can actually use.
That means:
This is the difference between an assessment and a transformation plan.
.
Autonomous networking is not a one-off audit. It’s an ongoing maturity journey.
The moonshot needs a build plan. But it also needs a run plan to maintain momentum. Apollo continued to run for years after it put people on the moon.
This is where we move from projects to the ongoing operations phase.
As capabilities improve, the roadmap should be revisited. Priorities will change. New scenarios will become possible. Supplier roadmaps will shift. Data quality will continue to evolve. Operating teams will learn. Governance needs to keep the transformation aligned to changing business objectives.
.
A carrier doesn’t reach AN Level 4 by declaring the target. It gets there by breaking the target into operational outcomes, current-state evidence, priority scenarios, OSS/BSS dependencies, capability gaps, prioritised initiatives and executable delivery artefacts. It then operationalises all of those actions.
Whether you’ve already committed to reaching AN Level 4 or not, we’d be delighted to speak with you about how you might use this approach to transform your operational network, systems and processes.
Telco keeps worrying about a skills shortage. But a group of Solent University students just reminded me that the talent is still there. We just
Most OSS experts focus on the implementation and post-go-live performance aspects of a transformation. That makes perfect sense, because they’re the most visible phases. But
Everyone wants to know who the best OSS vendor is. But since there are 500+ OSS/BSS vendors, that question usually starts an argument, rather than
Telco keeps talking about being scared of an imminent skills cliff. But perhaps the real problem is not just that experienced people are leaving. It’s