News, Reviews and Resources for ITSM Professionals.

Request Fulfilment in ITIL 2011

Home » Featured, Practices » Request Fulfilment in ITIL 2011

"ITIL 2011 sees a hefty revision for the Request Fulfilment process."

What is it?

The ITIL® Request Fulfilment process exists to fulfil Service Requests – for the most part minor changes or requests for information.

Request Fulfilment landed on us in ITIL v3 when there was now a clear distinction between service interruptions (Incidents) and requests from users (Service Requests for example password resets)

And what does ITIL 2011 give us?

ITIL 2011 sees a hefty revision for the Request Fulfilment process.  There are more detailed sub-processes involved with steps broken down logically.

Now, I like me a good diagram and finally Request Fulfilment gets a decent flow and most importantly the linkages to other interfaces to the other lifecycle stages are included in a lot more detail.

Perhaps the most impressive thing is far more detail in the section about the Critical Success Factors (CSFs) and Key Performance Indicators (KPIs) that have been included.  Having experienced the hilarity of definitions of over-complex metrics – this is a good starter for 10, straight off the bat and of course can be added to suit an organisation’s needs.

But what does all this REALLY mean?

It means nothing if the best practices cannot be applied and adapted into real life.

  • Now we all know that at the back of a Service Request is a process that will step through authorisation, any interfaces to other processes etc., but the business value is to provide a quick and easy way for end users to get new services.
  • A mechanism to reduce costs through centralising functions.
  • Understand what other stages of the lifecycles are needed alongside Request Fulfilment – this does not happen in glorious isolation.

Is there such a magic bullet?

The simple answer?  NO!

But there are a few things that should be taken into consideration when looking at implementing Request Fulfilment (often as part of an integrated solution).

Let’s look at the easy stuff first:

  • Look at starting nice and easily with simple Request Models that will happen often, and can be met with a consistently repeatable solution.
  • Look at what kind of options you are going to put in front of the user.  Most people are now familiar with the type of shopping basket type approach through the internet so offer them a familiar interface, with as many options that can be pre-defined
  • Make sure that the different stages of the request can be tracked – the purpose is two-fold:
    • End users don’t get (as) ratty
    • Reporting and routing can be made simpler and more accurate with meaningful status definitions

Getting the hang of this…

  • Give some thought to how you want to prioritise and escalate requests depending on their complexity to fulfil, and again pre-define where possible.

Let’s do the whole shebang…

  • Eventually there will be a need to include financial approval(s) which in turn means sticky things like deputies and budget limits
  • There may also be external interactions with fulfilment groups dealing with procurement

Back up a second – who now?

  • Give some thought to which groups are going to be involved.  In my experience it is sometimes easier to work backwards, from the outcome to the selection and fill out all the bits you need in between.
  • Easy stuff is most likely taken care of by a single, often centralised group – typically the Service Desk, or in some cases specific co-ordinators who work at that Level One tier.
  • Decide if your existing resolver groups are appropriate for some fulfilment tasks or where you need specialised groups and build your workflows to suit.  Typically the first-line support group handling the request always has the ability to track the progress of the request, and is the point of contact for the end users.

Is that it?

  • Whether your request is a simple How Do I to a Hand craft me a personally engraved and gift wrapped iPad the request needs a defined closure procedure.  There has to be a mechanism to validate that the request has been fulfilled satisfactorily before it is closed.

How do we go about deciding what works and what doesn’t?

There is something I will state, use and promote constantly, and that is the use of scenarios.  These are invaluable whether you are testing a deployment, performing user-acceptance testing with a client, or whether you are just evaluating products.

  • Decide on what criteria you need to establish your end goal
  • Break them down to manageable steps, and here the ITIL 2011 activities and points are very nicely presented to give a starter for ten
  • For a product review, for example, look at how easy it is to configure – can I do this myself using demos on the web, or do I need a proper demo on site/webinar with a tool administrator
  • As an aside, what kind of administrative skill is required for your tool of choice?

This is a doddle, no?

A number of things can kill an otherwise promising and/or straightforward deployment:

  • Poorly defined scope – People wanting the process to do too much or not really grasping the idea that Service Request models should be pre-definable, and consistently repeatable.
  • Poorly Designed User Interfaces – The best back end workflows in the world will not help you if the user interface makes no sense to an end user.  Too often I have banged my head against a desk with developers who love how THEY understand what is being asked, so who cares if some desk jockey can’t – they can ring the help desk, right?  WRONG!  Missing the entire point of the business benefits for removing the need to drive everything through 1-2-1 service desk interaction.
  • What is worse than a front end you need a degree in programming to work through?  Haphazard back end workflow that twists and turns like a snake with a stomach upset.  Just keep it simple.  Once it starts to get super-complex, then really ask yourself is this a minor request or something that requires specific change planning.
  • Make sure your tool of choice is capable of measuring meaningful metrics.  Remember, there are lies, damned lies and statistics.  What are you looking to improve, why, what is the benefit, and what can it lead to in terms of Continual Service Improvement

There are, of course, interactions that I haven’t gone into any great level of detail in this article; but do look at one of our latest articles by  Rob England has already touched on this in: What is a Service Catalogue? here on The ITSM Review.

Image Credit

Ros Satar

Ros Satar is a Blogger and Analyst for The ITSM Review. Her journey in ITIL/ITSM began in 2005 when she jumped into the deep end of Configuration Management. When not knee deep in paper and having a love/hate relationship with her many gadgets, she can be found putting in time at various sporting publications.

More Posts - Website

Follow Me:
Twitter