View previous topic :: View next topic |
Author |
Message |
AndyW Senior Itiler

Joined: Feb 14, 2008 Posts: 77
|
Posted: Wed Feb 27, 2008 10:49 pm Post subject: What creates a Problem Ticket |
|
|
Hi Im just wondering what reasons would create a Problem Ticket?
Or in other words what kicks the PROB process off in seperation to INC.
(I know the theory says a ‘Problem’ is an unknown underlying cause of one or more Incidents ...) But I would like to see that point less theoretically and focus more on daily businees. I need to tell the user when they should raise a problem ticket or when they should still stick with INC (e.g. major INC tickets/process)
As of now I would say:
- if we have an incident which potentially reoccur and have a massive impact on business
- SLAs, timeframes are endangered
- Incidents with no solution and no workaround in place
Maybe someone has a clearer definition of what creates a Problem Ticket.
Cheers, |
|
Back to top |
|
 |
UrgentJensen Senior Itiler

Joined: Feb 23, 2005 Posts: 458 Location: London
|
Posted: Wed Feb 27, 2008 11:14 pm Post subject: |
|
|
Hi AndyW,
The fundamental goals of Problem Management are to reduce the number of incidents generated so with that in mind I would suggest the two broadest considerations are:
That any incidents that have no implementable fix.
Any trends of incidents which are spotted when you run your reports.
Not sure I understand the bit about SLAs - do you mean looking for incident trends where they seem to come close to, or break, your SLA? Then yes that would certainly be in my review of the metrics.
Ultimately Andy there's only you against the world on this because every organisation and every IT - customer relationship is different.
Indeed let me know if you come up with any other ways of looking at this.
Cheers,
UJ _________________ Did I just say that out loud?
(Beige badge) |
|
Back to top |
|
 |
AndyW Senior Itiler

Joined: Feb 14, 2008 Posts: 77
|
Posted: Wed Feb 27, 2008 11:39 pm Post subject: |
|
|
Hi thx for the prompt reply.
For sure every organization looks diffrent on this subject but I was just wondering how is this seen in other companies.
Because I have the strange feeling that the difference between INC and PROB is hard to tell for the users.
If you look into the INC process (especially the process for major incidents) it is hard for the user to clearly differentiate whether they are still in INC for example analyzing an incident ticket trying to find a workaround or if they should raise a problem ticket.
cheers, |
|
Back to top |
|
 |
m_croon Senior Itiler

Joined: Aug 11, 2006 Posts: 262 Location: Netherlands
|
Posted: Wed Feb 27, 2008 11:52 pm Post subject: Re: What creates a Problem Ticket |
|
|
AndyW wrote: | I need to tell the user when they should raise a problem ticket or when they should still stick with INC (e.g. major INC tickets/process) |
Andy,
What is your definition of a user? If this is the end user (the final 'customer') of IT, why bother him/her with the difference between INC and PRB? From the perspective of the user, it should not matter how to call it as long as his disruption is fixed asap. In the feedback to the user, you might say that 'IT is working on a permanent fix which takes more time' and that you 'have a temporary fix for him to continue working for now', but do not try to put with the user the decision to either report an incident or a problem .
Maybe I have misinterpreted your post, let me know.
Regards,
Michiel |
|
Back to top |
|
 |
Mark-OLoughlin Senior Itiler

Joined: Oct 12, 2007 Posts: 306 Location: Ireland
|
Posted: Wed Feb 27, 2008 11:55 pm Post subject: |
|
|
Hi,
you keep refering to "users" not knowing what to raise. The users should be focused on reporting / raising incidents for their issues. The INC process should determine when an incident becomes a major incident. The major incident should have a triger for when it becomes a problem (indeed an incident may not become a major incident but a problem also so the process should have a trigger that signals when this occurs).
The incident management and problem management should be looking to ensure that these triggers get the right result.
In the past I have found people unable to get the distinction and actually did away with major incidents and replaced them with major problems on the basis that say a number of incidents related tot he same cause triggered a major problem. Once a workaround was put in it was lowered to a problem and continued from there. This is not as outlines in "ITIIL" but worked for the customer.
Have fun. _________________ Mark O'Loughlin
ITSM / ITIL Consultant |
|
Back to top |
|
 |
mitter Itiler

Joined: Dec 06, 2007 Posts: 21
|
Posted: Thu Feb 28, 2008 1:32 am Post subject: |
|
|
Based on the information
"an incident with no implementable fix"
Would you open a problem record for low priority one of incidents that have no immediate solution. or. 2nd level has to investigate the solution?
ex. spell check does not work when using webmail?? |
|
Back to top |
|
 |
UKVIKING Senior Itiler

Joined: Sep 16, 2006 Posts: 3591 Location: London, UK
|
Posted: Thu Feb 28, 2008 1:51 am Post subject: |
|
|
Synopsis
An incident does not become a problem. What should happen is that an incident or a series of incidents meet the initial criteria defined in the PM policy.
It is then decided by the PM team whether or not to raise a new problem record and initiate action on it.
Using the example give.., if 200 people open a call about spell checking not working in web mail, this may mean that PM would look to decide whether or not they want to spend resources to find out why.. when there really is no impact to the service - mail. and the amount of time spent is not worth the results
diminishing returns....
The PM should decide whether or not to raise a change
I think I spelled this out in an earlier thread ?!!>!! _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter |
|
Back to top |
|
 |
Mark-OLoughlin Senior Itiler

Joined: Oct 12, 2007 Posts: 306 Location: Ireland
|
Posted: Thu Feb 28, 2008 3:10 am Post subject: |
|
|
Hi,
good man John
"What should happen is that an incident or a series of incidents meet the initial criteria defined in the PM policy. "
You expanded on what I was refering to as a "trigger" which is the initial criteria as you mentioned. _________________ Mark O'Loughlin
ITSM / ITIL Consultant |
|
Back to top |
|
 |
mitter Itiler

Joined: Dec 06, 2007 Posts: 21
|
Posted: Thu Feb 28, 2008 3:52 am Post subject: |
|
|
Perhaps I have joined the wrong forum. I am attempting to define my PM policies and came here looking for suggestions and examples of how other organizations are doing things.
If this is the wrong forum. It would be grealty appreciated if you could advise. |
|
Back to top |
|
 |
UKVIKING Senior Itiler

Joined: Sep 16, 2006 Posts: 3591 Location: London, UK
|
Posted: Thu Feb 28, 2008 5:00 am Post subject: |
|
|
Mitter,
You are in the right forum for ITIL Problem Management
The main posters/responders - Mark O', UJ, SkinnerA, Ed - (if I miss any sorry) - are here to give advice and opinions
You need to write your own policy based on your own company's documentational standard (see SueKocher for stylist/format/etc - she is damn good source / poster about)
What we will do - like what I have done - is give our opinions, recommendations, etc - about what we have done and what you should do in respond to the question
What I wont do - is give you my Intellectual Property for free. I wont give copies of my policies, processes, procedures - beyond what is in ITIL manual - because YOU aint paying me.
I will give examples - like I have from historical events. I will comment on them.
And every answer will be oriented towards the implementation of ITIL and the application of ITIL in a IT environment
That said.
What do you expect from the forum ?
It is a non-commercial site dedicated to ITIL Best Practice, its implementation and the application there of.
We will give advice, cheerleader, opinions... we expect you to either take our advice, opinions etc for what they are. Free advice.
Please check the monday-itis thread ;- _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter |
|
Back to top |
|
 |
mitter Itiler

Joined: Dec 06, 2007 Posts: 21
|
Posted: Thu Feb 28, 2008 6:22 am Post subject: |
|
|
LOL
Thank You UVKING. What you described is exacly what I was looking for.
Of course I would not expect you to go ahead and offer up all of your hard work for free.
Recommendations based on experience is all that I am after.
ITIL tells you that a problem is one or more incidents. It does not tell you if the "one" incident should be one of high impact(aka a Critical incident), or if it could be "one" incident where the Root cause to determine the cause of an incident is required for incident resolution.
After you stated that you already answerd this question in a earlier thread, I went digging around and found more information.
I appreciate you taking the time to respond.
Thanks for the help
Mitter |
|
Back to top |
|
 |
UKVIKING Senior Itiler

Joined: Sep 16, 2006 Posts: 3591 Location: London, UK
|
Posted: Thu Feb 28, 2008 7:21 pm Post subject: |
|
|
Mitter,
A problem is defined as 'Problem' is an unknown underlying cause of one or more Incidents.
A problem is not automatically generated because an incident does not a root cause.
Like my example, IM selects incidents that meets the criteria for creating a problem record
It is then UP to PM to determine whether it is worth having a P record and doing t he work _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter |
|
Back to top |
|
 |
|