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: RChisolm
New Today: 48
New Yesterday: 66
Overall: 142267

People Online:
Visitors: 50
Members: 0
Total: 50

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 - Incident to Problem in Application Environment
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Incident to Problem in Application Environment

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


Joined: May 20, 2010
Posts: 4

PostPosted: Fri May 21, 2010 6:07 am    Post subject: Incident to Problem in Application Environment Reply with quote

Dear expert,

I am with large organisation that use SAP as our back-end system. For ticketing system we are using Remedy.

At this moment, we use Incident, Change and Request module in Remedy. We are planning to apply Problem Management in our process.

I would like to understand in which stage that incident will be considered as a problem?

Herewith illustration of our current process:
1. Incident that is caused by user mistake --> Stays as incident
2. Incident that is caused by bug (i.e. reporting, invoice printing, etc) --> We will derived change ticket from this incident
3. Incident that is caused by hardware failure (i.e. system down, network failure) --> Stays as incident

Based on that illustration, what kind of incident that lead to a problem in application environment? What scenarios that comes to my mind, if incident caused by user mistake, but it is happened regularly, then we create problem ticket. The rest, I could not think of it.. Please help me with example or illustration.

Your feedback is highly appreciated.. thanks!
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Fri May 21, 2010 3:47 pm    Post subject: Reply with quote

incidents never become a problem

incidents are incidents

problems are problems

Are you familiar with ITIL ?

there is a well documented definition of both
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Fri May 21, 2010 5:20 pm    Post subject: Reply with quote

Aulvin

1 = forget the tool - Remedy.
2 - go get the ITIL books - v2 or v3. preferably V2. Also look to the other ITIL V2 books about application management

Now to the heart of the matter - as I read it

You want to figure out what to do with application bug fixes and errors and how to classify them.

You are missing a key element from the description you put

If there is a fault (use the neutral word) with the application, this is what I recommend happen

1 - an incident ticket is raised
2 - it is analysed and determined whether it is U.I.E - User Input error or
if the fault is the underlying server (wintel or unix or mainframe) or the service - database web or such like. If none of these are the quickly analysed reason for the fault, then what is the resolution to the fault if any

3- if the fault points to the application as being faulty, then this needs to jump from the incident mgmt to the application defect mgmt process.

This process feeds the development of the solution to the appropriate team. This could be considered the application problem mgmt process - but it is actually part of the Software development lifecycle for that application under defect mgmt

The Defect would be triaged and determined how urgent or not the solution is needed. Then it is developed, tested and once accepted as the solution brought to the change mgmt process for deployment into production

So where does that leave problem mgmt

Hmm. the phrase IT depends comes to mind

For the application, I would consider the SDLC and hot fix / big fix path the problem mgmt process. But I would have it as an add on to the PM process

The incident / fault may still recur over and over again. it should be recorded as an incident and referenced to the Defect mgmt process

Your policy, process and procedures should reflect this.
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
thechosenone69
Senior Itiler


Joined: Jun 06, 2007
Posts: 268

PostPosted: Fri May 21, 2010 7:44 pm    Post subject: Reply with quote

Aulvin,

In addition to what UK have said. Incidents can relate to problems but they do not become a problem. For example you exchange server crashed and you dont know what is the root cause of the problem. you log a record for it, then relate any related incidents from users to it. But ya having that said, you should invest in the ITIL books and start reading.
_________________
Ali Makahleh
Configuration Management(Blue Badge),
ITILV2 Service Manager(Red Badge),
ITILV3 Expert(Lilac Badge) Certified.

“If you can't describe what you are doing as a process, you don't know what you're doing." W. Edwards Deming.
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Fri May 21, 2010 11:11 pm    Post subject: Re: Incident to Problem in Application Environment Reply with quote

aulvin wrote:
what kind of incident that lead to a problem?


You will have seen from the replies so far that you are approaching this from the wrong angle.

Incidents don't lead to problems; problems lead to incidents.

A problem is a situation in which a service may (or will) break or deteriorate irrespective of whether it has done so before. So it is related to future incidents, not past incidents. However the occurrence of past incidents is probably the most common way in which it is discovered that there is a problem to be dealt with.

Whenever an incident occurs it should be considered whether there might be an underlying problem worthy of attention. Some people take the view that that is always true for anything not attributable to a known error or outstanding problem.
_________________
"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
aulvin
Newbie
Newbie


Joined: May 20, 2010
Posts: 4

PostPosted: Sat May 22, 2010 4:31 am    Post subject: Reply with quote

Hello,

Thank you for the response. I am new in ITIL methodology. Have been gone for V.3 foundation training, but still struggling on problem management.

Based on your replies, I understand that both incident and problem would be independent event. I would also assume that both of the event would have different frequency and SLA. On incident we would have 200 incidents per month with average 1.5 days to solve the issues. I didn't see the same frequency of problem.

I also think that decision to create problem ticket should come from Problem Manager or similar capability, whereas incident was generated from user report of failure/outage.

I hope I have made a clear understanding here...
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Sat May 22, 2010 7:09 am    Post subject: Reply with quote

Except that a problem is not an event, it is a situation.

Who determines the opening of a problem record is a matter of policy. There are no hard and fast rules.

Problems do not have SLAs. At least not by my reckoning.

It is an oversimplification to suggest that incidents are raised by users. Additionally, anyone in IT services (and possibly even some automated systems) should have the capability of notifying the occurrence of an incident.

Problems can take from days to months to resolve, but I presume your incident days are actually hours. Most IT services are rather too important to lose 300 days a month, even if it is just one user.
_________________
"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
viv121
Senior Itiler


Joined: Dec 15, 2007
Posts: 113

PostPosted: Sat May 22, 2010 5:33 pm    Post subject: Reply with quote

Aulvin,

You have a point when you say that you are struggling with the problems. Everyone struggles with problems dear friend. You said you have 200 incidents opened per month. I suggest you go ahead and raise 400 problems raised per month and you'll have a working problem management management.

On the softer side

Define what you want to see as a problem. You mentioned that "incident and problem would be independent event" and you know what, you confused Diarmid. You did it, you are the one. What you should have understood by doing ITIL V3 foundation and following ITIL 'methodology' is that an Incident, a problem and an event are different and independent from each other.

Clinging to the softer side

Define what you want to see. You mentioned that the Incidents have an SLA of 1.5 days. Can you tell me what do you do in 1.5 days? Do do restore the service or fix the service? Are you resolving a few problems in a few minutes by any changes. This is to agree with Diarmid that even I haven't seen SLA bound problem management. You might have a team which is able to find out underlying root cause quickly and you never know you actually might be solving problem quickly. Do I assume that your 200 incidents are not repeatable in nature and if they are your helpdesk is able to sort them out at the first go?

In short, define problem and raise them. Hope you have a tool which is indeed a service manaement system.

Raise as many problems as you want. Go and sniff your datacentre eqipments. If they don't smell good, raise problems and have them resolved. This actually might decrease your incidents but increase your problems.

It also depends on how many problems you can afford to nurture.
_________________
regards,

Vivek
"the only statistics you can trust are those you falsified yourself"
Winston Churchill
Back to top
View user's profile Send e-mail
aulvin
Newbie
Newbie


Joined: May 20, 2010
Posts: 4

PostPosted: Sun May 23, 2010 3:37 am    Post subject: Reply with quote

Hello Diarmid, viv21 and everyone,

Thanks for all the feedbacks. I am getting clearer about these things.. In facts, i feel discussing this topic in forum is more effective than reading the theory (but i do need to understand the concept as well Smile

cheers,
aulvin
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.