Incident Management
Incident Management is arguably the most important and visible process in ITSM, documenting the break/fix activities of a service.
| Flow Chart Label | Tier Level | Detail |
| 1-3 | 1 | Incidents are created via the Service Desk (1), or automatically generated by Event Management (2). The Service Management system can be configured to route Incidents based on rules. In this example, the impacted service is a software application, and the Incidents are routed to a Level 1 group. The individuals with a Level 1 designation typically have the minimal skillset required to perform basic triage (3). |
| 4-7 | 1 | The Level 1 analyst queries the Knowledge Management System (4) for known issues related to the Configuration Item (CI) listed on the Incident. If the Incident is caused by a known issue (5), and the fix can be performed by Level 1 (6), the Level 1 analyst performs the remediation steps documented in the Knowledge Management system, and resolves the Incident (7). If the Level 1 analyst cannot identify the issue as known (5), or if the known issue cannot be resolved by Level 1 (6), the Incident is escalated to Level 2. |
| 8-12 | 2 | The Level 2 analyst is a Subject Matter Expert (SME) on the Service impacted by the Incident, having the skillset required for advanced troubleshooting (8), typically including some query, coding, testing, and analysis experience. This analyst will check the CI (9, 10) to identify similar Incidents, ensure the Level 1 analyst didn’t overlook a known issue, and check if the issue could be related to a recent release. If the Level 2 analyst successfully addresses the issue (11), the Incident is resolved (12), and the Knowledge Management system is updated with any instructions allowing Level 1 to address future similar incidents (4). If the issue cannot be resolved by Level 2 (11), findings are added to the Incident (including verification of the issue by replicating in a test environment), and the Incident is escalated to Level 3. |
| 13-17 | 3 | The Level 3 tier could consist of the architects, database administrators (DBAs), developers, and business analysts responsible for the service. The nature of the incident determines which resource troubleshoots (13) the issue. Outages, transaction failures, and other errors typically are routed to architects and DBAs. Unexpected application results are often reviewed by the business analyst, who may work with the developers to diagnose the issue. If a defect (software bug) is not identified, or the defect does not require a release (15), then the Incident is resolved (16) and the Knowledge Management system is updated with any instructions allowing Level 1 and/or Level 2 to address future similar incidents. If the Incident was caused by a defect (14), and a release is required to address (15), the Change Management (17) process is initiated. |
3 Replies to “Incident Management”