Service Manager

This is the latest version of the help for Ivanti Service Manager 2018. If you cannot find some of the features described in the help, you may be using an older version of the application. To upgrade the application, click here.
To view the help for the latest version of Service Manager, click here

About Incident Management

An incident is defined by ITIL as any break in the standard operation of a service that causes or might cause an interruption or reduction in the quality of that service. The goal of incident management is to restore normal services as quickly as possible when an IT service has been disrupted, and to make sure that business operations function normally. The definition of normal service is agreed to in service level agreements with the customers of your organization.

Incident management reduces or eliminates the effects of potential disruptions on IT services, so that end users can get back to work as soon as possible. To achieve this, the system records, classifies, assigns to specialists, and monitors the progress of incidents until they are resolved and closed. Service level agreements and escalations (in the absence of service level agreements) ensure that incidents are responded to and resolved on time with satisfactory resolution rates.

Incident control is the process of identifying, recording, classifying, and monitoring incidents until the impacted services are restored.

Default Incident Management Processes

Service Manager follows these key processes of incident management as defined by ITIL:

•Incident Detection and Recording

•Classification and Initial Support

•Resolution and Recovery

•Incident Closure

•Ownership, Monitoring, Tracking, and Communication

Incident Detection and Recording

Users can submit an incident in the following ways:

•By using the Self-Service Portal: A user creates an incident from the Self-Service Portal and the system notifies the Service Desk Manager who assigns the incident to a Service Desk Analyst.

•By contacting the Service Desk by phone or email: A user calls or emails the Service Desk. A Service Desk Analyst then creates an incident.

•By sending an email: The Service Manager email listener allows a user to create an incident directly from an email.

•By calling: If your Service Manager system uses HEAT Voice, a user can create an incident from a phone call.

The system automatically assigns a unique reference number (called a RecID) and date time stamp (CreatedDateTime) to each incident.

Service Desk Analysts can effectively capture key information about the incident from the Incident workspace. End users and Service Desk Analysts can search the Knowledge Base for solutions during incident recording. If a resolution exists in the Knowledge Base, the Service Desk Analyst resolves the incident without further action.

The Incident workspace helps you to manage your time and work efficiently while creating or working on incidents by providing the following features:

•Quick actions: Quick actions enable you to perform an action with a single click. From the Incident workspace, you can select an incident and perform a quick action on it without opening the incident directly.

•Open new tabs: You can open additional tabs to work on new issues or to view other modules while keeping your current sessions active.

Classification and Initial Support

Classifying and initially supporting an incident is accomplished by the following:

•In the Incident workspace, the system classifies incidents by service and category. When you select a service from the drop-down list, for the Service field on the Incident workspace, the system populates and filters the category menu with options from the service that you selected.

•Categorizing incidents allows the system to appropriately assign 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. This allows the system to identify trends in failures of similar services or categories. 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. See Default Priority Values.

Resolution and Recovery

•When a Service Desk Analyst fixes an incident, they set the status to resolved.

•The system tracks escalations, as configured by service level agreements (or the escalation engine in the absence of an service level agreement) of active incidents. An incident is considered breached if a Service Desk Analystt does not respond to and resolve it within a certain amount of time.

•During the initial classification of an incident, you can match the incident to another incident, a problem, or a Knowledge Base article by searching on the keywords in the Summary field of the incident. If the system finds a resolution or workaround, 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 end user.

•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 than 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, 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.

Incident Closure

The system automatically closes an incident that is in the resolved status after a certain number of days. By default, the system closes incidents after one day if there is no further communication from the user. Service Desk Analysts close incidents through the escalation engine service. The user or a Service Desk Analyst can reopen incidents that are in the resolved state if the resolution is not satisfactory.

After the incident is set to closed, a Service Desk Analyst or Service Desk Manager can review all of the information for the incident and update its details. The system sends a link to a survey to the user, giving them an opportunity to rate the effectiveness of the Service Desk in resolving the incident.

Ownership, Monitoring, Tracking, and Communication

•The system tracks and monitors incidents throughout their lifecycle until closure.

•Throughout the incident management process, the system notifies users when there is a change in the status of the incident, such as when the incident is set to resolved. Users can provide feedback through a survey to rate their satisfaction with the resolution and can reopen the incident if the resolution is not satisfactory.

•The system notifies the Service Desk when a user creates an incident, and notifies the incident owner (the Service Desk Analyst who the incident is assigned to) when the incident is assigned. The system notifies the appropriate users, such as the user, the incident owner, or the Service Desk Manager whenever the status or priority of the incident changes, or when other conditions are met. Service Manager has default notification business rules but the administrator can configure new business rules to better manage incidents in your organization.

•When an incident is closed, it remains in the system and you can view it for reporting and analytic 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 being worked on, and get a final cost associated with the incident when it is resolved or closed.

•Survey feedback from customers provides 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, a Problem Manager can view trends in incidents and determine if incidents are actually problems; a Configuration Manager can view configuration items that were reported as failures.