Question about Major Incident VS Problem Management

[zeba1]

We are just configuring Service Now and going live in the next month, I am being told that Parent/Child feature in Incident Management is ONLY to be used if we are not implementing Problem Management. I am being advised that because I am implementing Problem management every time there is a Major Incident I should automatically create a problem record and link all the incidents to the problem and not use Parent/child relationship to manage outages (multiple calls caused by the same incident).
Can someone please tell me if Parent/Child feature is only if we do not implement Problem Managment or should we use both to manage Major incidents and problems the way they should be. I would like to use both so I can manage Major Incidents for Incident Management and if its a reoccuring issue then open a problem ticket to investigate and do root cause analysis and prevent future occurence.

Thank you,

[Dmcolburn]

There are other considerations for using Parent-child tickets as a seperate "Special Incident Handling" different than a Major Incident-Problem. I thought perhaps I could stimulate some Synergy, spring-boarding from an idea to create something better, by getting more brains involved.

Consider this you Mensa thinkers:

A CIO attempting to "mature" the support organization's processes to move away from the crisis-driven, "no time to document knowledge" approach to managing Incidents. Also trying to "De-Silo" the support teams, stimulating them to work on "Special Incidents" as a collaborative support team with all expertise represented in a Diagnosis, Resolution, Urgent Change-Request pre-impact assesment team.

Special Incidents would be CIO selected, for High Visibiltiy Business Processes/Services IT supports.

New Role: "Service Owner" (or other name) a seasoned IT Level 2-3 person who represents the High priority business process (e.g. Retail Web Services). they become expert in the entire Service-Chain, knowing who to involve based on the initial Incident symptomology (new word?)

If a "High Priority" Incident is submitted by a Level 1 Service Desk Analyst (who validates that it is a real "High") for a group of "special" bus. processes (i.e. "special Incident") it is immediately Assigned to the Service Owner. Service Owner cuts a Parent Ticket to hold the overall knowledge for this Incident, and cuts Child tickets to each key support team SME who represents this special service for Level 2-3.This Notify each of an urgent (within 20 minutes) need to respond and be ready to be involved.

The Service Owner (SO) then pulls together all SMEs (who have Child Tickets) for an inital collaborative session (within 20 miutes). The SO coordinates the special Incident and assignes sub-teams (if required) to collaborate (in a team Chat Group) on Diagnosis, Resolution and then drafting a RFC to implement the resolution:

Why?
1. no mis-assignments (100% assigned to right team)
2. Coordinated collaboration across expertise SMEs (if facilitated well, and improving over time) makes for quicker and coordinated "everyone on same page" diagnosis activities.
3. Collaborative resolution design should be "get it right the 1st time" optimized (again they get better in time)
4. Collaborative resolution design --> pre-impact asessed RFC for resolution. This is golden for Urgent RFCs that are spawned by High Pri Incidents. Again Get it right the 1st time optimized. (Rushed RFCs in response to Incidents are deadly cause of "Change Related Incidents" read: shoot self in foot)
5. Last but Best: This collaborative approach to High Vis services kills the Silo mentality very quick, paving the way for truly effective (everyone understands) OLAs. This would support turly effective SLAs for Availability (Availability calculated from Incident history (the customer experienced Availability))

"Crisis Hardened" experienced Help Desk support folks will likely kick and scream over this, claiming "not real". Certainly the 'Hero-driven' IT suport folks will squwak about this approach Heroes generally are loner types who do their best diagnosis work (read: try stuff to see if it works) when nobody is looking.

In reality however, this is exactly what has to be done to be effective in complex infrastructures; collaborative tech experts synergizing on cretive solutions for high priority business processes. Until we capture the detailed service relationships in the CMDB, and save the knowledge we learn from every single Incident, experts will need to collaborate to find the most effective (least negatively impactful) solutions.

If you read and understood this scenario, hopefully you are stimulated to add your positive wisdom to the possibilities.

"Be the Dragon, Smote the Hero!"

DC

[Sean Cosgrove]

How does this work currently with the introduction of Major Incidents in the platform?  It all makes sense if Problem Management is something to perform after the dust has settled from a Major Incident.  Where I get confused is that within Problem Management, there is the option to communicate workaround to users within incidents associated to the problem.  That would imply both things are happening at the same time right?  

[babiso]

Not all sites can be promoted through social networks, because Some sites may simply be uninteresting for the majority, or there is simply nothing to put an example on social networks - selling expensive equipment for organizations. If we consider that the site is frankly left (intermediary, or sells goods by gray), then it becomes even more difficult to promote it. I recommend to contact seo company directly. I note that some sites practically do not publish new articles.

[manish64]

those are two different process so implementated differently