The (Ongoing) Evolution of the ITIL RequestFrom no standing at all to an equal peer of Incident, the humble Request has grown in importance with each new version of ITIL, writes ITSMWatch columnist Rob England (a.k.a., The IT Skeptic).
In ITIL v1, there was no recognised process for Incident Management, just a function called Help Desk, which was responsible for first level incident support, advice and acts as a day-to-day contact point for users of IT services. So, only Incidents were recognised as a processed object
What came first was never defined either. When someone calls, is the call an Incident until proven to be a Service Request? Or is it a Request until it reveals itself to be an Incident? Or is it something else (a call, a contact) until it yields to classification? This was left to the implementers (or software vendors) to decide.
Now ITIL v3 elevates the Service Request to equal billing with the Incident. In fact, if importance can be measured by number of pages then Service Requests get slightly more of the Peas Book (Service Transition) than Incidents do.
This is a great step forward but I believe it is not the final word. v3 still delineates between Incident and not-Incident as the two categories. That is, Service Requests are some kind of miscellaneous category for everything that is not actually an unexpected interruption to service. The two processes are quite separate. This does not fit well with my experience of reality. Admittedly, my reality has a few kinks, but in this case I speak on behalf of clients who feel the same way. For many service desks, Incidents are not the main part of their function.
I predict that ITIL v4 (if there is one) will finally recognise that the service desk deals with generic Requests/Tickets/Issues. These Requests have multiple categories or classes. Each class is a variant of a more general process that applies to all of them, in much the same way as there are several categories of Change, which all undergo variants of the general Change process.
I published a list in the article two years ago. Since then, I realised that the list had missed one―Fault. So, I thought I'd update the list for you. This revised list is constructed based on the concept that each class of request exists because it is a variant of the core Request Fulfilment Process, e.g., Complaints will be dealt with differently to Proposals. Different people and groups, different procedure, different reporting, different service levels. That is, I derived the different classes or categories based on the process being different. If two types of request use the same process then I decided they are synonyms.
After discussions on the blog, I also decided they needed to be re-grouped into a newly named hierarchy. I came up with three groups:
Action: I'd like to say Service but man is that an exhausted word!
Support: not everything will be/needs to be fixed so not Repair
Input: the user is contributing
Here is my taxonomy of these new Request classes: