The Automation Trap
IT operations teams invest in automation for the right reasons: reduce manual effort, accelerate response, eliminate human error. The problem is that automation amplifies whatever it acts on. Automated processes operating on incomplete or inaccurate data do not produce faster correct outcomes - they produce faster incorrect ones, at scale, with less opportunity for human intervention.
We see this consistently in ITOM engagements: organisations have invested in event management, orchestration, and automated remediation - and are experiencing more noise, more false positives, and more unplanned changes than before. The root cause is almost always the same: automation was deployed before the visibility layer was established.
The Visibility Stack
Effective IT operations requires visibility at three levels before automation delivers reliable value:
Level 1: Asset visibility (HAM and SAM)
You cannot manage what you cannot see. Hardware Asset Management provides a governed record for every physical asset - server, workstation, network device, peripheral - from procurement through to retirement. Software Asset Management extends this to licence entitlements, installations, and consumption.
Without accurate asset data, event management cannot correctly attribute alerts to assets. Change management cannot assess the blast radius of a modification. Vulnerability management cannot prioritise patching because it doesn't know which assets exist.
HAM and SAM are not exciting. They don't appear in vendor keynotes about AI-driven operations. But they are the prerequisite for everything that follows.
Level 2: Infrastructure topology (Discovery and Service Mapping)
Discovery scans your network and populates the CMDB with CIs. Service Mapping connects those CIs into service dependency graphs - showing which infrastructure components support which application services, and which application services support which business services.
Service Mapping is where ITOM becomes useful for the business rather than just for infrastructure teams. When a database server fails, Service Mapping answers the question that the CIO asks: which business services are affected? Without Service Mapping, that question requires manual analysis under pressure during an outage.
Level 3: Event intelligence (Event Management and AIOps)
Event Management ingests alerts from monitoring tools and correlates them against the CI and service model. AIOps applies machine learning to identify patterns, reduce alert noise, and surface anomalies before they become incidents.
Event Management produces value proportional to the quality of the CI and service model it works against. An event correlated to an accurate service graph surfaces business impact immediately. An event correlated to an incomplete or stale CMDB produces confusion, manual investigation, and the same outcome as the monitoring alert it was supposed to improve upon.
Automation without visibility is not efficiency. It is error propagation at speed. Fix the visibility layer first.
The Correct Implementation Sequence
For organisations starting an ITOM programme, the correct sequence is:
- HAM first: establish a governed hardware asset inventory. This gives you the foundation for Discovery reconciliation and change management.
- SAM alongside: licence compliance and software inventory can proceed in parallel with HAM. The data dependencies are different - SAM relies on Discovery results, not the physical asset model.
- Discovery configuration: configure Discovery for accuracy over volume. IRE rules, deduplication, and stale CI detection must be configured before Discovery runs at scale.
- Service Mapping: begin with your top 10 most critical business services. Build the dependency graph for these before expanding. Partial but accurate service maps are more useful than comprehensive but approximate ones.
- Event Management: once Service Mapping is in place for your critical services, event correlation produces immediate value. Start there, not with your full infrastructure estate.
- Automation and AIOps: with accurate asset data, a reliable service graph, and event correlation in place, automation and AI can be deployed with confidence that they are acting on accurate information.
The Licence Compliance Windfall
One consistently underestimated benefit of SAM implementation is the immediate cost reduction from licence reclamation. Most enterprise software portfolios have 20–40% of licences that are either unused, underused, or assigned to users who have left the organisation. SAM surfaces these through automated reconciliation of entitlements against actual usage.
In one engagement, a SAM implementation for a 3,000-seat organisation identified £180,000 in unused Microsoft licences in the first reconciliation run. The implementation paid for itself before the go-live checkpoint.
Common Implementation Pitfalls
- Running Discovery without reconciliation rules: Discovery without IRE configuration creates duplicate CIs rather than accurate ones.
- Service Mapping before CMDB stabilisation: Service Mapping built on a stale CMDB will fail at the first infrastructure change that isn't recorded.
- Event Management before a service model exists: event correlation without a service graph produces events with no business context - the same as the raw alerts you were trying to improve on.
- HAM as a one-time exercise: hardware asset management requires ongoing governance - procurement integration, deployment tracking, and decommission workflows. A one-time audit decays immediately.
MainStack delivers ITOM, HAM, and SAM implementations as part of our ServiceNow practice. If you are planning an ITOM programme or struggling with an existing implementation, we are happy to scope the right sequencing in a working session.
Related: IT Asset Management · CMDB