Chapter 15
Ten Key Bits of ITIL: Some Possible Quick Wins
In This Chapter
Identifying your customer’s needs
Getting a basic agreement in place
Seeing the benefits of a service desk
Knowing how to deal with incidents and problems
ITIL is great, but you can easily be put off by the size of it: five publications describing more than 20 processes. Whether your organisation is big or small, each ITIL implementation comes with its own difficulties. You have to start somewhere, and I’m a great believer in keeping things simple. Yes, planning is important, but you don’t want to fall into the trap of analysis paralysis and end up doing nothing. One thing you can do to get your spirits up is to identify and implement some quick wins – things that are relatively easy to do and that get visible results, keeping stakeholders happy.
Implement the suggestions in this chapter as soon as possible. Say when you’re going to do it, do it, and then publish the results.
Implementing Basic Service Level Management
If you don’t know what your customers need, you can never know whether you’re meeting their needs. It’s like fighting in the dark. You can never be right. (On the other hand, you can never be wrong – some people find this prospect attractive, but your customers won’t be impressed.)
Service level management is, pretty obviously, the process that manages service levels. The process tries to set up a proper relationship with your customers and understand their business needs. Of course first you need to know who your customers are. If you’re the internal IT department that provides IT stuff to other people and departments within the same company, your customers are the business unit managers or department managers. If you’re a commercial IT services company providing IT services to other companies in exchange for money, your customers are those other companies; usually there is an assigned representative who talks to you.
To implement service level management:
1. Set up a dialogue with your customers.
2. Find out what they want.
3. Agree with them what you can provide (see the next section on service level agreements).
4. Monitor and report on what you’ve achieved.
If you haven’t done this before, you’ll be surprised at the difference simply starting a dialogue with the business makes. In some cases the business will be amazed that you bothered to talk to it. If you’re open and honest and state your intentions up front, your customers will be happy to talk to you.
ITIL also defines the process of business relationship management and the role of business relationship manager. The service level manager defines, agrees and reports on the service level for specific services – the business relationship manager maintains an overall relationship with the customer, keeps in contact, and looks for new opportunities to support the customer’s needs. Many organisations combine these roles into one job description. When setting up some basic service level management, you consider which roles you need.
For more information about service level management, look at Chapter 5. For more information about business relationship management, look at Chapter 4.
Introducing a Service Level Agreement
After you work with your customers to identify their needs (see the previous section), start thinking about setting up a service level agreement (SLA) – a document that contains the targets you’ve agreed for your IT services, covering such things as:
When the service is needed
How long it should work for without failure
How long you should take to fix it
How fast it should work for a given number of users
You can’t do everything all at once. Who knows whether you’ll be able to achieve the service levels that your customers ask for? In the first instance, you can set up a single blanket SLA that just indicates your intention to control the level of service you provide. Something is better than nothing. Measurement and reporting are essential to building up an understanding about what you can achieve. So, on the assumption that you have no SLAs in place at the moment, set up a basic SLA and start measuring the actual service levels. Then set up regular meetings with each customer to report your achievements and discuss whether you’re improving the services and support that you provide. Now you can improve your SLAs.
For more information about SLAs, look at Chapter 5.
Creating an Operational Level Agreement
The previous section covers SLAs, but you can’t set these up in isolation without getting some commitment from the rest of the IT organisation that the service levels are achievable and the resources and willingness to meet service levels exist.
An operational level agreement (OLA) is an agreement between the service provider and another part of the same organisation. For example, the IT manager may have an agreement with the server team that commits it to meeting targets for the availability and performance of the server equipment in its care. Similarly, the IT manager may have an agreement with the service desk that gives it targets for picking up the phone and dealing with calls.
Make sure you involve IT staff in deciding what is needed to agree to service levels with the business, and what is achievable. Staff are more likely to agree to the targets in the OLAs if they were involved in setting them up.
For more information about OLAs, look at Chapter 5.
Setting Up a Service Desk
The main purpose of a service desk is to provide a single point of contact for users – someone for them to contact about IT issues.
In some companies the users don’t know who to contact, so they just ring any phone number that gets them through to an IT person. This person is probably not the right one to deal with the query, and doesn’t want to talk to the user, who is interrupting other work.
Nowadays, many organisations have set up a point of contact for IT, but if you haven’t, you’ll find it a very powerful thing to do. The users like it because they know who to contact. Your IT staff like it because they don’t get interrupted so often. And you can be more confident that issues will be dealt with in a consistent manner.
When setting up a service desk, make sure you understand the business needs and priorities. Setting up the service desk in parallel with setting up service level management is a good idea. Through service level management, you get an understanding of which incidents need to be fixed first and how long it should take.
Head over to Chapter 3 for further discussion on the service desk.
Cataloguing Services
A service catalogue is a catalogue of the IT services that your IT organisation provides to its customers. In its most basic form, it’s simply a list of the IT services, usually by application name or however they’re known to the users and most other people.
Setting up a service catalogue is the first step to understanding your priorities. After you list the services, you can start to identify how important to the business each one is and attribute a level of criticality. This helps when you start to negotiate service levels with the business and agree response times for recovering services.
You can find more about service catalogues in Chapter 5.
Establishing Some Basic Change Control
Don’t shoot yourself in the foot! Many IT service failures happen because somebody changed something and messed something else up in the process. This often happens because of a failure to sit down and think about and plan the change, giving careful thought to the repercussions.
Implementing a basic change management process can save your IT organisation a lot of embarrassment. As ever, you will get resistance from both inside and outside the IT organisation. But if you keep the process simple to start with and have a good justification for doing it, you can start to get things under control.
I explain change management in Chapter 7.
Knowing the Difference between Incidents and Problems
An incident is an unplanned outage, and a problem is the underlying cause of one or more incidents. Understanding this distinction can really help to make a difference to the way your users perceive the support they get from the IT organisation.
Users get frustrated if they have to wait around doing nothing because some techie guy is diligently trying to get to the bottom of an incident without first getting the user up and running. Equally, users become just as frustrated if an incident continues to recur on a regular basis and the IT organisation appears to be doing nothing.
The IT organisation must get the balance right. Through the incident management process, the service desk (not got one? head to the earlier section ‘Setting Up a Service Desk’), possibly with the help of second-line support, deals with the symptoms of the incident and restores the service to the user. The user may well be happy for the incident to be closed. The IT organisation now has an important decision to make. Should it:
Close the incident record and do nothing about the incident until it happens again?
Raise a problem record and start to investigate the underlying cause before further incidents create more business impact?
Getting your support staff to differentiate between incidents and problems and deal with them differently is relatively simple to do and it creates results that people notice.
Chapter 8 covers incident and problem management.
Measuring Your Achievements
Measurement and reporting are essential to building up an understanding about what you can achieve. However, many organisations that have not yet adopted ITIL or service management practices don’t know how well they’re performing. You can easily assume that you’re performing badly, or well, when the opposite is true. One of the first things to do when you want make a difference is to start to measure the level of service you currently provide.
Keep it simple to start with. For example, you can probably estimate how much time is lost due to IT failures – I’m sure you have a log of significant outages. If you add up the time and compare it with the amount of time you claim that your services are available, you can come up with a rudimentary service availability percentage. It may not be a measurement you want to share with your customers yet, but it provides some sort of benchmark.
When you start to discuss service levels with a customer, even the most rudimentary measurement gives you some idea of what you can achieve and can become a starting point for negotiations.
After you build up a history of the measurements of your service achievements, and you start to get things right and begin to meet the expectations of the customer, the time may come when you want to shout it from the rooftops.
Gathering Tools
What do I mean by tools? Well, I’m referring to IT using IT in order to deliver IT. All the IT staff who manage and deliver the services use IT. I expect you have a PC, and that PC has software installed that you use in your job. You may use a word-processing package to create a policy document, or you may use a call-logging software tool to record incidents reported to the service desk. Many different types of tool exist of varying complexity.
You hear a lot of talk about integrated service management toolsets – sets of software applications that support your service management processes. Such things sound very grand, and if you’re in a large organisation going for service management in a big way, you will find acquiring such tools is beneficial. But you don’t have to buy these straight away. Use basic tools to help you understand your needs, and then you can move up to more ‘grown-up’ tools as things develop. If you’re just starting out to try to improve your IT services, basic tools like a spreadsheet or simple database to log service desk calls are a good start.
Make good use of what you’ve got. Every organisation has an email system. Many of these have extra functions that allow you to create forms that can be filled in and sent to email addresses. You can use this as a basic process flow engine for circulating incident and problem details to support engineers. Similarly, you can use forms to circulate requests for change (RFCs) for review.
A quick search on the Internet for service management tools, using your favourite search engine, will yield a long list of websites, white papers and general help to get you started.
Getting Your Staff ITIL Trained
Considering this book is written by a training consultant, I’m bound to recommend training. But training is the right and proper thing to do. Plus staff can receive training in so many ways. You don’t have to stick to classroom training – many different computer-based training options are available.
In Chapter 14, I describe training as one of the ten ways to get ITIL to work for you, so I won’t repeat myself here. But training is also a quick win. For a small amount of investment you can demonstrate your commitment to making a difference by arranging some ITIL training. The philosophy of ITIL is really quite simple but not always obvious unless time is taken to explain it to staff. Sending as many of your staff as possible on some sort of ITIL training course ensures that everyone has the same view of what you’re trying to achieve. In addition, if you send them on a foundation course, they obtain an industry-standard qualification (hopefully).
Have a look at Appendix A if you’d like to find out about the ITIL qualification scheme.