Problem Management Parent / Child ticket methonology

[j_jones]

We currently have Problems opened automatically if a critical (Prio1) incident occurs. Some of the times these are recurrences of an existing an Problem. To depict this, we set a "Parent/Child" Problem Ticket relationship in which a check box designates the parent (Parent true/false) and in the child tickets, we set a field for "Link to Parent Problem" and enter the Parent Problem ticket number. Only Problem Records with the "Parent" set to true (checked) will be selectable in the "Link to..." field.

I was wondering how others with perhaps a bit more experience in ServiceNow have handled this issue. My organization has been using ServiceNow only since May of this year.

Any advise/ideas would be welcome.

[Michael Fry1]

We don't create Problems automatically since some P1 incidents could be a known issue (system reboots every night at 12:00am), or waiting x (vendor, parts, etc). Since you have recurring Incidents, you could associate them to one Problem until the issue is resolved, then close the Problem. We just insure that our incidents are closed first, and then use the Problem ticket for issue analysis.

Instead of the check box, you could use a filter on your related list and filter those Problems where the Parent field is blank.

[rob_blakey]

Hi Jeremy,

We were tossing up a similar solution to this, however, we did not find a need to raise parent/child records for problems, as if you are having similar P1's for the same problem, link the Incidents to that problem, which would still allow you to have 1 problem for all P1 Incidents.

That way, if you have repeat Incidents, for the same thing, you can see the impact via linked Incidents rather than raising multiple problems.

I would also look into your current process as raising a problem for every single P1 can land you in a bunch of hot water when it comes to managing you problems and addressing true root cause.

Hope this was useful.

Cheers,

Rob

[j_jones]

One of the reasons that we have a Problem created automatically from each Prio1 Incident is that my group also has the responsibility of managing the Prio1 incidents and driving to resolution as well as following up on Root Cause and Permanent fix. This is the reason, to indicate and document my groups activity as well as to document the process of the Critical Incident handling for further analysis as well.

Thanks for the input!

JJ

[rob_blakey]

Hi Jeremy,

I understand the need for that, but creating duplicate problem tickets for the same possible root cause is ludicrous. Having a good problem management process allows for this and caters for the scenario where multiple Priority 1 and other priority tickets can and should be linked to the same problem.

If your team is in charge of driving resolution as a High Priority Incident Team, and are also in charge of doing problem management then you may have a larger issue here as Problem investigations should be done by the other assignment group(s) within your organization. If the only reason you are doing this is to document your workload and activity, then you may need to have a serious review. I know this isn't helpful to your parent/child case for problem tickets, but I would suggest that some work is done on the process side of the fence as well.

My Suggestion is that if you just need to document the activity, then linking incidents to pre-existing problems should cater for your needs without having to raise multiple problems as mentioned before. If the teams are doing the work in finding out root cause, and you are in charge of documenting the resolution and cause of the incidents, this should allow for feasibility in linking these incidents to the right problem tickets.