ITSM Process Designer Usage, Capabilities and Limitations

Transcription

1 ITSM Process Designer Usage, Capabilities and Limitations

2 TABLE OF CONTENTS Purpose and Audience... 3 Fixes from Process Designer Overview... 5 Installation... 6 Process Designer Development Environment... 7 SRM... 8 Approvals... 8 Service Request Fulfillment ticket synch... 9 Differences from conventional PDTs... 9 Best Practice... 9 ITSM Differences from TMS:TaskFlow processing End User Training considerations Best Practice Page 2

3 PURPOSE AND AUDIENCE ITSM Process Designer brings a vast array of new potential functionality to the implementation of an ITSM solution. However, it has some limitations, and is not appropriate for all use cases. This document is intended to augment the documentation and training available for the ITSM Process Designer product. It assumes that the reader has already become familiar with how to work with Process Designer, but provides Consultants and End User Administrators with a deeper understanding of its capabilities, and when it should or should not be used for a particular use case. Page 3

4 FIXES FROM See the ITSM 8.1 documentation for the complete list of fixed items. Only ones noted in the version of this whitepaper are noted here. The install now works as described in the Install Guide for the install in Linux/UNIX and Oracle. You can now have the system set to create Service Requests when Incidents or Work Orders are created, and Process Designer will not create a duplicate SRs. The Set Fields Count Operation did not previously work for Oracle. Now it works with both Oracle and SQL Server. Page 4

5 PROCESS DESIGNER OVERVIEW ITSM Process Designer (ITSM PD) allows users to implement processes in BMC ITSM and SRM using a simple graphical interface. It is entirely data driven, so no Remedy workflow is involved. In the case of SRM, the ITSM PD process replaces the conventional AOTs and PDTs associated with the SRD. The control of the process is then managed by the ITSM PD plugin rather than the SRM flow system. In the case of ITSM (Incident, Problem, Change, Work Orders, Purchase Request and Purchase Request Line Item), the ITSM PD process generates tasks associated with the ticket, which then implement the process. The flow of the tasks is controlled by the ITSM PD plugin rather than the TMS Task flow system. The tasks can either be automated tasks performing actions under the control of ITSM PD, or they can be manual tasks assigned to a support group for completion. The current version of Process Designer is This version is compatible with ITSM and higher. Page 5

6 INSTALLATION There are 2 parts to the Process Designer installation. 1) PDICT This installer runs on a Windows laptop and installs Remedy workflow and data in the ARS server. 2) Server Installation For a Windows server, the installer must run on the ARS Server box. For a UNIX server, the installation is a manual procedure. Page 6

7 PROCESS DESIGNER DEVELOPMENT ENVIRONMENT ITSM PD provides versioning and process lifecycle to manage the development of a new process. A process is first created in the Design phase. In this phase it can be edited repeatedly, but cannot be tested. It is then promoted to the In Test phase. In this phase, every save of an edited process creates a new version, so the original version is never lost. However, in this phase the process still cannot be tested. It must be promoted to Live before it can be related to an SRD or an ITSM ticket and tested. Only 1 version of a given process can be Live, and Live processes cannot be edited. Other phases allow you to have multiple versions of the same process. Live processes can be Archived, Suspended or a copy can be created in the In Test phase. Other than Live or Suspended processes, any version of a process can be deleted. Suspended processes can only be returned to Live. Page 7

8 SRM The tasks in an ITSM PD process for SRM are not TMS:Tasks. They also do not correspond to AOTs or necessarily to ITSM tickets. They are steps in a process. Each step may gather information, make decisions or actually create a ticket. APPROVALS Only individual ad-hoc approvals are implemented in ITSM PD. The picklist implies that Management Chain and Level approvals are available, but they are not functional (they act like individual ad-hoc approvals no matter what you pick). Group approvals are not available. These limitations are scheduled to be addressed in a future release. You can map the individual approver to a Process Designer field, so it is possible to build a lookup of the approver into your process rather than hard-coding the name. SRM Q&A Map Answer to SR Field ITSM Process Designer Set SR Field to Process Designer Field Key Set Process Designer Field Approver to Approver where Key=Key Custom Form: Approver Conf Key Red Blue Approver Allen Mary Approval Task Approver Field Service Request Approvals at the SRD level are not inherently recognized by ITSM PD. The process will commence and create tickets or do whatever else it is designed to do without waiting for the SR level approval to be completed. So to use SR approvals, you must build into your process a wait at the first step to detect when the Service Request has been approved and advanced past the Waiting Approval status. Page 8

9 SERVICE REQUEST FULFILLMENT TICKET SYNCH The activity log on the SR and work info on the fulfillment tickets are not automatically copied back and forth. This defect is scheduled to be fixed in a future release. The status changes on the fulfillment side do not synch back to the SR automatically. You must explicitly change the SR status to In Progress and Complete as part of your ITSM PD process. When ITSM PD creates a fulfillment ticket, it does not create the link on the Incident or Change ticket to open the associated Service Request. You can map the SRID explicitly to the fulfillment ticket when it is created, and this will make the link visible, but it is not functional because the linkages with the AppInstanceBridge are not created correctly. This defect is scheduled to be fixed in a future release. Links to the Service Request are created for Work Orders DIFFERENCES FROM CONVENTIONAL PDTS The ITSM PD process does not automatically wait for predecessor tickets to complete before creating the next ticket. You must explicitly build that into your process Since an approval is a task within the process, it is possible to pause and gather approvals in the middle of a process after some tickets or other tasks have already been completed. OOB notifications will be sent from the applications including approvals. But you can add additional notifications at any point in your process. It is possible to update any field on any ticket in your ITSM PD process, so for instance a completed ticket can be reopened based on results obtained later in the process. The ITSM PD Process wizard can be used to gather information from the requester rather than the SRD Q&A functionality. However see best practice below. BEST PRACTICE For a straightforward Service Request where a conventional PDT meets all of the customer s requirements, ITSM PD will not add any value. Providing all of the standard SRM functionality of approvals, synchronized ticket states, and managing sequential ticket creation with ITSM PD will complicate the project. So, conventional AOTs and PDTs should be used. Where special customer requirements cannot be met with conventional SRM, ITSM PD provides extended capabilities. However, the restrictions noted above must be considered. When using ITSM Process Designer, it is suggested that the Q&A for a request be built using the Question Mapping functionality of the SRD. Page 9

10 ITSM When integrated with other ITSM applications, ITSM tasks are created for each ITSM Process Designer Task, but they are managed by the ITSM PD process, not the TMS Task Flow system. Tasks can either be automated tasks or manual tasks. In an automated task, an action is performed by ITSM Process Designer and the task is automatically closed so that the process can proceed to the next task. In a manual task, the task is assigned to a support group, and a user must perform the task and manually close it. Approval tasks cannot be used in an ITSM process. So normal Change Management approval processes would be in place, and no additional approvals can be added in the processing of the tasks. DIFFERENCES FROM TMS:TASKFLOW PROCESSING Automated ITSM PD tasks can read and write to any form in the Remedy system including custom forms. This allows it to perform integration activities by copying data from one application to another, eliminating the need for custom Remedy workflow to implement that functionality. Automated tasks can be used to implement custom notifications in the process. It is possible to write loops into your ITSM PD process, so for instance a completed task can be reopened based on results obtained later in the process. Tasks can be performed and Closed using the Process Wizard without actually viewing the Task ticket itself Not all tasks in a process may actually be executed depending on the flow through the process. However ITSM PD will Close the ones that are skipped so that the ticket can be Completed. When an ITSM PD process is mapped to a ticket, the tasks are not created until the appropriate status has been reached. So implementation tasks on a Change ticket will not be visible during the Planning phase. END USER TRAINING CONSIDERATIONS In order to implement a decision point in your ITSM PD process, it is necessary for a task to have an outcome. In a manual task, this requires use of the Process Wizard to select the outcome, or manually selecting the Outcome field (added by the Process Designer install) of the task when you Close the task. Either of these procedures requires training of the users, and proper setting of the task outcome. If the outcome is not set, then the process will not operate correctly and no value will be realized from the process. There is no indication on the ticket or the tasks that ITSM PD is in play on a particular ticket. The only way for a user to tell is whether the Process Wizard or Process Tracker buttons are operational. Users will need to be trained on how to recognize an ITSM PD controlled ticket, perhaps by using a keyword in the Summary. Page 10

11 Tasks are not created on a ticket until the status set in the Process Mapping form is reached. This is likely to impact the validation and approval of a Change Ticket. Since the starting task is assigned as soon as it is associated with the ticket, implementation tasks will not be attached until the ticket reaches the Implementation in Progress status. That means that the tasks are not available for inspection during the planning and approval phases. The Change personnel will need to be trained to recognize a Change ticket that will be using an ITSM PD process (Keyword in Summary?), and base their decisions on the knowledge of the standard process in place. BEST PRACTICE ITSM Process Designer is best used for tickets which have a rigidly established process around them. This is likely to predominantly involve standard change tickets, but could involve some types of incident tickets. Where the ability to read and update forms provides value, it can be used to avoid workflow customization. But any use of ITSM PD will need to be accompanied by end user training to properly implement the process. Page 11

12 Business runs on IT. IT runs on BMC Software. Business thrives when IT runs smarter, faster, and stronger. That s why the most demanding IT organizations in the world rely on BMC Software across both distributed and mainframe environments. Recognized as the leader in Business Service Management, BMC offers a comprehensive approach and unified platform that helps IT organizations cut cost, reduce risk, and drive business profit. For the four fiscal quarters ended Dec. 31, 2008, BMC revenue was approximately $1.88 billion. Visit for more information. BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the property of their respective owners BMC Software, Inc. All rights reserved. Page 12