What is a routine incident?

[BEN_U]

Dear Itiliers,

I'm documenting PM processes for my group and I'm trying to understand what a "routine incident" is (shown in itSMF booklet pg21).

The process goes as such;

01. Incident Alert
02. Routine Incident? (Y/N)
Y -> Assess incident and follow routine proceedures
N -> 03.
03. Match on Known Error DB? (Y/N)
etc etc

In this process a routine incident isn't matched against a problem or known error, nor does it create a new problem record, (should it?).

Also, the best (only) example I can come up with for a "routine incident" is "printer running out of paper".

Any ideas?

[Diarmid]

Ben,

irrespective of what any book refers to, a "routine incident" is whatever it is defined as by an organization using the term. It is only a useful term if you wish or require to treat it in some way differently from any other kind of incident and need to document that procedural variance.

On receiving report of such an incident, the only way it can be thus identified is by comparing against some list of incident type identifiers or criteria which is not incredibly different from comparing to a list of identified problems or known errors.

In other words your step 2 really has to say "match to routine incidents" and the following action is not particularly different from pursuing the documented treatment of known errors in that it is following specific instructions for that incident.

It is also very close to the treatment of service request as distinct from incident report. Perhaps that is a better distinction. Your example is certainly definable as a service request for a paper refill.

It would become interesting if a problem arose around something that was normally treated as a "routine incident". You would probably have to take it off the list until the problem was resolved.

What I am trying to illustrate is that the "routine incident" adds complexity to your incident management, complexity that has to be justified by some benefit somewhere.

It may just be terminology, but an incident never "creates a problem record". It may lead to the creation of a problem record, but it is much more common for a series of incidents to lead there.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[UKVIKING]

BEN_U

In addition, you really should not have routine incidents.....

Any incident that occurs frequently indicates soemthing... that may have to be investigated
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[BEN_U]

Thanks for the responses, but I've now got some further questions!

Suppose that I remove the "routine incident" process, and then the printer runs out of paper or something equally trivial. The process continues with the following steps;

--
05. Create a new problem record
06. Allocate PM resources to investigate
07. Process the incident / problem
--

The workaround is 'refill the paper tray'
The root cause is 'people using the printer'
-> Create a know error record
The resolution is (bear with me here)
a) Petition CM for a limitless paper tray or
b) Stop users from printing documents on that printer

What this creates is a headache, lots of overhead and an unresolvable problem for something that's trivial.

Now contrast this with keeping the "routine incident" process.

The incident is resolved without the overhead (at the risk of not identifying a possible problem), but there's more.

What's to stop Jo Blo from classifying everything as a "routine incident" to save himself some overhead?

Its a little, damned if you do / don't...

[Diarmid]

That's what happens when you assume that calls to the service desk are incidents before you analyse them.

- User reports paper low
- service desk records "service request - more paper" (documented)
- support tech/admin/assistant takes paper to printer and loads it
- service desk notified request honoured

OR

local business staff taught:
- how to reload printer
- how to requisition paper

OR

IT staff routinely visit every printer every day to replenish paper

The point is that for your service desk to recognize a "routine "incident" they have to have a list and instructions of what to do with each one (that is what stops Joe from classifying things any way he wants). So why not call them service requests, avoid all the confusion with incidents and document and record services?

The underlying point is that you have to design your processes so that they work, rather than so that they follow some abstract concept. Or, to put it another way, don't design processes until you have analysed your requirements. Or, to put it another way, "off the shelf" ITIL does not work.

[plug: if you had a Quality Manager, he would have told you all this already]
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[Diarmid]

This is where your problem lies

[entivo]

Ben,

This is what "routine incident" means to my organization;

When a call/email comes in to our Service Desk they record the details and make a quick assessment.

If it's something like a password reset, account lockout etc which is unlikely to be indicative of an underlying problem then it's treated as a routine incident. By that I mean that our normal IM process is followed.

The important thing about this approach (and making it work) is that the Service Desk Analyst has to use their experience and intuition to make the call about whether the incident is routine or not. If there is doubt they ask either the Problem Manager or 3rd Line Support people to help them make the call. We have talented and experienced people on our SD so we can do this well.

If the analyst decides that the incident may not be routine (i.e. that the normal IM process may not be appropriate) then they follow a different process which I have adapted from ITIL. During this process they check the known errors database, then check for open problems and if neither are found they open a new problem record.

Now I will probably get people responding to this with all sorts of criticism about this approach not being correct. Whatever. It works for us and we are happy with it. That's what ITIL is all about. They give you a framework and you adapt it to your particular organizational requirements.

[Diarmid]

entivo,

there is nothing wrong with your approach so long as:

1. it is documented with guidance as to criteria for making the decision
2. you have defined the skills, experience and capabilities required of the staff involved
3. you retrospectively analyse the body of routine incidents for consistency and appropriateness
4. whenever one goes wrong, you review your criteria etc.
5. the benefits outweigh the costs and risks
6. you audit incident management regularly


At a tangent, it is possible that password reset requests or account lockouts may indicate inadequate guidance or training for users, and this would be an underlying problem.

This does not impinge on your incident management strategy, but it is the reason that proactive Problem Management must not ignore "routine" incident patterns and frequencies.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[entivo]