ITIL Topic Covered:
Service Level Management

In the first blog covering Service Level Management, we looked at the concept of the service catalogue and I also left you with a couple of tasks to uncover the current support of your services.

The following is an extract from that blog:
For those with support contracts – do not read the contract at this point! Write out what level of support you need and think about how many times the system has failed (if possible try to identify the number of hours/part hours over the last 6 months). Once you have that information, review your contract against your needs and if availability figures are quoted, check these against your real service availability.
For those without support contracts once again write out what level of support you actually need (eg do you have a payroll application you bought from PC world 3 years ago and if it went wrong, how quickly would you like it fixed – forget about the how and who for now….)
This exercise will identify two things:
1) You will get an understanding of what is important to your business
2) You will understand how your current suppliers are performing and if their cover is sufficient as well as spotting your weak areas of unsupported services

Now hopefully, this either left you very happy or very concerned. So now, how do we go forward?
Well the best way to approach this is to think of your self as an internal department, writing an agreement to all of the users about the level of service they are going to get. Hopefully this exercise will start you looking at your systems in a new way and give you a starting point to review your current suppliers. Next, ask yourself if you are meeting their expectations or leaving them exposed?
Let me explain the end game…… the first exercise has come up with a service definition document for each of your services. This list’s your staff’s needs. It has also identified any suppliers that are not performing (task – sort them out!). You also have a list of unsupported areas (task – decide if you want them covered).
So what about these two tasks?
Well what about the suppliers that are not performing? Quite simple......give them the chance to sort themselves out and if they don’t, go elsewhere. Is it that easy, well no not really as all sort of considerations need to be thought about.
1. They might be cheap and the only supplier in your budget
2. You might be tied into a long contract
3. They might be the only people to support your application
4. Their might be costs in moving away from them
5. Another supplier might be just as bad

So this is where the contract / service level agreement comes in. If you are looking to exit you might need to demonstrate a material breach otherwise just waving it in front of them and making them aware that you know what they should be delivering can be just the catalyst they need to sort their act out. My experience certainly points to a lot of companies not delivering to their contractual requirements, not because they can’t, but because their customers do not drive them to. Once you are on top of the supplier, keep the pressure on! The first time you have a problem, follow the process through, if you have a service visit as part of your contract, get them out and see how quickly they book the visit in and how they perform.
Long term you may want to switch (and we will cover that in another blog) but for now, the focus should be on making them deliver.
So what about the unsupported areas?
Well the immediate reaction will be “they haven’t been supported before so why bother paying now?” and this is a perfectly good standpoint to take. Its all about risk, cost and probability. A large organization I have worked for ran an IBM AS400 with its main supply chain AND finance/payroll system on it. It had no DR for the box and the support was office hours / 8r fix. Some of the legacy applications were written in house and had NO support. Why did they have a low level of support? Because the cost of a failure and recovery was significantly less than the cost of comprehensive cover. The key words here are “failure and recovery”. Their was a way to get the service back but it was not immediate. The non supported applications were not the critical ones and if they did fail, more modern ways of delivering the system requirements could be coded quicker that actually fixing the busted code.
So every area that was not supported was weighed up around the following questions:
1. If the business is using it during non supported hours and it fails, would it cause us a significant problem
2. If the system failed could we find a new/better way of doing it
3. Can we recover our systems even if they are not supported
For your non supported systems, you need to ask yourself these questions. If the answers leave you worried, you may want to consider some form of support.