A CMDB health assessment carries very little risk, and the reason is mechanical rather than reassuring. It reads your configuration management database (CMDB). It doesn't write to it. No reconciliation rules are changed, no configuration items are merged, no discovery schedules are touched while the assessment runs. What comes out is a scored view of which configuration items you can rely on and which are guesses, written so it survives a change advisory board without you having to translate it.
The one genuine cost is a handful of hours from three or four named people. We'll come to that, because pretending it's free would be the kind of claim that makes the rest of this hard to believe.
Most of the anxiety about letting a consultancy near a CMDB is about write access. It's a fair worry. A badly aimed reconciliation change can flip thousands of records between sources on the next discovery run, and unpicking that is a genuinely bad fortnight.
So the assessment runs read-only. We look at the CMDB tables, the identification and reconciliation rule definitions, the discovery schedules and their logs, and the import sets or Service Graph Connectors feeding data in from elsewhere. Reading a rule definition tells you what it would do. Running it tells you what it did. We only need the first.
That has a practical consequence for you. The assessment doesn't need a change record, doesn't need a maintenance window, and doesn't compete with your release calendar. It can sit alongside a programme that's already running without adding a dependency to it.
The output is a score, but the score is only useful if you can see the working. Weighted critical success factors sit at the top, each broken down into key performance indicators (KPIs) and the underlying metrics, so a low score always resolves to a specific list of records and a specific cause.
The things we go looking for:
Each finding lands as a count, a class, and a named cause. Not a judgement.
The real risk in an assessment was never technical. It's that the report says out loud what people have been implying in meetings for two years, and the person accountable for CMDB data quality is rarely the person who caused it.
Here's the part worth sitting with. Your CMDB is already being scored. Every engineer who checks the CMDB, doesn't believe it, and opens a terminal instead has scored it. Every service owner who maintains a private spreadsheet of dependencies has scored it. That scoring is happening informally, it's uncontested, and it's almost certainly harsher than a measured baseline would be.
A scored report changes the shape of that conversation. Undocumented mistrust becomes a dated document with counts in it, attached to named causes, several of which turn out to be configuration rather than culture. It's much easier to ask for two engineers and a rule change than to argue against a general sense that the data is bad.
Configuration managers tend to get more support after a baseline, not less. Evidence is easier to fund than a feeling.
The assessment output belongs to you, and it's built to be re-runnable without us in the room:
That last split matters, and it's the one to hold us to. A findings list where every item conveniently requires the consultancy that wrote it is a sales document. A real one has items on it that you'll close yourselves in a fortnight, and it should say which those are.
Two places, and both are worth naming.
The first is your people's time. We need read access, and we need short conversations with the CMDB owner, a discovery engineer, and someone who knows how the third-party integrations were built. Hours, not days, but they're hours from people who are already busy.
The second is harder. Once the estate is measured, you can't easily un-measure it. If the assessment finds that a set of production servers has never been discovered, that finding exists from then on, and knowingly leaving it alone is a different position from not knowing.
Most CMDB owners consider that an argument for measuring rather than against it. It's still an honest thing to say before you start.
No. The assessment is read-only. We read CMDB tables, rule definitions, discovery schedules and logs, and the integration paths bringing in third-party data. Rule definitions tell us what a rule would do without anything having to run.
The window is fixed and agreed before we start, sized against your estate and the number of data sources feeding it. From your side it's read access plus short conversations with the CMDB owner, a discovery engineer, and whoever built or maintains the third-party integrations.
Counts, classes and causes instead of a general sense of unease. "The data is bad" doesn't get funded. A list of configuration items falling through a named identification rule does, because someone can act on it on Monday.
The remediation list is split into what your team can close internally and what needs specialist work. Ask any consultancy for that split before you engage them.
Yes. The scoring model, the weightings and the queries behind each metric are part of what you keep, so the same baseline can be re-run and compared like with like.
No. There's no change record, no maintenance window, and no write activity, so the assessment can run alongside existing work without becoming a dependency.
We run a fixed-scope CMDB health baseline. It scores which of your configuration items are trustworthy and which are guesses, and the output is a report you can take straight to a change advisory board without rewriting it first. The window is short and agreed before we start, once we've seen the size of your estate and how many data sources feed it.
Two related pieces of work sit alongside it, depending on what the baseline turns up. A data quality assessment scores your estate against weighted critical success factors, KPIs and metrics, and identifies where deduplication, normalisation and reconciliation are failing and why. A discovery and integration coverage review establishes what's missing from your estate view, where it's missing, and what that absence costs you during an incident, covering both horizontal discovery and third-party tool integration.
If a topic points at work outside configuration management, we'll tell you rather than scope it.
Book a scoping call and we'll tell you which of the three is the right starting point for your estate.