The Evolution of the ITIL RequestFrom no standing at all to an equal peer of the Incident, the humble Request has grown in importance with each new version of ITIL, writes ITSM Watch columnist Rob England.
In ITIL v2, Incident Management became a recognized 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 nothing. The Service Request branch hung into space, dangling wires and reinforcing steel into the void. Service Request process was never defined.
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. ITIL 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.
ITIL v4 will, most likely, I predict, finally recognise that the Service Desk deals with generic Requests/Tickets/Issues/Incoming. These Requests have multiple categories. Each category has its own 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.
The categories of request may include some or all of:
Once we come to see an Incident as just one category of a more general Request, then the service desks request management process will make more sense and map better to reality. (Certainly Incidents will have their own variant of the process with specialist activities such as Incident Matching).
SLAs will define responsiveness in terms of the categories of Request. (I think restoration of service should be defined as part of the Availability Service Level Objective, not the Responsiveness SLO). Management of Incidents (the restoration of service, incident matching) may still fall to a specialist Incident Manager, or it might be part of the role of the Request Manager.
Incidentally (no pun intended], I still encounter examples of SLA objectives for restoration of service. Outages will be prioritized based on their severity, but they will be restored as soon as they can be restored and no sooner. Priority 1 incidents must be resolved within one hour is like saying Fires must be extinguished within three minutes or Missing climbers must be found within an hour. Well find them when we find them. It makes sense to define responsiveness by severity/priority/impact, but not restoration.
From a narrow focus on restoration of service, the understanding of the service desk has grown with each revision of ITIL, and with it the importance of Request. Extrapolating the trend suggests that next time ITIL is revised Request will truly have its day.
Rob England, an ITIL professional and active itSMF member who lives in New Zealand. More thoughts from the IT Skeptic can be found at his blog www.itskeptic.org.