Art 6 Expanding on the previous articles entitled "MIR the Key" where the Management Information Reporting was discussed , in this article we will discuss the service data and its importance as well as the Management Information (MI) reporting and its value where Configuration Management is concerned. Truly central to successful IT operational service management is the integration of Configuration Data in the form of the CI's their relationships, status, attributes and versions and the availability of the information.
We will look at some ways for building the CMDB into the tool it should be, with some real life process examples; some good, some less so and we will also look at the levels where the information and reporting adds value in helping us to understand the management and control at the Strategic (S), Tactical (T) and Operational (O) levels.
Just to confirm I have no trouble at all with SACM as Services have always been assets and should have always appeared as CIs in the CMDB, just as the configuration information and relationships should always have been attributes. Although the term itself, (SACM), can cause consternation if used too loudly in an organisation that is currently down sizing.
As with any potential service requirement the principle ways forward is to consider what is required from the service at all levels, without that we are unlikely to design and build what we want; and as the reporting is evidence of meeting the requirements we have to ask the question:
What do we want from Configuration Management?
In the initial stages of Configuration Management when the levels of CI are being set, from my point of view, the following are important considerations. Incidentally, ITILnews and I are always pleased to hear if you think of more - please let us know.
Organisational requirements - I view these requirements as the same at strategic, tactical and operational levels and that is that the organisation, both the business and the IT structure that supports' it, require the information to make informed decisions about their IT services.
ITSM requirements - exactly as above, only for these we shall also look with granularity at the Operational benefits with ITSM.
Some of the important high level questions are:
- What have we got?
- What does it do?
- How can we change it?
- What is the cost?
- How do we measure success?
- How do we measure the service?
The reporting has to reflect this. All these questions will be of interest to the Operational, Tactical and Strategic levels of management at different times and depending what planning or activities they are considering.
What have we got? - Asset Management and depreciation - direct values, age and support costs, sustainability, location, the serviceability of devices and their support. How much longer is the manufacturer support going to run or can be extended for at a reasonable price? The answer to the last question will probably be reflected in the CMDB as a CI attribute: End of Support date.
What does it do? - Which are the business services that are supported through it or by it? At what value to the organisation? At what cost to replace? What business or IT impact to change? Which documents describes it? What touch points does it have with other functions organisations? I.e. the interfaces it has both internal and external.
How do we change it? - Feasibility, the potential impact of a change, the authority to undertake it, the timeliness of it, the entire governance structure.
How do we measure success (as seen by the business and IT Management [Strategic])? - CSFs
How do we measure the service (as managed by IT [Operational and tactical])? - KPIs
Note: As we identify the KPIs and CSFs through this article I will build the lists at the end of the article.
Service Data
Service Reporting is the delivery of information around the service that primarily provides information to the business on their service. The format, frequency and contents of the service reports should be identified and agreed during the design and building of all services.
It is quite normal for CMDB or SACM reports to form part of a Service Review, which means that the business will have a direct interest, and curiously enough in organisations where ‘re-charging' is part of the organisational setup they (the business) have been known to be quite effective policemen in the notification of equipment that they no longer have (Transfer to other cost centres).
CSFs All the business services that are supported by IT should be recognised by the CMDB, a good CSF would be to set a figure (usually a percentage) for the level of services that appear in the CMDB against the level that is recognised by the business.
If your organisations' Service Portfolio is being correctly maintained you would expect the number of services in it and the CMDB to be the same, with any delta being a driver for improvement.
The target achievement as a CSF that I would aim for is a CMDB that has that business reliant on it for its ' first port of call' when considering change or upgrade. With Configuration Management answering the first three questions bulleted above.
MIR is the information about the running of the service and its processes that is used for the management of the service and its improvement and evaluation.
KPI's - How many CI's can we add, update, delete in a reporting period? Is the backlog of updates reducing or growing? What is the level of Exception reports' we are getting from the Service Desk, Change Management or Audit verifications (these will be indicative of the accuracy levels).
CI's, of course, are rarely deleted; their status may well be changed to decommissioned or retired though.
The ability to produce credible answers from the CMDB should drive KPI's around the speed of up-dates driven by Change (measured by the elapse time between change implementation and CMDB update).
Configuration Management as a service is so central in the provision of key data and information that the difference between Service Reporting and MIR is probably less than is apparent for the other ITIL processes.
It is of course a fact that during the lifecycle any service there will be requests for changes to the reporting, these will be implemented by following the Change process. As often a cost is involved there is a clear interest (value) in getting the reporting right first time and also all Changes.
Suppliers
Unless the technology functions of your organisation are entirely in-house the need to align your suppliers with your Configuration Management needs is critical - and clearly cheaper if your requirements are defined from the start. The old adage ‘Build in not bolt on' only became old because it is correct and has stood the test of time.
Building the CMDB
There are a number of ways to build a CMDB and the choice or combinations will vary in accordance with the project and the organisation.
Also very important to the whole process is the concept and use of virtual CMDBs, if there are repositories of good data then wheel re-invention is of little value.
Software developers and deliverers should have strict version control down to a modular level. Linkage through to the CMDB front end will be exceptionally useful.
Networks have to be well defined and usually have annotated drawings/maps that describe and detail the services; this too is a valuable source of good data.
If you have a Electronic Document Management System (EDMS) then you may be some way down the route for linking your service specific documents as CIs supporting a service.
The down side to using a large number of virtual CMDBs is found where extraction of information then becomes fragmented or difficult because of it.
However there are some aspects or approaches that are generally true:
It's a pain: The building of a CMDB and the initial policing of its policies and procedures can be heavy going. CI's and attributes aren't everybody's cup of tea. You may require a level of change to other areas data that will take some selling - Software and Networks are mentioned above.
It's worth it: The benefits of well-managed Configuration Management data are enormous in the support of ITSM and the business of parent organisation.
Get your claws into procurement: Invariably when items are being purchased the procurer has or certainly should have, some incredibly useful information, along the lines of:
- Who has requested it - whether it is a single item or a number, the cost centre or project ID involved and through that the budget it will be charged to or owned by.
- Why they requested it - the CI/s involved will be procured with some form of deployment in mind, this may range to keeping a stock up to threshold level for rapid replacement, to an individual CI with a specific project purpose to thousand of laptops as part of a refresh programme.
- On delivery there will be more CI attribute information; date, cost, serial number/s, the Purchase Order reference for components that come with it, possibly pre-loaded software and licenses.
Bear in mind that the CMDB can be, and often is, used for a level of financial management that can mean for depreciation that the purchase order number and the date that ownership is taken on by the purchaser are really useful a number of years on.
Change Management are your friends: After procurement the people who know most about the CI's that are supporting a service are those who are trying to make it different. By ensuring that the Change Management gets good information on which to base Impact Assessments you can start getting them on your side. By then ensuring that you get good data from them about changes they are managing you are on route to a rolling build of the CMDB every time something changes.
With the rate of change in most organisations and a rolling build we start moving the CMDB towards a critical mass at surprisingly good speed. It is also a good method for leading the support staff towards good practise for configuration management. The sooner they find that they are getting good information that helps them for the next change the easier it becomes to draw them in.
You may be surprised how the records of CIs that are decommissioned will interest nearly everyone, usually done by a simple change of status, and an effective date with a link to the Change Record that authorized it.
The Service Desk is also your friend: Those who fix things inevitably find out stuff (stuff being good information). The Minimum Data Set (MDS) that a service desk extracts from their callers as part of Incident Management is either an instant validation or correction of some of the CMDB data.
Problem Management (more friends) will be using the Incident causal CI information for spotting trends and understanding the impact of a questionable CI.
Capacity Management (still more friends) will have CIs with thresholds and then using the CMDB information will be taking a view on ensuring future performance.
Your Friends will of course also be of great help to your accuracy in the form of Exception Reports for correcting the information on CI's and their attributes. The feeding back of corrective information will help you both in getting more credible data in the CMDB.
Make certain that the potential for these corrective reports are a part of your feedback processes and that your Suppliers are also committed to the process and delivering them.
It is important that you remain aware that the corrections may be required as the result of a simple error (they will always occur), or if trends appear it may mean that there is a process or governance failure that needs further investigation with the potential for improvement.
Rolling Build
Method: Set the CI levels to that which will provide the levels of information you may require, some fields and attributes are outstandingly clear and all should be driven by what you want out of the database.
Insert ‘claws' into the areas that have or require good data - Procurement, Change Management are the prime targets.
Provide the processes for getting the good Configuration Management data to the areas that need it, initial targets should include:
- Incident
- Problem
- Change
- Service Level Management (SLM)
- Finance
Start providing the data Really Important - see advantages below.
Rolling Build Disadvantages: The full benefits will take some time to be felt.
Advantages: You are using information that is most likely to be correct and verifiable, it is information that is already in use by the functional point from which you get it.
As the teams bulleted above start finding that their roles become easier with correct Configuration Management information available; the desire for more of it will grow, as will their willingness to be engaged in the process of supplying the information. The virtuous circle begins.
Critical mass: If you do it right this will be driven by your users and suppliers, mostly these are the same functional areas, as they follow through their own CSI initiatives for better accuracy and efficiency. The actual point will be clear as the drivers for a level of accuracy is driven by management.
Big bang
Method: A dedicated team sets out to discover and record all the unique IDs of the owned CIs and aim for a rapid population of the CMDB.
Big bang Disadvantages: Depending on the size of the estate this can be costly and the interim arrangements for change during the build can be difficult.
The interim process to accommodate the effect of change on CIs during the discovery period will be required. This can easily lead to a back log of data to be applied as soon as the CMDB is implemented a dent on its early credibility.
Discovery tools can be used for network attached CIs at a high level, however although ‘Discovery Tools' are often seen as the Holy Grail for information collection they cannot look in cupboards for ‘stock' - quite often unused laptops or desktops that are still under full support arrangements or at the least maintenance cover.
Advantages: A workable CMDB should be available and the benefits realised sooner
True life examples I have found
Firstly - Consider the supplier boundaries there are in your organisation, try to ensure that the passing of verifiable configuration management information is a contractual requirement.
- I worked in a financial organisation that had a superb ordering system on their intranet and all kinds of great information was collected as part of authorisation and the status of an order could be followed through to its delivery. Then, once procurement was complete and the item delivered the infrastructure supplier took over for the build and deployment stage; most of the data was not handed over with the device(s). This was some time ago but the opportunities missed still irritate with a Service Manager that loves the integration of information that can be so valuable within an ITIL framework.
Secondly - Going to a granular level when the data is readily available is good news - Honest!!
- On a large infrastructure and service project the configuration manager suggested that the level of attributes for RAID disks need not go as granular as serial numbers. The information was available as we were procuring all the disks, but I never got my way.
However not long after going live we started getting disk errors and it transpired that the bios levels were not all the same dependent on batches and manufacturer - had we have gone down to the level of serial numbers on the CMDB we would have been able to remediate just those disks that required it, instead of going to every site and doing them all. I am not over fond of ‘I told you so!' but my smile every time it was mentioned had to be surgically removed.
Escape thought
Why not Outsource the problem, this is of course a Siren Call, although the target will be that Outsourcing will reduce the pain of doing it and also pass the risk to another organisation. Please be very wary - if the specification of the contract does not fully address what information you as customer requires please do not be surprised when you have to pay to have that information extracted for you.
It often seems like an affront to pay for information on what is owned by your own organisation I know, but I can only caution that when setting and negotiating a contract the time taken on your requirements for the Service Reports and information will save you on the costs going forward.
Items that need to be CIs
- Services
The Service name should be the name that the business uses for the service (simple helps) and never duplicated for that way lies madness.
- Components
The CMDB picture is one of a hierarchy of CIs and component CIs that build to describe the end to end service. With CI's having relationships, attributes and status's that provides further levels of detail.
For the majority of CIs the relationships can and will be one to many, e.g. a server will be a CI that will have related to it a number of services that run on it and a number of components that are part of it, a disk array etc. An internet portal may have many feeds and conversely deliver a number of services.
- Documentation
For any particular service this will include the SLA's, the support contracts, the Service Design, a Service Catalogue entry, the Network topology, the interfaces to other services, it will be quite a long list.
Service Data value and Uses
- Incident Management
Monitoring shows a server down - what service is affected?
An End-User calls with an immediate issue - who else may be affected? How do you check?
What is the business impact? Which SLA refers?
Which resolver group needs to receive the Incident record?
When the incident resolution has been found which CI is identified as having caused the incident; so important for trend analysis and the input to Problem Management.
Was the CMDB data used found to be correct, if so good! If not then an exception report is required to correct the data and to identify why it was wrong - it could point to a simply error or a more important delta in a process
- Problem Management
The ability to be proactive;
With the trend having been identified - the CMDB data will identify the number of occurrences of the CI and therefore aid both potential cost of fix and enable the likely re-occurrence impacts to be more accurate; both of these advantages are significant and should be underestimated.
As with Incident Management if during the diagnosis or building the fix the CMDB data used was found to be incorrect the it must be reported via an exception report in order to identify why it was wrong - it could point to a simply error or a more important delta in a process
- Change management
Impact Assessments - the initial view of the potential impact on services will rely on CMDB data, as with the disciplines above, we are using CMDB data to make informed decisions, this will also include information on the documents that may need updating or have an attached schedule that could require updating.
As above if during the build of a change it is found that CMDB data is incorrect - make it right.
The new CIs will be authorised to be added to the CMDB by the change itself. The new version or revision of a CI is also authorised by a change.
Change Record id's are important fields for CIs and are often used to help with incident and/or problem diagnosis..
The Change Record field for all CI's in the CMDB should be one that holds historic records, that way it will provide the audit trail of the CI.
- Project & Programme support
CMDB data can and should be of enormous value towards project and programme feasibility studies and sizing and the final outcome will probably involve the Configuration Management team in a number of update activities.
- Reporting
We have covered above the items where Service Data can be used and how it can be kept in good order, we now move to how ITSM reports on the function itself.
Management Information Reporting (MIR)
The following are my ideas on regular reporting that is of value to both the Configuration Management Manager and the Service Management teams in an organisation.
For the reporting period (usually monthly)
- Number of CI updates brought forward from the previous reporting period
- Number of configuration management requests brought forward from the previous reporting period sorted by type - (these are requests for information, may be CI relationships for impact assessment for Change, numbers of CI occurrences for Problem or Programmes and Projects)
Note: By maintaining a rolling view of items 1 & 2 and comparing them to the same view of items 6 & 7, and here visual representation is easiest (graphs that build to a 13 month view) it provides both a view of achievement against demand and is a simple way of providing a base line for the potential impacts of new demand.
3. Number of new CI's added
4. Numbers of existing CI's updated - (identification of items where the update was driven by exception report (s) or audit will add value by informing towards the view of credible CMDB data)
5. Number of CI's with status changed to ‘Retired'
6. Numbers of new configuration management requests received by type
Note: Items 3, 4, 5 and 6 are the straight measures of achievements (throughput) for ‘The day job' of configuration management
7. Number of CI updates carried forward
8. Number of configuration management requests carried forward sorted by type
9. Number of newly identified existing services added to the CMDB in the reporting period – viewed over a number of reports will indicate how well the overall process has been working and at the strategic level gives you an indication of the high level status of your configuration Management data
Audit validations
Data Validation is a critical part of the CMDB processes, we have discussed the main methods, the continual improvement by correcting errors as found through other processes, primarily Incident Problem and Change and the discovery tools that check for connected items and their detail. Physical audits can also be employed and certainly have their uses especially where site re-locations or close-downs are concerned as they sometimes find equipment that pre-dates the current processes.
If audits and validations of data are scheduled activities then the results should also appear in the MIR reporting.
CSFs
Use by Programmes and Projects of CMDB for feasibility studies
If usage is the norm then Configuration Management or SACM has achieved a great deal and is where it should be. (Of interest Operationally - for workload, Tactically - identifies potential need for additional input from project or programme resources, Strategically - is the service model effective and efficient)
Approaches for information from internal or external (supplier) business account managers in reviewing new ideas and the potential cost involved
This is a further example that indicates the credibility of the data. (Of interest Operationally - for workload, Tactically - identifies potential need for additional input from project or programme resources, Strategically - is the service model effective and efficient).
Numbers of Ad-Hoc report requests
This is part of the virtuous circle where the quality of the information from Configuration Management helps to sell the need to provide good information in return. (Of interest Operationally - for workload, Tactically - identifies potential need for additional input from project or programme resources, Strategically - is the service model effective and efficient - should resource by allocated to enable divisions within the organisation to better understand and access CMDB Data - the potential value of investing in a read-only portal with access to specified fields etc).
KPIs
Reporting Items 3, 4, 5 and 6 from above
A direct measure that will indicate part of the workload of the CMDB team (Operational)
Size of backlog of CI's for updating.
A direct measure of the workload (Operational and Tactical)
Numbers of exception reports from each areas - how quickly corrections are made, number of Service Improvements where the reports indicate a process delta. (Operational, Tactical and Strategic) also a measure of CSI's aimed at Configuration Management and SACM
About the Author: "Colin Mayers is the Managing Director of Mayers Consulting. Colin operates across all market sectors and provides a wealth of experience with regards to Service Management. As for formal qualifications he holds the ITIL Managers Certificate, ISO20000 Internal Auditor and Consultant Certificate and also the Prince 2 Practitioner".
Please Note - ITILnews will be delighted to receive your comments on the above article or anything you wish to discuss just simply complete the "COMMENTS" section below...