Neven Zitek Within the previous article ITIL CSI 7-step improvement process: What is it all about? we gave general information regarding the core of the ITIL CSI: 7-step improvement process. In my honest opinion, this process is the main driver within the Continual Service Improvement (CSI) part of the service lifecycle, and therefore, it deserves much more attention than it currently gets. That is why, for this week’s article, we’ll explore data gathering steps and follow up with the data processing, data analysis, presentation, and actual correction implementation.
Figure 1: 7-step improvement process (steps marked blue are covered within this article)
Step 1: What should you measure?
Due to both horizontal and vertical involvement in business processes, there is a general belief that IT simply knows what customers want or need. At the same time, IT handles vast amounts of data; therefore, this step is often skipped, as IT incorrectly concludes that there must be data needed for CSI activities.
As CSI is all about (re)aligning delivery of IT services with business requirements / expectations, there is a great chance that current data collected is not of much use for CSI activities. Therefore, within the first step, it’s extremely important to define in simple terms which information will be useful. In order to find that out, you should ask yourself: What is the problem we are trying to resolve?
In order to find an answer to that question – just talk to the business. From my personal experience, even when you deliver services right down to the letter as defined within the SLA, sooner or later cracks will begin to show. Generally, it starts with seemingly small things (someone had e-mail issues three times this month), and gradually, it may escalate to more serious issues (management introduced a new business process that is heavily dependent on e-mail, but IT wasn’t aware).
When talking to a business, try to identify and link its corporate vision, mission, goals, and objectives. This should be compared with IT’s own mission, goals and objectives, critical success factors, service level targets, and, of course, job description (and requirements) for IT staff.
Step 2: What can you measure?
Disregarding the size or core business of your organization, there are always limitations on what can actually be measured. It was mentioned before, but allow me to mention it again: if something can’t be measured, it should not be part of the SLA. When defining measurement capabilities, make a list of service management tool capabilities, monitoring tools, reporting tools, or others currently in use.
Look into all current processes, procedures, and work instructions. Can you identify information flow? Which reports are generated, who is generating them, on what input and basis, and who is getting them? This information, along with measurement capabilities, will give you a pretty clear picture regarding the information currently available for CSI initiatives.
Perform a gap analysis between what you want to measure, and what you can measure, and if needed, present this information to the management in order to introduce new measurement capabilities.
Step 3: Gather the data.
Now that we’ve identified measuring points, and hopefully have measuring capabilities in place, the data gathering stage is mostly executed automatically by using appropriate technology. However, there still might be some manual work, such as report review, or similar.
The emphasis of data gathering for CSI initiatives is not on real-time monitoring, but rather on service or process effectiveness and the long-term sustainability of it. The focus of CSI is mainly on exceptions to and deviations from what is expected, and agreed targets set by the SLA, OLA, or underpinning contract.
Even though exceptions are in focus, they are not the only thing CSI is interested in. If your SLA is consistently met over time, CSI may investigate possibilities to optimize the current mode of operation, which will keep the performance level, but reduce the cost of operation. This can be achieved by introducing new technology, process compliance evaluation, and value evaluation (is there any difference in output by doing things differently).
Long road ahead
When the focus of an IT organization is solely on operations, incident management, request fulfillment, and technical management can overwhelm any organization. In technically coherent organizations, even change management can be neglected. The data gathered is mostly component based, and heavily dependent on monitoring tool capabilities.
CSI can rarely use such raw data; therefore, it’s extremely important to make the necessary preparations and define what data you need in order to make proper analyses based on set goals. In the next article, we’ll continue with data processing and data analysis, and the importance of the right sets of high-quality data will be clearly visible.
Some may argue that the first few steps of the CSI 7-step improvement process are a waste of time, and we should take the data we have and simply process it and move on. While this may be a shorter road, it won’t get you very far.
Check out the free ITIL Gap Analysis Tool to see how the processes and activities you measure fit with your measurement targets.
