High Level Overview of…

Request Management

Pegasus: Request Management

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.

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

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):

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

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.

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.

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.

Request Status Workflow

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

Request Management Functionality Overview

For an End User who does not work on requests:

1. New Request – submit a request2. Search Requests – create a user specific view to view existing requests3. 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:

4. New Request – submit a request5. Search Requests – create a user specific view to view existing requests6. New Form – create a new Request Form7. Search Forms – find existing Request Forms8. New Request Type – create a new Request Type9. Search Request Types – find existing Request Types10. DropDownList Admin – create dropdown lists for use in Requests you build11. 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

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

How to Enable Email Notifications for Request Management

Pegasus: Request Management

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.

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.

How to Submit a Request

Pegasus: Request Management

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

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

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

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

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

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

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.

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.

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

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

How to Create and Modify Views

Pegasus: Request Management

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.

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

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

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

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

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

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

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.

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

How to Add a Task to a Request

Pegasus: Request Management

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

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

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

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.

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

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

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

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

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

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.

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

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

How to Submit a Similar Request

Pegasus: Request Management

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

Click on the icon beside “Add Similar Request”.

All info from the Request EXCEPT Requested Completion Date transfers to the new Request. Any custom fields on the form will have the same data; user should verify all fields and make updates as needed.

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

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.

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

How to Send an Ad Hoc Message

Pegasus: Request Management

If additional information is required for a submitted request, a member of the Assigned Work Group can send the Requestor an Ad Hoc Email.

Open the request and click the Ad Hoc Email tab. Note that the Requestor and Request Owner names are pre-filled.

Type the Ad Hoc message in the text box. Type the last name of any other persons to receive the email in the “Recipients” box to start the search.

Select the person from the Intellisensis list. The name will fill the “Recipients” text box.

Click the green “+” beside the “Recipients” box to add the person. Repeat the steps to add more recipients.

If you make a mistake in the addition of recipients and need to remove one, highlight their email in the list and click the Delete keyboard button to remove them.

Once all recipients have been selected, click the “Send Email” button. Recipients and sender will receive an email notice. User will receive a “success” message for the Ad Hoc note.

The email sent to the Requestor and Request Owner contains an active link to the request, Ad Hoc message, plus other information pertinent to the request.

Once the Ad Hoc message has been sent, the recipient list “refreshes” back to the requestor and request owner. Message text is manually deleted.

You can verify that the Ad Hoc message was sent by clicking the “History” tab.

How to Convert a Request to an Incident

Pegasus: Request Management

If the assigned Work Group determines that a submitted Request should be an Incident, it can be converted within Request Management.

Open the request and click the icon beside “Make this an Incident”. A confirmation popup window will appear. Click OK.

An escalation “success” message will be created. Requestor will receive an email notice about Incident.

The conversion process closes out the Request with the Closure Code of “withdrawn” and inserts the Incident ID in the Closure Notes. Request fields become disabled.

The “Request Tree” tab of the Request denotes that it is now completed.

The Requestor will receive an email alert about the creation of the Communication that contains an active link to the Communication.

The Communication created displays the source as “Request” and the assigned Work Group as the Help Desk. It is linked to the Incident.

The Incident created displays the source as “Request” and the assigned Work Group as the Help Desk.

How to Convert an Incident to a Request

Pegasus: Request Management

If the assigned Work Group determines that a submitted Incident should be a Request, it can be converted within Request Management.

Once you return the Incident list, locate the one in question. Click the ID to open it.

Click on the Options button of the Incident. Choose the “Convert to Request” menu item. If prompted, complete any required fields.

A pop-up window will appear. If you know the correct form to choose, scroll and select. Otherwise, click the green pushpin icon.

Choose the desired Request Form for the conversion by clicking on the hyperlink of the Form.

If the Request Form has any custom fields, you will be prompted to complete them.

After entering any custom fields, click the ADD button. If you neglect to enter any required fields, you will receive an error message directing you to finish entry.

A “success” message will be created. Requestor will receive email notices about the closed Incident and the new Request.

Incident has been closed out with the Status Code of “Resolved”.

The Communication associated with the Incident has been closed. Notation about Request creation to fulfill Incident.

Search Requests reveals that the Incident was converted to a QA Consulting request.

The “Request Tree” tab of the Request denotes the status of the parent and any child requests. In this example, there are no child requests.

An email will be sent to the Requestor and Request Owner about the conversion of the incident to a request with an active link to the Request.

How to Log an Enhancement Request for Request Management

Pegasus: Request Management

After using Request Management for a while, users may wish to add new features or enhancements to the application. All such requests for change should be logged in Pegasus using a specific request – ITSM ENHANCEMENT.

Complete the fields on the request, adding as much detail as possible. Include any documents as attachments, if desired. Click the Add button to submit the request.

You will receive a “successful” message and receive an email notification on the submission.

The email sent to the user contains an active link to the ticket, along with a short description of the logged item.

All logged enhancements will be reviewed by the SMO team. Users will receive email follow-up from Pegasus once the item is accepted for change or rejected.

Conclusion

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.