This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Problem vs Incident

Wondering how others deal with this.

According to ITIL, an "incident" is 'An unplanned interruption to an IT Service or reduction in the quality of an IT service.'

A "problem" is 'the cause of one or more incidents.'

BUT, in WHD, you need to have a Ticket with a Problem first, then add incidents to it.

Typically, when there is a problem, it isn't discovered as a problem until you have 3 or more incidents.

So… do others go back and convert the first incident into a problem, then begin to 'collect' the other incidents and add them to the converted problem?

Or do you take the 4th or 5th, etc incident and make that a problem, and add the first several incidents to the problem.

Or doesn't it matter?

Just wondering (and wanting to be a better Help Desk Manager in the process :-)

  • What we do is create a new ticket that is not tied to a client with general information about the problem. We then mark this ticket as a problem ticket and link the existing tickets to this ticket as incidents.

  • Hello,

    Incident and Problem Management does not see it so rigid, that only several incidents about the same issue can only open a problem ticket. One incident can be enough to open / convert to a problem ticket.

    We use it as needed. Sometimes we use one of the incident tickets and change this to a problem ticket and add all incidents into this one or we specifically open a problem ticket and move then all incident tickets into the problem ticket (I personally prefer the latter one).

    It works for us quite well, so far. What needs to be kept in mind is, that under specific circumstances, an updated and closed problem ticket can update, close and inform all incident tickets. Because there is different information in a problem ticket this can be a bit unsuitable. This happened to me a few month ago.

    Regards,

    Eberhard

  • I guess I never tried to create a ticket with no client. Didn't know you could do that.

    Interesting approach.

    So, if you create a Problem Ticket, then assign 'past' incidents to it, what if a Tech has already closed the 'past' incident? Will the "problem" ticket then re-open the 'closed' incident that was added?

    Also, does adding a Note to a Problem Ticket add that Note to all the Incident tickets?

    I know I can experiment, but was hoping to get some 'experienced' answers as well.

    Thank you for the quick response

  • So you say "an updated and closed problem ticket can update, close and inform all incident tickets". Does that mean whatever is done to the Problem Ticket happens to all the associated Incident Tickets as well?

    Can you modify an individual Incident ticket that is associated with a Problem ticket?

    thank you for the reply

  • Here is what has happened in my testing.

    1) If you add an Incident ticket to a closed problem ticket, the incident will remain open and the problem will remain closed.

    2) Notes from problems appear on incident tickets that are linked at the time of the note being written. In our above example, this means that the late-added ticket will not get the notes. Notes added to incidents ticket will also appear on the problem,

  • Hello,

    For us the problem ticket is relevant to solve the source issue that triggered all the incidents. Normally the problem ticket is assigned to a different group within our department.

    I find it helpful to add the incidents to the problem ticket to emphases a potential issue, or even major issue. The longer the list is the more the issue becomes urgent. In the past we said "..we got a lot of calls about XYZ... can you look into this please" and dealt with the incidents. But sometimes it could happened that the issue was not seen as a problem because of lack of information.

    Since we use problem tickets we create reports. So far we don't have a lot of problem tickets, but an increase in problem tickets would be a good indicator of an underlying infrastructure or setup issue. Which in turn can help to pro-actively look into the service. Which can trigger request in "Change Management" or "Event Management" etc.

    In April or May of last year we started more and more to use this. One of the first time we had about 20+ or so incident tickets linked to one problem ticket. The problem ticket was updated (issue was solved) and closed. This triggered that all of the 20+ incident tickets were updated, user informed by email and ticket closed. emoticons_cry.png Because this was not intended the users got a "technical" information of the solution of the issue. This of course triggered a lot of calls... emoticons_cry.png

    It did not happen again. I did not know what exactly we have done back in April. I need to look into this again and do some tests.

    Regards,

    Eberhard

  • I like to convert the first Incident ticket into the Problem.  This gives me a accurate timeline for our SLA management.  We don't determine the severity by the number of reported incidents but by how a core business service is affected.  We classify these as Major Incidents and close them as soon as the issue is resolved in order to calculate the SLA.  When it closes I have a task running that opens a new ticket and thats what I run our Problem Management process with.  This process is used to determine root cause and to assign Action Step tickets (linked to the Problem Mgmt ticket) that are performed in order to minimize the Major Incident from recurring.   Would love to have a discussion\idea exchange on how everyone runs their Incident\Problem mgmt process.