CA Nimsoft Service Desk

(1)

Rapid Workflow Implementation Guide

7.13.7

(2)

Legal Notices

Warranty

The material contained in this document is provided "as is," and is subject to being changed, without notice, in future editions. Further, to the maximum extent permitted by applicable law, Nimsoft LLC disclaims all warranties, either express or implied, with regard to this manual and any information contained herein, including but not limited to the implied warranties of merchantability and fitness for a particular purpose. Nimsoft LLC shall not be liable for errors or for incidental or consequential damages in connection with the furnishing, use, or performance of this document or of any information contained herein. Should Nimsoft LLC and the user have a separate written agreement with warranty terms covering the material in this document that conflict with these terms, the warranty terms in the separate agreement shall control.

Technology Licenses

The hardware and/or software described in this document are furnished under a license and may be used or copied only in accordance with the terms of such license.

No part of this manual may be reproduced in any form or by any means (including electronic storage and retrieval or translation into a foreign language) without prior agreement and written consent from Nimsoft LLC as governed by United States and international copyright laws.

Restricted Rights Legend

If software is for use in the performance of a U.S. Government prime contract or subcontract, Software is delivered and licensed as "Commercial computer software" as defined in DFAR 252.227-7014 (June 1995), or as a "commercial item" as defined in FAR 2.101(a) or as "Restricted computer software" as defined in FAR 52.227-19 (June 1987) or any equivalent agency regulation or contract clause. Use, duplication or disclosure of Software is subject to Nimsoft LLC’s standard commercial license terms, and non-DOD Departments and Agencies of the U.S. Government will receive no greater than Restricted Rights as defined in FAR 52.227-19(c)(1-2) (June 1987). U.S. Government users will receive no greater than Limited Rights as defined in FAR 52.227-14 (June 1987) or DFAR 252.227-7015 (b)(2) (November 1995), as applicable in any technical data.

Trademarks

Nimsoft is a trademark of CA.

Adobe®, Acrobat®, Acrobat Reader®, and Acrobat Exchange® are registered trademarks of Adobe Systems Incorporated. Intel® and Pentium® are U.S. registered trademarks of Intel Corporation.

Java(TM) is a U.S. trademark of Sun Microsystems, Inc.

Microsoft® and Windows® are U.S. registered trademarks of Microsoft Corporation. Netscape(TM) is a U.S. trademark of Netscape Communications Corporation.

Oracle® is a U.S. registered trademark of Oracle Corporation, Redwood City, California. UNIX® is a registered trademark of the Open Group.

ITIL® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries. All other trademarks, trade names, service marks and logos referenced herein belong to their respective companies. For information on licensed and public domain software, see the Nimsoft Monitor Third-Party Licenses and Terms of Use document at: http://docs.nimsoft.com/prodhelp/en_US/Library/index.htm?toc.htm?1981724.html.

(3)

Contact CA Nimsoft

Contact CA Support

For your convenience, CA Technologies provides one site where you can access the information that you need for your Home Office, Small Business, and Enterprise CA Technologies products. At http://ca.com/support, you can access the following resources:

■ _{Online and telephone contact information for technical assistance and customer}

services

■ Information about user communities and forums

■ Product and documentation downloads

■ _{CA Support policies and guidelines}

■ Other helpful resources appropriate for your product

Providing Feedback About Product Documentation

Send comments or questions about CA Technologies Nimsoft product documentation to

[email protected].

To provide feedback about general CA Technologies product documentation, complete our short customer survey which is available on the CA Support website at

(4)

(5)

Contents 5

Chapter 1: Introduction

7

Overview ... 7

Key Features ... 8

Tickets and Ticket Management ... 9

Auto-Routes ... 10

Workflow Action Options ... 11

Ticket Approval ... 13

Ticket Templates ... 13

Communication Templates ... 15

Support Groups and Roles ... 16

SLA Targets and Thresholds ... 17

Chapter 2: Out-of-the-box Application Records

19

Support Groups ... 19

Roles ... 21

Service Level Management Targets and Thresholds ... 23

Chapter 3: Request Management Workflow

27

Request Management Overview ... 27

Service Request Workflow Process ... 28

Service Request Related Records ... 30

Service Request Ticket Templates ... 30

Service Request Communication Templates ... 30

Service Request Auto Routes ... 31

Service Request Workflow Action Options ... 33

Chapter 4: Incident Management Workflow

37

Incident Management Overview ... 37

Incident Ticket Life-Cycle... 38

Incident Ticket Related Records ... 40

Incident Ticket Templates ... 40

Incident Communication Templates ... 40

Incident Auto-Routes ... 41

(6)

6 Rapid Workflow Implementation Guide

Chapter 5: Problem Management Workflow

49

Problem Management Overview ... 49

Problem Ticket Life-Cycle ... 51

Problem Ticket Related Records ... 53

Problem Ticket Templates ... 53

Problem Communication Templates ... 55

Problem Auto-Routes ... 56

Problem Workflow Action Options ... 57

Chapter 6: Change Management Workflow

61

Change Management Overview ... 61

Change Request Life-cycle ... 62

Standard Change ... 64

Normal Change ... 67

Emergency Change ... 70

Break-fix Change ... 73

Change Management Related Records ... 75

Change Ticket Templates ... 76

Change Communication Templates ... 79

Change Auto-Routes ... 80

Change Workflow Action Options ... 81

Change Approval Groups ... 100

Chapter 7: Known Issues and Points to Note

103

Known Issues ... 103

No Support Group related to Configuration Management Role ... 103

No Report an Outage Ticket Template for Analysts ... 104

Users will be unable to log Service Requests from the UI ... 106

Incorrect Matching Conditions for 'Withdraw Change' Workflow Action ... 107

No Communication Associated with Submit for Approval Workflow Action... 108

Points to Note ... 110

(7)

Chapter 1: Introduction 7

Chapter 1: Introduction

This document provides information on the out-of-the-box workflow configurations available when a new instance of Nimsoft Service Desk is created.

It provides information on the various application records that are available

out-of-the-box to support the workflow design, provides the workflow design for each ticket type and configuration records that form part of each workflow design.

You can choose to use the available workflow configurations as is or modify them to suit your specific support process needs.

Prior to modifying the workflow configurations, it is recommended that you review the existing design, identify the changes you wish to make.

Having done so, you should create a process flow diagram depicting the desired workflow process, identify the different records needed to support the flow and then begin any modifications.

Note: It is recommended that all application setup actions are complete before taking

up task towards modifying or customizing the workflow configurations. For detailed information about setting up the application with relevant application data and to understand the permissions model and how it affects users' interaction with the application, please refer to the Administrator Guide.

This section contains the following topics:

Overview (see page 7)

Key Features (see page 8)

Overview

The out-of-the-box workflows have been designed based on the ITIL service

management best practices; and using the key features of Nimsoft Service Desk. After setting up the application with required data; like Organization, Contact etc.; you can relate contacts to existing support groups, configured as part of the out-of-the-box configurations you and achieve rapid time-to-value by using the out-of-the-box workflows with little or no modifications.

Tickets can be logged by sending an email to the support email ID, or from the application either by using an existing ticket template, or by using the 'Create New' option. Other automated interfaces can also be configured to integrate with the ticket creation process; for example, alarms from the Nimsoft monitoring systems can be configured to result in ticket creation.

(8)

Key Features

Once the ticket is created, auto-routes can get applied to the ticket; which set the ticket into a pre-determined status for the analysts to work on. From this point on, the progression of the ticket through its life-cycle can be managed by a defined workflow process.

The out-of-the-box workflow configurations include auto-routes and workflow actions that manage the ticket through its life-cycle. Each ticket type has its own unique workflow design, including auto-routes which will assign the ticket to an appropriate support group based on ticket matching conditions, workflow action options which will be available at different stages of the ticket, based on ticket phase and other matching conditions.

In addition to auto-routes and action options which manage the progression of the ticket; the out-of-the-box configurations include communication templates for

managing the notifications when an action is executed; and ticket templates for logging specific types of tickets to help ensure appropriate auto-routing of the ticket.

The various entities associated with each workflow, and details on how the ticket progression is managed by the workflow are explained in the sections that follow.

Key Features

The out-of-the-box workflows have been designed to use some key features of logging and managing tickets in Nimsoft Service Desk.

When a new instance of the application is installed, some sample application data like Support Groups, Roles, Ticket Templates and Communication Templates that are part of the workflow design are also installed in addition to the auto-routes and workflow actions that constitute the core of the workflow design. Some SLA targets and threshold rules are also configured and available out-of-the-box.

The out-of-the-box configurations can be modified to meet any specific IT support processes. You can also create additional workflow actions or auto-routes modeled on the available configurations, and extend the functionality to further exploit the features available in Nimsoft Service Desk.

For details on the range of ticket management concepts implemented in Nimsoft Service Desk, and information on various workflow related configurations, please refer to the Administration Guide.

(9)

Key Features

Tickets and Ticket Management

A ticket is a transaction document that records all the information related to a request submitted by or on behalf of an end user or consumer of IT support or services. Tickets have different fields and tabs where specific information related to the request can be recorded and stored. In addition to the standard ticket fields, the application administrator can configure and add custom fields to the ticket. The information in these fields can be used to better understand and service the request.

As the ticket progresses through its life-cycle, the ticket records grow to include

activities done towards resolving the request. This includes details on all transactions on the ticket including manual and automatic actions and communications to and from the ticket. A Ticket also carries records of the efforts undertaken to towards fulfilling and closing the request.

In Nimsoft Service Desk; there are five types of tickets:

■ _{Service Request - Used to log and manage standard requests from users for access}

to systems and services.

■ Incident Ticket - Used to report and manage issues like disruption, unavailability or

reduction in quality of a system or service that user(s) already access and use.

■ _{Problem Ticket - Used to investigate and resolve or mitigate major issues affecting}

many users; with the focus on root-cause analysis and problem solving.

■ Change Request - Used to log and manage request for change to the IT

Infrastructure or services affecting many users; and hence involves a change approval process based on the change type.

■ Task Ticket - Used to track and manage smaller units of work towards completion

of a ticket (usually a Change or Problem Ticket); and logged as a child to another ticket.

Note: Task tickets are never logged as independent tickets; they are always used to

divide individual units of work done to resolve another ticket.

Ticket management is the system which manages the progression of a ticket towards its closure. Each ticket type (with the exception of task tickets) has its own unique

workflow process; which manages the progression of the ticket towards its closure. The out-of-the-box workflow configurations are part of this ticket management process; and have been configured taking into account industry best practices and common use cases.

(10)

Key Features

There are three main aspects of ticket progression, which are included as part of the out-of-the-box workflow:

■ _{Phase: This is used to help segment and define the steps in a given process}

workflow. During a ticket life-cycle, the ticket passes through different phases; and based on its progression; it could loop back to a previous phase. As each ticket type has its own progression; the phase definitions differ based on the ticket type.

■ Status: This refers to the current stage of the ticket in its life cycle; like New,

Queued, Active, Pending, Complete, Resolved, Closed, Archived, etc. There are fixed ticket statuses, and the status definitions cannot be modified. The ticket can move from one status to another - not necessarily in a specific order.

■ Reason Code: This is used to assign a reason why a ticket is in a given status and/or

phase. For example, a ticket could be set into Pending status for several reasons - like Pending Customer, Pending Vendor, Pending Information etc. While the status is fixed - Pending - the reason code defines why it is in that status.

A combination of the ticket status and reason code is used to manage the workflow actions available on the ticket; and help manage the ticket progression. Details about the ticket phases and ticket progression for each ticket type are laid out in the workflow diagrams in the ticket management section for each ticket type.

Auto-Routes

Auto-Routes are ticket routing rules that can be applied to route tickets to appropriate Support Groups queues based on matching conditions such as source, priority etc. Auto-Routes are configured to automate the process of assigning a ticket to specific group based on specific criteria.

Configuring well defined auto-routes ensures that the ticket is assigned to the

appropriate queue and can be worked on without delays that can be caused by manual routing of tickets.

Important! An auto-route gets applied to a ticket only once, when a ticket is first

created. All subsequent routing or changes in assignment have to be done using manual assignment action from the options available in the Take an Action dropdown on the ticket.

In the out-of-the-box configurations; auto-routes are designed to be triggered based on the 'Source' of the ticket; or other matching conditions such as Reason Code.

When an auto-route gets applied the ticket; it assigns the ticket to the queue of the appropriate support group. It also sets values for fields like Phase, Status and Reason Code; thus placing the ticket in a known state for the analyst to start working on it. Some auto-routes have communication templates associate with it; and send out notifications about ticket creation and assignment to relevant stakeholders.

(11)

Key Features

Chapter 1: Introduction 11 Note: It is recommended that new tickets be created using a ticket template, as

templates have set fields values that match the matching conditions for the auto-routes, and help ensure that the right workflow actions become available on the ticket upon assignment. New tickets have an increased possibility of being actionable when tickets are created using templates.

It is also recommended that when creating new ticket templates, if the set field values match the matching conditions of existing auto-routes, the same routing rules can be used for routing newer templates.

Workflow Action Options

Workflow Action Options are the set of actions that can be taken on a ticket; which guide the ticket towards closure. Workflow actions allow tickets to be managed via a defined process. Workflow action options, which are specific to each ticket type, are an important aspect of the workflow design. These are manual actions which are made available to analysts working on ticket. Access to workflow actions is controlled by permissions.

Workflow Action Options can be configured to become available on a ticket based on matching conditions; like Status, Reason Code, Phase, etc. Some workflow actions options are available without any matching conditions, and hence will be available on a ticket in any state.

Workflow actions can also be configured to send out notifications to stakeholders when the action is executed. Some values can also be set as required fields prior to execution of the workflow action.

When a workflow action is executed on the ticket, it sets some field values as configured; and can move the ticket into a next state; thus guiding the ticket towards closure.

In the out-of-the-box configurations, a range of workflow action options are available for each ticket type. Based on the ticket phase and other matching conditions, the different action options available on the ticket allow a controlled progression of the ticket towards closure.

Some action options have associated special function; which further automate the execution of an additional action (like Accept Assignment, Reassign in Group etc.). Based on the kind of actions; some workflow actions have communication associated with it.

(12)

Key Features

The main attributes of the out-of-the-box workflow actions are:

■ _{Structured Sort Order, which controls the order in which different actions are}

displayed in the 'Take an Action' dropdown. This is done consistently for all ticket types. For example

■ All 'Take Ownership' actions are Sort Order 100

■ All 'Reassign' actions are Sort Order 200

■ All 'Set Pending' actions are Sort Order 300

■ All 'Resolve' actions are Sort Order 900

■ Clear description for each workflow action; which explains why and when an action is to be executed. The description is displayed when the user hovers over an action in the dropdown. This is done as a way of assisting the analysts in selecting the appropriate action by giving information on what result will be attained by executing an action.

■ _{Consistent naming conventions for workflow actions for all ticket types. This is done}

to bring uniformity in the nomenclature and ease of use for analysts.

Some special workflow actions, such as 'Resolve on First Call' for Incidents, have been configured to enable trending. Executing this action sets the ticket into a 'First Call Resolution' Phase.

A report can be drawn to identify the number of tickets with this phase; which will further help identify what type of issues can be handled by L1 support. This information can be used to build a better knowledge base for L1 to use and resolve more incidents on first call; thus improving the quality of support.

Note: When building new workflow actions; it is recommended that you follow the sort

order and naming convention in the out-of-the-box workflow; and to provide clear description for a workflow action. A clear description can aid analysts in determining which action to execute.

(13)

Key Features

Ticket Approval

Approval is the process of seeking the permission of designated approvers to proceed with an action that is requested. ITIL recommends that an organization setup an approval process for all requests for change to the IT infrastructure. By including a change approval process, the organization can ensure that all proposed changes are analyzed, justified, and validated before implementation. The change implementation process also ensure that all changes are well-planned and include the implementation and verification plans and a backout plan. In some organizations, users seek approval for standard requests such as the procurement of systems or services.

The service desk administrator can set up an approval process for all types of tickets including Service Request, Incident, Problem, Change, and Task tickets. To configure the approval process, the service desk administrator can configure approval groups for each ticket and relate approvers and reviewers to the approval groups. The service desk administrator can configure a workflow action that the analyst can take to submit a ticket for approval. The service desk administrator can also set up multi-level approval process to move the ticket through multiple levels for approvals.

The service desk administrator can configure approval groups that are made up of selected individuals who are members of the Change Advisory Board (CAB) or the Emergency Change Advisory Board (ECAB). The service desk administrator can also configure approval groups to be made up of contextual approvers. A contextual approver is identified from the ticket that is submitted for approval. For example, contacts such as the approvers or the reviewers of a related CI or the manager of the requester can be a contextual approver.

When a ticket is submitted for approval, an email notification is sent to the related approvers and reviewers. The approvers and reviewers can submit their approval or review comments by logging in to the application or by replying to the email notification.

Note: By default, approval routing is configured only for change requests. You can

enable approval routing for other ticket types.

Ticket Templates

In the context of IT support, there are several oft repeated requests like request for permissions to use or access a device or service, adding or removing users to a system or service, reporting unavailability of a system or service, or request for some standard modification like upgrade to a latest version of software.

For such frequently raised requests, Ticket Templates can be configured and made available to users by assigning permission to relevant support groups or roles.

(14)

Key Features

Ticket Templates offer a standardized information collection system for requests that can be anticipated. It also facilitates effective application of auto-routes, based on set fields in the template. Thus, tickets logged using the template can be assigned directly to a specific group/individual; facilitating quicker response to the request.

A ticket template is related to any one ticket type and can be configured by setting field values for any of the standard ticket fields, as well as for any custom fields for that ticket type. If special assignment rule is to be followed for tickets logged using this template (assigned to individual or assigned to group field is set); the administrator can choose to override auto-routes for that ticket type from getting applied.

Based on the set field values, auto-routes could get applied to the ticket, setting it into the appropriate state. The action options which then become available on the ticket, guide the ticket towards fulfillment and closure.

Task Ticket Templates can be configured, and related to Task Groups and/or Task Flows; aiding further automation of creation, routing and completion of tasks required for completion of a request.

In the out-of-the-box configuration; ticket templates are configured for Incident, Problem, and Change Management. Problem and Change Management also have a related task group and task flow respectively. You can model these templates and configure new templates as per your specific requirements.

Note: It is good practice to analyze existing ticket activity to identify the top five or ten

repeated types of requests and to develop ticket templates for these requests. While configuring the templates, pay special attention to the specific attributes required to allow analysts to work on the ticket without further interaction with the requester. You can configure these templates and assign permission to relevant support groups or roles. It is highly recommended that users use templates to log requests as it ensures appropriate auto-routes get applied to the ticket, and appropriate workflow actions are available on the ticket. Tickets logged using templates are more actionable by analysts, and if all relevant information is provided by the requester, it reduces delays in working on the request.

(15)

Key Features

Communication Templates

Communication Templates are pre-configured email templates, with the standard message subject and message body text configured by the application administrator. Communication templates can be used to send out notifications from the application from tickets, service feedback schedule, etc.

Communication templates can be used for automated notifications that can be related to auto-routes and workflow actions or SLA target thresholds. When an auto-route gets applied to the ticket, a workflow action is executed on the ticket or an SLA target threshold is violated; notification using the related communication template gets sent to recipients identified in the Send To field of the template.

Permission to communication templates can be granted to support groups and roles; and the analysts working on the ticket can use the template for sending manual communication from the ticket.

Communication templates can be configured to pull information from the ticket or related forms by using 'Add a field from the form' option. The selected field is set as a placeholder on the communication template, and is filled in from the context when the communication record is generated.

The recipients of the communication can also be pulled from the context of the communication; example 'Send To' ${tr.person1_alt_email}. This will send the notification to the contact who is the requester of the ticket.

In the out-of-the-box configurations; Communication Templates are associated with selected auto-routes and workflow actions; which send automatic notification to associated recipients (like Requester/Requested for; Assigned to contact or support group etc.) about the execution of the auto-route or workflow action. Some communication templates have also been configured for SLA threshold violation notification.

You can further exploit this feature by assigning an email ID to the support group; which will ensure that notification is sent to the support group ID rather than every individual contact related to the support group.

Note: Please refer to the Administration Guide for information on how Incoming and

Outgoing Emails are processed by the application. Communication templates can be localized and made available to users in their preferred local. Please refer to the Administrator Guide for details on how communication templates can be localized and related implications on communication details visible on a ticket

(16)

Key Features

Support Groups and Roles

A Support Group is a grouping of contacts according to their geographical locations, skill sets, or relative tasks that they use the application for. Such grouping of contacts can be used for functions like skill based ticket routing, ticket assignment, ticket approval etc. A Role is a grouping of contacts and support groups into a single banner based on the broader functions they perform using the application. Such grouping of contacts and support groups is used for managing permissions effectively.

Together, Support Groups and Roles can be used to effectively manage actions like assigning permissions and managing ticket assignment, notification etc.

In Nimsoft Service Desk; a logged in user's ability to access to various entities like navigation menu items, ticket toolbar options, workflow action options, communication templates, ticket templates etc. is controlled by permissions. Permissions can be managed better by assigning permission to support groups or roles; which can then be inherited by contacts that are related to the support groups or roles.

A set of support groups and roles are defined and available out-of-the-box.

In the out-of-the-box configurations; Roles have been used to manage permissions to navigation menu options, workflow action options, ticket templates etc. Support groups have been related to the role based on the various functions they are expected to perform using the application. This has been found to be a good practice for implementing a Service Management solution.

Support Groups that have been configured out-of-the-box have been used for ticket assignment action, and for sending out communications from the ticket as appropriate. Contacts can be related to support groups; and their interaction with tickets can be controlled by the support group they belong to.

Note: You can enhance the functionality of Support Groups by configuring Next

Escalation Group for support groups that work with tickets, and Support Group Email ID and Phone; and use this for effectively managing SLA threshold violation actions. You can also configure Support Group Business hours to better manage assignments to geographically dispersed support teams.

It is highly recommended that contacts be related to the existing support groups as these Support Groups have been used as part of auto-routes and communication templates configured out-of-the-box. Also, permission for the workflow actions has been assigned to the Support Groups available out-of-the-box.

It is also recommended that new support groups that are being configured be related to relevant existing out-of-the-box roles. This will help ensure that the permissions model implemented out-of-the-box can be fully exploited.

(17)

Key Features

SLA Targets and Thresholds

Service Level Management deals with the process of negotiating Service Level Agreements and of the process of ensuring that these are met. Service Level Management is responsible for ensuring that all IT Service Management processes, Operational Level Agreements, and Underpinning contracts are appropriate for the agreed Service Level Targets.

Service Level Management monitors and reports on Service Targets, which are measured against set service metrics such as Response Time, Resolution Time etc. In the out-of-the-box configurations, some Service Targets and thresholds have been configured to be applied against different Service Metrics to monitor Service Level Agreements. Based on ticket matching conditions, the target gets applied to the ticket; and the ticket is monitored for SLA compliance. Based on the threshold rules,

notifications are sent out, or the ticket gets assigned to the next escalation group.

Note: In the out-of-the-box configurations, SLA targets have been configured mainly for

(18)

(19)

Chapter 2: Out-of-the-box Application Records 19

Chapter 2: Out-of-the-box Application

Records

When a new instance of Nimsoft Service Desk is installed; a set of system defined entities, like system defined contacts, support groups, communication templates etc. are installed by default.

When choosing to install the out-of-the-box configurations, support groups, roles, communication templates, ticket templates, auto-routes, workflow actions and SLA targets that are part of the out-of-the-box workflow configurations also get installed. This section provides information on the out-of-the-box application records, like Support Groups, Roles etc., that are included as part of the out-of-the-box workflow configurations. Ticket specific records like templates, auto-routes and workflow actions specific to each ticket type are listed as part of the workflow design for each ticket type. This section contains the following topics:

Support Groups (see page 19)

Roles (see page 21)

Service Level Management Targets and Thresholds (see page 23)

Support Groups

Support Groups are integral to the out-of-the-box workflow design. Tickets get assigned to support groups as defined in the auto-routes; and access to different workflow action options are managed by permissions assigned to the support groups.

The table below lists the support groups that are available out-of-the-box; and the permissions assigned to them.

Group ID

Support Group Name

Used For Purpose

11 Service Desk (L1)

Permission, Notification, Assignment

This is the L1 support group handling the first level of triaging of tickets. Based on matching conditions, tickets get auto-routed to this support group for further action. 20 Change

Approvers

Notification, Approval Group

This Support Group is used to queue tickets that are to be reviewed by change

(20)

Support Groups

21 CAB Notification, Approval Group

This is the Change Approval Board; for grouping contacts who are involved in the change approval process.

22 ECAB Notification, Approval Group

This is the Emergency Change Approval Board; for grouping contacts involved in emergency change approval process. 28 Change

Manager

Permission, Notification, Approval Group

This Support Group is used for grouping contacts who are Change Managers 29 Facilities Group Permission, Notification, Assignment, SLA Escalation

This support group has been created as a sample group for handling specific tasks. In the out-of-the-box workflow design, this support group handles tasks that are part of the Provision New Employee ticket

template. 30 Desktop Support Permission, Notification, Assignment, SLA Escalation

This support group is used for grouping analysts who provide desktop support.

31 Server Support (L2) Permission, Notification, Assignment, SLA Escalation

This support group is used for grouping analysts who provide L2 server support.

32 Configuratio n Permission, Notification, Assignment, SLA Escalation

This support group can be related to the Configuration Management role; and can handle tasks related to managing configuration items.

In addition to the above support groups, which are configured for the out-of-the-box workflows; the following three support groups are available by default:

■ Administration: This support is for the contact (s) designated as Application

Administrator. Contacts in this support group get access to all application functionality; all navigation menu options, and can create or modify all types of records in the application.

■ _{Self-Service: This support group is for all contacts who are end users of the IT}

support. Contacts with Self-Service License are automatically added to this support group and have access to the Self-Service User interface.

■ Public: This support group is used to group all contacts that are not members of the

Self-Service or Administration support groups and can be used when assigning common permissions to all contacts who are not self-service users. In the out-of-the-box workflow design, this group has been used only minimally.

(21)

Roles

Roles can be used as an effective way of handling permissions. Contacts and/or Support Groups can be related to a role and permissions can be assigned to the role. Contacts and Support Groups inherit permissions assigned to the role.

Roles are an important aspect of the out-of-the-box workflow design as access to the different ticket types and reports is managed by permissions assigned to different roles. The table below lists the roles configured and made available out-of-the-box.

Role Name Related Support Groups

Permission details

Service Desk Supervisor

None Has permissions to workflow action option for reopening resolved or closed tickets and access to reports under Trends and Metrics in the navigation menu

Default

Self-Service ■ Self-Service

Has access to all navigation menu items in the Self-Service user interface and all actions available to all self-service users.

This role also has access to the following ticket templates:

■ Provision Web Server (Sample)

■ Report an Outage

■ Provision New Employee (Sample)

Admin _■ _{Administration This role has not been used in the out-of-the-box} workflow

Change

Management ■ Service Desk _(L1)

■ Change Approvers

■ Change Managers

Has permission to workflow action options for taking actions related to Change tickets, access to Create Change (Using Template), List Change, Scheduled Changes and Search Change Request in the navigation menu and access to 'Open Tickets Aging' report.

The role also has access to the following ticket templates:

■ Normal Change Request (Agent)

■ Standard Change Request (Agent)

■ Emergency Change Request (Agent)

■ Break-fix Change Request (Agent)

(22)

Roles

Problem

Has permissions to workflow action options for taking actions related to Problem tickets and access to Report Problem (Using Template), List Problem, Search Problem and Reports in the navigation menu.

This role also has permission to the following ticket templates:

■ Problem Report (Agent)

■ Proactive Problem (Agent)

■ Report Known Error (Agent)

■ Problem Pre-closure Ticket Review (Task Group)

■ PRB-Resolve Related Ticket (Task)

■ PRB-Review Knowledge Article (Task) Change

Approvers ■ Change _Approvers

■ CAB

■ ECAB

Has permission to workflow action to manually approve change for implementation and set the change in the implementation phase and access to Change Management items in the navigation menu including Create Change (Using Template), My Approval Tasks, Search Change, Scheduled Changes and Reports

■ Create Break-fix request (Agent)

■ Emergency Change Request (Agent) Incident

Has permission to workflow actions for taking actions related to Incident Tickets and access to Incident Management related items in the navigation menu including 'List Incident', 'Report Incident, Report Incident (Using Template), Search Incidents and Reports

Service Request Management

■ Service Desk (L1)

Has permission to workflow actions for taking action related to Service Requests and access to Request Management related items in the navigation menu including 'Log Request (Using Template), Search Service Request and Reports

(23)

Service Level Management Targets and Thresholds

Configuration

Management N

o n e

Has permissions to access navigation menu items related to configuration management including 'Create Configuration Item', 'Search Configuration Item' and 'Reports'.

Knowledge Management

None Has permission to access navigation menu items related to knowledge management including 'Create KB Article', 'Search KB Article', 'Manage KB Article' and Reports

Change Requester

None Has permission to access navigation menu items related to logging a change ticket including 'Create Change Using Template', Search Change Requests' and 'Scheduled Changes'

Change

Manager ■ Change _Manager

Has permission to workflow actions related to submitting change for approval, withdrawing change from approval, approving change for implementation, and stopping the approval process.

■ Create Break-fix request (Agent)

■ Emergency Change Request (Agent)

Note: It is recommended that any new Support Groups being configured be related to

these roles; and that roles are used for managing permissions more effectively.

Service Level Management Targets and Thresholds

Service Level Management deals with identifying IT services and defining Service Level Agreements that specify conditions around the availability of a service. In Nimsoft Service Desk, you can define the service targets based on available service metrics and set up violation and non-violation thresholds to measure service delivery against agreed upon service level agreements.

(24)

The table below lists the service targets that are available as part of the out-of-the-box workflow configurations. Service Target Service Metric Applies to Ticket Type Matching Conditions Thres hold Value (mins) Viola tion Thres hold Action on Threshold violation Critical Priority Incident Response Time Response Time (24X7) Incident _■ _ticket type = incident ■ ticket priority code =1 (critical) > 15 No Send Email Notification

>= 30 Yes Send Email Notification High Priority Incident Response Time Response Time (Support Group Business Hours) Incident _■ _ticket type = incident ■ ticket priority code = 2 (high) > 45 No Send Email Notification

>= 60 Yes Send Email Notification Medium Priority Incident Response Time Response Time (Support Group Business Hours) Incident _■ _ticket type = incident ■ ticket priority code = 3 (medium) > 105 No Send Email Notification >= 120

Yes Send Email Notification Critical Priority Incident Resolution Time Resolution Time (24X7) Incident _■ _ticket type = incident ■ ticket priority code = 1 (critical) > 45 No Send Email Notification

>= 60 Yes Send Email Notification High Priority Incident Resolution Time Resolution Time (Support Group Business Hours) Incident _■ _ticket type = incident ■ ticket priority code = 2 (high) > 225 No Send Email Notification > = 240

Yes Send Email Notification

(25)

Medium Priority Incident Resolution Time Resolution Time (Support Group Business Hours) Incident _■ _ticket type = incident ■ ticket priority code = 3 (medium) > 465 No Send Email Notification >= 480

Yes Send Email Notification Sample Generic 4 Hour Response Time Response Time (24X7) Service Request , Change Request , Task

■ None > 120 No Send Email Notification

■ None >= 240

Yes Send Email Notification Sample Generic 8 Hour Resolution Time Resolution Time (24X7) Service Request , Change Request , Task

■ None > 120 No Send Email Notification

> 240 No Assign to Next Escalation Group >=

480

Yes Send Email Notification

Note: The Sample Generic SLA targets have been configured as an example to show

actions such as 'Assign to Next Escalation Group'. You can modify these to create more specific targets for different ticket types.

(26)

(27)

Chapter 3: Request Management Workflow 27

Chapter 3: Request Management Workflow

Standard requests from an end user, seeking information or advice regarding the use of a system or service, or requesting a modification or a standard change to an available service can be handled using Service Requests. Service Request may also be used by an end user to report an issue being faced.

This section provides information about the Request Management process and the out-of-the-box workflow design for managing Service Requests.

Note: A ticket that needs to go through an approval process, should be processed as a

Change Ticket, not a Service Request. This section contains the following topics:

Request Management Overview (see page 27)

Service Request Workflow Process (see page 28)

Service Request Related Records (see page 30)

Request Management Overview

Request Management is the process of managing a Service Request through its life-cycle. This includes logging, routing, monitoring and delivering the requested service.

Request Management involves establishing a Request Fulfillment Process which aims to:

■ Channel user's request for standard services which have a pre-defined approval process.

■ _{Source and deliver the components of requested standard services (e.g. licenses}

and software media).

■ Assist with general information like availability of services and the procedure for obtaining them, and handling complaints or comments from users.

All tickets logged by end users without using a template, result in the creation of a Service Request. Email requests from users (unless specifically configured otherwise) also result in creation of a Service Request.

Depending on the nature of the request, a Service Request can either be handled as per the Request Management workflow or an Incident, Problem or Change ticket can be logged from the initial Service Request and worked on as per the workflow process for the relevant ticket.

(28)

Service Request Workflow Process

Service Requests typically pass through three phases from creation to closure;

Acceptance, Fulfillment and Closure. Based on the source of the ticket; the Acceptance phase could be bypassed and the ticket could directly be set in the fulfillment phase. The progression of a Service Request is shown in the diagram below:

(29)

Service Request Workflow Process

(30)

Service Request Related Records

The templates, auto-routes and workflow actions that are part of this workflow design are listed in the sections that follow.

Service Request Related Records

The out-of-the-box workflow configuration includes key configuration records that help facilitate the workflow design, and enable progression of the ticket through the workflow design.

The following workflow configuration records are included as part of the Request Management workflow design.

Service Request Ticket Templates

There are no ticket templates for Service Requests made available out-of-the-box. You can configure templates for requests related to systems or services that are usually raised by requesters in your organization and make them available for the end users as appropriate.

Service Request Communication Templates

The following communication templates related to Service Requests are made available as part of the out-of-the-box workflow configurations:

Template Name Send To Purpose SRQ Group Assign ${tr.assigned_to_grou p_name}

Notify support group about assignment of the ticket to the support group

SRQ Pending Cust

${tr.person1_alt_ema il}

Notify requester that the ticket has been set as pending information from requester; and notifying requester to provide required information.

SRQ Change ${tr.person1_alt_ema il}

Notify requester that to facilitate approvals for the request, a change request is being created from the service request.

SRQ Canceled ${tr.person1_alt_ema il}

Notify requester that the service request has been canceled.

SRQ Ind Assign

${tr.assigned_to_indi vidual_name}

Notify an individual about assignment of the ticket using Assign to Individual action option.

(31)

SRQ Accept ${tr.person1_alt_ema il}

Notify requester that the service request assignment has been accepted by a service desk agent.

SRQ Success ${tr.person1_alt_ema il}

Notify requester that the service request has been successfully fulfilled.

SRQ Failed ${tr.person1_alt_ema il}

Notify requester that the service request fulfillment has failed.

SRQ Close Fail ${tr.person1_alt_ema il}

Notify requester that the service request which has failed fulfillment will be closed. SRQ Reopen ${tr.person1_alt_ema

il}

Notify requester that the service request has been reopened.

SRQ Ack ${tr.person1_alt_ema il}

Notify requester that a service request has been created as requested.

Task Completed Notice

${assigned_to_individ ual_name}

Notify assigned to individual that a related task ticket has been completed successfully Task Failure

Notice

Notify the assigned to individual that a related task has failed completion.

The Communication Templates are related to auto-routes and workflow actions; and notify appropriate stakeholders about execution of an action on the ticket.

In addition to these templates which are created as part of the out-of-the-box workflow design, you will also find several system defined communication templates which you can associate with workflow action, auto-route and SLA notifications.

Service Request Auto Routes

In the out-of-the-box workflow configurations, auto-routes have been configured to get applied to the ticket based on the ticket source.

(32)

The table below lists the auto-routes configured and made available out-of-the-box for Service Requests. Auto Route Name Sort Order Matching Conditions

Set Fields and Set field values Related Communication Service Request (Email) Auto Route 950 (Source =

Email) ■ assigned_group_id = _{Service Desk (L1)}

■ Phase = Acceptance

■ Reason Code = Email Service Request ■ Status = New ■ Priority = Medium SRQ Group Assign SRQ Ack Service Request (Web) Auto Route 950 (Source =

Web) ■ assigned_group_id = _{Service Desk (L1)}

■ Phase = Acceptance

■ Reason Code = Web Service Request ■ Status = New SRQ Group Assign SRQ Ack Service Request (Agent) Auto Route 950 NOT (Source = Web) AND NOT (Source = Email) ■ Phase = Fulfillment ■ Reason Code = In Progress ■ Status = Active SRQ Accept

Since Service Requests are usually initiated by the end user, it is necessary to inform the requester about ticket creation and assignment. Hence, most auto-routes for Service Requests have a communication template associated with it.

When an auto-route gets applied; the requester is notified about the ticket creation; and the assigned to support group is notified about assignment of the ticket to their support group. This ensures that communication about the ticket is sent to the immediate stakeholders.

(33)

Service Request Workflow Action Options

Action Options are workflow actions that help guide the ticket through a defined workflow process. Action Options become available on a ticket based on matching conditions like Status, Reason Code, Phase etc. and can be used to control the progression of the ticket through its life-cycle.

Action Options can be configured to control actions such as enforce required field values when that action option is executed; set field values upon execution and trigger

automatic notifications when the action is executed. Action Options could also have special functions, like Submit for Approval, associated with it, enabling further automation of associated actions.

The table below lists the Action Options that are available with the Out-of-the-box workflow configurations. Action Option Name Special Function Matching Conditions

Set Fields and Set field values Required Fields Communic ation Take Ownership of New Request Accept Assignment (status = New) AND (phase = Acceptance) ■ Phase = Fulfillment ■ Reason Code = In Progress ■ Status = Active None SRQ Accept Take Ownership Accept Assignment NOT (Status = Resolved, Status = Closed or Status = New) ■ Reason Code = In Progress ■ Status = Active None None Reassign to Group Assign to Group (status =

Active) ■ Reason Code _{= Assignment}

■ Status = Queued None SRQ Group Assign Reassign to Individual Assign to Individual (status =

■ Status = Queued None SRQ Ind Assign Reassign in My Group Assign to Individual (status =

■ Status = Queued

None SRQ Ind Assign

(34)

Set Pending Vendor

None (status =

Active) ■ Reason Code _{= Vendor}

■ Status = Pending None None Set Pending Customer None (status =

Active) ■ Client _Viewable (Work_View_ Type) = Yes ■ Reason Code = Customer ■ Status = Pending ■ Work_Type = Client Note Worklog descripti on SRQ Pending Customer Resume Pending Request None (status =

Pending) ■ Reason Code _{= Resumed}

■ Status = Active None None Create Linked Change Request Create Change (status =

Active) ■ Reason Code _{= Linked} Change Created None None Convert Service Request to Incident Create Incident (status =

Active) ■ Phase = _Closure

■ Reason Code = Incident Created ■ Status = Closed None None Convert Service Request to Change Request Create Change (status =

■ Reason Code = Created Change Request ■ Status = Closed None None

(35)

Complete as Successful None (status = Active) AND (Phase = Fulfillment) ■ assigned to group = Service Desk (L1) ■ Failed Fulfillment = No ■ Phase = Closure ■ Reason Code = Fulfilled ■ Status = Resolved ■ Days to auto-close = 5 None SRQ Success Fulfillment Failure None (status = Active) AND (phase = Fulfillment) ■ Failed Fulfillment = Yes ■ Phase = Closure ■ Reason Code = Failed Fulfillment ■ Status = Closed None SRQ_Failed Cancel and Close Service Request None NOT (status = Resolved) OR (status = Closed) ■ Phase = Closure ■ Reason Code = Canceled ■ Status = Closed None None Reopen and Take Ownership Accept Assignment (status = Closed) OR (status = Resolved) ■ Phase = Fulfillment ■ Reason Code = Reopen ■ Status = Active None SRQ Reopen

(36)

Delete Service Request (Admin)

None None _■ _None None None

Note: Workflow actions like 'Reassign in My Group' can be used to manage ticket

queues and distribute the workload among members of a support group. As such an action does not need to be communicated to the requester, here notification is sent only to the assigned individual about the ticket assignment.

(37)

Chapter 4: Incident Management Workflow 37

Chapter 4: Incident Management Workflow

Issues reported by users (or automated interfaces) with an existing system; or potential issues that could impact service are logged as incident tickets. Incident Management deals with handling and processing incident tickets to ensure resolution of the issue with minimal impact to the user.

This section provides information about the Incident Management process and the out-of-the-box workflow design for managing Incident tickets.

This section contains the following topics:

Incident Management Overview (see page 37)

Incident Ticket Life-Cycle (see page 38)

Incident Ticket Related Records (see page 40)

Incident Management Overview

ITIL defines an 'Incident' as any event which is not part of the standard operation of the service and which causes, or may cause, an interruption or a reduction of the quality of the service. An Incident could be due to a known/existing issue or could be result of a failure or error in the IT object or device.

The objective of Incident Management is to restore normal operations as quickly as possible with the least possible impact on either the business or the user at a

cost-effective price, and within defined service levels. Incident Management does not attempt to identify the root cause of the incident and is focused on resumption of normal operations within agreed upon Service Level Agreements.

The process of incident detection and recording, classification and initial support, investigation and diagnosis, resolution and recovery, and final closure of the incident, form part of the Incident Management Process.

The incident management process involves establishing a service restoration process which aims to:

■ Channel users' reports of an interruption to a service or drop in quality of a service.

■ _{Enable validation and diagnosis of the reported incident}

■ _{Manage the process of ensuring incident resolution and restoration of service.} ■ Monitoring compliance with defined service level agreements for service

(38)

Incident Ticket Life-Cycle

Incident Tickets typically pass through four phases from creation to closure; Acceptance, Diagnosis, Investigation and Closure. Based on the source of the ticket; the Acceptance phase could be bypassed and the ticket could directly be set in the diagnosis phase. The progression of an Incident ticket is shown in the diagram below:

(39)

Incident Ticket Life-Cycle

(40)

Incident Ticket Related Records

The templates, auto-routes and workflow actions that are part of this workflow design are listed in the sections that follow.

Incident Ticket Related Records

The out-of-the-box workflow configuration includes key configuration records that help facilitate the workflow design, and enable progression of the ticket through the workflow design.

The following workflow configuration records are included as part of the Incident Management workflow design.

Incident Ticket Templates

The following ticket templates are made available as part of the Incident Management out-of-the-box configurations

Template Name

Categ ory

Description Set Fields Permission

Report and Outage

Gener al

Self-Service- Report an

outage to the service desk ■ Source = _Web

Administration (Support Group) Default

Self-Service (Role)

Note: The Override Auto Routing checkbox is unchecked for the ticket template. An

auto route will get applied to the ticket created using this template; and will assign it to an appropriate support group.

When the auto-route gets applied, the other fields like assigned to group, status, reason code and phase will get set as configured in the auto-routes.

Incident Communication Templates

The following communication templates are made available as part of the out-of-the-box Incident Management workflow configurations:

Template Name Send To Purpose

INC/PRB Assign Ind

${tr.assigned_to_indi vidual_name}

Notify an individual about assignment of the ticket using Assign to Individual workflow action.

(41)

INC/PRB Assign Group

${tr.assigned_to_grou p_name}

Notify the support group that the ticket has been assigned to the group using the Assign to Group workflow action.

INC Auto-Route (Web)

Notify the requester that the incident ticket has been logged and assigned to a support group queue.

INC Accepted ${tr.person1_alt_ema il}

Notify the requester that the assignment of the incident has been accepted and is being worked on.

INC Resolved ${tr.person1_alt_ema il}

Notify the requester that the incident has been resolved.

INC Reopened ${tr.person1_alt_ema il}

Notify requester that the incident ticket has been reopened.

INC Pending Customer

Notify requester that the incident has been set as pending and requires additional information from the requester

INC Major Service Desk (L1) Notify service desk support group(s) that an incident has been declared as Major Incident..

INC Canceled ${person1_alt_email} Notify requester that the incident ticket has been canceled.

Task Completed Notice

Notify assigned to individual that a related task ticket has been completed successfully Task Failure

Notice

Notify the assigned to individual that a related task has failed completion. The Communication Templates are related to auto-routes and workflow actions; and notify appropriate stakeholders about execution of an action on the ticket.

In addition to these templates which are created as part of the out-of-the-box workflow design, you will also find several system defined communication templates which you can associate with workflow action, auto-route and SLA notifications.

Incident Auto-Routes

In the out-of-the-box workflow configurations, auto-routes have been configured to get applied to the ticket based on the ticket source.

(42)

The table below lists the auto-routes configured and made available out-of-the-box for Incident Tickets. Auto Route Name Sort Order Matching Conditions

Set Fields and Set field values Related Communication Incident Default Auto Route 950 (Source =

Web) ■ assigned_group_id _{= Service Desk (L1)}

■ Phase = Acceptance ■ Reason Code = Incident Created ■ Status = New Incident Auto-Route Web Incident Default Agent 950 NOT (Source

= Web) ■ Phase = Diagnosis

■ Reason Code = In Progress

■ Status = Active

None

Note: When the ticket is created by end users, an auto-route gets applied based on

ticket source and the requester is notified about the ticket creation; and the ticket goes into an 'Acceptance' phase.

However, when an analyst who works on the ticket logs the Incident; the 'Acceptance' phase is bypassed; and the ticket is directly set into the 'Diagnosis' phase. The

out-of-the-box workflow is designed in this way with the assumption that if an analyst is logging the ticket; it is a valid incident that has been accepted by service desk; and can be worked on towards diagnosis and resolution of the incident.

Incident Workflow Action Options

The workflow actions available for incident tickets for part of the Incident Management Workflow design.

(43)

The table below lists the Action Options that are available with the Out-of-the-box workflow configurations for Incident Management.

Action Option Name Special Function Matching Conditions

Set Fields and Set field values Requir ed Fields Communicati on Accept New Incident Accept Assignment

(status = New) _■ _{Phase =} Diagnosis ■ Reason Code = In Progress ■ Status = Active None Incident Accepted Take Ownership Accept Assignment NOT (Status = Resolved, Status = Closed or Status = New) ■ Reason Code = In Progress ■ Status = Active None None Reassign to Group Assign to Group (status =

■ Status = Queued None INC/PRB Assign Group Reassign to Individual Assign to Individual (status =

■ Status = Queued None INC/PRB Assign Individual Reassign in My Group Assign to Individual (status =

■ Status = Queued None INC/PRB Assign Individual Set Pending Vendor None (status =

Active) ■ Reason Code _{= Vendor}

■ Status = Pending

(44)

Set Pending Customer

None (status =

Active) ■ Client _Viewable Worktype = Yes ■ Reason Code = Customer ■ Status = Pending ■ Worktype = Client Note Workl og descri ption Incident Pending Customer Resume Pending Request None (status =

Pending) ■ Reason Code _{= In Progress}

■ Status = Active None None Assign for Investigati on Assign to Group (status = Active) AND (phase = Diagnosis) ■ Phase = Investigation ■ Reason Code = Assignment ■ Status = Queued None INC/PRB Assign Group Create Linked Problem Create Problem (status =

Active) ■ Reason Code _{= Linked} Problem Created None None Create Linked Change Request Create Change (status =

Active) ■ Reason Code _{= Linked} Change Created None None Create Linked Incident Create Incident (status =

Active) ■ Reason Code _{= Linked} Incident Created None None Convert Incident to Service Request Create Service Request (status =

■ Reason Code = Created Service Request ■ Status = Closed None None

(45)

Convert Incident to Change Request Create Change (status =

■ Reason Code = Created Change Request ■ Status = Closed None None Resolve Incident None (status = Active) AND (phase = Investigation) ■ assigned to group = Service Desk (L1) ■ Phase = Closure ■ Reason Code = Pending Closure ■ Status = Resolved ■ Days to auto-close = 5 None Incident Resolved Resolve on First Call None (status = Active) AND (phase = Diagnosis) ■ assigned to group = Service Desk (L1) ■ Phase = Closure ■ Reason Code = First Call Resolution ■ Status = Resolved ■ Days to auto-close = 5 None None

(46)

Declare Major Incident None (status = Active) AND (phase = Diagnosis or Investigation) ■ Phase = Major Incident ■ Reason Code = Major Incident ■ Severity = Major ■ Status = Active None Incident Major Resolve Major Incident

None None _■ _{Phase =} Closure ■ Reason Code = Major Incident Resolution ■ Status = Resolved ■ Days to auto-close = 5 None Incident Resolved Close Resolved Incident None (status =

Resolved) ■ Status = _Closed

None None

Remove from Major Incident

None (phase = Major

Incident) ■ Phase = _{Investigation}

None None

Cancel and Close Incident

None NOT (status = Resolved) OR (Status = Closed) ■ Phase = Closure ■ Reason Code = Canceled ■ Status = Closed None Incident Canceled Reopen Resolved Incident Accept Assignment (status =

Resolved) ■ Phase = _{Investigation}

■ Reason Code = Reopen ■ Status = Active None Incident Reopened