I have a very general question. are there any guidelines on how to practically take on Configuration management. We all have followed the ITIL trainings and understand the objectives and most of the tasks required to get there, but traditionally and I find Configuration management to be a mess in most of the companies I know. Seems like everyone has its own way of deciding what is required and how to collect info from the techies. Therefore, I wonder if any sample policies, data collection templates and good recommendations are available. We will be using HPSD (Hewlett Packard Service Desk.) Thank you in advance for your answer.

Regards, Daniel

Hi Daniel,

Thanks for this question, configuration management is probably the least understood and most important service management process. Yet most have no idea how to start and many think it requires huge investments. But this is not always the case.

I can't speak directly to HPSD, but I can talk about the real purpose of a CMDB, and how to begin establishing one. Regardless of what you heard, read, or seen, the purpose of Configuration Management is to control changes through creation and maintenance of documentation. This is not the same as Change Management, which is a process for evaluating and handling change requests in the pursuit of quality of service improvement.

Configuration Management is a process to identify, record, maintain, report on, and verify documentation. Change Management and other ITIL processes use this documentation to make better decisions. Creating and maintaining records of Configuration Items (CI) such as hardware, software, and the documentation related to these CIs is all Configuration Management describes, nothing more and nothing less.

The activities of Configuration Management all relate to the simple idea of creating and maintaining a database of information regarding CIs, and then inserting the usage of this database into the decision making process. This simple understanding is the path to success regarding Configuration Management, and the establishment of a Configuration Management Database, or CMDB.

Focus on the CIs relevant to delivering your vital services. Locate the existing information repositories, but leave them in their current form for now. Your goal is not to impose major new projects on existing teams, but rather to locate sources of data and formalize their maintenance and control. The first step is to locate all of the sources of information relating to your hardware and software. Don't worry about a single repository for Incident, Problem, Known Error, and Change records, hardware, software, and services for now. (You probably already have a system that tracks Incidents, Problems, and Known Errors or their equivalent right now — your ticketing system, as one of the repositories within your CMDB.)

Once you know where your CI information resides, you must plan how to integrate the repositories. The next step is to arrange the sources of CI data into a structure — a metabase. This does not always require investments in new systems or software development. Depending on your size, maturity, and unique requirements, your CMDB solution will vary.

You can create a spreadsheet of where your configuration information resides. You can create relational systems tying together existing tools and systems such as Human Resource directories, ticketing systems, asset registers, log files, and any other appropriate source of data.

Please see the article I wrote titled "Configuration Management for the Rest of Us" which explains how to get going.

Thanks again, and I hope this helps -- Hank Marquis