A blueprint for consolidating incident, change and configuration management onto ServiceNow when network operations and IT service management have grown up as separate worlds.
This is a blueprint, not a client case study. The situation described is a composite of the conditions we design for, not a named engagement. Targets below are measures we would baseline and report against — not results already achieved.
A regional operator with roughly 400 IT and network staff runs incident management in three places. Network operations works out of a monitoring console and an email distribution list. The IT service desk runs a ten-year-old ticketing tool. Field operations coordinates by phone and a shared spreadsheet.
When a core switch degrades, the network team sees it first. The service desk finds out when customers call. Nobody can answer the question executives ask within ten minutes of any significant event: which customers are affected, and what is our exposure?
The configuration data that would answer it exists, spread across an inventory system that is broadly accurate for physical assets, a spreadsheet of application dependencies maintained by one architect, and institutional memory. Impact analysis is a bridge call, not a query.
Network operations resolves events in minutes. Any workflow adding clicks to that path will be bypassed, and a bypassed system produces worse data than no system.
Previous inventory efforts decayed within two quarters. Anything requiring humans to remember to update it will decay the same way.
The existing service desk cannot be switched off over a weekend. Both systems have to run in parallel through transition with a single source of truth for reporting.
Reportable incidents carry a filing window. The new system has to shorten the evidence-gathering path, not lengthen it during transition.
The shape of the solution, before any of the detail below.
Event to customer impact, without a bridge call
These are the calls that determine whether the engagement works — most of them made before any build starts.
The CMDB exists to answer 'what breaks if this fails'. We model to CSDM, but we scope by working backwards from the impact questions the business actually asks, rather than cataloguing everything discoverable. A smaller CMDB that is trusted beats a complete one that is not.
Discovery populates infrastructure. Integration with the existing inventory system covers network elements. Service mapping builds application dependency relationships from observed traffic rather than from interviews. Data certification campaigns run on a cadence with named owners, and a health dashboard makes decay visible before it becomes distrust.
Events flow from the existing monitoring stack into Event Management, get correlated and enriched with CMDB context, and raise incidents automatically. The network engineer keeps working in their console; ServiceNow becomes the system of record without becoming the system of work.
Once business services are mapped to their infrastructure, an event on a switch resolves to an affected service and its customer base automatically. The ten-minute question becomes a dashboard rather than a bridge call.
Incident first, because it delivers the impact visibility everyone wants. Then change, then problem, then request and the catalogue. Each process runs in parallel with the legacy tool for a defined period, with reporting consolidated so there is never ambiguity about the real number.
Durations are indicative for an engagement of this shape. Yours would be sized during assessment.
Process discovery across network operations, IT service desk and field operations; data profiling of every candidate CMDB source; future-state design validated with the people who will use it.
Activities
Instance configuration, discovery rollout and CMDB population — established before any process goes live, because process on a bad CMDB produces distrust that is hard to reverse.
Activities
Incident management configured and connected to the monitoring stack through Event Management, with correlation rules tuned against real event volume.
Activities
Remaining processes rolled out, with change risk assessment using CMDB relationships and a service catalogue built around user tasks rather than the org chart.
Activities
Parallel running ends, legacy tool decommissioned, and the platform moves into steady-state support with adoption actively measured by team.
Activities
Every one of these is baselined before work starts, so the comparison at the end is defensible rather than flattering.
| Measure | Target | How it's measured |
|---|---|---|
| Time to customer impact answer | Under 5 minutes, self-serviceMeasured from event timestamp to impact dashboard reflecting affected services and customer count, without a bridge call. | Measured from event timestamp to impact dashboard reflecting affected services and customer count, without a bridge call. |
| CMDB certification pass rate | 95%+ sustained at 6 monthsAutomated certification campaigns against sampled CIs, tracked on the health dashboard rather than asserted. | Automated certification campaigns against sampled CIs, tracked on the health dashboard rather than asserted. |
| Auto-created incident share | Majority of network incidentsProportion of network-originated incidents raised by Event Management rather than manually, with correlation ratio tracked alongside. | Proportion of network-originated incidents raised by Event Management rather than manually, with correlation ratio tracked alongside. |
| Change success rate | Baselined week 1, improving quarterlyPercentage of changes completed without rollback or resulting incident, using CMDB-driven risk scoring. | Percentage of changes completed without rollback or resulting incident, using CMDB-driven risk scoring. |
| Service desk adoption | Full migration off legacy toolTicket volume by system through parallel running, with the legacy tool decommissioned on a committed date. | Ticket volume by system through parallel running, with the legacy tool decommissioned on a committed date. |
Named up front. A risk register written after something goes wrong is just a post-mortem.
Scope is fixed to the impact questions agreed in assessment. Additional CI classes go to a backlog for later phases, not into the current one.
Correlation rules are tuned against replayed historical event volume before go-live, and alert quality is reviewed weekly during hypercare with rules adjusted.
Network engineers are in the design workshops from week one, and the integration deliberately keeps them in their existing console rather than moving their work.
Each process has a committed decommissioning date agreed at design, with exit criteria defined in advance rather than negotiated at the point of switch-off.
It never does. Tell us where yours differs and we'll tell you honestly whether we're the right people for it.
Or email us directly at reachus@segakiv.com