High Level Overview of… Request Management

1. Pegasus: Request Management High Level Overview of…Request Management

2. Request Management Objectives • The Objectives of Request Management: • Provide a standard mechanism for Requestors to request work or a service directly from the various Workgroups • Provide the ability for Requestors to monitor the status of their submitted requests • Provide the ability for Workgroups to triage, monitor, communicate, and complete requests • Provide transparency of the available services and the ability to set expectations on the turnaround time for these services to the Requestors (our customers) • Problem Statement: • Today, requestors utilize different methods to request services from the various Workgroups. These methods are hard to understand and to find. In addition, many requests are logged via the Help Desk. This requires Help Desk staff resources to triage these to appropriate Workgroups instead of these requests being routed directly to the appropriate Workgroup and results in unnecessary time delays for our customers.

3. When to Use Request Management? • Continue to use the existing Incident Management … • when something is not working correctly (malfunctioning computer hardware, applications, services) • Use Request Management … • to request work or a service to be performed by a Workgroup who is live on Request Management (identified by Request Types found on New Request). • Examples: New computer hardware, User access to applications, Enhancement to an application, Project Management Services, Request to setup Request Management, etc.)

4. Converting a Request to an Incident and Converting an Incident to a Request • When should a Request be converted to an Incident? • Any Workgroup member (workgroup specialist) when triaging incoming requests, can convert a Request to an Incident if they determine that the Requestor is not requesting work or a service but instead is reporting a disruption. • When should an Incident be converted to a Request? • An Workgroup member or a Help Desk member when triaging incoming incidents can convert an Incident to a Request if all of the following are true (if they are both not true it should remain an incident): • The Workgroup is Live on Request Management • The Workgroup has the corresponding Request Type setup in Request Management • Helpful Hint! Workgroups enrolled in Request Management can be determined on the New Request Screen

5. Request Vocabulary • Requestor • The person who is requesting work or a service to be performed by a Workgroup. It can be someone outside or inside Informatics. • Request Owner • A person who is the true owner of the Request in the case when a Requestor is submitting a request on behalf of another person. • Workgroup • The group that will be performing the work or service identified in the Request type. • Request Type • These are the various types of requests (one per each unique type of work or service) that are setup by each Workgroup. • These are visible on New Request which is used by requestors to submit requests.

6. Request Vocabulary – Continued • General Purpose Request • When Requestors don’t know which request type to select, they can log a General Purpose Request which will be triaged by the Help Desk to the appropriate Workgroup. • Request • The actual request occurrence requested by a Requestor. • identified by the prefix “R” followed by a number (R101). • Request Form • These are the building blocks of a Request Type defined by Workgroups prior to going live on Request Management. • Each Request Form can include custom fields that need to be captured from the Requestor at the time a request is submitted. • To view standard request fields, common to all forms, view the General Purpose Request.

7. Request Status Terminology • Request Status values: • Submitted * • A Request is set to Submitted at the time the request is logged by a Requestor. • Assigned • A Request is set to Assigned at the time an Workgroup member is assigned to the request (can be assigned by the Workgroup Manager or Workgroup member). • In Progress • A Request is set to In Progress by the Workgroup member working on the request when they have started work. • Testing • A Request is set to Testing when a feature of a Workgroup’s request is in a testing phase and not yet in production. • Pending * • A request can be set to Pending (on hold) and a pending reason must be set (e.g., Pending Approval, Prioritization, Information, etc.). • Completed * • A request is set to Completed at the time the request is closed. A closure reason code also is required (Duplicate, Fulfilled, Rejected, Withdrawn, etc.). * An email notification will be sent to the Requestor and the Request Owner at the time a request is moved to these statuses. Users can opt in to also get emails for the other statuses in their Preferences.

8. Request Status Workflow

9. Advanced Request ManagementRules - Request Types and Request Forms • Each Request Type can have multiple Request Forms associated with it. The Request Type is the parent and the Request Forms are the children. • A single Request Form (a child) is associated with a single Workgroup. • All children must be closed before the parent will be allowed to be closed. • A single Workgroup must own and monitor the parent and its children. • For Complex Requests - It is possible to embed parent Request Types in other Request Types with multilevel request tree structures. Each level must be either parallel or sequential (not both).

10. Request Management Functionality Overview For an End User who does not work on requests: • New Request – submit a request • Search Requests – create a user specific view to view existing requests • Views • Predefined: “Request – My Open” and “Request – My Department Open” • User definable views are also available that were created in Search Requests For a Workgroup Member who works on requests and also can submit requests: • New Request – submit a request • Search Requests – create a user specific view to view existing requests • New Form – create a new Request Form • Search Forms – find existing Request Forms • New Request Type – create a new Request Type • Search Request Types – find existing Request Types • DropDownList Admin – create dropdown lists for use in Requests you build • Views • Predefined: “My Worklist” (additional section added called “Requests Assigned to My Workgroups”) • Predefined: “Request – My Open” and “Request – My Department Open” • Predefined: “Request Assigned to Me – Open” and “Request Assigned to My Workgroup – Open” • User definable views are also available that were created in Search Requests

11. A big thanks to: • Request Design Workgroup members: • Lynn Brooks, Laura Butler, Michael Burt, Susan Conner, Alan Cantrell, Cass Fagan, Chris Jircitano, Jason Pattee, Leslie Mackowiak, Ruby Reyes • Request Build Workgroup members: • Lynn Brooks, Alan Cantrell, Jim Hargrave, Lee Knight, Jane Mandeville, Ruby Reyes, Chris Wright • Request Pilot Testers: • Jim Hargrave and Team (CWS Team), Mark Bailey (Horizon Clinicals Team), Chris Wright and Cheryl Graves & Team (Help Desk), Meredith Speight (VMG Training Team), Mike Frizzell (VMG EMR Team), System Support Team reporting to Karen Hughart. • Other Roles of Interest: • Executive ITSM Project Sponsor: Jeff Kimble • ITSM Project Sponsor: Alan Cantrell • ITSM Program Manager: Jane Mandeville • Request Development Manager: Jason Pattee • Request Developers: Brian Lee, Troy Nelson, Holli Trapp • Request QA Leader: Kathy McFarland • Request Process Owner and Request Pilot Project Manager: Lynn Brooks

12. Pegasus: Request Management How to Enable Email Notifications for Request Management

13. Request Management uses the Email Notifications and Alerts already present in Pegasus. Choose the “My Profile” item under the Support option on the Pegasus module menu bar.

14. Maximize the web page and click on the “Personal Subscriptions” tab. Enable the five new options for Request. Click the “Save” button to save changes.

15. Pegasus: Request Management How to Submit a Request

16. The new Request Management module in Pegasus gives users another self-service option. To begin, choose Request>>New Request.

17. Users have multiple ways to search for the desired Request. The “Workgroup” and “Sort” filters may be used separately or in concert.

18. If the desired Request cannot be found, users have the option of using the “General Purpose Request” form.

19. Once a Request has been chosen, click on it to open it. The “New Request” page will load.

20. Starting at the top of the form, begin to fill in all Required fields. Additional info can be entered in the two ‘description’ fields.

21. Complete any required custom fields on the form. If desired, attach additional documents to the request.

22. Once all fields have been entered, click the ADD button. Users will receive a “Successful Submission” message when the request has met submission requirements. Both Requestor and Request Owner will receive email notification.

23. The email sent to the Requestor and Request Owner contains an active link to the request, short description, requested completion date, and assigned work group.

24. Opening the Request reveals more about its assignment, storage of information, and other options available to the user.

25. The submitted request is viewable under Request >> Search Requests.

26. Pegasus: Request Management How to Create and Modify Views

27. Request Management has pre-set Views built into it. However, users have the ability to create specific Views of Requests. To begin, choose Request>>Search Requests.

28. Using the available filters, select options for your customized View. When done click the Search button.

29. When the results are returned, type the name of the new View in the “View Name” field. Click the Create View button.

30. User should receive a “success” message about the creation of the new View. It will also appear in the dropdown for My Request Views.

31. If the name of the View needs to be changed, enter the revised name for the View and click the Update View button.

32. The revised name for the View will now appear in the My Request Views dropdown.

33. The custom View is also available by going to Views and choosing the item from the My Views dropdown.

34. A custom View can also be deleted. After launching the View from Request >> Search Requests, click the delete button to remove it. A pop-up confirmation will appear. Click OK.

35. The custom View is removed from the Search Requests >> My Request Views dropdown and the Views >> My Views dropdown.

36. Pegasus: Request Management How to Add a Task to a Request

37. It is possible to add a task to a submitted Request if the request type was built to allow ad hoc tasks.

38. To begin, locate and open the Request you wish to clone for an added task.

39. Click on the icon beside “Add Additional Task to this Request”.

40. If you know the name of the Active Request Type, enter it in the text box. Otherwise, type a “/” to retrieve a list of all Active Request Types.

41. After choosing the Active Request Type, click the icon to continue.

42. Enter all required standard and custom fields of the Request. Attach any documents necessary.

43. Once all info and any attachments have been added to the Request, click the ADD button. “Success message” and appropriate emails will be generated.

44. As noted, if the new task has a duration assigned, it will be added to the expected completion time for the original request.

45. The new Request that has been added can be seen in the Request Tree tab of the original request.

46. The email sent to the Requestor and Request Owner contains an active link to the request, short description, requested completion date, and assigned work group.

47. The added request is viewable under Request >> Search Requests.

48. Note that the added task is independent of the original Request. It can be completed before the original Request without issue.

49. Pegasus: Request Management How to Submit a Similar Request

50. It is possible to generate a Similar Request from a submitted Request. To begin, locate and open the Request you wish to clone.