Incident Management

BMC Helix Network Service Operations for Communication Service Providers is committed to supporting TMF API and ODA standards for essential ecosystem integrations required for the CSP market success. These standards help ensure service delivery excellence spanning the entire infrastructure. BMC has been collaborating with TM Forum in its path to help drive digital transformation as CSPs continue their journey to becoming an Autonomous Digital Enterprise. For example, the Alarm Schema is aligned to the TMF definition and the Source Information is also a TMF defined schema.

By using BMC Helix Network Service Operations for Communication Service Providers, incidents are automatically created in Incident Management. You can then handle them throughout their lifecycle: from creation to closure. BMC Helix ITSM, however, is more than just a tracking tool for tickets. It helps you to resolve incidents by proactively suggesting related tickets and knowledge articles that you can use to understand how other similar tickets were resolved.

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.

Related topics

Managing-alarms-by-using-REST-API

Managing-incident-requests

Roles-and-permissions

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. 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 following video (2:57) helps you to learn about Incident Management in BMC Helix ITSM. 



icon_play.png https://youtu.be/hVUsAnHZcFU


Business value for BMC Helix ITSM

BMC Helix ITSM provides an intuitive, social, and mobile service desk experience that enables a more knowledgeable and collaborative workforce organized around IT roles, not modules.

BMC Helix ITSM: Service Desk acts as a single point of contact for user requests, user-submitted incidents, and infrastructure-generated incidents. The workflows automate the incident 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.

Fast and efficient ticket logging

BMC Helix ITSM provides a single interface to create multiple ticket types such as incidents based on alarms. Ticket creation is faster with a limited number of required field values.

Information for quick ticket resolution

You can add the following additional information to the incident for a quick ticket resolution:

  • Tasks
  • Configuration Items
  • Related Items
  • Related Parties
  • Source Information

For more information, see Managing-incident-requests.


End-to-end process

The following figure provides an overview of the incident lifecycle. 

Incident life cycle_updated.png



Stages of an incident

BMC Helix ITSM helps you manage incidents through the following stages:

Stages

Description

Incident registration

When an alarm is created through REST API, an incident is automatically created in Incident Management.

To manually create a new incident, see Creating-an-incident-request.

Incident assignment

Administrators configure BMC Helix ITSM, so that when you create an incident, it is automatically assigned to a support group. When you record an incident, if you select an incident that has an assignment group predefined, the incident is assigned to that group. Otherwise, the routing rules used by Incident Management automatically assign the incident request to the most appropriate group when you save the incident request record. 

Check the Ticket Console to see which incidents are assigned to you or to your support group. You can assign the incident to yourself by clicking the Assign to me option.

Ticket console.png

Incident tracking

After you create a incident, you can change the details or add new information to it. For example, you can update the incident status, add related parties, related items, create source information, or change the customer and contact information. If you share a knowledge article with the end user, you can save the article to the incident.

Best practices: Keep the information in a incident up-to-date. This helps you to make better informed decisions about how to manage the incident, keep your personal and group statistics up-to-date, and notify the affected customer about the progress of the incident.

In the following image, the Activity tab shows the history of the incident and includes an activity note.

Incident tracking.png

Incident resolution

The alarms are automatically cleared through the Fault Management System with a call from the REST API. After all the tasks and alarms that are attached to the incident are resolved or cleared, if the incident is in the In Progress status, the status of the incident automatically changes to Resolved. If the incident is in the Assigned status, you must manually change the status of the incident to Resolved. If the incident is in Resolved status and you open the alarm again with the alarm severity value to any other value than Cleared, the status of the incident changes to In Progress. Once the incident is closed, you cannot update the alarm severity from Cleared to any other value.

When you're ready to resolve an incident, you mark the incident as resolved, select the appropriate status reason, and add a resolution note.

Incident tracking.png

Incident closure

When you resolve the incident, you can change the status to Closed immediately.


How incident ownership is determined

Based on the following criteria, Incident Management automatically determines incident ownership when the incident 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.


Test your knowledge

Check your knowledge. See if you can answer each question. Click the questions to view the answer.

How can you determine which open incidents to work on?

Check the Ticket Console to see which incidents are assigned to you or to your support group.

What's the difference between resolving an incident and closing an incident?

Resolving an incident means that you think the incident is ready to be closed, but you do not yet have confirmation from the customer. You can close an incident after the customer verifies the resolution.

 

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