Table of Contents. Process Diagram Data Model... 5 SYSTEM ENTITIES... 6 WFUSER... 6 AREA Case Type Request Type Category...

Transcription

1

2 Table of Contents Process Diagram Data Model... 5 SYSTEM ENTITIES... 6 WFUSER... 6 AREA... 6 Case Type... 6 Request Type... 6 Category... 6 Subcategory... 6 Status... 6 Priority... 7 Closure Type... 7 COLLECTIONS... 7 Ticket History Forms... 7 Visibility rules... 7 Validations Business Rules Rules for Tables updating Performers Assignment rules... 11

3 Your company is growing up and the technologic resources management becomes more critical and complicated. Impacts generated by unavailability and malfunctioning are getting bigger, making assistance requests more frequent and complex. Bizagi s Help Desk process template allows you to efficiently manage employees incidents and requests in a single process, providing effective solutions in the lowest time. The process allows to improve employee productivity and to handle your activities with a continuous improvement concept: delivering control of case records in the knowledge base and requesting actions improvement. This way, every case becomes positive feedback that will reduce case opening and standardize the attention of frequent incidents. Feel free to download it from our Free Process Central and to customize it according to your needs. 3

4 This document will guide you through the main steps to build the Internal Help Desk process in Bizagi. The main factors are presented here. The Internal Help Desk process starts when an employee opens a case. It will be assisted by the Help Desk Agent The Help Desk Agent must verify the case information and check whether further information is needed, if the case must be escalated or if he/she can resolve it. Once all the required information is complete and the case is addressed by the person who is able to resolve it, the solution is sent. When the effectiveness of the solution is verified, the case is recorded in the KB, if required, and finally is closed by the Help Desk Agent. 4

5 In the Data Model, there is the Business Process entity called Ticket. This entity contains all the attributes and relationships of the case. The first relationship is with the system entity WFUSER, which allows the process to identify the case performers, such as the requester, the Help Desk Agent, technicians, people to whom the case is escalated and the person to whom improvement suggestions are sent. Relations with Parameter tables are established too, such as Case Type, Priority and Status. These allow the user to select values for being used as case information. Finally we have the relationship with the Ticket History collection. This is a one to many relationship since a case can have many comments. This way the information is recorded between the different case performers. A brief description of the entities is presented below. 5

6 This entity is useful to identify the employee who opened the case, the performers and the people in charge of the areas to whom improvement suggestions are sent. This entity identifies the Area to which a user belongs parameter entities This identifies the case type which can be an Incident or a Request. This is a Request classification so that a case can be escalated in a more specific way. This is an Incident classification. This is an Incident sub-classification so that a case can be escalated in a more specific way. This identifies the case status, which can be Open, Waiting for Information, Resolved or Closed. 6

7 This identifies the case priority, which can be Critical, High, Medium or Low This identifies the case closure type according to the case type, which can be Immediate or with Monitoring. It is a collection that saves the information flow between the different case performers. In this collection the person who makes the comment, the date and additional files are saved. The Internal Help Desk forms require the use of advanced properties of Behaviors and Validations, so that queries and information can be entered in the correct way. Some of the Internal Help Desk forms require visibility rules so that information is shown or hidden according to what has happened in the case. This presents the information in an organized manner for the end users For the Analyze and Resolve task, some visibility rules are used for showing information related with escalation and information request. Thus, only if these actions are going to be executed, will their information be shown. 7

8 Visibility rules are also used for showing the Information Tables in the different tabs of the forms. If the tables have no records, they are not shown. 8

9 In the Analyze and Resolve task, Bizagi validates that the case resolver only executes one of the 3 possible options: Request information to the requester Escalate the case or Send a solution. In order to achieve that control a validation is used, in the Advanced Properties of the form, that will throw an error message when the user tries to execute more than one action at the same time. 9

10 This process executes different business rules to establish the process flow and to manage its information. These rules are executed on enter, on exit and/or on save of some tasks. These rules are executed on exit of Analyze and Resolve, Send Requested Information and Report solution did not work and are used to enter information into the different information tables. These rules, make it possible to enter information automatically to the tables such as the name of the person who recorded the information and the date when he/she did it 10

11 Once the information has been added to the tables, it is displayed as follows: The assignments in the Analyze and Resolve task, are one of the most important things for the Internal Help Desk process because the cases must have assistance from the correct people. For this reason it is necessary to establish conditions that allow the process to do the assignments in the correct way. These rules are executed in the performers assignment of the Review and Analize task. Here four conditions are used: Default: This condition is used to assign the case, initially, to the Help Desk Agent. Here the Attribute first is evaluated. It is TRUE the first time the process enters the Analyze and Resolve task and it will be FALSE the rest of the process. 11

12 Selected Area: This condition evaluates if the process had previously entered into the Analyze and Resolve task and if it was escalated to an area so that the current assignee is a person who belongs to such area. Selected Person: This condition evaluates if the process had previously entered into the Analyze and Resolve task, and if it was escalated to a specific person so that such person is the new case assignee. 12

13 Keep Assignee: This condition evaluates if the process had previously entered into the Analyze and Resolve task and for any reason (Requested information was sent or Requester reported ineffective solution) must be resumed by the last person who worked on the case. This process also executes rules on enter and on exit of different tasks for validating and saving information of every case. Now you are ready to customize this process to your needs. 13