The (Ongoing) Evolution of the ITIL Request
Lets elaborate a little on what some of these mean:
Provisioning: User requires access to a service or part of a service, e.g., a security permission, a menu option, a token, a digital certificate, a client install, a desktop device, a phone, etc.
Booking: Scheduled attendance at training, seminar, meeting, reservation of a resource, annual leave.
Ordering: Books, desks, catering, stationery, travel.
Change: as defined by Change Management, typically means change to a configuration item (CI). Some organisations allow users to open RFCs directly, others have some form of prior request entity.
Work: tasks that falls outside change management. Run a report. Move a PC. Install a projector.
Incident: an unplanned interruption to an IT service or reduction in the quality of an IT service.
Fault: failure or detected imminent failure of a CI; no service impact (yet). Only users within IT would be expected to report these, or an automated tool. If confirmed, it will spawn a Problem. This class was much debated on the blog. An Incident is by definition something that has already impacted the Service, a Fault hasnt. Both have varying priorities and urgencies and impacts. But the processes differ. If you are uncomfortable with this, ignore me and treat Incident and Fault as synonyms. Twelve is a nicer number of classes than 13 anyway.
Help: correcting data arising from user error (NOT from a Problem). Restoring a deleted file, untangling a mess.
Advice: how do I ? Should I ? Which is the best way to ?
Proposal: the service desk can be a front-end to the demand component of project portfolio management. Think of it as a Request For Project.
Suggestion: idea, requirement, request. Something less formal or evolved than a proposal but might lead to one.
Feedback: praise, reported experience, remarks.
Complaint: poor experience. (Of course, Complaint had to be #13.)
Based on the principle of distinguishing classes by differing processes, the first three classes (Provisioning, Booking, Ordering) could well break into a number of subclasses. There are other types of contacts to the Service Desk that aren't requests at all. The classic is a follow-up on a request. Feedback that doesn't require action would also not be a request.
Once we come to see an Incident as just one class of a more general Request, then the service desks Request Management process will make more sense and map better to reality. SLAs will define responsiveness in terms of the classes of Request. (I think restoration of service should be defined as part of the Availability Service Level Objective, not the Responsiveness Service Level Objective). 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 prioritised 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. That is, we define how much resource will be assigned to it, how the communications plan changes, how escalation and supervision will be heightened, and other aspects of how we respond. We cant promise timeframes.
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 the Request. Extrapolating the trend suggests that next time ITIL is revised the Request will truly have its day.
Along with the IT Skeptic, the IT Swami is an alter-ego of the author, who resides on the IT Skeptioc Blog and offers prognostications about ITs future to the few who listen.