can anyone explain Process flow of incident problem change management?

aparna reddy1
Tera Contributor

hii all, 

 

can anyone please expalin the  Process flow of incident problem change management?

 

thanks in advance

1 ACCEPTED SOLUTION

Aoife
Tera Guru

Something breaks -> Incident is opened 

During analysis for resolve Incident, more Incidents come in for same thing or a determination is made that there is a way to fix it but to prevent it from happening again there is more work -> Problem is Opened

During RCA on the Problem, a work around is found, report it back to open Incident tied to the Problem.

Permanent fix is found for Problem -> Change Request is opened to fix it and apply the fix.

There can also be a Major Incident in between Incident and Problem, or instead of a Problem.  A Major Incident is not for the faint of heart, it is a rigorous method to maintain visibility, create war rooms, setup phone bridges, radiate information, etc. regarding the ongoing efforts to fix an outage, or similarly bad thing that has happened.

That's the 30,000ft view of it.

Quick examples:

Incident -> a server just crashed, fixed by savaging parts from a standby server.

Problem -> now we do not have a standby server, need to order parts.

Incident -> an application just quit responding

Incident 2 -> another application on the same server or the same application just quit responding for another user

Incident 3 -> another application on the same server or the same application just quit responding for another user

Problem -> Something may be wrong with the server, or a shared library that all the applications use or another server that the all communicate with via REST, or something of that sort.

Workaround -> restart the applications in question, seems to be working again

RCA -> determine why it happened and if more needs to be done to prevent it in the future

Solution found -> Open a Change Request to make the change(s) and apply them.

Close the Problem

 

Aoife

View solution in original post

1 REPLY 1

Aoife
Tera Guru

Something breaks -> Incident is opened 

During analysis for resolve Incident, more Incidents come in for same thing or a determination is made that there is a way to fix it but to prevent it from happening again there is more work -> Problem is Opened

During RCA on the Problem, a work around is found, report it back to open Incident tied to the Problem.

Permanent fix is found for Problem -> Change Request is opened to fix it and apply the fix.

There can also be a Major Incident in between Incident and Problem, or instead of a Problem.  A Major Incident is not for the faint of heart, it is a rigorous method to maintain visibility, create war rooms, setup phone bridges, radiate information, etc. regarding the ongoing efforts to fix an outage, or similarly bad thing that has happened.

That's the 30,000ft view of it.

Quick examples:

Incident -> a server just crashed, fixed by savaging parts from a standby server.

Problem -> now we do not have a standby server, need to order parts.

Incident -> an application just quit responding

Incident 2 -> another application on the same server or the same application just quit responding for another user

Incident 3 -> another application on the same server or the same application just quit responding for another user

Problem -> Something may be wrong with the server, or a shared library that all the applications use or another server that the all communicate with via REST, or something of that sort.

Workaround -> restart the applications in question, seems to be working again

RCA -> determine why it happened and if more needs to be done to prevent it in the future

Solution found -> Open a Change Request to make the change(s) and apply them.

Close the Problem

 

Aoife