How to improve your service configuration data and what that means for CMDB

A reader asked How do you maintain the information of your complex interlinked system?

We need to do something because the problem is that most of the information (critical) is in the head of the technical people. And most of them don't like documenting their stuff.

So our issue is behavioural and procedural. No tool will fix that.

What we need to do is to get them to write it down. Right now you have the tools to write it down. Everyone does. (we'll talk about how WELL they work in a minute. Stop being perfectionist).

The way process improvement works - and I explain this over and over to the IT tech community - is
1) get ownership and accountability
2) define the behaviour you expect through policy
3) capture the current procedures and repositories (that record and report configuration data)
4) communicate the policy
5) educate in how to comply using the current procedures and repositories
6) measure compliance as best you can
7) performance-manage so that people comply
8) when people complain about the metrics, work together to improve the measurement infrastructure
9) when people complain about the procedure being too burdonsome, work together to improve the efficiency of the process and reduce the manual effort
10) when people complain about the data being too inaccurate, work together to improve the effectiveness of the process.
11) if you identify efficiency and effectiveness improvements that imply a tool improvement, make technology improvements according to that requirement in order to deliver that efficiency or effectiveness. For a tiny number of organisations this improvement will imply a full CMDB (see below) technology to automate data capture and/or federate the data view. Mostly not. What you use now will work well enough if you improve the behaviours and make smaller improvements to the tools.

THAT's what we need to do. Standard process improvement. Please can I stop explaining that now?

Regular readers will know I have explained this before and before and before and...

There is a lot of stuff on CMDB here.

P.S. this has also been hammered elsewhere on this blog but I'll repeat it here:
To me - and ITIL - a CMDB is (composing from multiple ITIL definitions since ITIL is as usual opaque about this) "a database used to store every component or other service asset that needs to be managed in order to deliver a service and the hierarchy and other relationships between them to work together to deliver an IT service". The "configuration" of CMDB is the configuration of your services. the essential element that distinguishes a CMDB from any other asset bucket is that it stores the relationships to understand the impacts on service.

So if the root entity isn't a service and the relationships aren't there to do impact analysis on that service, it isn't a CMDB.