Incident Management

By default HEAT follows the key processes of Incident Management as defined by ITIL.

Incident Detection and Recording

An end user or IT requester can submit an incident in the following ways:

• Directly to the Service Desk by using the Self Service module (see Self Service help for how to do this). A requester creates an incident, the service desk is notified by email, the incident is assigned, and the Service Desk Analyst processes the incident.
• By contacting the service desk by phone or email. The Service Desk Analyst creates an incident when receiving a call.
• The email listener allows the requester to create an incident directly from an email.

If your HEAT environment is using FrontRange Voice (or IPCM), incident records can also be created from customer phone calls.

Analysts can effectively capture key information on the incident from the incident form. Requesters and Service Desk Analysts can search the knowledge base for solutions during incident recording. If a resolution exists in the knowledge base, the incident is resolved without further action.

The user interface helps you to manage your time and work efficiently while creating or working on incidents.

• Quick actions: Quick action buttons enable you to perform an action with a single click. On the Incident tab, you can select a form and perform a quick action without opening the form directly.
• Open new tabs: You can open additional tabs to work on new issues or view other modules while keeping your current sessions active.

Classification and Initial Support

Classifying and initial support of the incident is aided by the following:

Categorization

On the incident form, incidents can be classified by service and category. When you select an option from the service menu on the incident form, the category menu is filtered and populated with options from the service you selected. You can also click the service map button after selecting a service to view a topology map of the selected service in the context of other services that are upstream or downstream. This is useful if you are identifying failures with the current service.

Categorizing incidents enables appropriately assigning them to specialists by matching categories with skills. For example, an incident with a category of desktop hardware could be assigned to the desktop hardware group.

Categorizing incidents not only identify services that failed, but also configuration items that encountered failures. A trend in failures of similar services or categories can be identified as a problem. Categorization is also useful for reporting purposes.

Default service level agreements are attached to some services. If an incident matches a service with a configured service level agreement, the incident should be resolved according to the terms of the service level agreement as defined for the organizational unit of the incident customer.

Priority

See Default Priority Values

When the incident is fixed, the status is set to resolved.

Escalations configured via service level agreements (or the escalation engine in the absence of an service level agreement) track the progress of active incidents to resolved status. An incident is considered breached if it is not responded to and resolved within a certain amount of time.

Incident Matching. During the initial classification of an incident, each incident can be matched to another incident, a problem, or a knowledge base entry by initiating a search on the keywords in the incident Summary field. If the incident is matched and the resolution or workaround is found, you can bypass the investigation and diagnosis process and resolve the incident.

Incidents can be resolved during the initial contact with the Service Desk, thus ensuring a quicker restoration of normal service for the requester.

The objective of Incident Management during an incident is to restore normal service as quickly as possible. The objective is not to make a system perfect. If service can be restored by a temporary workaround quicker then by correcting the underlying root cause of the issue, then that is acceptable. Correction of underlying root causes is done after service is restored by the Problem Management team by a process called root cause analysis. If the cause of the incident is actually a problem, then the Service Desk Analyst can work with the Problem Management process by linking an incident to a problem or by creating a problem to link to an incident.

An incident in resolved status is automatically closed after a certain number of days (by default, incidents are closed after one day) if there is no further communication from the requester. Incident closure is achieved through the escalation engine service. Incidents that are in resolved state can be reopened by the requester or the analyst if the resolution is not satisfactory.

After the incident closure, the analyst or manager has the opportunity to review all the information and update details. After the incident is closed, a link to a survey is sent to the customer, giving the customer an opportunity to rate the effectiveness of the Service Desk in resolving the incident.

Incidents are tracked and monitored throughout their lifecycle until closure.

Throughout the Incident Management process, users are notified when there is a change in the status of the incident and when the incident is resolved. Users are given the opportunity to provide feedback in the form of a survey to rate their satisfaction with the resolution and given the opportunity to reopen the incident if the resolution is not satisfactory.

Service Desk staff is notified when there new records are created, and the incident owner is notified of incident assignments. Notifications are sent to the appropriate users whenever there is a change to the incident's status and priority, or when other conditions are met. Notification business rules are configured by default, but your application administrator can configure new business rules to better manage incidents in your organization.

After incidents are closed, they remain in the database and are viewable for reporting and analytics purposes. Service Desk Managers can view and generate dashboards and reports to determine how the Service Desk performed against service level agreements (or escalations in the absence of default service level agreements).

Service Desk Managers can also view the cost of the incident while it is worked on, and get a final cost associated with the incident upon the incident's resolution or closure.

Survey feedback from customers provide valuable metrics on the effectiveness and timeliness of the Service Desk in resolving incidents as well as helps Service Desk Managers track the performance of the Service Desk Analysts.

Other process owners can also view dashboards and generate reports from incidents to aid their processes. For example, the Problem Manager can view trends in incidents and determine if incidents are actually problems or the Configuration Manager can view configuration items that were reported as failures.