Executive Summary
AIOps programs in large telcos can easily become technology-led initiatives. Teams may begin with event correlation, machine learning or sophisticated inventory models before establishing which operational problems need to be solved and what benefit each use case will provide.
A more practical approach starts with the operations workflow. It identifies where manual effort is being spent, quantifies the potential improvement in FTE effort and Mean Time to Resolution (MTTR), and then builds only the data and automation capabilities needed to realise that value.
This blog discusses six implementation challenges that repeatedly influence AIOps outcomes:
· Prioritising use cases based on measurable operational value.
· Establishing accurate inventory and topology foundations.
· Avoiding unnecessary complexity in Product-Service-Resource modelling.
· Using performance metrics to strengthen correlation, detection and root-cause analysis.
· Giving automation the same importance as intelligence.
· Integrating change management to prevent avoidable incident handling.
Introduction: AIOps Is an Operations Transformation
For a large telco or enterprise, implementing AIOps is not simply a matter of introducing an AI platform. The operating environment is typically shaped by multiple products, legacy systems, fragmented inventories, large event volumes and established operational processes. The implementation therefore needs to be anchored in how work is actually performed.
The central question should not be, “Which AI capability can we implement?” It should be, “Which part of the operational workflow consumes the most effort, and what is the most practical way to improve it?”
Challenge 1
Prioritize Use Cases Based on Business Value, Not Technical Appeal
One of the first mistakes organizations can make in an AIOps journey is moving directly into implementation without establishing the benefit that each use case is expected to deliver. For many operations organizations, the intended outcomes include lower manual effort, reduced FTE demand, improved MTTR and better service quality. Those outcomes should drive the use-case portfolio.
A practical starting point is to map the complete operational workflow, beginning with how a ticket or incident is received, whether proactively from monitoring or reactively from a customer, and following every activity through triage, diagnosis, escalation, communication and resolution. This makes it possible to see where operations teams spend the most time and where automation or intelligence can remove meaningful effort.
Effort must then be considered alongside benefit. A use case can look attractive while delivering limited value relative to its implementation complexity. For example, creating an incident automatically from a customer email may require handling multiple formats, incomplete information, duplicates and exception scenarios. If only a small number of incidents originate through email, the benefit may not justify making it an early priority.
By comparison, incident summarization and KCI generation are often lower-complexity opportunities that can produce earlier productivity gains. The objective is not to select the most sophisticated use case. It is to select the use case that provides the strongest operational return for the effort involved.
Key takeaway: Start with the operating workflow, quantify the expected benefit, and prioritise use cases using an effort-versus-value view.
Challenge 2
Get the Inventory and Topology Foundation Right
Large Tier-1 telcos and enterprises commonly have fragmented inventory landscapes, with different systems and operational flows for different products and services. This becomes a fundamental challenge for correlation and root-cause analysis.
Correlation cannot deliver its intended benefit when network-device information or physical and logical relationships are incomplete or inaccurate. Without dependable topology context, it is difficult to determine whether alarms are genuinely related, understand dependencies or identify the probable root-cause resource.
A single source of truth for inventory is desirable, but it may not be immediately achievable. Where multiple systems remain, the practical priority is to make the data required for the selected AIOps use cases complete, accurate and consistent.
One useful approach is to define a Minimum Data Set (MDS) for each product or service with the operations and domain teams. The MDS should specify the minimum resource attributes, topology relationships and contextual information needed by the intended use cases. Existing inventory systems can then be assessed against that requirement, gaps can be identified, and corrective work can be prioritized before major correlation, or RCA implementation begins.
Key takeaway: Do not try to compensate for weak inventory and topology by adding more intelligence to the correlation algorithm.
Challenge 3
Do Not Over-Engineer the Inventory Model
Accurate inventory is essential, but organizations can also spend too much time creating an ideal model that is not best suited to their operational needs.
A Product-Service-Resource (PSR) model can provide a valuable view from a failed network resource to the services and products it affects. Before making a significant investment in that model, however, it is important to understand whether operations teams need and will use this view.
If a team predominantly works at the resource layer, investigates alarms against devices and does not depend on product or service impact during its workflow, a comprehensive PSR model may not provide immediate value. This is especially relevant in large telcos where legacy implementations make consistent product and service definitions difficult to establish.
The nature of the incoming operational data should also guide the decision. If issues and alarms are mainly reported against resources rather than services, the better initial investment may be to strengthen resource-level data quality and MDS coverage. PSR relationships can then be expanded where a proven operational use case requires them.
Key takeaway: Build the minimum inventory and relationship model required by the target use cases, rather than pursuing architectural perfection by default.
Challenge 4
Event Data Alone Is Not Enough: Performance Metrics Add Critical Context
Events and alarms are usually the starting point for AIOps, but relying on them alone limits the depth of the analysis. Event correlation can group potentially related symptoms and reduce noise, but identifying what actually changed and which resource is the probable root cause often requires performance context.
Historical and near-real-time metrics allow AI and ML techniques to examine what was happening to a resource before, during and after a set of events. Performance data can therefore strengthen several capabilities:
· Event correlation, by providing behavioral context for deciding whether events are related.
· Root-cause analysis, by highlighting the resource that began behaving abnormally before wider symptoms appeared.
· Anomaly detection, by identifying deviations from normal behavior before fixed thresholds are crossed.
· Early issue detection, by using trends that indicate deterioration.
· Predictive intelligence, by recognizing patterns that may precede operational failure.
The scale and cost trade-off
For a large network, collecting, transporting, storing and processing performance metrics can be complex and expensive. The answer is not necessarily to ingest every available metric. The collection strategy should be aligned to the selected use cases, domains and resource types.
As with inventory MDS, an organization can define the minimum performance dataset needed for each use case. This provides sufficient context without turning the AIOps initiative into an unnecessarily broad data-platform programe.
Key takeaway: Events indicate that something happened; metrics help explain what was happening around it and bring the analysis closer to the root cause.
Challenge 5
Give Automation the Same Importance as Intelligence
AIOps programs often concentrate on event correlation, alert correlation, incident reduction, predictive intelligence and root-cause analysis. These capabilities are important, but automation can provide equally important and sometimes earlier benefits in reducing FTE effort and MTTR.
The operations workflow should again provide the starting point. Working with operations teams helps identify the repetitive manual activities that consume the most time. In many environments, diagnostics and troubleshooting represent a major share of that effort. Engineers execute checks, collect outputs from different devices and tools, interpret the results, decide the next action and eventually summarize what is required to resolve the incident.
Agentic AI is particularly relevant where troubleshooting is not a fixed sequence. An agent can invoke diagnostic tools, interpret the returned outputs, decide the next check using the available context and continue until it has gathered enough information. It can then provide the engineer with a concise summary of the findings and the likely action required.
The progression should be deliberate: manual diagnostics, automated diagnostics, agent-driven troubleshooting, recommended remediation and, after sufficient maturity and control, automated remediation.
Deterministic automation still has an important role where the workflow is predictable. Agentic AI is more appropriate where the process requires interpretation, contextual decisions and dynamic selection of the next step.
Key takeaway: AIOps should not only explain incidents; it should progressively remove the manual work required to investigate and resolve them.
Challenge 6
Integrate Change Management to Prevent Unnecessary Incident Handling
Network changes are frequent in large telcos, but change-management processes are not always integrated with monitoring, event management and incident management. A planned change can therefore generate alarms that result in incidents, even when the cause is already known.
Operations teams must then investigate the incident, identify its relationship to the approved change and close it manually. This creates a process gap, additional handling and avoidable use of operational time.
Change information should form part of the context used by AIOps correlation. When an alarm or a correlated event group coincides with a relevant planned change, the platform should be able to determine whether an incident should be created, suppressed or handled through a different workflow.
The effectiveness of this approach depends on the change record containing enough information to associate it with the affected network resources. Accurate resource identification, timing and scope are therefore important parts of the integration.
Key takeaway: Correlation should use change context to stop operations teams spending time on incidents whose cause is already known.
Conclusion: Build for Operational Value
The practical challenges of AIOps in a large telco are interconnected. Selecting the right use cases requires a clear view of operational effort. Correlation and RCA require reliable inventory, topology and performance context. That data foundation should be sufficient for the use case without becoming an over-engineered transformation program. Intelligence must then be complemented by automation, while change context should be used to prevent unnecessary work from entering the operations queue.
The consistent theme is simple: measure AIOps by the operational work it removes and the outcomes it improves, not by the sophistication of the technology deployed.
