ITOM is only as good as the CMDB underneath it
Discovery is easy to switch on and hard to keep true. Every capability above it — Service Mapping, Event Management, impact analysis, vulnerability prioritisation — inherits the quality of that data, which is why ITOM projects succeed or fail on governance rather than on tooling.
You’ll speak to a certified consultant, not a salesperson.
ITOM in practice
Four ways ITOM implementations disappoint
Nobody owns the data
Discovery runs, the CMDB fills, and then drift begins on day two. Without a named owner per CI class and a health dashboard someone is measured on, the CMDB degrades quietly until people stop trusting it.
Credentials and network access were an afterthought
Discovery quality is mostly a function of what the MID server can reach and authenticate against. This is a security and network conversation, and starting it late is the single most common cause of ITOM delays.
Service maps were built once and never maintained
A beautiful map of an application that has since been re-platformed is worse than no map, because decisions get made on it. Maps need an owner and a review trigger.
Event Management became a second alert queue
Ingesting everything without correlation rules just moves the noise. The value is in deduplication and CI binding, and that work is unglamorous and essential.
Discovery is easy. Keeping it true is the job.
A CMDB degrades from the day it is populated unless somebody owns each class and is measured on its health.
What we do differently
- Start with the CMDB you need, not the one you could have
Scope the class model to what will actually be consumed downstream. A narrow, accurate CMDB beats a broad, stale one every time.
- Get the access conversation done in week one
Credentials, firewall paths and MID server placement are the critical path. We surface them before they become a delay.
- Align to CSDM deliberately
Not as a compliance exercise, but so that ITOM, SecOps and SPM can share the same definitions later without a migration.
- Leave you a health regime
Dashboards, thresholds and named owners, so the data stays true after the project closes.
Every engagement opens with the 30-day platform review. You keep the report and the plan whether or not you work with us.
Questions we get asked
Do we need ITOM to get value from ServiceNow?
No, and starting ITSM and ITOM simultaneously is a common way to overload a team. But most of the ambitious things people want — impact analysis, vulnerability prioritisation, real service reporting — depend on the CMDB, so it usually comes second rather than last.
Our CMDB is already a mess. Where do we start?
With an honest assessment of what is actually consumed. Large parts of most CMDBs feed nothing at all. We identify what matters, fix identification and reconciliation for those classes, and leave the rest alone until it earns attention.
How does Discovery handle cloud and containers?
Cloud Discovery covers the major providers, but ephemeral resources need a tagging strategy and a deliberate decision about what belongs in the CMDB at all. That decision is more important than the configuration.
Can Event Management replace our monitoring tools?
It is not a monitoring tool — it is where alerts from your existing tools get correlated and bound to services. Expect it to sit alongside what you have.
Tell us what's not working
Thirty minutes, a certified consultant, and a straight answer about whether we can help with ITOM. If we can’t, we’ll say so and point you somewhere better.