Incident to Problem in Application Environment

[aulvin]

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!

[UKVIKING]

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

[UKVIKING]

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

[thechosenone69]

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.

[Diarmid]

[aulvin]

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...

[Diarmid]

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

[viv121]

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

[aulvin]

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

cheers,
aulvin