The (Ongoing) Evolution of the ITIL Request

Two years ago, we looked at the evolution of the ITIL Request here on ITSMWatch. Since then, discussions on my blog have reshaped some of the ideas. Let's revisit them:

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

In ITIL v2, Incident Management became a recognised process. (Whether or not this is a correct use of the word process is a discussion for another day). Mentioned in passing was the possibility of a call being a Service Request rather than an Incident, at which point the process branched to ... well, nothing. The Service Request branch hung into space, dangling wires and reinforcing steel into the void. Service Request process was never defined.

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.

v3

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.

New Taxonomy

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:

Action -

Provisioning

Booking

Ordering

Change

Work