A list of Request Classes to help out ITIL

Recently we discussed how I think ITIL V3 muddies the definition of Incident, and of Incident Management. As part of that discussion I realised that my own list of Request classes had missed one, "Fault". That list came from my book Introduction to Real ITSM which is a satirical version. A more serious one was originally published by me in the article The Evolution of the ITIL Request on ITSMWatch.

So I thought I'd update my list.

First I went to check what else I missed.

The IT Skeptic couldn't find a good list. I did extensive research ...in the analyst's sense of "research". That is, I quickly thumbed through ITIL V3 Service Operation of course, and Foundations of IT Service Management Based on ITIL® V3 and an amazing new book The Guide to the Universal Service Management Body of Knowledge (find it here - more on that book another time).

No doubt there are plenty of lists out there (some of which I'll turn out to be in possession of), and I expect to see a few references in the comments section please.

This list is constructed based on the concept that each class will have 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 responsiveness service levels.

[Updated 20/9/2009
More discussion of this topic over here.

On reflection, I don't even think "Request" is the right word for the parent entity of which they are all categories. i think "Ticket" or "Service Response" or somesuch is a better word. Request comes from a user; Faults don't, Incidents might not, Work might not.

We use "Request" for historical reasons to mean "generic bucket for everything Service Support respond to". We shouldn't.
]

Herewith is

the IT Skeptic's Taxonomy of Request Classes

[Updated: a hierarchy introduced to the taxonomy]

  • Action
    • Provisioning
    • Booking
    • Ordering
    • Change
    • Work
  • Support
    • Incident
    • Fault
    • Help
    • Advice
  • Input
    • Proposal
    • Suggestion
    • Feedback
    • Complaint

Notes

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

  1. 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.
  2. Booking: Scheduled attendance at training, seminar, meeting, reservation of a resource, annual leave.
  3. Ordering: Books, desks, catering, stationery, travel.
  4. Change: as defined by change management, typically means change to a CI. Some organisations allow users to open RFCs directly, others have some form of prior request entity.
  5. Work: tasks that falls outside change management. Run a report. Move a PC. Install a projector.
  6. Incident: an unplanned interruption to an IT service or reduction in the quality of an IT service. (Question: if an interruption or degradation of service is within the terms of the SLA, is it an Incident? )
  7. 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 was much debated recently. If you follow ITIL then an incident and a fault are the same thing.)
  8. Help: Correcting data arising from user error (NOT from a Problem). Restoring a deleted file, untangling a mess...
  9. Advice: How do I … ? Should I … ? Which is the best way to … ?
  10. 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.
  11. Suggestion: idea, requirement, request. Something less formal or evolved than a proposal but might lead to one.
  12. Feedback: praise, reported experience, remarks.
  13. Complaint: poor experience.

Of course Complaint had to be #13. So have at it folks: what do you think?

If you found this post useful, and you are a Facebook user, please Like this blog :

Comments

Service Response

[Moved up to the main blog post above]

This is it

This new hierarchy is great. The Input-class is a good addition.

Now we need a new process to handle the requests. The new Request Management process has Action, Support and Input sub-processes. The first step is to classify the incoming requests at the highest level and start the relevant sub-process which will then do the second level classification.

Now if we just could rewrite Itil V3. The sad thing is that there are two conflicting version of the quite basic concept of incident and some of the V3 trainers do not even admit that there is a difference and those who have started with V3 do not understand that most practitioners are working with the older concepts. There has been a lot of evidence of that here in these recent discussions.

Aale

clustering of similar process steps

Aale: this indeed is a practice you can often find. Specifically when an organization has installed a single helpdesk function with a non-skilled population. Splitting off the common intake steps allows them to limit one specific process ("intake and routing") to one specific team (helpdesk). Organizations often seem to like that, avoiding the matrix organization....

As a consequence, the specs of the left-over processes will have to be cut-off at this intake phase, otherwise they'll be redundant with this singled out intake process. Removing redundancy often is the actual reason for organizatins to split the shared intake from the rest of their processes.
In BPM terms and in terms of the process model, both options are valid.

The Evolution of an Incident?

Skep

Check out George's latest post at ITSMWATCH. A plug for V3 authors that they spotted the obvious - the humble service request, and a call to keep incident, requests and events very separate. Why?

http://www.itsmwatch.com/itil/article.php/3801266

As I have posted on a separate blog - there is every reason to make an incident a type of service request, and by doing so make simpler the task of reporting the drivers for your operational workload and costs, even by customer, community and SERVICE!

It would be a life-changing event for some managers to actually be able to follow the thread of event-alert-incident-service request (to apply a modification?)... in a single service or customer specific report on service level attainment... linking the effort required to respond to perhaps customer impact, or deficiencies in service management practices.... hhmm..

One last comment - doesn't anyone recall that today's incident management practices have a large debt to pay to the California forest fires (perhaps even Auzzie ones) of the 1970s that spawned the national Incident Command System (ICS) of the US Federal Government...

A sneaky edit!

Input class? What input class? Aha! Skep has sneakily updated the original article.

And I have a comment on it. "Suggestion" is fine under the input category, but I wonder about "proposal". Defined as a 'request for project' and a part of PPM, I think it's much closer to the 'Action' class than the 'Input' class. I'm pretty sure requesters would feel that way.

Aale: trainers not admitting to conflicts or confusion within ITIL? Outrageous! :D

A fine discussion topic

Agree that everything is a request.

Agree that ITIL is shying away from defining the right amount of categories.

Agree with aroos that it needs to be structured a bit more. Here's my suggestion:

  • Request
    • Support / fix existing expected service
      • (6) Incident
      • (7) Fault (unhappy with this as it's the only case where IT staff, not acting as users, raise the "request")
      • (8) Help
      • (9) Advice
    • New stuff
      • Predefined requests (I'm not convinced that breaking these down into subtypes has process value?)
        • (5) Work
        • (3) Ordering
        • (1) Provisioning
        • (2) Booking
      • (4) Change
      • (10) Proposal
      • (11) Suggestion
    • User experience (or "other")
      • (12) Feedback (only a "request" if it requests some response)
      • (13) Complaint

And there are other types of communication that aren't requests. The classic is ... a follow up on a request. Feedback that doesn't require action would also not be a request.

simplification is good, mostly.

I quite like that list, but I'm not sure how help differs from advice, and if I was managing a contract with a supplier I would probably want to distinguish help/advice from pure break/fix. I would probably group proposal and suggestion together, and feedback/complaint (a complaint is negative feedback). Follow up requests can be significant in evaluating the quality of the service so I would include it - but bear in mind that will always link to an existing record.

A lot of tools also make use of the concept of a task as a activity that has to take place to fulfil any of the higher level 'requests' and that might be worth adding to the list of meta record types. Actually in my experience in the real world we miss the importantce ITIL places on the links between records - a call that starts off as a simple break fix can generate a problem - known error-change workflow.

Two related things that I always find it hard to settle on a definitive answer about. One is the typical small application "fault" that you either can, or have to, live with until the next major release, and the other is when the service is not operating to full specification, but the user is unaware of it. The best example I can think of is when you use a back up circuit - the service is still there but you have lost the redundancy should anything else go wrong.

A practical issue is how you record this within your service management tool - do the desk have to categorise the calls using an additional layer when they receive them or can you slice and dice the data during post event analysis.

workflow differs?

I distinguish between Help and Advice because the workflow differs, but maybe it doesn't, at least not enough to matter. Likewise feedback/complaint. Feedback wends its leisurely way into the reporting system. A complaint gets the CRM or AM jumping...

process, procedure, workflow

I suppose it depends at what level you want to distinguish between different work flows.

If request was better defined in the books both as a term and as a standardised work flow I think some of the issues here would disappear. I don't have the book in front of me, but my view is:

An event happens. Almost always (always?) with some root cause that might or might not be of interest to us.

That event needs to be detected, classified and reported to an agent of some sort, be it help desk, manager or software. Do we care which?

An event may or may not generate actions (break fix/request/change/problem etc.) but if it does generate actions then:

Actions need to be recorded
Tracked
Categorised
Prioritised (based on impact and urgency)
Allocated resources
Allocated control (who can escalate/stop/suspend/re-prioritise)
Actioned - including the generation of sub actions/tasks
Finished (completed/rejected/failed)
Checked
Reported
Reviewed
Closed

Have I missed anything out?

As tool vendors have been telling us for years the same tool can be used to handle a multitude of linked work flows.

The things that might distinguish workflows are:

To what degree they are pre/self determined, both in terms of the path they follow and the decision making process
The seperation of decison making from actioning
The amount of parallel actions required/dependencies with other actions.

We need to distinguish the differences:

To make sure decisions are made by the right agent
To report of what has happened in a meaningful way

In old ITIL terms we don't care about the procedure as long as it conforms to a high level process - I don't care how you prioritise an incident as long as you prioritise it. In modern tool enabled ITSM I don't care about the work flow that implements a procedure as long as I can implement/monitor/control it in my tool.

I think what I'm arguing is that I feel something is missing between an event and a request/incident - the generic "thing" (in my philosophy student days I was taken aback by how often the tutors had to resort to saying "some kind of stuff" when skirting around the missing element of an argument)that requires action, that for example generates a request from an event.

too abstract to be useful?

If the list is too granular, I think you have gone too far the other way :)

And surely many requests don't originate from an Event in the ITIL sense of something detected (detectable?) in the IT environment?

In what way?

Well tell me where the work flow doesn't fit? What it doesn't do, obviously, is define the work flow for any specific case, but it does provide a framework for defining the work flow.

I think you are right about not originating "from an event in the ITIL sense" - I think what I was hinting at was the need for a different term or a wider definition. A user trying to do something and discovering they can't do it is a typical example, or a change in a business requirement.

How does it differ?

How does the help/advice workflow differ? I'm not seeing it. Agree with James.

moot?

mmmm yes it is probably moot. Help requires a tech to go zap something, which will need assessment of whether it should be a Change. Advice is usually turned round on first call....

I think you guys are right...

help v advice

Please don't let techies go zap anything... unless they can follow a SOP (delete print queue) or operate under authority of an approved change request. Advice might be turned round on first call, but could/should generate other actions - editing user manuals, changing user training. And I'm not sure how the terms translate into other languages.

exactly

Right! The only sensible way - imho - is to look at this discussion inside-out: which processes are performed by the IT service organization to deliver services, which are the triggers for those processes, and how can we differentiate the nature of those triggers from a customer perspective.
That will provide:
- a workable result: it allows you to connect to the processes. Covering it in your support tool cannot be a problem anymore.
- a meaningful result: the customer's perspective is taken into account.
- an integrated result: it allows you to cover each of these interfaces in the SLA. E.g. if you agreed to support the user with business support questions, this requires a specific level of knowledge in front- or back-office, cost will be made, and payment should be agreed. In ITIL V2 this was called the Business Support Desk, which actually is NOT in the ITSM domain at all - it's in the Functional Service Management domain. But an IT organization can agree to all kinds of combinations of tasks in the end-to-end field of information management, so it's up to the local organization. As long as they understand what they're doing...

Incident & Request Classifications

OK YOU PEOPLE:

BRAINSTORM:

How about coordinating Incident & Request classifications with the IT Financial Management process (IT Accounting)?

The Financial Management process has accountability for tracking assets and resources.

This common sense approach might be added as a tip into ITIL LIVE.

Waaddaa Yaaa Think?

let's give it a try

John,
first of all: IT financial management is not a process but a function. An important consideration, since it greatly affects the implementation!

Second: the function "IT financial management" should indeed agree on how incident and problem management would support its responsibilities (as detailed in the SLA). And the same would apply to the process of configuration management. As well as to the other ITSM processes. It would be simple to detail this in practice: just imagine what "a financial incident" would be, or "a financial problem".

Third: I don't think you have to wait for the horrifying expensive ITIL Live to provide practical guidance on this. End of March, we'll deliver the add-on title on IT financial management in the series on Best Practices we're developing. It will provide consistent information on how to implement an IT financial management function in an IT service organization, and how to relate that to the processes, and to other possible functions. Hope you can hold your horses until then....

uber-classes

Hi Joe

i was thinking the same three uber-classes too, in fact they are already organised that way. In practice I'm not sure I agree with doing it though. There will be a pulldown to classify the ticket. I think anyone smart and fast enough to be a helpdesk operative can choose from 13. And I think they'd prefer it to two steps: class, subclass.

All feedback requirss a response. it require acknowledgement that the user was heard, and it should be compiled and reported.

unter-classes

"All feedback requires a response" - OK, that makes sense

Maybe your grade of helpdesk agents are unusually smart and focused. Ours ... not so much. Smart enough, but highly prone to putting in bad information because they lose focus, or lose something else.

But two steps should be fine (as long as the first one isn't "request" :) ). If you group work, ordering, booking and provisioning into one (some orgs call this "service request" but I hate the term because it leads to confusion), you'd have a fair structure.

Do we need to capture all the workflow alternatives right at the beginning? Surely we could leave some of the distinctions to a later step, via a flag attribute, especially for the less time-critical ones.

A good list but it should be

A good list but it should be structured.

I would use a two-level taxonomy. Incidents and service request would be the upper level. I would use the old definition of an incident: "any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in, the quality of that service"

In your list 6,7,8,9 and 13 would be incident types. Then we would need a new name for 6. Failure? A disruption would not need to be SLA breach to be classified as incident-failure.

The rest I would classify as service request types.

Aale

no reason why an incident is a disitinct entity

See my article on the evolution fo the request. i see no reason why an incident is a disitinct entity to other forms of request, other than history

The names are misleading

In the V2 sense, both incident and problem are different from their normal meaning in English. In my language we have solved the incident-issue by not translating the word but using the original. Problem is more problematic as it is already a word in Finnish too. Maybe they should have used The meaning of Liff and call it Rotorua: Any event ....which causes or may cause... and Waikato: The unknown underlying cause of one or more Rotorua's. (I've never visited new Zealand but would like to)

The thing is that the Service Desk has to decide quickly which process to revoke and the definition of V2 incident is practical. Either it is a clear request for service or it is something else. Both can have subclasses as needed. I believe thirteen 1st level classes is too much in practise.

Aale

Quoting: "Incident: an

Quoting:
"Incident: an unplanned interruption to an IT service or reduction in the quality of an IT service. (Question: if an interruption or degradation of service is within the terms of the SLA, is it an Incident? )"

Yes, it is an Incident even if within the terms of the SLA. It has to be registered, it has to be dealt with (within the agreed time). If not treated as an Incident, the actual levels of the service quality are difficult, if not impossible to monitor. Furthermore, each "happening", taken separately, may perhaps not break the SLA, but when combined, they can. If not treated as Incidents, how (and when) will you know that the service levels are below the ones described in the SLA, due to total of non-SLA-breaking Incidents?

Syndicate content