Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: S07P
New Today: 133
New Yesterday: 154
Overall: 131031

People Online:
Visitors: 76
Members: 7
Total: 83 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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.


The Itil Community Forum: Forums

ITIL :: View topic - What is a routine incident?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

What is a routine incident?

 
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message
BEN_U
Newbie
Newbie


Joined: Sep 18, 2008
Posts: 2

PostPosted: Thu Sep 18, 2008 4:56 pm    Post subject: What is a routine incident? Reply with quote

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?
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu Sep 18, 2008 5:14 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3256
Location: London, UK

PostPosted: Thu Sep 18, 2008 6:09 pm    Post subject: Reply with quote

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
Back to top
View user's profile
BEN_U
Newbie
Newbie


Joined: Sep 18, 2008
Posts: 2

PostPosted: Fri Sep 19, 2008 1:30 pm    Post subject: Reply with quote

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...
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Fri Sep 19, 2008 4:38 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Fri Sep 19, 2008 5:02 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
entivo
Newbie
Newbie


Joined: Jan 12, 2008
Posts: 17

PostPosted: Wed Apr 08, 2009 6:29 pm    Post subject: Reply with quote

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.
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Wed Apr 08, 2009 7:04 pm    Post subject: Reply with quote

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. Cool 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
Back to top
View user's profile Send e-mail
entivo
Newbie
Newbie


Joined: Jan 12, 2008
Posts: 17

PostPosted: Wed Apr 08, 2009 10:32 pm    Post subject: Reply with quote

Diarmid wrote:


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. Cool 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!
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.