What creates a Problem Ticket

[AndyW]

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,

[UrgentJensen]

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)

[AndyW]

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,

[m_croon]

[Mark-OLoughlin]

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

[mitter]

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

[UKVIKING]

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

[Mark-OLoughlin]

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

[mitter]

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.

[UKVIKING]

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

[mitter]

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

[UKVIKING]

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