Presentation is loading. Please wait.

Presentation is loading. Please wait.

Request Management Mirror-. A random three day sample of Incidents revealed that about 86% of the registered Incidents were legitimate Requests Many other.

Similar presentations


Presentation on theme: "Request Management Mirror-. A random three day sample of Incidents revealed that about 86% of the registered Incidents were legitimate Requests Many other."— Presentation transcript:

1 Request Management Mirror-

2 A random three day sample of Incidents revealed that about 86% of the registered Incidents were legitimate Requests Many other Request processes exist that do not go through Service Manager Conclusion: we process lots of Requests in Informatics! User feedback -- Informatics is black box The Help Desk receives some Requests Other Requests come in via Email Web sites Sharepoint Pdf documents

3 Meet user community needs provide entry that is intuitive and easy to use build smart systems and processes to insure effective triage and monitoring facilitate appropriate and timely communication to the requestor

4 Quick and effective access to tools that will enable Requests to be logged and fulfilled Improved quality and consistency of Request processing Increased level of visibility through centralized management of Request processing Reduced cost of processing RequestsImproved visibility of the Request lifecycle

5  Listen to this preview so you can tell us what we forgot or what should be improved before we go forward  Communicate to work groups and Requestors

6 Requests Portal data in Service Manager workflow in Service Manager Standardized notifications Improved visibility Better coordination between workgroups Workflow will enable

7 Requests - Basic Flow

8 Submitted all Requests begin in this phase and remain there until someone looks at the ticket Pending the Request is in a wait state: Budget Resource Feasibility Other Approval Information Prioritization Assigned an individual has been assigned to the Request In progress the Request is active Completed the Request is completed and has a Closure Code: Duplicate Completed successfully Withdrawn Rejected

9 Requestors will be notified whenever a Request has a Phase change Ad hoc notifications will also be enabled Target workgroup managers will be notified when new requests are logged Requestors can opt out of the notifications except for when the request is Completed

10 Request Process Interaction between the Requestor and the work group Process to build content Interaction of work group, Service Manager & Requests management group Process to Review Requests Oversight by Requests management group and the Huddle

11 Users will have options Web forms will be built to enable the entry of Request details A web service will allow alternate entry options Allows for teams to build there own forms or enable existing forms

12 Users will be required to enter minimal information Submitted date Requestor Workgroup Request Owner Preferred method of contact Short description

13 Users will be required to enter minimal information Submitted date system generated Requestor “ Workgroup defaults to Help Desk Request Owner “ Requestor Preferred method of contact “ email Short descriptiononly required field

14 easily find request forms By workgroup By application By service My prior requests My department’s requests

15 Users should be able to report or query Incidents also Utilize Employee Self Service

16 Some content will be standardized across all portal pages Generic requests – enter some text and the Helpdesk will triage Log an Interaction through Employee Self-Service Key word search Request history My Requests My department’s Requests Explanation of Priority setting

17 Other content will require work groups to coordinate with Request Management to specify how their Requests should be processed

18 By entering a Request through the Request portal

19 EAI may want to specify what should happen when someone requests a server Layout a form to collect the data What type of ticket(s) are created in Service Manager Requests, Changes, etc Who they are assigned to? Are approval steps needed? Workflow – what sequence of events makes sense?

20 Eliminate ambiguity Estimate effort Propose alternatives Finalize requirements Complete development Resolve issues identified in testing

21 Number of requests over a time period Number of times Requests are re- assigned Actual completion vs. Estimated completion Actual completion vs. Requested completion Number of requests by phase Key performance indicators

22 Huddle Oversight Requested feature assigned to correct work group? Review Key Indicators Encourage use of the Requests process

23 Elapsed time in individual phases Number of Requests by workgroup Number of Requests by Request template Number of Requests by requestor Number of Requests that don’t meet timelines List of Requests by workgroup to use for Priority setting etc

24 Finalize design with feedback from this group Build workshop next week Develop the core infrastructure in Service Manager Start with 3-4 pilot request templates Add more templates for use by Informatics Open the Requests Portal outside of Informatics

25

26  Please spread the message  Provide more feedback to us when you encounter bright ideas


Download ppt "Request Management Mirror-. A random three day sample of Incidents revealed that about 86% of the registered Incidents were legitimate Requests Many other."

Similar presentations


Ads by Google