Posted: Fri May 21, 2010 6:07 am Post subject: Incident to Problem in Application Environment
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.
Joined: Sep 16, 2006 Posts: 3299 Location: London, UK
Posted: Fri May 21, 2010 5:20 pm Post subject:
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
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.
Joined: Mar 04, 2008 Posts: 1884 Location: Newcastle-under-Lyme
Posted: Fri May 21, 2010 11:11 pm Post subject: Re: Incident to Problem in Application Environment
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
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.
Joined: Mar 04, 2008 Posts: 1884 Location: Newcastle-under-Lyme
Posted: Sat May 22, 2010 7:09 am Post subject:
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
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,
"the only statistics you can trust are those you falsified yourself"
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
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