Home 
 1. Overview  
 What is Service Level Management?  
 Why use Service Level Management?  
 Who uses Service Level Management?  
 How Service Level Management works  
 What does Service Level Management cost?  
 2. Implementation guide  
 Define what needs to be done  
 Prepare to implement  
 Implement  
 Review the implementation  
 Implementation resources  
 3. Operations guide  
 What needs to be done?  
 When does it need doing?  
 Who does it?  
 Operational resources  
 4. Toolkit  
 Examples  
 Templates  
 5. Roles and responsibilities  
 Service manager  
 End-user representative  
 6. Review of Service Level Management  
 Recap of Service Level Management  
 Checklist  
What needs to be done?
Implement FITS processes Produce service report Review service levels
The day-to-day tasks for FITS Service Level Management link directly into the implementation of the other processes. 

In order to build on the 'guesstimate' measurements you added to the service catalogue when working through the Service Level Management implementation guide, you need to capture some real data.  A section on measurements is included in each of the other processes to help you to do this.

You will use the data you gather to create a report on the overall service actually being provided. This will form the basis for discussion and review by ICT/technical support and, eventually, end-user representatives.


Go back to Operations Guide
Implement FITS processes
If you have not already done so, you should implement the rest of the FITS processes.  Follow the links from the FITS homepage for process and implementation details:

Service Desk
Incident Management
Problem Management
Change Management
Configuration Management
Release Management
Availability and Capacity Management
Service Continuity Management
Financial Management

Produce service report
Each FITS process has its own recommended measurements.  By carrying out the full implementation and operations instructions for each process, you will collect some relevant measurements that you can use to create a service report. It is not necessary to wait until all processes have been implemented to start producing a service report - all information is helpful.  The report should include the following types of information: period of report, reactive statistics, proactive statistics and change statistics.

Period of report
State the period of time the report covers.  Reports should be regular rather than random - this helps you to interpret trends and fluctuations more easily.
Reactive statistics
Include useful statistics on the handling of incidents and requests that indicate the level of service being provided.
Proactive statistics
Include measurements that indicate that preventative action is being taken.
Change statistics
Include an indication of the number of technical improvements and new services provided in the period.

We have created a service report template to help you get started. See also our example service report

Review service levels
To start with, only those responsible for providing technical support should review the service report.  Formal review meetings with end-user representatives can come later, when you have developed a greater awareness of the level of service being provided. It also allows the process to become familiar to a small group before it is widened to include more people.

Use the information in the service report to identify potential issues and areas requiring further investigation.  Monitor trends over a period of time and look for fluctuations.  Remember that it is dangerous to take statistics at face value, as there may be many possible reasons behind them.  Here are some examples of the variety of possible answers (the list is not exhaustive).

Trend
Some possible causes
Action required
Increase in incidents
  • A major incident occurred, affecting a number of users.
  • A newly introduced service was not rolled out successfully.
  • All incidents were not previously being logged.
  • Check incident logs for unusual occurrences or similarities.
  • Check recent release and change activities.
  • See Incident Management, Change Management and Release Management for further guidance.
  • Increase in number of changes implemented
  • More underlying problems had been identified, resulting in improvements being made.
  • Changes carried out were not well planned and had to be re- implemented.
  • Changes were not previously recorded.
  • Check problem records.
  • Check requests for change.
See Problem Management and Change Management for further guidance.
Top