Many IT Organizations have implemented an ITIL based Configuration Management System to track and control IT Service Assets. As I mentioned in my earlier article, “Don’t be Intimidated by ITIL” this system doesn’t necessarily need to be an elaborate and costly commercial product. It just needs to have sufficient scale, features, and capabilities to meet the current and future needs of your particular business.

With a Configuration Management System (CMS) in place, the organization immediately begins to realize a number of benefits, including (but certainly not limited to):

• Improved ability to track changes and anticipate downstream impacts
  
• Easier and quicker handling of incidents
  
• Greater speed and accuracy in escalation of incidents
  
• Greater security due to increased control over items in the environment (Configuration Items, or CIs)
  
• Increased ability to manage proactively due to improved ability to spot trends in capacity, availability, and incident management
  
• Facilitates compliance with Sarbanes-Oxley, HIPAA, and other regulatory frameworks
  
• Greater control over software versioning and licenses
  

That’s the good news. The bad news is that these highly desirable benefits will quickly disappear if the Configuration Management System is not actively managed. In order to realize the benefits, nearly every other aspect of IT Service Management utilizes data stored in the CMS in order to make decisions. If the data is not current, accurate, and complete, these decisions will invariably be suspect, and the consequences can be dire. The CMS goes from valuable asset to dangerous liability.

The bottom line: your Configuration Management System is only as good as the process you put around it. Fortunately, this fate can be avoided. A few tips for ensuring the validity of data:

• Make someone within the IT organization unambiguously accountable for the integrity of the data in the CMS. In a large organization, this might be a dedicated role, but in many businesses this person might wear other hats. The Configuration Manager role could be combined with the Change manager, Release Manager, or possibly the Service Desk Manager.
  
• Establish regular naming conventions and stick to them. This is absolutely essential to ensure valid data, and attention to detail is required. I frequently encounter companies with CMS entries for “SERVER1, server1, Server1, and server-1”. These all refer to the same piece of hardware, and look quite similar at first glance. Let’s look at some potential consequences of this:
  
  
  
  1. A System Admin submits a Request for Change for SERVER1. The Change Manager reviews and approves the change. Some services and application dependencies are listed for SERVER1, but others are tied to server-1. Implementation of the change results in unanticipated service outages.
     
  2. The existing IT Service Continuity Plan contains disaster recovery information for server-1. When a new service is added to the server, it is recorded under SERVER1. The continuity plan is not updated and a full recovery of services in case of emergency becomes impossible.
     
  3. The server is retired and fully depreciated by the accounting team. The status of SERVER1 is changed to “retired”, but other names for the same system
     1Next ››
     Keywords:

     Brian Flora, change management, CMDB, cms, Configuration Management, ITIL, ITSM

     You do not have flash or javascript support.

     Average (2 votes)
     

     Reply