This article has been contributed by Peter Hubbard, Principal IT Service Management Consultant at Pink Elephant EMEA and is based on a recent presentation that he delivered at the itSMF UK Conference and Exhibition.
Request Fulfilment is one of the most useful, yet underrated, areas within IT Service Management. It has been widely recognized for many years that the ‘Front Face’ of IT is the service desk, and so how the service desk performs colours the whole perception the business has of the entire IT Department.
But what is Request Fulfilment? Request Fulfilment provides a channel for users to request and receive standard services for which a predefined approval and qualification process exists. It simple ensures that each request doesn’t have to ‘reinvent the wheel’. A request model is a way of predefining the steps that should be taken to handle a process.
So how do you implement it?
Getting the basics right
The first thing that you need to do is create a Service Request Catalog. At its most basic level this is simply a list of all the Service Requests it’s possible for the business to make of an IT department.
The easiest way to do this is to ask your service desk staff, after all they spend all day dealing with these very issues. Ask them to write a list of their most frequent service requests, and use this as your starting point to turn an entry in the Service Request Catalogue into a fully mapped and automated Request Model.
The second major thing to do is to make sure that you separate your incidents from your requests in the toolset. After all, they are separate things! Telling a business that 10,000 incidents were received to the service desk sounds like the world is ending. Saying that 1,000 incidents were received, and 9,000 service requests were made for new kit is a very different story.
Build a request model
You MUST do this. Request Fulfilment without Request Models is just mucking about. The whole point of Request Fulfilment is to work out in advance the steps that are required, the information that you need to collect and when, and who performs the required actions & authorizations. This is the soul and centre of Request Fulfilment. Collecting all that information and not transforming it into a model, either as an established manual procedure, or ideally, within an ITSM toolset is just plain silly!
In order to build a request model the simplest method is to bring the people who are involved in fulfilling that request together.
Ask them to verbally walk through the activities involved using post it notes to build a basic flow on the wall. Once the steps have been agreed, and are in the right order, go back and detail what happens at each step: who does it, what information they would need to fulfill that step, any agreed timescales or authorizations required etc. I find this takes about half a day for a moderately complex request like building a new starters laptop and delivering it to them. Once you have the model capture it in a formal document (Visio flowchart with explanations is best) and then use this to configure your chosen ITSM toolset to automate the request.
Request Fulfilment is simple, but that’s not the same as easy?
Many people are often make the mistake in being under the impression that ‘doing’ Request Fulfillment doesn’t take more than a week or two, but let’s say you haves 800+ known types of service request. The rule of thumb is to allow half a day to map a request model as you work out all the steps involved and who does them. Then allow another half a day to document that flow into a format that can be saved, understood, and shown to others. Then add another half a day to put that flow into the toolset. So that 2 weeks worth of work was actually 1200 days work!
My best advice to keep things simple is to start with an easily understood, and not too complex request. Avoid starting with the ‘new starter’ request as a typical new starter request will involved multiple actions crossing HR, Security, Access Mgt, Facilities and IT. I am not saying don’t do it at all, just make sure you start with something simpler to get the feel for the process first.
The most spectacular mistake I have ever seen made with regards to Request Fulfilment was when I saw a CIO promise to his executive board that 95% of all service requests would be completed within 5 days.
It’s safe to say that I almost fell off my chair. I very quietly sidled up to him afterwards and said that it was very courageous promise he had just made…would he mind if I asked a few questions?
Question: Have you defined what a Service Request is as opposed to an Incident?
Answer: No, is that important?
Question: Have you worked out a complete list of all the types of request that you support?
Answer: Not as such
Question: What is the most common type of request you receive at the Service Desk?
Answer: A request to build a new laptop
Question: Have you worked out the steps involved in fulfilling that request and the timescales involved?
Answer: No, but I know it can’t take long to simply build a laptop!
I went off and built the request model for that request. It turned out that the process to build a laptop took 37 separate steps, across 4 teams, and went to 2 external organizations who had their own response times in their contracts. If everything worked as it was supposed to then it would take 10 days to complete the cycle. Essentially the CIO had just set himself up to fail and the board hammered him for the next 6 months every time they had a meeting.
The moral of the story? Know the steps, and timescales involved before you start committing to SLA targets!
Benefits to Request Fulfilment
I always tell people ‘never keep a dog and bark yourself!’ Most ITSM toolsets are built around perfectly good workflow engines with associated notification rules. Well… guess what…that’s how Request Fulfilment works too. You work out ONCE what a particular request needs to do, who it should go to, what they should do and so on. Then you take that hard won information and enter it into the toolset as a Request Model. From that point on the tool does the hard work for you. It moves the requests to the right team(s) automatically. It makes sure they have all the information they need on a silver platter, and it even escalates the issue to the relevant authorities if pre defined criteria are breeched.
Someone has to do all of the things I have just listed, and unless you have the tool doing it (supported by your processes of course) then your service desk agents have to do it by hand, which means you’ll soon have your agents tied up manually shepherding requests and explaining to irate users why their laptop is not ready yet. By using Request Fulfilment most of this is done for you by the tool through the Request model; although you should always make sure the final ownership of the requests sits with the service desk as normal. Trust…but verify!
A final note
Tackle Service Request Fulfilment head on. Handling Service Requests manually is major drain on your resources on the service desk at the moment and the single largest cause of user dissatisfaction.
Do comments such as ‘we never get told what’s going on with our requests?’ or “why does it take so long to get anything done by IT?” sound familiar?
Well, you can either deal with each issue as it arises on a one by one basis, or you can invest some start-up time into identifying the top 10 requests that get made to your service desk, and create them as request models. Then put them in your toolset and automate the notification and assignment rules.
Request fulfilment frees up your service desk, and technicians time from endlessly chasing their tails as they try to find out what the next step in the chain is and who they should be talking to. By automating the basics you free your staff up to concentrate on other areas of greater interest.