Pegasus: Request Management

 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.

 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.)

 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): 1. The Workgroup is Live on Request Management 2. 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

 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.

 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.

 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 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 s for the other statuses in their Preferences.

 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).

For an End User who does not work on requests: 1. New Request – submit a request 2. Search Requests – create a user specific view to view existing requests 3. 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: 1. New Request – submit a request 2. Search Requests – create a user specific view to view existing requests 3. New Form – create a new Request Form 4. Search Forms – find existing Request Forms 5. New Request Type – create a new Request Type 6. Search Request Types – find existing Request Types 7. DropDownList Admin – create dropdown lists for use in Requests you build 8. 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

 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

Pegasus: Request Management

Thank You! This course and related training presentations will continue to be available for your reference here, in The Learning Exchange under the “My Courses” section. The Learning Exchange