Incident Management – High Level Overview

Hi I am Ketan Ghelani, Program Manager on the Service Manager Team responsible for Incident and Problem Management. I will write a series of posts on Incident Management. I will show how to map a sample Incident Management Process scenario to the capabilities of Incident Management in Service Manager. Here is the roadmap for the posts.

– High Level Incident Management processes and Incident Management capabilities in Service Manager (This post)

– Describe a sample business scenario case and define the process

– Map the process to the Incident Management Capabilities in Service Manager (This will be probably a series of its own)

The objective of Incident Management Process is to restore normal operations as quickly and cost-effectively as possible with minimal impact on business or the user. MOF and ITIL both provide a framework to define the processes and best practices for Incident Management. MOF refers to it as the Customer Service Service Management Function (SMF).

MOF’s Customer Service SMF flow is defined here. The figure below shows a high level representation of the Incident Management process


Some of the best practices for the incident management process includes following key elements:

· Incident detection and recording: Ensures all incidents are tracked and provides information to aid with problem management.

Classification and Initial Support: Classification ensures that incidents are correctly categorized, prioritized and routed to the proper support resources. Initial support processes allow new incidents to be checked against known issues to facilitate quick resolution.

· Investigation & Diagnosis: Provides a structure to troubleshooting (e.g. investigation, diagnosis and resolution) till closure. The incidents are tracked and monitored throughout the life cycle.

· Resolution and Recovery: Provides the steps required to resolve the incident, often by interfacing with the change management process to implement remedial actions. If the incident is not resolved it is escalated.

· Escalation: Provides handling for major incidents that require a response beyond the normal incident process. This includes management and functional escalations, effective communications, and formal rollback plans.

The Service Manager Incident Management solution is built on top of Service Manager using the SDK. I have described below platform capabilities at high level in context of Incident Management:

  • Incident: Incident class in Service Manager is derived from a generic WorkItem class in service manager (model-based database post)
  • Queues: Service Manager provides capabilities to create queues for Incidents, based on the properties of the incident. For example you can create a Tier 1 Queue that contains all incidents that have Support Group property set to “Tier 1”. Queues are then used in views, security scoping and reporting purposes.
  • Tasks: Service Manager provides capabilities to create tasks that enable calling external tools or programs to retrieve data useful in making decisions while handling an incident. , that could help troubleshoot incident. Some of the tasks you’ll see out of the box for Beta 1 are Ping and Remote Desktop tasks.
  • Templates: There are two types of templates in Service Manager, Notification templates and Form templates. These templates can be applied through incident lifecycle. Service Manager will provide a number of templates out of the box. Customers can also create new templates based on their requirements.
  • Workflows:A sequence of activities (workflow activities) that automate a business process (such as automatic resolution, auto e-mail response). There are several out of the box workflows provided for Incident Management.
    • In Beta 1 the workflows provided are:
      • SCCM DCM-Integration Workflow: Enables creation of incidents from DCM compliance errors and apply a specific template..
      • Automated Incident Changes: Ability to kick-off a workflow that applies a specific template or notify someone based on any changes in an Incident property, for e.g. if the incident changes from priority 2 to priority 1 you can apply a specific template that assigns the incident to a specific group that is handling priority 1 incidents.
      • Notification Workflow: Notify personas via email when an incident matches certain criteria at some point along the Incident lifecycle.
    • We are also developing the following workflows for a future release:
      • Self Service Portal Workflow: Allows for an incident to be routed appropriately when users enters a new or updates the existing incident through a web page.
      • Email Workflow: Supports creation of new Incidents from emails to support desk.
      • Ops Manager Integration Workflow: Enables creation of incidents from alerts matching specified criteria in Ops Manager, and maintains synchronization between Ops Manager alerts and associated incidents.

In subsequent posts we will go into details of how we configure these workflows to meet specific business needs.