Belief is like a red helium balloon. You can't bear to let go of it. But letting go is easy, and once you do it floats away and you wonder why you ever held it.
Work, politics, race, religion... try it with ever larger balloons.
The world changes, beliefs don't. They deflate.

User login

Recent Comments

This book is about how to run services, in any organisation, in any industry. It describes the basics, the core stuff, in realistic pragmatic terms. And it is pragmatically brief - we kept it to 50 paperback pages.

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.

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

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.

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.

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. (Question: if an interruption or degradation of service is within the terms of the SLA, is it an Incident? )

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.)

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: 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.

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...

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

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.

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...

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.

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.

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.

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...

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....

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.

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.

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.

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.

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?