Introduction
Originally from 2012 this is a republishing of our archive as we move fully to this platform.
One of our latest assignments was to bring Service Management to a procurement department as part of an initiative to improve their processes and decrease costs.This meant we had to be rather inventive in adapting traditional IT-based Information Technology Infrastructure Library (ITIL) processes to a department whose IT is handled elsewhere. This was most noticeable when creating the Service Asset and Configuration Management (SACM) process. This process is the one that underpins the other ITIL processes, providing data to Request Fulfilment, Incident Problem & Change Management, as well as higher order Service Catalogue & Service Level Management. Ultimately, it gives an organisation the ability to identify the costs of a service, reduce those costs over time by optimising Configuration Items (CIs) and providing proper stewardship of the assets that are under the control of the service provider.
Let’s face it, a lot of companies get hot under the collar about SACM. They initiate major projects to create vast technically-focused Configuration Management Databases (CMDBs) that no one uses because the data is either so detailed, it becomes impossible to keep it up-to-date, or is so technical that no one understands it.
This was a particular issue for our client who had multiple copies of the same data on spreadsheets, with multiple versions of the same information on various servers located in different countries. This had resulted in the copies going out of sync and disputes about which version was correct. Without establishing a Single Point of Truth (SPoT), this was not something that would be resolved easily. Mistakes were being made based on the false data with a substantial financial impact.
ITIL Structured Approach
A solution was needed that utilized ITIL Service Management standards and the technology already present at the site, was easy to use and would be maintainable over time and gave them a SPoT. We took a structured approach to build a process that would meet the requirements of our client and follow the standard ITIL SACM model:
- Management and Planning – The management team and configuration management decided on what level of configuration management was needed and how this level would be achieved, and documented this in a Configuration Management plan
- Configuration Identification – Configuration identification focuses on establishing a Configuration Item (CI) classification system. Configuration identification determines: the configuration structures and selection of CIs; the naming conventions of CIs; the CI labels; relations between CIs; the relevant attributes of CIs; type of CIs; etc.
- Configuration Control – Configuration control is performed to ensure that the CIs are adequately controlled. No CIs can be added, adapted, replaced or removed without following the agreed procedure
- Status Accounting and Reporting – The lifecycle of a component is classified into different stages. For example: development or draft, approved or withdrawn. The status that different types of CIs go through must be properly documented and the status of each CI must be tracked
- Verification and Audit – A Configuration Manager must conduct audits to ensure that there are no discrepancies between the documented baselines and the actual situation. And that release and configuration documentation is present before the release is rolled out.
How We Planned and Implemented the Solution
Management and Planning – Rummler Brache and RACI
We commenced Management and Planning by building a Rummler-Brache swim lane flowchart to detail the workflow and a RACI matrix for the process. The former enabled us to see how many roles would be needed for the process and the steps each role would perform, which is vital to planning the implementation. The flow chart let us see when an activity in the process moves between roles and tells us how to record the process states.
Through codifying the flowchart into a spreadsheet, we could determine the major activities and the subsidiary tasks, as well as describing each task in detail. This formed the basis of implementing the process in the system and the skeleton of the user manual. Each process we developed at this site not only has a Rummler-Brache flowchart and process spreadsheet, but also a user manual showing how the process is implemented at the user level in the relevant systems.
Configuration Identification – Workshops
Then we started on ‘Configuration Identification’ which has a special meaning at this particular site. Configuration Identification incrementally establishes and maintains the definitive current basis for Control and Status Accounting (CSA) of a system and its CIs (see Configuration Items above) throughout their life-cycle This client was using ITIL Service Management techniques to improve their procurement business processes. Therefore, simply taking a standard configuration database model was not going to be appropriate because the items they needed to track were not typical IT ones. The solution was to run a series of workshops with the service experts to determine the important configuration types for the teams within the department. We used the metaplan technique to coax this information from the teams that were going to use the CMDB. Once we had determined the CI types, we built a database model showing how each CI type is linked. We identified who would be the Configuration Owner for each service, normally the team leader responsible for processing the particular business process.
Then we took the existing systems’ CMDB model and modified it for the procurement configuration types. The ticket system we were using, OTRS, is very flexible and lends itself to customisation. This flexibility meant that the amendment of the configuration types, from the out-of-the-box, standard IT ones to those more appropriate to the procurement environment, was quite simple. This is one of the major selling points of this open source system. It took less than a week to complete this reconfiguration.
Configuration Control – Senior Management Commitment
Next we set up a means of Configuration Control to evaluate all change requests and change proposals, so that we could control all the modifications to the system’s design and documentation. This allowed us to ensure that the CMDB was populated with relevant data. It was vital that the importance of this task was communicated to all members of the team working on the site. Therefore we arranged presentations explaining the configuration process and the importance of the configuration data to the company. We ensured that the profile of this task was given full backing from senior management, and assigned the accountability for the completion of the data to a Configuration Manager whose task it is to ensure the data gets added to the CMDB by the relevant team members. Deadlines were given, the data collected and entered. The Configuration Manager was trained in the process of recording and reporting CIs and all departures from the baseline. Should he suspect problems, the baseline configuration and approved modifications can be quickly determined for verification.
Status Accounting and Reporting – CI Exceptions
During the Configuration Identification phase, we established the Status Accounting and Reporting model and developed a series of reports to assist the Configuration Manager. The first two reports:
- CI Type Exception Report: a list of which CI types are missing per service
- CI Attribute Exception Report: a list of which CI attributes were not completed per service
This enables the Configuration Manager to identify those CIs that are not being addressed at all, as is often the case. Too often a CMDB is created, initially populated and then not used. Sometimes, as new services are added, the CMDB is not updated and these reports show when this happened.
We also wanted to show the management progress of the Configuration Owners and Configuration Manager in completion of the data, therefore we developed two more reports:
% of Missing CI Types: a report to identify how each service, or rather Configuration Owner, is performing in terms of creating their CI types
% of Missing CI Attributes: a report to identify how each service, or rather Configuration Owner, is performing in terms of completing their CI attributes.
These show us the baseline status of the completeness of the data and enable us to report to management areas that needed addressing.
The system itself shows the status, i.e. Development, Production or Retired, of the services for each configuration. We also generated reports to show the weekly change in this status as a whole and as a percentage of the number of CI types and CI attributes.
Once we had these base reports, we could generate the appropriate Critical Success Factors and Key Performance Indicators. These were monitored in the weekly management meeting and appropriate action taken.
Verification and Audit – Future Proof
Finally, we ensured that Configuration Verification and Audit would be carried out once a quarter. Stale data is one of the biggest issues in Knowledge and Configuration Management, and it is important that this is addressed in the last step of the process. This is achieved by identifying the CI types that have not been changed since the last audit three months previously. The Configuration Manager is then accountable for investigating the reason for this lack of update with the relevant Configuration Owner.
Adaptable ITIL Service Management
This blog post shows that Configuration Management is possible in any environment and that ITIL Service Management is easily adaptable. A SPoT can be created easily in OTRS, enabling the easy identification of key configuration items for all dependent processes
To find out more about our expert consulting services either:
- Complete the contact form
- Contact via Linkedin https://www.linkedin.com/company/pdca-consulting
- Call +49 172 579 4719
- Scan the QR Code for later
