Identify and Record Major Critical Incidents

The diagram describes the various phases in the life-cycle of a Major Critical Incidents. In this blog I will be delving into the First phase, which is the Identification and Recording of the Critical Incident.
Here is the flow chart for the Identification Process. I will also show how RACI plays an important role in designating responsibility. R=Required A=Accountable C=Consulted I=Informed.

– Service Desk Analyst – Support Group

1. A request is received. A User contacts the Service Desk to lodge a service request, seek information or record an incident. The is Responsible and Accountable.

2. The next activity is deciding what is the request type? The reviews the request – directing it to either the Service Request Management Process, or the Incident Management Process dependent upon respective entry criteria. Decision – The Request type is a Request / Query OR Decision – The Request type is an Incident. (a) If Request/Query, go to step 3 (b) If Incident, go to step 4. The is Responsible and Accountable.

3. Based upon the assessment of the initial request the records and lodges a service request within the service management system. This kicks off the Service Request Management module. The is Responsible and Accountable.

4. The verifies that the request is an incident and reviews the service management system for similar existing incidents. This after s/he confirms that the request type is an Incident. The is Responsible and Accountable.

5. The searches for duplicate incidents. (a) If Yes, go to step 6 (b) If No, go to step 7. S/he takes a decision – The Incident is a Duplicate OR Decision – The Incident is not a Duplicate. This is to check if this kind of incident already exists in the system. The is Responsible and Accountable.

6. The identifies a duplicate incident, using this information to gain a better understanding of both the impact and potential resolution requirements. If it is a duplicate, it is mapped to existing Incident which is already existing in the system. The is Responsible and Accountable.

7. The creates a new Incident recording required attributes based on the fact that it is not a duplicate. The is Responsible and Accountable. The is Informed.

8. The searches the knowledge base and completes incident matching activities within the Service Management tool. Now the incident is created. The is Responsible and Accountable.

9. The Service Desk Analyst references the Technology Incident Management (Incident Prioritization document) to asses both the Urgency and Impact of the incident. This provides the initial Priority assessment of the incident. Based on the findings the priority is assessed and set. At this stage the is still Responsible and Accountable.

10. The control now moves to the support group. The manually detects an incident, through observation, monitoring or other means that are available. If the Service desk analyst specifies that the incident is critical, they are notified immediately. The is Responsible and Accountable.

11. Automated monitoring detects the failure or potential failure of a component under management. This incident is detected typically by the Event Management process. The is Responsible and Accountable.

12. The , either manually or automatically, creates a new Incident recording and verifying all required attributes. The is Responsible and Accountable.

13. Now that the incident is created, the assigns and confirms the urgency and criticality of the incident. The assigns references the Technology Incident Management (Incident Prioritization document) to asses both the Urgency and Impact of the incident. This provides the initial Priority assessment of the incident and that it is a Critical Incident. The is Responsible and Accountable.

This concludes the Identification and Recording which is the phase I of the Major Incident Management Process. Please look out for my next phase shortly (Investigation and Diagnosis).

Authored by Vijay Chander – All rights Reserved – 2023