This documentation supports the 22.1 version of BMC Helix ITSM: Service Desk.To view an earlier version, select the version from the Product version menu.

Incident Management overview

The primary goal of the incident management process, according to ITIL standards, is "to restore normal service operation as quickly as possible with minimum disruption to the business, thus ensuring that the best achievable levels of availability and service are maintained." The mission of the incident management process is to resolve incident requests as quickly as possible in a prioritized fashion.Incident Management is designed to support this goal.

Incident Management is typically initiated in response to a customer call, a service request, or an automated event. An example of an automated event might be an alert from a monitoring system, such as BMC ProactiveNet Performance Management (BMC BPPM). 

Related topics

Incident management user roles

Problem management user roles

Best practice
When dealing with incident requests, the following best practices are critical for success:

  • Prioritization so that incidents that cause the organization the most pain (such as lost sales or work stoppage) are fixed first. This approach conserves your resources, and uses them where they are most needed. 
  • Consistent recording of incident request details. These details are then made available to other applications, such as BMC Helix ITSM: Change Management. This means that entries can be searched, analyzed, and communicated throughout the organization. 
  • Integration with BMC Helix CMDB. This information can be used both to resolve the immediate incident and to determine whether other systems might be affected.

An incident is any event that is not part of the standard operation of a service and that causes an interruption to or a reduction in the quality of that service. Normal service operation is the operation of services within the limits specified by the service target. When integrated with Incident Management, BMC Service Level Management monitors service targets. 

The incident management process also handles customer requests for service, such "I need a new laptop," or "I need access to this network resource." Customers can use BMC Service Request Management to enter service requests. If BMC Service Request Management is not available, your organization can use Incident Management.

Business value

BMC Helix ITSM: Service Desk acts as a single point of contact for user requests, user-submitted incidents, and infrastructure-generated incidents. BMC Helix ITSM: Service Desk is the anchor product that enables you to get started with Service Desk Optimization.

BMC Helix ITSM: Service Desk consists of two features: Incident Management and Problem Management.

These ITIL-compliant applications automate the incident and problem management processes to enable IT to respond quickly and efficiently to conditions that disrupt critical services.

Incident Management focuses on getting users up and running after disruptions.

Problem Management focuses on determining the root cause of a problem, and on using the BMC Helix ITSM: Change Management processes to correct the root cause.

The following graphic shows the relationship between incident, problem, and change management processes for user requests:

Apps_Relationships.png

End-to-end process

The following figure provides an overview of the incident request lifecycle. The incident management process consists of the following procedures for handling requests from users.

  1. Service desk analysts register incident requests for users.
  2. Service desk analysts and group coordinators assign incident requests to the appropriate specialists or change coordinators for resolution or implementation.
  3. Group coordinators track incidents to manage reassignment notifications or SLA escalations.
  4. Specialists resolve incident requests that have been assigned to them.
  5. After an incident has been escalated, the service owner of the affected service determines how the incident can be resolved in the most efficient manner.
  6. Service desk analysts resolve and close incident requests, and requesters can review incident requests that have been completed for them.
  7. When their approval is requested, group coordinators review a solution that has been proposed for general use.

Incident Management Process.png

Watch the following video (7:31) to learn about the basic flow of the Incident Management process.

Disclaimer

Although the concepts and procedures presented in this video are correct, the user interfaces shown are not current.

icon-play.pnghttps://www.youtube.com/watch?v=-nwIS66hsTI

How the Process Flow Status area displays the flow

The Process Flow Status area displays the flow of the incident request through the stages of the process in blue. The current stage of the incident is highlighted in green. The status of the incident is indicated by both color and text. At each stage, the diagram provides applicable accelerators. When you select an accelerator, you are prompted to enter the data required to complete the task. You can also enter optional recommended data in the dialog box.

processvis_46834_516.gif

Watch the following video (2:12) to learn about the basic flow of the Incident Management process.

Disclaimer

 Although the concepts and procedures presented in this video are correct, the user interfaces shown are not current.

icon-play.pnghttps://youtu.be/BPqgxrvTDSg

How incident ownership is determined

Based on the following criteria, Incident Management automatically determines incident ownership when the incident request record is created:

  • Presence of relevant Incident Owner events in the Assignment Configuration (see Configuring assignments).
  • The default support group of the person who submits the incident request record.
  • The support group the incident request record is assigned to.

For example, consider the following support groups:

  • Support Group A has a support group role of Help Desk. The default support group of Person A is Support Group A.
  • Support Group A2 also has a support group role of Help Desk. Person A is not a member of Support Group A2.
  • Support Group B does not have a support group role of Help Desk; for example, it might have a support group role of Tier 2. The default support group of Person B is Support Group B.
  • Support Group C does not have a support group role of Help Desk; for example, it might have a support group role of Tier 3.

Based on these support groups, the following example events show how the incident owner is set when no incident owner assignment event is predefined:

  • Person A submits an incident and assigns it to Support Group A2 with the role of Help Desk. Ownership of the incident is set to Support Group A2 because the Assigned Group has the role of Help Desk. Otherwise, ownership of the incident is set to Support Group A, as it is the default Support Group of A.
  • Person B submits an incident and assigns it to Support Group A. Ownership of the incident is set to Support Group A because the group has the role of Help Desk.
  • Person B submits another incident, and assigns the incident to Support Group C. Support Group B becomes the owner, because Person B is the submitter.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*