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: justfifa
New Today: 1
New Yesterday: 42
Overall: 146509

People Online:
Visitors: 37
Members: 1
Total: 38 .

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 - Problems Implementing the Incident Management process
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Problems Implementing the Incident Management process

 
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk
View previous topic :: View next topic  
Author Message
kimberlito
Newbie
Newbie


Joined: Aug 21, 2007
Posts: 6
Location: Portugal

PostPosted: Wed Sep 26, 2007 6:46 am    Post subject: Problems Implementing the Incident Management process Reply with quote

Hi all
In your opinion, what are the major problems of implementing an Incident Management process? Is it the organization culture (people resistant to change)?

I dont think that implement an incident management process is just about getting an ITIL compliant tool and thats it!

Any experience or ideas?
Tanks in advance
_________________
Kimberlito
Service Desk & Incident Management Project Leader.
ITIL Foundations Certified
Back to top
View user's profile Visit poster's website
dam
Senior Itiler


Joined: Sep 05, 2007
Posts: 57

PostPosted: Thu Sep 27, 2007 1:53 am    Post subject: Reply with quote

Hi kimberlito,

It’s not possible to answer to this question, the first problem is that you have to have a clear idea about WHY do you want to implement the incident management process.

To improve your customer level of satisfaction?
To be more efficient in problem solving?
To be able to measure the quality of the service you provide?
To improve the internal company’s governance?

Once you have some clear objectives in your mind implementation obstacles become much more evident.

Good luck,
DAM
Back to top
View user's profile
kimberlito
Newbie
Newbie


Joined: Aug 21, 2007
Posts: 6
Location: Portugal

PostPosted: Fri Sep 28, 2007 8:42 am    Post subject: Reply with quote

Tanks for the anwser dam,

My biggest goal in implement incident management is, as you said:

- To be more efficient in problem solving;
- To be able to measure the quality of the service I provide;
- To improve my customer level of satisfaction.

and...

I want to make RULES. In my job, there are no rules. Everybody enters my office and ask me "Hi Rui, please I need this, I need that, etc. etc..." and in some cases, my mind cant save all the requests wich result in forgotten incidents!

The main cause is that I work with Pharmacists, ie, very intelligent people, but with very little knowledge in IT, but... They are scientists! Thei dont have to be specialist in IT! They have to be specialist in Chemistry, matemathics, etc.!
And thats it!

Once again, tanks for your reply Smile
_________________
Kimberlito
Service Desk & Incident Management Project Leader.
ITIL Foundations Certified
Back to top
View user's profile Visit poster's website
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Fri Sep 28, 2007 11:13 pm    Post subject: Reply with quote

Hello Kimberlito,

We find that the biggest biggest problems associated with implementing Incident Management are "terminology" and "understanding". Very few practitioners we've come across truly understand that enterprises already perform Incident Management all day long, every day, in each and every environment. As a result, they fail to communicate that what they're trying to achieve is "not" to implement a new concept but, rather, to take what is existing and standardize, centralize and optimize it... as well as helping everyone understand "why" you would want to achieve all of this.

Believe it or not, even the ITIL authors didn't get that Incident Management is an old concept and that it is already performed all day long by all groups, in all environments, in all enterprises. As a result, the ITIL documentation all focuses on implementing very limited forms of Incident Management, in the Production environment, only. This limitation adds to the confusion, when trying to convince an enterprise that they should do something in Production but not in all other environments... or that they should do something in IT but not in other parts of their business.

In any case, we find that a practitioner who understands how to educate stakeholders and provide solid justifications for "understanding" has a much higher probability of success than one that doesn't. The experienced practitioner will be able to get existing stakeholders that they're really not doing anything that is much different than what they're already doing. Instead, they will simply be "formalizing" what they're already doing, by centralizing where they create, track and manage their information, so that the greater enterprise can benefit from such information.

By the way, the "why" of implementing ITIL is rather simple... ITIL is about "transparency" and getting consistent data about your enterprise so that you can use it to "steer" your enterprise. That is, to constantly optimize and improve your enterprise. Leaders cannot accurately drive the enterprise without accurate data/information about it. ITIL provides the information that helps feed the dashboard that the driver requires. What many practitioners fail at is translating this why into a solid business case that shows a true financial return on investment (ROI). I believe that understanding how to create and write business justifications is also a very critical part of being successful.

Anyhow, I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL Platform
Back to top
View user's profile Send e-mail Visit poster's website
dam
Senior Itiler


Joined: Sep 05, 2007
Posts: 57

PostPosted: Sat Sep 29, 2007 12:48 am    Post subject: Reply with quote

Hi kimberlito,
I truly agree with Guerino1, that has raised a very crucial point. When you decide to adopt ITIL you are not reinventing the wheel, just trying to organize a well established incident management practice.

How to proceed? I give you my point of view.

You (or your management) understand that service support needs to be improved.

How can you improve the level of your service support? ITIL gives you some good ideas, but don’t forget that to make your project successful you have to be able to demonstrate to the outside world (management and peers not directly involved in support activities) that your project is improving things.

The only way to do this is to produce numbers that speak for you.

Indicators
Metrics
Key Performance indicator
Critical Success Factors

To be able to do this you have to track all the activities of the service desk. (on paper, on an excel sheet, using a dedicated tool etc…)

If you work out this in a simply but clever way (setting up a couple of good metrics to follow, like average resolution time of an incident by priority, % of incident resolved directly by the service desk with no functional escalation) you can produce a positive retro-action:

Motivate your peers to track formally all their support requests (and so get into the process you have established) because you will use this information to produce stats. So “no more cases will be treated if not tracked ”

Motivate management to invest in your project because they see numbers that speak and even hopefully, trends that motivate (like average resolution time decreasing after six months)

Then the more you get interest and appreciation around what you do, the more you can ask to the others.

Hope this can help,
DAM
Back to top
View user's profile
kimberlito
Newbie
Newbie


Joined: Aug 21, 2007
Posts: 6
Location: Portugal

PostPosted: Sat Sep 29, 2007 3:37 am    Post subject: Reply with quote

Guerino1, Dam, tanks for your replies.
I really appreciate your answers.
Good point of views.
_________________
Kimberlito
Service Desk & Incident Management Project Leader.
ITIL Foundations Certified
Back to top
View user's profile Visit poster's website
Marcel
Senior Itiler


Joined: Sep 21, 2006
Posts: 63
Location: USA

PostPosted: Thu Oct 04, 2007 1:01 am    Post subject: Reply with quote

In addition to the valid points already addressed by others, I would like to share a few practical challenges that I have encountered in almost every organization where I was involved in implementing an ITIL based incident management process:

1) IT staff often has a hard time differentiating between incidents and problems as per ITIL’s definitions. ‘Problem’ is the common word in spoken language to indicate something is broken that needs to be fixed, but in ITIL ‘problem’ has a very specific definition. It takes a lot of repeated communication to make people understand these concepts and it is important that the ‘messengers’ who bring the store are very consistent in their use of terminology.

2) For a long time you will find people leaving incident tickets open until the root cause has been resolved, even though a perfectly fine workaround was already put in place. Again, this is the result of not differentiating properly between incidents and problems. You will need to put metrics on incident resolution time and follow up with groups/people that frequently miss the target resolution time. This may help you detect the situation I described.

3) Incidents are often categorized using schemes like CTI (Category, Type, Item). Make sure that your CTI is a consistent global structure that is maintained centrally. The various stakeholders can provide inputs, but these will need to be reviewed centrally before they are entered into the structure. If you don’t do this, you will soon end up with a mess that will make it difficult to create valuable reports across the board, as many groups will try to set up ‘their’ piece of CTI only to meet their own needs.

4) Some organizations try to enforce certain behavior through the tools they implement, for example by making fields mandatory. I have seen this fail in many cases. There certainly are some things you want to enforce through the tool, but often it is better to enforce things through procedures combined with reports that demonstrate adherence to these procedures. This will help you to make people accountable.

5) Many IT staff members consider logging tickets for incidents an administrative burden. Many will try to avoid it, while others just log the bare minimum with poor quality tickets as a result. Don’t be surprised to find tons of tickets where the resolution is described as ‘this has been fixed’ without actually saying what was done. Make sure that people understand why it is important to log incident tickets and to do it well. Plan periodic reviews with each group where you discuss the content of a sample of their tickets.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk 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.