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

34 Service Request Related Records Set Pending Vendor (status = Reason Code = Vendor Status = Pending Set Pending Customer (status = Client Viewable (Work_View_ Type) = Yes Worklog descripti on SRQ Pending Customer Reason Code = Customer Status = Pending Work_Type = Client Note Resume Pending Request (status = Pending) Reason Code = Resumed Status = Active Create Linked Request Create (status = Reason Code = Linked Created Convert Service Request to Incident Create Incident (status = Phase = Closure Reason Code = Incident Created Status = Closed Convert Service Request to Request Create (status = Phase = Closure Reason Code = Created Request Status = Closed 34 Rapid Workflow Implementation Guide

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

36 Service Request Related Records Delete Service Request (Admin) 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. 36 Rapid Workflow Implementation Guide

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 restoration and availability. Chapter 4: Incident Management Workflow 37

38 Incident Ticket Life-Cycle 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: 38 Rapid Workflow Implementation Guide

39 Incident Ticket Life-Cycle Chapter 4: Incident Management Workflow 39

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

41 Incident Ticket Related Records INC/PRB Assign Group INC Auto-Route (Web) INC Accepted INC Resolved INC Reopened INC Pending Customer ${tr.assigned_to_grou p_name} ${tr.person1_alt_ema il} ${tr.person1_alt_ema il} ${tr.person1_alt_ema il} ${tr.person1_alt_ema il} ${tr.person1_alt_ema il} Notify the support group that the ticket has been assigned to the group using the Assign to Group workflow action. Notify the requester that the incident ticket has been logged and assigned to a support group queue. Notify the requester that the assignment of the incident has been accepted and is being worked on. Notify the requester that the incident has been resolved. Notify requester that the incident ticket has been reopened. 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_ } Notify requester that the incident ticket has been canceled. Task Completed Notice Task Failure Notice ${assigned_to_individ ual_name} ${assigned_to_individ ual_name} 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. 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. Chapter 4: Incident Management Workflow 41

42 Incident Ticket Related Records The table below lists the auto-routes configured and made available out-of-the-box for Incident Tickets. Auto Route Name Incident Default Auto Route Incident Default Agent Sort Order Matching Conditions 950 (Source = Web) 950 NOT (Source = Web) Set Fields and Set field values assigned_group_id = Service Desk (L1) Phase = Acceptance Reason Code = Incident Created Status = New Phase = Diagnosis Reason Code = In Progress Status = Active Related Communication Incident Auto-Route Web 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. 42 Rapid Workflow Implementation Guide

43 Incident Ticket Related Records The table below lists the Action Options that are available with the Out-of-the-box workflow configurations for Incident Management. Action Option Name Accept New Incident Take Ownership Reassign to Group Reassign to Individual Reassign in My Group Set Pending Vendor Special Function Accept Assignment Accept Assignment Assign to Group Assign to Individual Assign to Individual Matching Conditions Set Fields and Set field values (status = New) Phase = Diagnosis NOT (Status = Resolved, Status = Closed or Status = New) (status = (status = (status = (status = Reason Code = In Progress Status = Active Reason Code = In Progress Status = Active Reason Code = Assignment Status = Queued Reason Code = Assignment Status = Queued Reason Code = Assignment Status = Queued Reason Code = Vendor Status = Pending Requir ed Fields Communicati on Incident Accepted INC/PRB Assign Group INC/PRB Assign Individual INC/PRB Assign Individual Chapter 4: Incident Management Workflow 43

44 Incident Ticket Related Records Set Pending Customer (status = Client Viewable Worktype = Yes Workl og descri ption Incident Pending Customer Reason Code = Customer Status = Pending Worktype = Client Note Resume Pending Request (status = Pending) Reason Code = In Progress Status = Active Assign for Investigati on Assign to Group (status = (phase = Diagnosis) Phase = Investigation Reason Code = Assignment Status = Queued INC/PRB Assign Group Create Linked Problem Create Problem (status = Reason Code = Linked Problem Created Create Linked Request Create (status = Reason Code = Linked Created Create Linked Incident Create Incident (status = Reason Code = Linked Incident Created Convert Incident to Service Request Create Service Request (status = Phase = Closure Reason Code = Created Service Request Status = Closed 44 Rapid Workflow Implementation Guide

45 Incident Ticket Related Records Convert Incident to Request Create (status = Phase = Closure Reason Code = Created Request Status = Closed Resolve Incident (status = (phase = Investigation) assigned to group = Service Desk (L1) Phase = Closure Incident Resolved Reason Code = Pending Closure Status = Resolved Days to auto-close = 5 Resolve on First Call (status = (phase = Diagnosis) assigned to group = Service Desk (L1) Phase = Closure Reason Code = First Call Resolution Status = Resolved Days to auto-close = 5 Chapter 4: Incident Management Workflow 45

46 Incident Ticket Related Records Declare Major Incident (status = (phase = Diagnosis or Investigation) Phase = Major Incident Reason Code = Major Incident Severity = Major Incident Major Status = Active Resolve Major Incident Phase = Closure Reason Code = Major Incident Resolution Incident Resolved Status = Resolved Days to auto-close = 5 Close Resolved Incident (status = Resolved) Status = Closed Remove from Major Incident (phase = Major Incident) Phase = Investigation Cancel and Close Incident NOT (status = Resolved) OR (Status = Closed) Phase = Closure Reason Code = Canceled Incident Canceled Status = Closed Reopen Resolved Incident Accept Assignment (status = Resolved) Phase = Investigation Reason Code = Reopen Incident Reopened Status = Active 46 Rapid Workflow Implementation Guide

47 Incident Ticket Related Records Reopen Closed Incident Delete (Admin) Accept Assignment (status = Closed) Phase = Investigation Reason Code = Reopen Status = Active Incident Reopened The Incident Management Workflow design has two action options that are specific to Incidents: Resolve on First Call: This workflow action is designed to allow a means of measuring issues that are handled by the L1 support directly; without assistance from other support groups. Analyzing this data helps improve the efficiency of the L1 team by creating more knowledge articles that they can use to triage common incidents. Declare Major Incident: This workflow action is designed to help track the number of major issues detected; if required, a problem ticket can be created based on the Major Incident to resolve the root cause of the Major Incident. Chapter 4: Incident Management Workflow 47

48

49 Chapter 5: Problem Management Workflow A Problem is the unknown Cause of one or more Incidents, and is often identified as a result of multiple Incidents reported by multiple users. A Problem is usually reported when an Incident is so severe that a Configuration Item could fail or when service availability is severely affected. This section provides information about the Problem Management process and the out-of-the-box workflow design for managing Problem tickets. This section contains the following topics: Problem Management Overview (see page 49) Problem Ticket Life-Cycle (see page 51) Problem Ticket Related Records (see page 53) Problem Management Overview Problem Management deals with determining and eliminating the root cause of the issue in such a way as to prevent recurrence. Problem Tickets are usually logged before a critical failure - to identify the root cause of the incidents and prevent a failure. Problem Tickets can also be logged to review a failure and to take corrective action; or for proactive prevention of potential disruption of critical services. The objective of Problem Management is to minimize the adverse impacts of Incidents or Problems caused by errors in the IT infrastructure, and to initiate actions to prevent recurrence of Incidents related to those errors. Problem Management deals with finding out the root cause of the incidents which led to the creation of the problem ticket and resolve the root cause of the incidents. Problem Management aims at resolving issues in such a way as to eliminate future prevent recurrence and to minimize the impact of the issue even if incidents cannot be totally prevented; with the focus being on root cause analysis to get to the root of the problem and identify ways of solving the problem. Where the Problem resolution necessitates a change, a ticket is logged to implement the change before resolving the problem ticket. Chapter 5: Problem Management Workflow 49

50 Problem Management Overview The Problem Management process involves establishing a root cause analysis process which aims to: Categorize reports of existing or potential problems with an existing device or service. Enable diagnosis of the problem reported. Manage the process of allowing for error control, to control existing or potential disruptions, leading to closure of the problem. 50 Rapid Workflow Implementation Guide

51 Problem Ticket Life-Cycle Problem Ticket Life-Cycle Problem Tickets typically pass through four phases from creation to closure; Categorization, Diagnosis, Error Control and Closure. All problem management tickets, irrespective of the source; set in the Categorization phase; and then worked on towards closure as appropriate. The progression of a Problem ticket is shown in the diagram below: Chapter 5: Problem Management Workflow 51

52 Problem Ticket Life-Cycle 52 Rapid Workflow Implementation Guide

53 Problem Ticket Related Records The templates, auto-routes and workflow actions that are part of this workflow design are listed in the sections that follow. Problem 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. Task tickets and task ticket templates are included as part of the Problem Management workflow design. The following workflow configuration records are included as part of the Problem Management workflow design. Problem Ticket Templates The following ticket templates are made available as part of the Problem Management out-of-the-box configurations Template Name Catego ry Description Set Fields Permission Problem Report (Agent) Genera l Assigns ticket to Problem Management group for review Reason Code = Problem Report Symptom Description = Enter a description of the problem Administration (Support Group) Problem Management (Role) Symptom Details = Enter details of the problem Proactive Problem (Agent) Genera l Reports a problem and assigns it to the reporter Reason Code = Proactive Problem Symptom Details = For a Proactive Problem, create a description, and assign a class. Replace these details with a detailed description of the problem. Administration (Support Group) Problem Management (Role) Chapter 5: Problem Management Workflow 53

54 Problem Ticket Related Records Report Known Error Genera l Template for direct creation of known error Reason Code = Known Error Status = New Symptom Details = For a Known, create a description, and assign a class, cause, and Resolution. Replace these details with a detailed description of the problem. Administration (Support Group) Problem Management (Role) PRB- Resolve Related Tickets (Task Ticket) Proble m Standard Problem Management Task - Prior to closure, ensure all related tickets are appropriately resolved. Reason Code = Execution Status = Queued Task Description = Look at the related tickets to this problem, and resolve them prior to closure of this problem ticket. Administration (Support Group) Problem Management (Role) Task Name = Resolve Related Tickets PRB-Revie w Knowledg e Articles (Task Ticket) Proble m Standard Problem Management Task, prior to closure ensure all related knowledge is reviewed and/or retired Assigned Group ID = Problem Management Reason Code = Execution Status = Queued Task Description = Review related knowledge for this problem prior to closure. status, or retire articles as required. Administration (Support Group) Problem Management (Role) Task Name = Review Knowledge 54 Rapid Workflow Implementation Guide

55 Problem Ticket Related Records Note: Please take note of the following: 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. There are two task tickets (PRB_Resolve Related Tickets and PRB_Review Knowledge Articles) that make up a Task Group related to Problem Tickets. These are sample templates; and are not directly tied into the out-of-the-box workflow for Problem Management. You can modify the workflow to include these tasks into the problem resolution and closure process. Problem Communication Templates The following communication templates are made available as part of the out-of-the-box Problem Management workflow configurations: Template Name INC/PRB Assign Ind INC/PRB Assign Group Problem Pending Customer Task Completed Notice Task Failure Notice Send To ${tr.assigned_to_indiv idual_name} ${tr.assigned_to_grou p_name} ${person1_alt_ } ${assigned_to_individ ual_name} ${assigned_to_individ ual_name} Purpose Notify an individual about assignment of the ticket using Assign to Individual workflow action. Notify the support group that the ticket has been assigned to the group using the Assign to Group workflow action. Notify requester that the problem ticket has been set as pending information from the customer. 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. 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. Chapter 5: Problem Management Workflow 55

56 Problem Ticket Related Records Problem 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. The table below lists the auto-routes configured and made available out-of-the-box for Problem Tickets. Auto Route Name Sort Order Problem Default 950 Proactive Problem Matching Conditions 900 Reason Code = Proactive-Pro blem Known Errors 950 Reason Code = Known-Errors Set Fields and Set field values assigned_group_id N = Problem o Management n Phase e = Categorization Reason Code = Assessment Status = Queued Phase = Categorization Reason Code = Proactive-Problem Status = Queued assigned_group_id = Problem Management Phase = Categorization Reason Code = Known-Errors Status = Queued assigned_group_id = Problem Management Related Communication Note: In the out-of-the-box workflow design; it is assumed that Problem Tickets will be logged and managed by the Problem Management Role; and the problem tickets will be logged using the out-of-the-box ticket templates. As the ticket is logged by the request management role; no communication templates have been related to the auto-routes for notifying requesters about ticket creation or assignment action. 56 Rapid Workflow Implementation Guide

57 Problem Ticket Related Records Problem Workflow Action Options The table below lists the Action Options that are available with the Out-of-the-box workflow configurations for Problem tickets. Action Option Name Take Ownership Reassign to Group Reassign to Individual Reassign in My Group Set Pending Information Set Pending Customer Special Function Accept Assignment Assign to Group Assign to Individual Reassign in Group Matching Conditions NOT (Status = Resolved, Status = Closed or Status = New) (status = (status = (status = (status = (status = Set Fields and Set field values Reason Code = In Progress Status = Active Reason Code = In Progress Status = Queued Reason Code = In Progress Status = Queued Reason Code = In Progress Status = Queued Reason Code = Information Status = Pending Client Viewable = Yes Reason Code = Customer Status = Pending Work Type = Client Note Required Fields Worklog descriptio n Communica tion INC/PRB Assign Group INC/PRB Assign Individual INC/PRB Assign Individual Problem Pending Customer Chapter 5: Problem Management Workflow 57

58 Problem Ticket Related Records Resume Work on Pending Ticket (status = Pending) Reason Code = In Progress Status = Active Assign for Diagnosis (Self) (status = A c c e p t (phase = Categorization ) Phase = Diagnosis Reason Code = In Progress CCTI_Clas s Assign for Diagnosis (Group) Assign for Diagnosis (Individual) Promote to Known Error Assign to Group Assign to Individual (status = A s s i g n m e n t (phase = Categorization ) (status = (phase = Categorization ) (status = (phase = Diagnosis) Phase = Diagnosis Reason Code = Assignment Status = Queued Phase = Diagnosis Reason Code = Assignment Status = Queued Phase = Error Control Reason Code = In Progress CCTI_Clas s CCTI_Clas s INC/PRB Assign_Gro up INC/PRB Assign_Indiv idual 58 Rapid Workflow Implementation Guide

59 Problem Ticket Related Records Waiting on (status = Reason Code = Waiting on (phase = Error Control) Status = Pending NOT (reason code = Waiting on ) Create Linked Request Create (status = (phase = Error Control) Reason Code = Waiting on Linked Close Problem Cancel and Close Problem Reopen Problem Delete (Admin) (status = Phase = Error Control NOT (status = Resolved OR status = Closed) Accept Assignment (status = Closed) Phase = Closure Reason Code = Closed Status = Closed Phase = Closure Reason Code = Canceled Status = Closed Phase = Diagnosis Reason Code = In Progress Status = Active Chapter 5: Problem Management Workflow 59

60 Problem Ticket Related Records Note: The out-of-the-box workflow configurations for Problem Tickets does not have a specific workflow action for creating or managing tasks related to Problem Management or actions related to Resolve Problem. It is recommended that you configure a workflow action to Resolve Problem tickets. With this workflow action, you can associate a special function 'Auto-Create Tasks' to create tasks for implementing the resolution and ensuring the all related task tickets are closed, and knowledge articles updated before resolution of the problem ticket. 60 Rapid Workflow Implementation Guide

61 Chapter 6: Management Workflow is defined as addition, modification, or removal of an existing IT system or service; like software or hardware systems, configurations, access and permissions documentation etc. A can be reactive - in response to a problem that has been identified; or proactive - to prevent potential problems or improve service delivery. This section provides information about the Management process and the out-of-the-box workflow design for managing requests. This section contains the following topics: Management Overview (see page 61) Request Life-cycle (see page 62) Management Related Records (see page 75) Management Overview Management is the process of managing a change ticket through its life-cycle. This includes setting up processes for classification of the change type, approval and review of a change; including setting up multi-level approval process where needed; implementation of a change and closure of the change request. The objective of Management is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes. Due to the fast pace of change in technologies; the associated need for change in the IT service offerings is equally pressing. s that are not well planned can lead to problems. Therefore there is a need for tightly managed and controlled approach towards change in IT systems and services. Management aims to minimize any undesirable disruptions to an existing IT service due to change implementation. This is managed by configuring appropriate approval groups; comprising of individuals who can comment on a change and determine whether to proceed with the change or not. This is further aided by configuring workflow actions to ensure that once approved, the change ticket goes through relevant implementation and post implementation review. Management involves setting up a process for efficient handling of changes; and aims to ensure that: is classified using an appropriate change type; and processed through a workflow for that change type. is submitted through an appropriate change approval process; specific to the type of change. Chapter 6: Management Workflow 61

62 Request Life-cycle is implemented as per a defined process; with tasks to ensure all aspects of the change are appropriately implemented. implementation is reviewed to ensure that overall business risk is minimized; and that the change is recorded in all related systems prior to closure. Request Life-cycle request can be classified into the following four types; based on factors like nature of change, impact, urgency etc. Standard : This change type is suggested for common requests related to IT systems and services used often in the organization; for example request from an employee for installation of a software, or access to a system or database. Such requests do not need an elaborate change approval process; and can be approved by contextual approvers like the requester's manager or an approver associated with a configuration item. Normal : This type of change is suggested for implementing proactive, planned changes to IT systems and services; for example implementing new IT security systems; which will impact how users access the IT resources over a VPN. Implementation of such a change would call for a thorough investigation, detailed change implementation plans, multiple levels of review and approvals, potential down-time during implementation; and post implementation review to ensure that the change was implemented correctly. Emergency : This type of change is suggested for reactive situations; where implementing a change is necessary to either correct or avert a major problem with existing systems or services; For example a server is failing; leading to downtime for several users and to correct this, the faulty server has to be replaced. As delay in implementing could cause additional issues; a quicker approval process and implementation process is needed in this situation. Break-fix : This type of change is normally used to report a change after it is implemented; in a situation where the change was implemented without an approval process; For example, the security of a server was compromised; and it has to be removed from the network to prevent further security breech. Break-fix changes do not go through an approval process; and is only used to record the change. To support the approval needs for different types of change; different approval types can be associated with a change ticket. The approval types you can set are: All Approvers: When this Approval Type is selected, ALL approvers must approve the ticket. If any approver (even one among all assigned approvers) rejects the ticket, the approval process ends and the change is rejected. Any One Approver: A is approved as soon as any ONE approver approves. The change approval process does not wait for inputs from remaining approvers; the approval is rejected only when ALL approvers REJECT the proposal. 62 Rapid Workflow Implementation Guide

63 Request Life-cycle Any One Approval or Rejection: A change is approved or rejected by a single approver from Approval Group. The decision of the FIRST approver who responds (Approve or Reject) to the approval process gets applied. In this case, the Approval process does not wait for inputs from the remaining approvers. The out-of-the-box configurations for change management include customized workflow process for each type of change, and relevant approval type has been associated with the different change types. Note: It is highly recommended that the new change requests be logged using the appropriate ticket template for the relevant change type. This will ensure that the correct change approval process gets associated with the change. Chapter 6: Management Workflow 63

64 Request Life-cycle Standard 64 Rapid Workflow Implementation Guide

65 Request Life-cycle Standard Chapter 6: Management Workflow 65

66 Request Life-cycle s typically pass through five phases from creation to closure; Raise, Manager's Approval, Implementation, Standard Post Implementation Review and Closure. Based on whether the ticket is approved or rejected in the Manager's Approval phase; the action on approval or action on rejection gets applied; and the ticket either moves forward into the implementation phase; or moves back into the Raise Phase. The progression of a Standard through its life-cycle is shown in the diagram below: Note: Workflow action options starting with zz (example - zzmanager Approved) are for backend actions by the system; in response to another action, and are used for automating a subsequent action. For example; the zzmanager Approved action could be executed by the approval engine when the ticket is approved by the requester's manager; and can be used to set the ticket into the Implementation Phase. These workflow actions do not get displayed in the 'Take and Action' dropdown; and are not available for manual action for analysts. 66 Rapid Workflow Implementation Guide

67 Request Life-cycle Normal Chapter 6: Management Workflow 67

68 Request Life-cycle Normal 68 Rapid Workflow Implementation Guide

69 Request Life-cycle s typically pass through six phases from creation to closure; Raise, Manager's Approval, Manager Review, Implementation, Normal Post Implementation Review and Closure. Normal changes have a two stage approval process. The first stage is the Manager's Approval phase. Once the ticket is approved in this phase; the auto-action (zzmanager Approved) sets it into the Manager Review Phase; which is the next approval phase. The Manager Review Phase has two supplementary phases; 'CAB Approval Phase' and 'CAB Review Phase'. The Manager can take one of the following manual action which will set the ticket either into next phase: Approve for Implementation workflow action will set the ticket directly into Implementation phase. Submit for CAB Review workflow action will set the ticket into CAB Review Phase, and the Approval Type 'Any one Approval or Rejection' will get set on the ticket. Thus, the ticket can be approved or rejected based on the response from the first approver who responds to the approval notification. Submit for CAB Approval or Submit for Urgent Approval workflow action will set the ticket into CAB Approval Phase, and the Approval Type 'All Approvers' will get set on the ticket. Thus, the ticket will have to be approved by ALL approvers. Any one rejection will lead the ticket to be rejected. Based on the nature of the change; and other organizational processes; the Manager can determine how to proceed with the change. The progression of a Normal through its life-cycle is shown in the diagram below: Note: Workflow action options starting with zz (example - zzmanager Approved) are for backend actions by the system; in response to another action, and are used for automating a subsequent action. For example; the zzmanager Approved action could be executed by the approval engine when the ticket is approved by the requester's manager; and can be used to set the ticket into the Implementation Phase. These workflow actions do not get displayed in the 'Take and Action' dropdown; and are not available for manual action for analysts. Chapter 6: Management Workflow 69

70 Request Life-cycle Emergency 70 Rapid Workflow Implementation Guide

71 Request Life-cycle Chapter 6: Management Workflow 71

72 Request Life-cycle Emergency s typically pass through five phases from creation to closure; Raise, Manager Review, Implementation, Emergency Post Implementation Review and Emergency Closure. The primary difference between Emergency and Normal process is that Emergency s do not have the Manager Approval phase. Once the change is raised; it goes directly into the Manager Review Phase. The Manager Review Phase has two supplementary phases; 'ECAB Approval Phase' and 'ECAB Review Phase'. The Manager can take one of the following manual action which will set the ticket either into next phase: Approve for Implementation workflow action will set the ticket directly into Implementation phase. Submit for ECAB Review workflow action will set the ticket into ECAB Review Phase, and the Approval Type 'Any one Approval or Rejection' will get set on the ticket. Thus, the ticket can be approved or rejected based on the response from the first approver who responds to the approval notification. Submit for ECAB Approval workflow action will set the ticket into ECAB Approval Phase, and the Approval Type 'All Approvers' will get set on the ticket. Thus, the ticket will have to be approved by ALL approvers. Any one rejection will lead the ticket to be rejected. Based on the nature of the change; and other organizational processes; the Manager can determine how to proceed with the change. Depending on whether the change is approved or rejected; the ticket progresses further. The progression of an Emergency through its life-cycle is shown in the diagram below: Note: Workflow action options starting with zz (example - zzmanager Approved) are for backend actions by the system; in response to another action, and are used for automating a subsequent action. For example; the zzmanager Approved action could be executed by the approval engine when the ticket is approved by the requester's manager; and can be used to set the ticket into the Implementation Phase. These workflow actions do not get displayed in the 'Take and Action' dropdown; and are not available for manual action for analysts. 72 Rapid Workflow Implementation Guide

73 Request Life-cycle Break-fix Chapter 6: Management Workflow 73

74 Request Life-cycle 74 Rapid Workflow Implementation Guide

75 Management Related Records As Break-fix s are logged to record a change after it is implemented (without going through an approval process); Break-fix s pass through three phases from creation to closure; Record, Break-fix Review and Break-fix Closure. Unlike other types of changes; Break-fix change does not have an associated approval cycle; or an extended implementation phase, because the primary purpose of logging a break-fix change is when the change has already been implemented without first being approved. The progression of a Break-fix through its life-cycle is shown in the diagram below: The templates, auto-routes, and workflow actions that are part of the workflow design for all types of change tickets are listed in the sections that follow. Management 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. Task tickets and task ticket templates are included as part of the Management workflow. The following workflow configuration records are included as part of the Management workflow design. Chapter 6: Management Workflow 75

76 Management Related Records Ticket Templates Ticket Templates are pre-formatted ticket forms with pre-populated values supplied for some key ticket fields, as per the purpose and intended audience for the template. A ticket template can have values defined for selected fields; and some fields can be set as 'Required' fields; enabling a standardized way of logging requests. It also facilitates effective auto-routing of ticket logged using the template by defining fields like source; assigned to etc. The following ticket templates are made available as part of the out-of-the-box workflow configurations. Template Name Normal Request (Agent) Standard Request (Agent) Emergency Request (Agent) Create Break-fix Request (Agent) Provision New Employee (Sample) Categor y Description Set Fields Permission General Create normal change request General Create standard change request General Create emergency change request General Create break-fix change request Employ ee Services Provision new employee with the lead time of 5 days Type =Normal Reason Code = Normal Agent Type = Standard Reason Code = Standard Agent Type = Emergency Reason Code = Emergency Agent Type = Break-fix Reason Code = Break-fix Agent ccti_id = Provision - Employee Description = New Employee Provisioning Request Reason for change = New Employee Joining Organization Administratio n Management (Role) Administratio n Management (Role) Administratio n Management (Role) Administratio n Management (Role) Administratio n Management (Role) Default Self Service (Role) 76 Rapid Workflow Implementation Guide

77 Management Related Records Provision Web Server (Sample) IT Services Sample template for provisioning web server. Assigned Group ID= Server Support (L2) ccti_id = Provision - Server - Web Administratio n Default Self Service (Role) Description = Provisioning request for new server Public Phase = Raise Reason Code = New Reason for = New Web Server Request Status = Queued Provision Office (Task Ticket) Employ ee Services Sample task template which is part of a Task Flow - Provision New Employee Assigned Group ID = Facilities ccti_id = Provision - Office - Furniture Phase = Initiated Administratio n Public Reason Code = New Request Description = Construct office, Desk, Chair, Other Task Name = Provision Office Facilities Provision PC (Task Ticket) Employ ee Services Sample task template which is part of a Task Flow - Provision New Employee Assigned Group ID = Desktop Support ccti_id = Provision - Personal Computer Phase = Initiated Administratio n Public Status = Queued Description = Provision new PC Task Name = Provision PC Chapter 6: Management Workflow 77

78 Management Related Records Provision Network Accounts (Task Ticket) Security Sample task template which is part of a Task Flow - Provision New Employee Assigned Group ID = Administration ccti_id = Security - Provision - Account Phase = Initiated Administratio n Reason Code = New Account Status = Queued Description = Set up network access Task Name = Network Access Request Provision Web Server (Task Ticket) Server Provisio ning Sample task template, which is part of a Task Flow - Web Server Provisioning Assigned Group ID = Server Support (L2) ccti_id = Provision - Server - Web Phase = Raise Task Administratio n Reason Code = New Task Status = Queued Description = Configure new web server Task Name = Web Server Provisioning 78 Rapid Workflow Implementation Guide

79 Management Related Records Update Configurati on Manageme nt Database (Task Ticket) Configu ration Sample task template, which is part of a Task Flow - Web Server Provisioning Assigned Group ID = Manager ccti_id = Infrastructure - Update - CI Phase = Raise Task Administratio n Public Reason Code = New Task Status = Queued Description = Update CMDB with data on newly created server Task Name = Update CMDB Note: Please take note of the following: 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. There are two Task Flows, with related task ticket templates. You can modify the workflow to include these tasks into the change implementation process. Communication Templates The following communication templates are made available as part of the out-of-the-box Management workflow configurations: Template Name Pending Customer Individual Assign Group Assign Send To Purpose ${person1_alt_ } Notify requester that the change ticket has been set as pending information from the customer. ${tr.assigned_to_indi vidual_name} ${tr.assigned_to_gro up_name} Notify an individual about assignment of the ticket using Assign to Individual workflow action. Notify the support group that the ticket has been assigned to the group using the Assign to Group workflow action. Chapter 6: Management Workflow 79

80 Management Related Records Closed with Exceptions Closed without Exceptions ${person1_alt_ } Notify requester that the change request has been closed with exceptions ${person1_alt_ } Notify requester that the change request has been closed without exceptions Task Completed Notice Task Failure Notice ${assigned_to_indivi dual_name} ${assigned_to_indivi dual_name} 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. 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 approval notifications. 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. The table below lists the auto-routes configured and made available out-of-the-box for Requests. Auto Route Name Sort Order Break-fix 900 Normal Default (Agent) Matching Conditions Reason Code = Break-fix 900 Reason Code = Normal Agent Set Fields and Set field values Type = Break-Fix Phase = Record Reason Code = New Status = Active Type = Normal Phase = Raise Reason Code = New Status = Active Related Communication 80 Rapid Workflow Implementation Guide

81 Management Related Records Emergency Default (Agent) Standard Default 900 Reason Code = Emergency Agent Type = Emergency Phase = Raise Reason Code = New Status = Active 950 Type = Standard Phase = Raise Reason Code = New Status = Active Note: In the out-of-the-box workflow design; it is assumed that New Requests will not be logged directly by requesters. requests will be logged either by Service Desk (L1) or other support groups by creating a change from a Service Request, Incident or Problem ticket. As notifications for creation of the change ticket are triggered by the respective workflow actions, no notification to the requester has been associated to the auto-routes. You can choose to relate a communication template to these auto-routes if necessitated by your support processes. Workflow Action Options The table below lists the Action Options that are available with the Out-of-the-box workflow configurations for tickets. Action Option Name Special Function Matching Conditions Set Fields and Set field values Required Fields Communicati on Take Ownershi p Accept Assignment NOT (Status = Resolved, Status = Closed) NOT (Reason Code = Pending Approval) Reason Code = In Progress Status = Active Chapter 6: Management Workflow 81

82 Management Related Records Reassign to Group Assign to Group (status = NOT (Reason Code = Pending Approval) Reason Code = Assignment Status = Queued Group Assign Reassign to Individual Assign to Individual (status = NOT (Reason Code = Pending Approval) Reason Code = In Progress Status = Queued Individual Assign Reassign in My Group (status = R e a NOT (Reason s Code = Pending s Approval) i g n Reason Code = Assignment Status = Queued Individual Assign i n G r o u p Set Pending Informatio n (status = NOT (Reason Code = Pending Approval) Reason Code = Information Status = Pending 82 Rapid Workflow Implementation Guide

83 Management Related Records Set Pending Customer (status = NOT (Reason Code = Pending Approval) Client Viewable = Yes Reason Code = Customer Worklog descripti on Pending Customer Status = Pending Work type = Client Note Resume work on Pending Ticket (status = Pending) Reason Code = In Progress Status = Active Submit for Managem ent Review (status = A c c e p t ( Type = Break-fix) NOT(Phase = Break-fix A Review) s s i g n m e n t Phase = Break-fix Review Reason Code = Break-fix Review Cancel and Close (status = ( Type = Break-fix) Phase = Break-Fix Closure Reason Code = Canceled Status = Closed Chapter 6: Management Workflow 83

84 Management Related Records Close (status = (phase = Break-fix Review) ( Type = Break-fix) Phase = Break-Fix Closure Reason Code = Break-fix Request Closed Closed Without Exceptions Status = Closed Cancel and Close (status = Phase = Break-Fix Closure ( Type = Break-fix) Reason Code = Canceled Status = Closed Close (status = (phase = Break-fix Review) ( Type = Break-fix) Phase = Break-Fix Closure Reason Code = Break-fix Request Closed Closed Without Exceptions Status = Closed Reopen and Take Ownershi p Accept Assignment (status = Closed) (phase = Break-fix Closure) Phase = Break-fix Review Reason Code = Reopen Status = Active 84 Rapid Workflow Implementation Guide

85 Management Related Records zzmanage r Approved (Status = zz Phase = Mgr Review Reason Code = Manager Approved Status = Active zzmanage r Rejected (Status = zz Phase = Raise Reason Code = Manager Rejected Status = Active Chapter 6: Management Workflow 85

86 Management Related Records Submit for Manager's Approval Submit for Approval (Status = (Phase = Raise ) appr_action _id when_ approved = zzmanager Approved ( Type = Normal) NOT (Reason Code = Pending Approval) appr_action _id_when_ rejected = zzmanager Rejected Approval Phase = Manager Approval Approval Type = Any one Approval or Rejection Reason Code = Pending Approval Status = Active Withdraw from Manager's Approval Withdraw from Approval (Status = (Phase = Manager's Approval) Phase = Raise Reason Code = Withdrawn (Reason Code = Pending Approval) Status = Active ( Type = Normal) 86 Rapid Workflow Implementation Guide

87 Management Related Records zzcab Approved (Status = zz Phase = Implementa tion Reason Code = CAB Approved Status = Active zzcab Rejected (Status = zz Phase = Normal Closure Reason Code = CAB Denied Status = Active Withdraw Withdraw from Approval (Status = Phase = Raise (Phase = CAB Approval CAB Review) Reason Code = Withdrawn (Reason Code = Pending Approval) Status = Active ( Type = Normal) Approve for Implemen tation (Status = Active (Phase = Mgr Review) Phase = Implementa tion Reason Code = Approved ( Type = Normal) Chapter 6: Management Workflow 87

88 Management Related Records Submit for Urgent Approval Submit for Approval (Status = (Phase = Mgr Review) ( Type = Normal) appr action id when approved = zzmanager Approved appr action id when rejected = zzmanager Rejected Approval Phase = CAB Approval Approval Type = All Approvers Phase = CAB Approval Reason Code = Pending Approval 88 Rapid Workflow Implementation Guide

89 Management Related Records Submit for CAB Approval Submit for Approval (Status = (Phase = Mgr Review) ( Type = Normal) appr action id when approved = zzmanager Approved appr action id when rejected = zzmanager Rejected Approval Phase = CAB Approval Approval Type = All Approvers Phase = CAB Approval Reason Code = Pending Approval Chapter 6: Management Workflow 89

90 Management Related Records Submit for CAB Review Submit for Approval (Status = (Phase = Mgr Review) ( Type = Normal) appr action id when approved = zzmanager Approved appr action id when rejected = zzmanager Rejected Approval Phase = CAB Approval Approval Type = Any One Approval or Rejection Phase = CAB Review Reason Code = Pending Approval Implemen tation Complete d (Status = Active (Phase = Implementatio n) ( Type = Normal) Phase = Normal Post Implementa tion Review Reason Code = Implementa tion Completed Status = Active 90 Rapid Workflow Implementation Guide

91 Management Related Records Implemen tation Failed (Status = Active (Phase = Implementatio n) ( Type = Normal) Phase = Normal Post Implementa tion Review Reason Code = Implementa tion Failure Close as Successful (status = (phase = Normal Post Implementatio n Review) Phase = Normal Closure Reason Code = Completed Successfully Closed Without Exceptions ( Type = Normal) Status = Closed Close with Exceptions (status = (phase = Normal Post Implementatio n Review) ( Type = Normal) Phase = Normal Closure Reason Code = Completed With Exceptions Status = Closed Client Viewable Time Spent Worklog Descripti on Worklog Type Closed With Exceptions Cancel and Close (Status = Phase = Standard Closure ( Type = Standard) Reason Code = Canceled Status = Closed Chapter 6: Management Workflow 91

92 Management Related Records zzstandar d Manager Approved (Status = zz Phase = Implementa tion Reason Code = Manager Approved Status = Active zzstandar d Manager Rejected (Status = zz Phase = Raise Reason Code = Manager Rejected Status = Active 92 Rapid Workflow Implementation Guide

93 Management Related Records Submit for Manager's Approval Submit for Approval (status = (phase = Raise ) ( Type = Standard) appr action id when approved = zzstandard Manager Approved appr action id when rejected = zzstandard Manager Rejected Approval Phase = Manager Approval Approval Type = Any One Approval or Rejection Phase = Standard Manager Approval Reason Code = Pending Approval Withdraw from Manager's Approval Withdraw from Approval (status = (Reason Code = Pending Approval) Phase = Raise Reason Code = Withdrawn (phase = Manager Approval) ( Type = Standard) Chapter 6: Management Workflow 93

94 Management Related Records Implemen tation Complete d (status = (Phase = Implementatio n) ( Type = Standard) Phase = Standard Post Implementa tion Review Reason Code = Implementa tion Successful Implemen tation Failed (status = (Phase = Implementatio n) ( Type = Standard) Phase = Standard Post Implementa tion Review Reason Code = Implementa tion Failure Close as Successful (Status = (Phase = Standard Post Implementatio n Review Phase = Standard Closure Reason Code = Completed Successfully Closed Without Exceptions ( Type = Standard) Status = Closed Close with Exceptions (Status = (Phase = Standard Post Implementatio n Review ( Type = Standard) Phase = Standard Closure Reason Code = Completed with Exceptions Status = Closed Client Viewable Time Spent Worklog Descripti on Worklog Type Closed with Exceptions 94 Rapid Workflow Implementation Guide

95 Management Related Records Cancel and Close (Status = Phase = Normal Closure ( Type = Normal) Reason Code = Canceled Status = Closed Cancel and Close (Status = Phase = Emergency Closure ( Type = Emergency) Reason Code = Canceled Status = Closed Approve for Implemen tation (Status = (Phase = Raise ) Phase = Implementa tion Reason Code = Approved ( Type = Emergency) NOT (Reason Code = Pending Approval) zzecab Approved (Status = zz Phase = Implementa tion Reason Code = ECAB Approved Status = Active Chapter 6: Management Workflow 95

96 Management Related Records zzecab Rejected (Status = zz Phase = Emergency Closure Reason Code = ECAB Denied Stauts = Closed Submit for ECAB Approval Submit for Approval (Status = (Phase = Raise ) appr action id when approved = zzecab Approved ( Type = Emergency) appr action id when rejected = zzecab Rejected Approval Phase = ECAB Approval Approval Type = All Approvers Phase = ECAB Approval Reason Code = Pending Approval 96 Rapid Workflow Implementation Guide

97 Management Related Records Submit for ECAB Review Submit for Approval (Status = (Phase = Raise ) appr action id when approved = zzecab Approved ( Type = Emergency) appr action id when rejected = zzecab Rejected Approval Phase = ECAB Review Approval Type = Any One Approval or Rejection Phase = ECAB Review Reason Code = Pending Approval Withdraw Withdraw from Approval (Status = Phase = Raise (Reason Code = Pending Approval) Reason Code = Withdrawn (Phase = ECAB Approval OR Phase = ECAB Review) Stauts = Active ( Type = Emergency) Chapter 6: Management Workflow 97

98 Management Related Records Implemen tation Complete d (Status = (Phase = Implementatio n) ( Type = Emergency) Phase = Emergency Post Implementa tion Review Reason Code = Implementa tion Successful Status = Active Implemen tation Failed (Status = (Phase = Implementatio n) ( Type = Emergency) Phase = Emergency Post Implementa tion Review Reason Code = Implementa tion Failure Status = Active Close as Successful (Status = (Phase = Emergency Post Implementatio n Review) ( Type = Emergency) Phase = Emergency Closure Reason Code = Successfully Completed Status = Closed Closed Without Exceptions 98 Rapid Workflow Implementation Guide

99 Management Related Records Close with Exceptions Delete Request (Admin) (Status = (Phase = Emergency Post Implementatio n Review) ( Type = Emergency) Phase = Emergency Closure Reason Code = Completed with Exceptions Status = Closed Client Viewable Time Spent Worklog Descripti on Worklog Type Closed with Exceptions In addition to the above workflow actions; which are part of the core workflow design; the out-of-the-box configurations for change also contain the following workflow actions for logging and managing related tasks: Start Provisioning Tasks: This workflow action is available when a ticket is submitted using the 'New Employee Provisioning Template'; or meets matching conditions on that template. Executing this action sets the ticket phase as 'Tasking'; with Reason Code as 'Tasking in Progress' Start Provisioning Task: This workflow action is avaialble with a ticket is submitted using the Web Server Provisioning Template, or meets matching conditions on that template. Executing this action sets the ticket phase as 'Tasking' with Reason Code as 'Tasking in Progress' zztasking Successful: This workflow action is a backend action that is fired when all tasks in the task flow are completed as successful. Execution of this action sets the ticket phase as 'Standard Post Implementation Review' and Reason Code as 'Tasking Successfully Completed'. zztasking Failed: This workflow action is a backend action that is fired when a task in the task flow has failed completion. Execution of this action sets the ticket phase as 'Implementation' with Reason Code as Tasking has Failed'. Chapter 6: Management Workflow 99

100 Management Related Records Approval Groups For implementation of the Approval Process; the administrator can configure Approval Groups with different matching conditions such as Type, CCTI etc. When a change ticket with the matching conditions is logged; the approval groups get automatically related to the ticket. You can either select Contextual approvers or reviewer to be members of the approval group; or select specific individual contacts as approvers and reviewers in that approval group. The following Approval Groups are configured as sample groups in the out-of-the-box configurations. Approval Group Name Matching Conditions Description Management Approval Approval Group CAB Approval Approval Group ECAB Approval Approval Group ${appr_phase} = 'Manager Approval' ${appr_phase} = 'CAB Approval' ${appr_phase} = 'ECAB Approval' This approval group gets related to a change ticket when it is in Manager Approval phase. The Requester's Manager gets picked from the context of the ticket as the approver. This approval group gets related to the change ticket when it is in CAB Approval Phase. You can select contacts who you wish to relate to this approval group. This approval group gets related to a change ticket when it is in ECAB Approval Phase. You can select contacts who you wish to relate to this approval group. 100 Rapid Workflow Implementation Guide

101 Management Related Records You can modify the matching conditions to suit the needs of your organization; and configure additional approval groups modeled on the groups above. Note: There are no contacts currently related to these approval groups. You will need to select approvers and reviewers from the contacts configured in your instance and relate them to the approval groups. Only contacts from those support groups that can be used for Approval will be available for you in the name search lookup displayed for selecting approvers and reviewers to the approval groups. Chapter 6: Management Workflow 101

102

103 Chapter 7: Known Issues and Points to Note This section contains information on some known issues and limitations in the out-of-the-box workflow design and suggested workarounds for these. This section also lists some key points to note about the workflow design or the configuration changes made to support the workflow design. This section contains the following topics: Known Issues (see page 103) Points to Note (see page 110) Known Issues The following errors and omissions have been identified with the out-of-the-box configurations; and are still open in the current release: No Support Group related to the Configuration Management Role No 'Report an Outage' Ticket Template for analysts. Users will be unable to log Service Request from the UI. Incorrect matching conditions for the workflow action 'Withdraw from ' No Communication Templates have been related to 'Submit for Approval' workflow action. These issues and suggested workarounds have been explained in the following sections. No Support Group related to Configuration Management Role Configuration Management Role and Configuration Support Group Relationship is broken: A Role titled 'Configuration Management' has been created, with permissions to Configuration Management related options in the Navigation Menu; and a Support Group titled 'Configuration' has been created. For the permissions model to work, the 'Configuration' Support Group has to be related to the 'Configuration Management' Role. However, this relationship has been missed in the out-of-the-box configurations. Chapter 7: Known Issues and Points to Note 103

104 Known Issues Solution: Relate the Configuration Support Group to the Configuration Management Role. Follow these steps: 1. Click Manage Roles in Application Setup in the Navigation Menu The Manage Roles form will be displayed, and all existing Roles will be displayed in the table. 2. Click Configuration Management Role in the table The Configuration Management Role details will be displayed in the form. 3. Click 'Add Groups' button on the form displaying the Configuration Management Role. The lookup with Support Groups that can be used for permissions will be displayed. 4. Click the checkbox next to 'Configuration' Support Group from the groups listed and click 'Select' The Configuration Support Group will get related to the 'Configuration Management' Role. You can now relate contacts to the Configuration Support Group, and these contacts will inherit the permissions assigned to the Configuration Management Role. No Report an Outage Ticket Template for Analysts Permission to Report an Outage Ticket Template is not given for Incident Management Role: The Incident Management workflow design considers that analysts will log Incident tickets using the 'Report an Outage' Ticket template configured with Source as 'Agent'. However, there is no such Ticket Template in the out-of-the-box configurations. For the workflow design to work, new tickets logged by analysts will need to be logged with the Source field manually set as 'Agent'. Solution: Configure a ticket template with appropriate set field values and enable permission for the ticket template to Service Desk (L1) or other relevant support group(s). Follow these steps: 1. Click 'Manage Ticket Templates' in Workflow Tools in the navigation menu. The Manage Ticket Templates form will be displayed. You can create a new ticket template using this form. 104 Rapid Workflow Implementation Guide

105 Known Issues 2. Select 'Incident' in the Ticket Type dropdown to configure the ticket template for Incident tickets. 3. (Optional) Specify a 'Category' to categorize the template. Note: It is a good practice to categorize ticket templates, especially if you plan to configure templates for different types of requests. 4. Specify a Template Name that helps identify the template and its use. For example 'Report an Outage (Agent)'. 5. (Optional) Specify a definition for the template which helps users further identify what the template is to be used for and click 'Apply s' The Set Fields and Permissions tabs not get active and you can now set field values to match the auto-route rules for appropriate routing of incident tickets. 6. Select 'Source' as 'Field to Set' from the dropdown list displaying fields that can be set on the ticket template, and click 'Add' The corresponding selection field to select the source will get displayed in the 'Value' column. 7. Select 'Agent' from the dropdown list displaying possible values for the Source field and click 'Apply s' to save the value for the source field. The basic configuration to match Incident Tickets created using the template to the appropriate auto-route is not complete. You can set additional field values if needed. Next, from the Permissions tab, you can assign permission for the ticket template to the Incident Management Role. By default, permissions to the template is available to 'Administration' support group. 8. Click 'Manage Permissions' button on the Permissions tab. The Permissions editor lookup will be displayed. All Support Groups that can be used for permissions and all roles configured will be displayed. 9. Choose 'Incident Management' Role from the list displayed and click 'Add' and close the Permissions editor. Permission to the new ticket template will now be available to the Incident Management Role, and ticket logged using the template will follow the auto-routes and workflow design for Incident tickets. Chapter 7: Known Issues and Points to Note 105

106 Known Issues Users will be unable to log Service Requests from the UI Users will be unable to log new Service Requests using the User Interface: Analysts related to 'Service Request Management' Role, or other support groups or roles will not be able to log a new Service Request from the UI as they don't have access to 'Log Service Request' option in the navigation menu and because there are no Service Request related ticket templates in the out-of-the-box configurations. Also, Self-Service Users will not be able to create Service Requests using the UI as they do not have access to 'Submit Request' option in the Navigation Menu, and there are no ticket templates related to Service Requests. It is assumed that Service Requests will be logged by Self-Service Users via , and the appropriate auto-route will get applied to the ticket. Solution: A recommended workaround for this is to identify top requests that you would classify as Service Requests, and configure ticket templates for these requests. You can then assign permission for these requests to the Request Management Role or Default Self-Service Role. Another workaround is assigning permission to Log Service Request option to Service Request Management Role and Submit Request to the Default Self-Service Role. You can assign permission to the 'Submit Request' navigation menu option to Self-Service Users and Log Service Request to analysts Follow these steps: 1. Click 'Manage Navigation Menu' in Administration Utilities in the navigation menu. You can assign and manage permissions to different navigation menu options from this form. To assign permission to the 'Create New' option for Self-Service Users: 2. Select 'Self-Service Home' in the form name filter The list will be filtered and the table will list forms related to the Self-Service User interface. 3. Select 'Submit Request' option (Form ID 218) from the list. The form details will be displayed in the form below. 4. Click the Permissions tab and Manage Permissions button on the permissions tab. The Permissions Editor lookup will be displayed. 5. Select 'Default Self-Service' Role, click Add and close the permissions editor. Self-Service Users will not have access to Submit Request option in the navigation menu. 106 Rapid Workflow Implementation Guide

107 Known Issues To assign permission for analysts to the Log Service Request option, follow the procedure above filtering the list using navigation menu group 'Request Management' Note: It is recommended that you configure ticket templates for Service Request and assign permissions to relevant roles to better manage this function. Incorrect Matching Conditions for 'Withdraw ' Workflow Action Workflow Action 'Withdraw from Approval' for Normal has incorrect matching condition: The Workflow Action 'Withdraw from Approval' is designed to be available for change tickets when Status is Action, Reason Code is Pending Approval and Phase is CAB Approval or Phase is CAB Review, and Type is Normal. Due to an error during configuration, the matching condition for Phase is configured as 'Phase = CAB ApprovalCAB Review' instead of 'Phase = CAB Approval CAB Review. Because of incorrect matching conditions, this workflow action will not be available on the ticket at the desired state. Solution: Correct the configuration for the matching conditions, so that it will be available in the desired state: Follow these steps: 1. Click 'Manage Workflow Actions' in Workflow Tools in the navigation menu. The Manage Workflow Actions form will be displayed. 2. Enter 'Withdraw ' in the search window to locate the workflow action. Note: Check the filter conditions to ensure that Ticket Type is set to either or All. There are two workflow actions called 'Withdraw ', one with matching conditions for Type Emergency and the other with matching conditions for Type Normal. 3. Click the 'Withdraw ' workflow action from the list. The workflow action option details will be displayed in the form below. The Matching Conditions tab will display the matching conditions configured for the workflow action. If the selected action is for Normal, the incorrect configuration will be displayed in the matching conditions (Phase = CAB ApprovalCAB Review). Click on the existing matching condition and the existing details will be populated in the form below. You can modify this to correct the error. Chapter 7: Known Issues and Points to Note 107

108 Known Issues 4. Reconstruct the Matching conditions for the workflow action: a. Match Type = Include b. Status = Active c. reason code = Pending Approval d. Phase = CAB Approval CAB Review e. Type = Normal Note: Using the pipe ( ) character sets more than one option for a selected attribute (Example: Phase = CAB Approval or Phase = CAB Review) 5. Click Apply s The matching conditions for the workflow action will be displayed in the field. 6. Review the matching conditions to ensure that it is constructed correctly. The configuration needed to make the 'Withdraw ' workflow action in the appropriate state is now complete. You can test the configuration by creating a Normal, and working it through to 'Submit for Approval' stage. One the change has been submitted for approval, the Withdraw workflow action should be displayed. No Communication Associated with Submit for Approval Workflow Action There are no communication templates associated with the Submit for Approval related Workflow Action: The Submit for Approval Workflow Actions do not have associated communication templates to notify Approvers and Reviewers about the action being executed. It has been observed that users of Service Management solutions do not want encourage the practice of approving Requests by responding to the notifications. Due to this, the communication templates have not been related to this workflow action by design. Solution: There are two system defined communication templates which can be used to notify approvers and reviewers about a change that has been submitted for approval: Manual Approver Notification (ID -22) Manual Reviewer Notification (ID -23) You can relate these template to any or all Submit for Approval Workflow Actions. 108 Rapid Workflow Implementation Guide

109 Known Issues For example, you can relate the communication templates to the 'Submit for Manager's Approval' Workflow Action Follow these steps: 1. Click 'Manage Workflow Actions' in Workflow Tools in the navigation menu. The Manage Workflow Actions form will be displayed. 2. Enter 'Submit for Manager's Approval' in the search window to locate the workflow action. Note: Check the filter conditions to ensure that Ticket Type is set to either or All. 3. Click on the 'Submit for Manager's Approval' in the list. The workflow action details will be displayed in the form below. You can relate the communication templates from the Communications tab. 4. Click 'Add Template' button in the Communications tab The Communication Templates lookup will be displayed. You can relate communications to the workflow action from this lookup. 5. Select the 'Include System Defined' checkbox to include system defined communication templates in the list and click Search A list of available communication templates will be displayed. 6. Select the templates 'Manual Approver Notification' and 'Manual Reviewer Notification' from the list and then click Select. The selected communication templates will get related to the workflow action, and notification using these templates will be sent to contacts listed as Approvers and Reviewers for the change ticket. Chapter 7: Known Issues and Points to Note 109

110 Points to Note Points to Note In addition to the above, please take note of the following limitations in the out-of-the-box configurations: Application functionality of incoming response to ticket notifications, example, updates to the ticket in response to an Approval or Rejection to a change ticket, has not been tested. The functionality of configuring multiple boxes and relating a mailbox to a ticket type has not been explored. It is assumed that s will result in creation of a Service Request. CCTI based categorization for tickets and configuration items, and use of CCTI to build ticket auto-routes has not been explored as the categorization system varies from one organization to the other. When configuring new workflow actions and auto-routes; or ticket templates using the existing design, please take note of the following: 'Source' has been used as a matching condition for different ticket types. A new Source value 'Agent' has been added as part of the out-of-the-box workflow design. This will need to be followed when configuring ticket templates and workflow actions to meet the existing workflow design. 'Reason Code' has been configured as matching condition for Request related auto-route and workflow actions. This will need to be adhered to when configuring additional templates, workflow actions or auto-route rules. Definitions for Phase and Reason Code must be followed correctly when configuring additional records, as mistakes in this could lead to the workflow action or auto-route failing. 110 Rapid Workflow Implementation Guide