The previous configuration management lead understood how the CMDB connected to incident, change and problem management, because those processes were part of the role. The replacement was hired mainly on cost, and mainly against the job title, without that wider understanding being part of the brief. Within months, the CMDB stopped meeting the needs of the processes around it, and it cost over $100,000 in consulting fees to put right.
The assumption behind the original decision is worth naming directly, because it's more common than the outcome suggests. Configuration management gets treated as a standalone process, separate from what a CMDB is for and how it fits into the rest of ITSM, and the person running it isn't expected to understand the processes it feeds.
Configuration management doesn't exist for its own sake. The CMDB feeds change impact analysis, incident routing and problem management's root cause work. A configuration management lead who understands only their own process, and not what incident and change teams need from the data, will keep the database technically maintained while it quietly stops serving the processes around it.
That's what happened here. The new lead ran the configuration management process competently on its own terms. Data got entered. Records got updated. What didn't happen was any judgement about whether the data was shaped the way incident management needed it, or whether change impact analysis could actually rely on it.
None of this would have shown up in a review of the configuration management process on its own terms. Data entry was timely. Fields were populated. Anyone auditing configuration management in isolation, against its own procedures, would have found a process working as designed. The defect only became visible from outside the process, in the processes it was meant to serve, the same governance gap behind why unknown CI owners drive up IT spend more broadly.
The first signals came from the processes that depend on the CMDB, not from configuration management itself. Incidents took longer to resolve, because the dependency data incident teams needed to trace impact wasn't being maintained with their use case in mind. More changes failed, for the same underlying reason: the impact analysis behind them was working from data that had drifted from what change management actually needed.
Multiple complaints followed, from the ITSM processes that depend on the CMDB, that it had become unusable for their purposes. That's a telling detail. The configuration management process wasn't failing on its own terms. It was failing the processes it was supposed to support, which is a harder gap to see from inside the role.
There was no mechanism in place that would have surfaced this earlier. Configuration management reported its own metrics, on its own schedule, to its own stakeholders. Incident management reported separately. Change management reported separately again. Nobody was reviewing the three side by side, so a configuration management dashboard that looked healthy in isolation could sit next to a rising change failure rate for months without anyone connecting the two. The gap wasn't hidden. It just wasn't anybody's job to look for it across the boundary between processes, which is precisely the boundary a configuration management lead is supposed to be watching.
The client brought in Apex to rectify the mistakes, at a cost of more than $100,000 in consulting fees. That figure is the cost of correcting data and process drift that a configuration management lead with wider ITSM understanding would most likely have caught and corrected as it happened, rather than letting it accumulate to the point of multiple process complaints.
After the initial rectification, Apex took over running the configuration management process as a managed service, rather than the client repeating the same hiring decision. That choice was a direct response to what had gone wrong. The process needs someone who understands the wider ITSM landscape on an ongoing basis, not just at the point of a one-off fix.
A configuration management lead who serves the wider ITSM function does a few things differently from one who runs the process in isolation:
None of this requires the configuration management lead to run incident, change and problem management themselves. It requires understanding what those processes need from the data well enough to keep providing it, which is exactly what the job description missed the first time around.
When Apex took over running configuration management for this client, the point wasn't simply to have more experienced hands on the process. It was to put a structural check in place that would have caught the original drift before it reached three months of complaints.
None of these three mechanisms is complicated on its own. What they have in common is that they don't rely on someone in the configuration management role noticing a gap in the processes around them, unprompted. They build the cross-process check into the operating model itself, so it happens whether or not the person running configuration management would have thought to go looking for it.
If you're hiring for the role, or reviewing whether your current setup is working, the useful question isn't whether the person can run the configuration management process. It's whether they understand incident, change and problem management well enough to know when the data they're maintaining stops serving those processes, before those processes start telling you.
We run a CMDB health baseline over two weeks that scores whether your configuration data is actually meeting the needs of the processes around it, not just whether it's internally consistent. The output is a report you can take to your change advisory board, or to whoever's making the next staffing decision.
Talk it through on a CMDB diagnostic call, or book a meeting with the team directly.
Cost is a legitimate factor in any hire. The issue is treating configuration management as a role that can be filled on job title and cost alone, without checking for understanding of the wider ITSM processes it feeds. That understanding is what prevents the kind of drift described here.
Track incident resolution time and change failure rate alongside configuration management's own metrics, not separately from them. If those start moving in the wrong direction without an obvious cause elsewhere, the CMDB's fitness for those processes is worth checking directly.
A one-off fix corrects the data at a point in time. The original problem was a person in the role without the wider ITSM understanding needed to keep it correct. Running it as a managed service addresses that ongoing need directly, rather than leaving the client to make the same hiring decision again.
No. It replaces the need to have internal staff carrying the full operational and cross-process understanding day to day. Governance and accountability for the CMDB still sit with the client; Apex runs the process itself.
Written by Iain Moone, Apex Configuration Group.
Book a free call to discuss how Apex can help you on your journey to a better CMDB