CA Nimsoft Service Desk

Transcription

1 CA Nimsoft Service Desk Rapid Workflow Implementation Guide

2 Legal Notices Copyright 2013, CA. All rights reserved. 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 (June 1995), or as a "commercial item" as defined in FAR 2.101(a) or as "Restricted computer software" as defined in FAR (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 (c)(1-2) (June 1987). U.S. Government users will receive no greater than Limited Rights as defined in FAR (June 1987) or DFAR (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:

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 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 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 Chapter 1: Introduction 7 Overview... 7 Key Features... 8 Tickets and Ticket Management... 9 Auto-Routes Workflow Action Options Ticket Approval Ticket Templates Communication Templates Support Groups and Roles SLA Targets and Thresholds Chapter 2: Out-of-the-box Application Records 19 Support Groups Roles Service Level Management Targets and Thresholds Chapter 3: Request Management Workflow 27 Request Management Overview Service Request Workflow Process Service Request Related Records Service Request Ticket Templates Service Request Communication Templates Service Request Auto Routes Service Request Workflow Action Options Chapter 4: Incident Management Workflow 37 Incident Management Overview Incident Ticket Life-Cycle Incident Ticket Related Records Incident Ticket Templates Incident Communication Templates Incident Auto-Routes Incident Workflow Action Options Contents 5

6 Chapter 5: Problem Management Workflow 49 Problem Management Overview Problem Ticket Life-Cycle Problem Ticket Related Records Problem Ticket Templates Problem Communication Templates Problem Auto-Routes Problem Workflow Action Options Chapter 6: Management Workflow 61 Management Overview Request Life-cycle Standard Normal Emergency Break-fix Management Related Records Ticket Templates Communication Templates Auto-Routes Workflow Action Options Approval Groups Chapter 7: Known Issues and Points to Note 103 Known Issues No Support Group related to Configuration Management Role No Report an Outage Ticket Template for Analysts Users will be unable to log Service Requests from the UI Incorrect Matching Conditions for 'Withdraw ' Workflow Action No Communication Associated with Submit for Approval Workflow Action Points to Note Rapid Workflow Implementation Guide

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 to the support 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. Chapter 1: Introduction 7

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. 8 Rapid Workflow Implementation 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. 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 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. Chapter 1: Introduction 9

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. 10 Rapid Workflow Implementation Guide

11 Key Features 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. Chapter 1: Introduction 11

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. 12 Rapid Workflow Implementation Guide

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,, 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 Advisory Board (CAB) or the Emergency 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 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 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. Chapter 1: Introduction 13

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 Management. Problem and 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. 14 Rapid Workflow Implementation Guide

15 Key Features Communication Templates Communication Templates are pre-configured 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_ }. 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 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 s 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 Chapter 1: Introduction 15

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 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. 16 Rapid Workflow Implementation Guide

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 Incidents. You can configure extend this to other ticket types as desired. Chapter 1: Introduction 17

18

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 11 Service Desk (L1) 20 Approvers Used For Permission, Notification, Assignment Notification, Approval Group Purpose 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. This Support Group is used to queue tickets that are to be reviewed by change management Chapter 2: Out-of-the-box Application Records 19

20 Support Groups 21 CAB Notification, Approval Group 22 ECAB Notification, Approval Group 28 Manager 29 Facilities Group 30 Desktop Support 31 Server Support (L2) 32 Configuratio n Permission, Notification, Approval Group Permission, Notification, Assignment, SLA Escalation Permission, Notification, Assignment, SLA Escalation Permission, Notification, Assignment, SLA Escalation Permission, Notification, Assignment, SLA Escalation This is the Approval Board; for grouping contacts who are involved in the change approval process. This is the Emergency Approval Board; for grouping contacts involved in emergency change approval process. This Support Group is used for grouping contacts who are Managers 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. This support group is used for grouping analysts who provide desktop support. This support group is used for grouping analysts who provide L2 server support. 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. 20 Rapid Workflow Implementation Guide

21 Roles 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 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 Management Service Desk (L1) Approvers Managers Has permission to workflow action options for taking actions related to tickets, access to Create (Using Template), List, Scheduled s and Search Request in the navigation menu and access to 'Open Tickets Aging' report. The role also has access to the following ticket templates: Normal Request (Agent) Standard Request (Agent) Emergency Request (Agent) Break-fix Request (Agent) Provision New Employee (Sample) Chapter 2: Out-of-the-box Application Records 21

22 Roles Problem Management Service Desk (L1) 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) Approvers 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 Management items in the navigation menu including Create (Using Template), My Approval Tasks, Search, Scheduled s and Reports This role also has access to the following ticket templates: Create Break-fix request (Agent) Standard Request (Agent) Normal Request (Agent) Emergency Request (Agent) Incident Management Service Desk (L1) 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 22 Rapid Workflow Implementation Guide

23 Service Level Management Targets and Thresholds Configuration Management Knowledge Management Requester Manager Manager Has permissions to access navigation menu items Nrelated to configuration management including o 'Create Configuration Item', 'Search Configuration n Item' and 'Reports'. e Has permission to access navigation menu items related to knowledge management including 'Create KB Article', 'Search KB Article', 'Manage KB Article' and Reports Has permission to access navigation menu items related to logging a change ticket including 'Create Using Template', Search Requests' and 'Scheduled s' Has permission to workflow actions related to submitting change for approval, withdrawing change from approval, approving change for implementation, and stopping the approval process. This role also has access to the following ticket templates: Create Break-fix request (Agent) Standard Request (Agent) Normal Request (Agent) Emergency 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. Chapter 2: Out-of-the-box Application Records 23

24 Service Level Management Targets and Thresholds The table below lists the service targets that are available as part of the out-of-the-box workflow configurations. Service Target Critical Priority Incident Response Time High Priority Incident Response Time Medium Priority Incident Response Time Critical Priority Incident Resolution Time High Priority Incident Resolution Time Service Metric Response Time (24X7) Response Time (Support Group Business Hours) Response Time (Support Group Business Hours) Resolution Time (24X7) Resolution Time (Support Group Business Hours) Applies to Ticket Type Incident Matching Conditions Incident Incident Incident Incident ticket type = incident ticket priority code =1 (critical) ticket type = incident ticket priority code = 2 (high) ticket type = incident ticket priority code = 3 (medium) ticket type = incident ticket priority code = 1 (critical) ticket type = incident ticket priority code = 2 (high) Thres hold Value (mins) Viola tion Thres hold Action on Threshold violation > 15 No Send Notification >= 30 Yes Send Notification > 45 No Send Notification >= 60 Yes Send Notification > 105 No Send Notification >= 120 Yes Send Notification > 45 No Send Notification >= 60 Yes Send Notification > 225 No Send Notification > = 240 Yes Send Notification 24 Rapid Workflow Implementation Guide

25 Service Level Management Targets and Thresholds Medium Priority Incident Resolution Time Sample Generic 4 Hour Response Time Resolution Time (Support Group Business Hours) Response Time (24X7) Incident Service Request, Request, Task ticket type = incident ticket priority code = 3 (medium) > 465 No Send Notification >= 480 Yes Send Notification > 120 No Send Notification >= 240 Yes Send Notification Sample Generic 8 Hour Resolution Time Resolution Time (24X7) Service Request, Request, Task > 120 No Send Notification > 240 No Assign to Next Escalation Group >= 480 Yes Send 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. Chapter 2: Out-of-the-box Application Records 25

26

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 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. 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 ticket can be logged from the initial Service Request and worked on as per the workflow process for the relevant ticket. Chapter 3: Request Management Workflow 27

28 Service Request Workflow Process 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: 28 Rapid Workflow Implementation Guide

29 Service Request Workflow Process Chapter 3: Request Management Workflow 29

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 SRQ Group Assign SRQ Pending Cust SRQ SRQ Canceled SRQ Ind Assign Send To ${tr.assigned_to_grou p_name} ${tr.person1_alt_ema il} ${tr.person1_alt_ema il} ${tr.person1_alt_ema il} ${tr.assigned_to_indi vidual_name} Purpose Notify support group about assignment of the ticket to the support group Notify requester that the ticket has been set as pending information from requester; and notifying requester to provide required information. Notify requester that to facilitate approvals for the request, a change request is being created from the service request. Notify requester that the service request has been canceled. Notify an individual about assignment of the ticket using Assign to Individual action option. 30 Rapid Workflow Implementation Guide

31 Service Request Related Records SRQ Accept SRQ Success SRQ Failed ${tr.person1_alt_ema il} ${tr.person1_alt_ema il} ${tr.person1_alt_ema il} SRQ Close Fail ${tr.person1_alt_ema il} SRQ Reopen SRQ Ack Task Completed Notice Task Failure Notice ${tr.person1_alt_ema il} ${tr.person1_alt_ema il} ${assigned_to_individ ual_name} ${assigned_to_individ ual_name} Notify requester that the service request assignment has been accepted by a service desk agent. Notify requester that the service request has been successfully fulfilled. Notify requester that the service request fulfillment has failed. Notify requester that the service request which has failed fulfillment will be closed. Notify requester that the service request has been reopened. Notify requester that a service request has been created as requested. Notify assigned to individual that a related task ticket has been completed successfully 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. Chapter 3: Request Management Workflow 31

32 Service Request Related Records 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 ( ) Auto Route 950 (Source = ) assigned_group_id = Service Desk (L1) Phase = Acceptance SRQ Group Assign SRQ Ack Reason Code = Service Request Status = New Priority = Medium Service Request (Web) Auto Route 950 (Source = Web) assigned_group_id = Service Desk (L1) Phase = Acceptance SRQ Group Assign SRQ Ack Reason Code = Web Service Request Status = New Service Request (Agent) Auto Route 950 NOT (Source = Web) NOT (Source = ) 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. 32 Rapid Workflow Implementation Guide

33 Service Request Related Records 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) (phase = Acceptance) Phase = Fulfillment Reason Code = In Progress Status = Active SRQ Accept Take Ownership Accept Assignment NOT (Status = Resolved, Status = Closed or Status = New) Reason Code = In Progress Status = Active Reassign to Group Assign to Group (status = Reason Code = Assignment SRQ Group Assign Status = Queued Reassign to Individual Assign to Individual (status = Reason Code = Assignment SRQ Ind Assign Status = Queued Reassign in My Group Assign to Individual (status = Reason Code = Assignment SRQ Ind Assign Status = Queued Chapter 3: Request Management Workflow 33