It's recommended that you begin your set-up process with incident management; since your organization most likely already manages defects in some way, beginning there will create a sort of "default" CMDB. Incidents are a type of documentation, and each Incident is a Configuration Item. Expand upon that by linking some Incidents together, and then move on to including changes as well.

As your maturity grows, then you can begin to add more Configuration Items and relationships – but only if they’re important. When adding Configuration Items, don’t just think about technology related things; also consider the people, locations, services, documentation, hardware and software that make your organization run.

When starting your CMDB, ask yourself these questions: Which items do I want to control? Does it really add value to my organization to monitor and control these? Do I truly have the ability to control these?

You only should be recording information and relationships that are important to the IT services of your business. If you record everything down to the last mouse and keyboard, your CMDB may become a daunting amount of information that’s impossible to implement. Instead, only record items that are (a) able and likely to be managed and controlled by your and your team, and (b) relevant to the success of your team and organization. By limiting the items that are included in your CMDB, you will help increase the chances that all items will be accurate and kept up to date. It's best to start off with "big ticket" items (i.e., services, servers, data centers, routers) and work down from there, which allows you to evaluate the business value of each layer of interconnected items. You can always add more detail later.

In addition, make it a best practice amongst the team to be in the following mindset when adding Configuration Items: “If I want to update this, will it make sense to raise a Change to get the information updated?” If the answer is “don’t be ridiculous!” then you might want to reconsider the value of including the item in your CMDB.

Next, ask yourself how these items are related to each other; for example, Service A might depend upon Server B, which is located in Office C. Taking the time to document these dependencies allows you to create a truly interconnected network of relationships. Don’t ever underestimate the effort involved in managing and maintaining these. You can buy tools to help you detect IT assets, and you can buy even more expensive tools to help you see how they are interconnected – but at the end of the day, someone needs to know how each asset relates to people and services, and someone needs to manage and maintain this stuff.

Adding and maintaining relationships might sound very daunting, but once you get your culture in place to manage Configuration Items properly, and create those linkages, it begins to add a tremendous amount of value to your business.

Once you've created your initial CMDB, you can use change management to ensure that it is kept up to date. If you let updates to the information go untracked, eventually the content will get out of control and the information and relationships will become less and less dependable. Eventually, agents won’t be able to trust the data and will have to find other ways of recording what they need to record – further undermining the data you’ve carefully gathered.

To avoid this, make it a best practice to create a change record for each update made to Configuration Items, and then link that change record to the affected Configuration Item. For example: imagine that a server that is documented as a Configuration Item needs to have its memory upgraded. Rather than just upgrading the memory and then updating the description for the server's Configuration Item, agents should first create a change record documenting the requirement to upgrade the server memory. This change record can then be linked to the server's Configuration Item via the Affected Items pane in the right navigation of the change record, resulting in a clear explanation for why the Configuration Item was updated, and therefore verifying the reliability of the entry. If this process is followed for all changes to the CMDB, it will remain a viable tool for you and your organization.