1

A Guide to SupportDesk ITSM

1 Introduction

Terminology: All SupportDesk systems are built around the same default terminology. In SupportDesk ITSM, the Customer and Inventory fields have been renamed as User and CI to better fit an ITSM environment. Wherever possible in this guide, the original (Data Dictionary) name for each field will accompany the SupportDesk ITSM name for each field in triangular brackets.

Call: the generic term for a record in any of the Call Folders e.g. Incidents, Problems & Change Requests.

If as part of your SupportDesk system you have purchased the ITIL Pack, you will have the functionality to handle IT Service Management as prescribed by the IT Infrastructure Library (ITIL) ®.

Then following sections explain how the ITIL-Pack is configured to support the various elements of ITIL Service Management.

2 The Main Window

Click on the different Call Folders to display the Live Calls view where you can access all live Incidents, Problems and Change Requests, search for particular Calls and log new ones (depending on privilege levels set by an administrator in Login Management).

2

Figure 1: Main Window

3 Folders

The ITIL Pack comes with different Folders already pre-configured for your Incidents, Problem and Change Management processes, with the different Folders and their Folder types described next.

Figure 2: ITIL Settings on Folder Management

Figure 3: SupportDesk ITSM default Folder Setup

4 Incident and Problem Management

For years, the lifecycle of receiving, recording, resolving and reporting on issues or requests was referred to as ‘problem management’. The ITIL framework makes a useful distinction between two related processes, previously lumped together under the problem management banner.

Incident Management refers to the calls or requests that your service desk deals with on a day-to-day basis. Problem Management, in contrast, is to do with the resolution of underlying issues that may cause some of your day-to-day incidents.

Click NEW to open a new call form

Select a view to apply to the main window

Double-click to open any Call and view full details

Sort by any heading, or use the Find tool to search for keywords or reference numbers

Folder list: select different folders to display different ITIL Call types.

3

Having a dedicated Problem Management Folder separate from Incident Management allows you to monitor the differing life cycles of these records more effectively. But we can also link incidents and problems to monitor more closely the cause and effect relationships that may exist between these call types.

The Incident and Problem Management Folders work in much the same way. However, the forms differ in some ways.

Figure 4: Incident form

Figure 5: Problem form

With separate Folders for Incident and Problem Management, you are free to configure the workflow for each Folder differently. You can also configure the individual Call fields and terminology to be used in each Folder in their respective Data Dictionaries.

5 Change Management

ITIL best practice makes another distinction between the tracking and resolution of Problems and the characteristically more rigidly structured process of Change Management.

A Request for Change (RFC) can be raised independently of a Problem (such as a change brought about from above by the business) but is often related directly to the successful resolution of problems (for example, the implementation of a new email server to resolve the problem of intermittent email access for multiple users).

As a result of RFCs often relating to the physical IT environment and possible repercussions of a change, RFCs may need to be related to multiple CIs. The Change Management Folder therefore has special functionality to enable Changes to be raised relating to more than one CI <Inventory> or User <Customer>.

4

Figure 6: Launching a Change Request for multiple PCs

By selecting multiple CIs and then selecting New Change Request from the Quick Calls! menu, it is possible to launch a Call in the Change Request folder that is linked to each of those CIs via Activities. For general information on how to use and configure Activities, please consult the SupportDesk Documentation Suite.

Figure 7: Activities sub-tab on a Change Request

6 CMDB

ITIL also impresses the need to utilise a CMDB and specifically the cause and effect relationships between incident, problems, change requests, customers and CIs. Central to this is the idea of linking records to represent these relationships. In SupportDesk ITSM, it is possible to link incidents, problems and changes in various combinations. A discussion of the various relationships that can be configured follows.

Linking Calls at the Same Level

The principle of linking Calls means you can easily keep track of related issues.

For example:

Incident A: I cannot access Outlook on my PC today

Incident B: I cannot send or receive email since this morning

Assume that the CIs (in this case PCs) related to both incident A and B need to access Server A to perform email functions. This would make a relatively strong argument for linking Incidents A and B, since they may well turn out to have the same root cause.

Linking Calls Hierarchically

Consider the previous example. Perhaps, after further investigation (and further incidents with similar subjects), it is discovered that Server A is unreliable and spends an unacceptable amount of time offline. In this situation, it is reasonable to raise a Problem to record this server’s unreliability.

5

For example:

Problem: Server A is sporadically going offline

With the logging of this problem, you will not want to link the related Incidents to each other but to the Problem record via hierarchical links. In this situation, you would link the incidents as children to the Problem record. Normally a Change Request would be raised as a parent of a problem record. This keeps a logical hierarchy to all linked records and enables you to use the ‘close linked records’ button from the top level call to close all calls below.

Linking Calls: How it’s done

Figure 8: Linking Calls

7 SLAs the ITIL Way: Impact, Urgency & Priority

The SupportDesk ITIL pack comes with a preset SLA structure based on ITIL’s suggested Impact + Urgency = Priority model. Priority will automatically adjust depending on the sum of the other two fields:

Figure 9: Selecting Impact and Urgency

2. Minor + 0. High = 2. Medium

Select which Folder to search for related Calls

Use chevron buttons to link and unlink records to the current Call

Select your search term from the drop-down of related items or write in a keyword

Choose to show either parents or children. Calls you create will be logged in line with the way this button is toggled i.e. parent or child of current call.

6

Impact: measure of the significance of this issue to the business

Urgency: measure of how quickly this issue should be dealt with

Priority: rank giving an indicator of the order in which issues should be addressed.

Each priority has deadlines associated with it, which can be edited from Service Level Management on the Setup menu. Be aware that priorities are locked into ITIL Folder types. You need to be sure to edit the correct Folder’s priorities.

Figure 10: Priorities and Deadlines

Figure 11: Priority Period Settings

You can further edit impacts, urgencies and priorities from within Service Level Management on the Setup menu. For more information, contact Support.

Respond within: the point where a call should have been first responded, represented by a status change.

Warning after: milestone warning of impending Action/Fix breach. Often set at an arbitrary point between other two deadlines.

Action/Fix within: the point where the call should be resolved or closed.

7

8 Types and Sub-types

Figure 12: Type Detail

Each Folder in SupportDesk ITSM has a set of categories that have been set to appear only in one Folder. They can be edited through the Folder and Folder Type drop-downs on each category (as above).

Use the Folder drop-down if the category in question only applies to one Folder. Use the Folder Type drop-down if you intend to have more than one Folder of each Folder Type.

Figure 13: Folder selection

9 Status

Statuses are a way of keeping track of the lifecycle of your different call types. SupportDesk ITSM comes with separate statuses for incidents, problems and changes already loaded. However, you will more than likely find that you will want to edit these to reflect your service desk workflow.

Use the Parent Category drop-down to parent a sub-type to a type.

8

Figure 14: Status Details

10 Activities

Activities are unusual in that they are not simply a value recorded by means of a field on the call form, but are a ticket in themselves. The most common way to use Activities is to record sub-tasks within a Call.

Using Activities to track OLAs

Another use for activities is to track Operational Level Agreements or SLAs you hold with your suppliers. This is also a very good example of how activities may be of use.

First, create an activity to record one of the SLAs you hold with one of your third parties and give it a name to reflect this (such as ‘Azlan Technical SLA’).

Figure 15: Activity Type Details

If you create a status, you can parent it to the activity so that, whenever you select it, the activity will also be launched and visible from the call form.

Lock a status into one folder type

Mark whether the status is a Responded, Resolved or Closed status

Parent the status to other statuses to preserve a rigid workflow

Use these fields to record the details of the SLA you hold with the third party.

9

Figure 16: Status with Child Activities

Figure 17: Call showing Child Activity

Scheduled date indicates the point where the OLA breaches. At this stage, notifications can be triggered, via email and pop-up, to the assignee of the call or even the third party itself (requires SupportDesk Escalation and Email modules).

Select the Activity to be auto-launched

Give the status a suitable name to reflect its use

10

11 Analysis

Figure 18: Analysis Details

The analysis drop-down is designed to record the reason for closure (or Closure Code). Analysis is a way to re-evaluate the call at point of closure and is closely associated with the solution. As a result, the value selected in this drop-down may differ to the value in the type drop-down. For example:

Type: Service Impacted

Sub-Type: Application Error

Analysis: No Fault Found

In this example, the cause of the incident turned out to be that the end-user did not know how to correctly use his equipment!

12 Closing Calls the ITIL Way

According to ITIL, you can never close an Incident until the related Problem has been solved and a Change has been implemented. However, we’ve elected to give you the choice!

To close a Call without closing linked calls (either because you don’t want to or there aren’t any), simply select the closed status on the Call form.

To close all linked calls to the call you are currently viewing, go to the Search & Link Related Calls tab and click Close All Linked Records. You will then be asked to enter a solution, which will be applied to all of the calls to be closed.

Note: Pressing the Close All Linked Records button for a call only closes calls hierarchically lower than that call. Therefore, if it is parented as previously suggested, a change will result in problems and incidents being closed, but a problem with only close incidents and leave any associated changes open.

11

Figure 19: Close All Linked Records button on Search & Link Related Calls form

If you are using the SupportDesk Email Module, all automatic emails set to be sent on the closure of a call will be sent for all related calls, reducing the need for further contact with each customer.

13 Further Information

We hope this guide proves useful and helps you to understand SupportDesk ITSM’s Service Management framework. However, if you require further assistance, or to request additions to the guide or SupportDesk ITSM program, please contact itil@houseonthehill.com