| Many ITIL experts argue that Configuration
Management is the ITIL sun around which the other
ITIL planets revolve. Certainly this is a strong
argument because all of the other ITIL processes
do come into regular contact with Configuration
Management. Therefore meeting the goals for Configuration
Management is critical for success when implementing
ITIL but are you currently meeting those goals?
Let us have a look at the ITIL Configuration Management
goals:
Configuration Management provides a logical model of the infrastructure or a service by identifying, controlling, maintaining and verifying the versions of Configuration Items ( CIs) in existence.
The goals of Configuration Management are to:
- account for all the IT assets and configurations within the organisation and its services
- provide accurate information on configurations and their documentation to support all the other Service Management processes
- provide a sound basis for Incident Management, Problem Management, Change Management and Release Management
- verify the configuration records against the infrastructure and correct any exceptions
Let us break the goal for Configuration Management down into its fundamental components and see what we can identify to help justify ITIL:
Configuration Management provides a logical model of the infrastructure or a service by identifying, controlling, maintaining and verifying the versions of Configuration Items ( CIs) in existence – before we can look at this element we need to understand the ITIL definition of a Configuration Item:
Component of an Infrastructure, or an item, that is( or is to be) under the control of Configuration Management. CIS may vary widely in complexity, size and type, from an entire system (including all hardware, software and documentation) to a single module or minor hardware component.
So a Configuration Item is a component of the Infrastructure that is required to provide the services, systems and applications etc. required to provide an agreed service to the IT customer. The complexity is your choice, for example you may decide that a work station is a CI or you may decide to break a work station into its components, (processor, keyboard, mouse and screen), and make each of these a CI. However Configuration Management is primarily concerned with the relationships between CIs, i.e. by looking at one CI I can see how it relates to the other CIs required to process a particular system or service. For example the Service Desk will use the relationship between CIs establish impact and then to determine priority. Note Asset management maintains details on assets above a certain value, their business unit and their location whereas Configuration Management also maintains the relationships between assets which Asset Management does not.
The first question when trying to determine this goal element is whether you have a Data Base illustrating the relationships between your CIs, or assets? If not then how can you identify impact? How will you recover from a remote disaster? You may find that you don’t even have a central Asset Data Base in which case this is a strong justification in itself. So first look to see if you have central Asset Data base and look to se if you have the relationships for each Item and prepare you case accordingly.
This element talks specifically about; identifying, controlling, maintaining and verifying the versions of Configuration Items. What you need to do here is to identify whether you have a standard approach to manage the life cycle of all CIs from conception to termination. If you do check that it covers all CIs and that it is well maintained. A good clue is the Service Desks getting calls from customers concerning technologies that according to the Configuration/Asset Data Base the customer does not have, e.g. Customer “My scanner isn’t working.”, Service Desk “That is not surprising because according to our records you don’t have one!”. A bit tongue in cheek but illustrates the point. So in summary the two things to check is that you have a process, or procedure, for identifying and controlling CIs and that you have process, or procedure, for maintaining the status of those CIs. Depending upon your findings you can prepare your arguments accordingly.
Account for all the IT assets and configurations within the organisation and its services – this is an important objective because not all CIs will appear as assets, for example internally written programs are not normally seen as assets, procedural documentation is not normally seen as an asset and people are not normally seen as an asset but they are Configuration Items. This element means that checks should be performed to ensure that all potential CIs have been included in the Data Base. So a simple action to verify if you are meeting this element i.e. do you check or not? Of course if you do not have a Configuration Data Base there will be nothing to check anyway.
Provide accurate information on configurations and their documentation to support all the other Service Management processes – assuming that the data in your CMBD is accurate the question is how do you provide it to the other Service Management processes? Integration between the Service Management process is critical, for example when the Service Desk is entering data in an Incident record does the CI data automatically populate the record? Or does the Service Desk agent have to enter the data manually? Or even worse the data is not entered because it is not available? To check whether you are meeting this goal element look at the other Service Management processes and identify where the CMDB data is not being used when it should be. Of course if you do not have a Configuration Data Base there will be nothing to check anyway.
Provide a sound basis for Incident Management, Problem Management, Change Management and Release Management – Incident, Problem and Change are the processes that use of the CMDB for information but more critical for decision making purposes. For example an accurate and complete CMDB means that better decisions can be made for identifying the impact of a problem or incident, costs can be better calculated for potential changes and escalation will be more accurate etc. There is much talk about knowledge tools in Service Management yet probably the most important knowledge is what you have and where it is etc. yet the importance of the CMDB is often overlooked. This element concentrates on the attributes contained In the CIs. Just having a CMDB is not good enough you must have data contained in each CI that provides meaningful information to the other Service Management processes. You need to look at the attributes, or fields, for your CIs to ensure that the data provides useful information for the other Service Management processes. You will need to ask the owners of the other processes if they getting all of the data and if not what else do they need. From this you can identify whether you are meeting this goal element or not. Of course if you do not have a Configuration Data Base there will be nothing to check anyway.
Verify the configuration records against the infrastructure and correct any exceptions - as mentioned earlier Configuration Management provides information and data to all of the other processes. This element is related to previous elements except that instead of checking that all CIs are present in the Configuration Management Data Base (CMDB) but checking that the content of that CIs are accurate. So just like the previous element it is a simple action to verify if you are meeting this element, i.e. do you check or not? Of course if you do not have a Configuration Data Base there will be nothing to check anyway.
You will have seen the following statement throughout these elements – ‘Of course if you do not have a Configuration Data Base there will be nothing to check anyway’. Unfortunately this typical of too many IT departments you know it has been estimated that 70% of the revenue spent on Y2K was spent just tracking assets and their relationships. Somehow the message seems to have been forgotten. If you do not have at least a central, accurate and complete CMDB you should be raising alerts immediately.
Business alignment indicator – there is one outstanding common component which is that the customers understand their responsibilities to control, manage and protect all IT assets within their environment. It is the responsibility of IT to ‘account for all the IT assets and configurations within the organisation and its services’ but this depends upon feedback from the customers to provide information concerning any IT assets that are purchased by them or for them to update the CMDB. If the customers fail to do this then IT can only account for the IT assets that are under the direct control of IT. It is a joint responsibility between the customers and IT to ‘verify the configuration records against the infrastructure and correct any exceptions’ but this can only be achieved with cooperation and in conjunction with the customers. To verify the CMDB records against the Infrastructure would require, in most cases, IT Service Management staff visiting customer locations so that they can verify the actual assets with the CMDB. Obviously this needs full cooperation with the customers. Finally the customers should be able to view the status and configuration of all assets in their environment so that they can control, manage and protect all IT assets within their environment.
|
