Step 5: analysing the data

We're making progress... It's time for some self gratification.

Data analysis is where the information is transformed into knowledge of the events that are affecting your organization. It takes more skills and experience to perform data analysis than data gathering. It's not only a matter a reporting and producing graphs but also to document observations and conclusions.

Questions that will drive this analysis exercise:

• Are we operating according to plan?
• Are we meeting targets?
• Are corrective actions required?
• What is the cost of the service gap?
• Are operations running according to plan?
• Are targets defined in SLAs or the Service Catalogue being met?
• Are there underlying structural problems that can be identified?
• Are corrective actions required?
• Are there any trends? If so then what are the trends showing? Are they positive trends or negative trends?
• What is leading to or causing the trends?

Proper analysis on the data places the business in a position to make strategic, tactical and operational decisions.

Step 4: processing the data

The main goal now is to convert the data from step 3 to an appropriate format for the required audience.

Report-generating technologies are typically used at this stage as various amounts of data are condensed into information for use in the analysis activity.

Usually the best approach is to report the data into logical groupings, keeping in mind that what's important to show is the overall performance of a service.

Indeed, while monitoring and collecting data on a single component is important, it is key to understand the component’s impact on the larger infrastructure.

If you are hosting a merchant site, having 5 nines on your database availability (over a reasonable amount of time) is an accomplishment. But this really makes sense from a customer's perspective if the other components of the infrastructure have reached the same availability (web servers, DNS...).

Step 3: gathering data

Gathering data requires having some form of monitoring that keeps quality as the key objective.

The emphasis is not on assuring realtime service performance, rather it is on identifying where improvements can be made.

This been said, the Continual Service Improvement process is unlikely to need, or be able to cope with, the vast quantities of data that are produced by all monitoring tools and you'll have to focus on a specific subset of monitoring at any given time.

Keep your monitoring plan dynamic and pointing to priorities, you may need to investigate an activity one quarter and a completely different one the quarter.

Let's differentiate 3 categories of metrics:
• Technology metrics: these metrics are often associated with component
and application based metrics such as performance, availability etc.
• Process metrics: these metrics are captured in the form of CSFs, KPIs
and activity metrics for the service management processes. These metrics
can help determine the overall health of a process.
• Service metrics: these metrics are the results of the end-to-end service.

Exceptions and alerts need to be considered during the monitoring activity as they can serve as early warning indicators that services are breaking down.

Inputs to this step:
• New business requirements
• Existing SLAs
• Existing monitoring and data capture capability
• Availability and Capacity Plans
• Service improvement plans
• Previous trend analysis reports
• List of what you should measure
• List of what you can measure
• Gap analysis report
• List of what to measure
• Customer satisfaction surveys

Outputs from this step:
• Updated Availability and Capacity Plans
• Monitoring procedures
• Identified tools to use
• Monitoring plan
• Input on IT capability
• Collection of data
• Agreement on the integrity of the data

Step 2: define what you can measure

In a perfect world, measure everything you should.
In the real world, you won't necessarily measure everything (because of staff, technical, time or even legal... limitations).

Golden rule: what cannot be measured should not be in an SLA.

After assessing the tools you currently have in place, compile of list of what can currently be measured without any tool customization.

Then look at existing reports, databases, any existing documentation and you'll be able complete your list.

A gap analysis (must have versus currently have) will tell you what set of data and what tools are missing.

Your inputs for this step:
- list of what you should measure from previous step
- process flow
- procedure
- work instructions
- technical and user manuals from existing tools
- existing reports

Step 1: define what you should measure

Day one in your new job: what should you measure? what is important to the business?

There are 2 approaches that you can combined:

1 - start with a prep work: define the VBF (Vital Business Functions) and then identify services underpinning VBF

2 - utilize the existing Service Level Agreements

Don't underestimate the measurements implementation effort and don't go into too much details. Keep it simple to start with.

Other input sources:

• Service catalogue
• Mission statement
• Department goals and objectives
• Legislative requirements
• Budget cycle
• Balanced scorecard

In small and/or young structures, those inputs may be missing but this should not impair the process per se (it will limit how far you can go thought).
This being said, a complete service catalogue is a must-have / must-build.

Heptalogy to come

Today my friends, we are learning a new word together (my bad and congrats if you already knew it): heptalogy.
It has nothing to do with ITIL, it is a set of seven works that are connected by a common storyline.
No Harry Potter here, in the next 7 posts (heptapostology???), we'll talk about the 7 steps of Continual Service Improvements:

• 1/ define what you should measure
• 2/ define what you can measure
• 3/ gathering the data
• 4/ processing the data
• 5/ analyzing the data
• 6/ presenting and using the information
• 7/ implementing corrective action

Service Improvement was already a key process of ITIL v2. In v3, it is one of the ITIL book by itself.
Enough teasing!

Building the Service Desk

Today le'ts talk about CMDB and ticket tracking systems solutions.

A CMDB is the first stone of a complex structure you are building, so don't look at it as a standalone piece, but as the keystone all your future processes will rely on.

Some leads to choose an ITIL ready, or evolutive, or open-source CMDB :

• OTRS (the number one is this list had to be an opensource)
• EverDream (a DELL product)
• SiteHelpDesk-IT (with some 17799 compliance)
• Tracker Suite for IT
• Parature Help Desk
• Computer Associates Unicenter ServiceDesk
• Symantec Altiris Asset Management & CMBD