Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
NOTE: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Thu Sep 18, 2008 5:14 pm Post subject:
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
Joined: Sep 16, 2006 Posts: 3589 Location: London, UK
Posted: Thu Sep 18, 2008 6:09 pm Post subject:
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
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?
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Fri Sep 19, 2008 4:38 pm Post subject:
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
Last edited by Diarmid on Fri Sep 19, 2008 5:15 pm; edited 2 times in total
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Fri Sep 19, 2008 5:02 pm Post subject:
This is where your problem lies
BEN_U wrote:
01 Incident Alert
02 Routine Incident? (Y/N)
Y -> Assess incident and follow routine procedures
N -> 03
03 Match on Known Error DB? (Y/N)
--
05 Create a new problem record
06 Allocate PM resources to investigate
07 Process the incident / problem
--
Does every incident lead to a problem unless you have a match? how do you get any work done? The overheads must be horrendous.
Does the problem team race with the incident team to see who can fix it quickest?
This kind of thing gives ITIL a bad name. _________________ "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
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.
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Wed Apr 08, 2009 7:04 pm Post subject:
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
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
Agreed. We are lucky to have good SD analysts with the ability to make good calls in this respect. I think much of the reviewing and auditing comes with maturity.
Diarmid wrote:
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.
Again, agreed. But I would wager that if you looked at the top 5 incidents in 100 organisations you would find password and printer issues in all of them. Roll on single sign on with biometrics for all systems!
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum