2.148.3 Request Fulfillment Process 2.148.3.1 Program Scope and Objectives 2.148.3.1.1 Background 2.148.3.1.1.1 Process Description 2.148.3.1.1.2 Goal 2.148.3.1.1.3 Objectives 2.148.3.1.2 Authority 2.148.3.1.3 Roles and Responsibilities 2.148.3.1.4 Program Management and Review 2.148.3.1.5 Program Controls 2.148.3.1.5.1 Controls 2.148.3.1.5.2 Metrics 2.148.3.1.5.3 Tailoring Guidelines 2.148.3.1.6 Terms/Definitions/Acronyms 2.148.3.1.6.1 Terms and Definitions 2.148.3.1.6.2 Acronyms 2.148.3.1.7 Related Resources 2.148.3.1.8 Training 2.148.3.2 Process Workflow 2.148.3.2.1 Main Process Diagram 2.148.3.2.2 Inputs 2.148.3.2.3 Outputs 2.148.3.2.4 Activities 2.148.3.2.5 Procedure 2.148.3.2.5.1 Procedure Flow Diagram 2.148.3.2.5.2 SACM 1 Configuration Management Planning Part 2. Information Technology Chapter 148. IT Support Services Management Section 3. Request Fulfillment Process 2.148.3 Request Fulfillment Process Manual Transmittal May 29, 2020 Purpose (1) This transmits revised IRM 2.148.3, IT Support Services Management, Request Fulfillment Process. Material Changes (1) Restructured IRM 2.148.3 documentation with Internal Controls from IT IRM Process Section Template V5. (2) Updated seven paragraphs on Program Scope and Objectives (3) Updated Background paragraph (4) Removed third paragraph of Purpose of Process Description (5) Updated Document Overview paragraph (6) Updated Purpose paragraphs one, two, and three (7) Updated 6 graphic flow charts Effect on Other Documents IRM 2.148.3, dated March 28, 2016, is superseded Audience This Process Description is applicable to all organizations within the IRS requesting IT products and services and by anyone which has the responsibility of delivering those products and services to our Information Technology customers and users. Effective Date (05-29-2020) Nancy A. Sieger Acting Chief Information Officer 2.148.3.1 (05-29-2020) Program Scope and Objectives Overview - This IRM describes the formal process for managing the Enterprise Information Technology (IT) Request Fulfillment Process Description Purpose - This IRM contains procedural steps for Request Fulfilment process owners, service catalog managers, service owners, Associate Chief Information Officer (ACIO) liaisons and frontline managers. Audience – IT organizations providing IT service offerings Policy Owner – User and Network Services (UNS), ACIO is responsible for oversight of Request Fulfillment Program Owner – UNS is the program owner for Request Fulfilment Primary Stakeholders – The primary stakeholders are UNS, Enterprise Operations (EOps), ACIO Strategy & Planning (S&P), Application Development (AD), Cybersecurity, and Enterprise Services (ES). Program Goals – This IRM provides the fundamental knowledge and procedural guidance to maintain the Enterprise IT Request Fulfilment. 2.148.3.1.1 (05-29-2020) Background Request Fulfillment come from customers and users ordering products and services that are in the service catalog. Requests can also be initiated as the result of an approved Work Request (WR), approved Change Request or a Break/Fix replacement. The output of the process is the delivery of products or services requested. 2.148.3.1.1.1 (05-29-2020) Process Description This Request Fulfillment Process describes what happens within the Request Fulfillment Process and provides an operational definition of the major components of the process. This description specifies, in a complete, precise, and verifiable manner, the requirements, design, behavior characteristics of the Fulfillment Process. This is a documented expression of a set of activities performed to achieve a given purpose. Tailoring of this process in order to meet the individual needs of each project is covered in the Tailoring Guidelines section of this document. For the purpose of this document, roles such as Service Requestor, First Level Support, Service Owner, Service Support Provider, etc. are provided to describe a set of responsibilities for performing a particular set of related activities Note: Not all products and service are available to all requesters. Availability is based on Service Level Agreement (SLA) for the product or service and requester’s entitlement. 2.148.3.1.1.2 (05-29-2020) Goal The format and definitions used to describe each of the process steps for Request Fulfillment are described below: Purpose - The objective of the process step. Roles and Responsibilities - The responsibilities of the indivduals or groups for accomplishing a process step. Entry Criteria - The elements and conditions (state) necessary to trigger the beginning of a process step. Input - Data or material needed to perform the process step. Input can be modified to become an output. Process Activity - The list of activities that make up the process step. Output - Data or material that are created (artifacts) as part of, produced by, or resulting from performing the process step. Exit Criteria - The elements or conditions (state) necessary to trigger the completion. 2.148.3.1.1.3 (05-29-2020) Objectives The following work products are used to assist in the implementation of the Request Fulfillment Process: Service requests from recording procedure (IT Service Desk function and/or WRMS) Information on open service requests Service Level Agreement Catalog of Services User Entitlements Knowledgebase Operational Level Agreements Underpinning Contracts Standard Operating Procedures (SOPs) and IRMs 2.148.3.1.2 (05-29-2020) Authority All proposed changes to this document should be directed to the IRS Information Technology Customer Service Support Director, owner of this Process Description and be pursued via the IPM process to clearly define interfaces, roles, responsibilities, and coordinate participation and collaboration between stakeholders. 2.148.3.1.3 (05-29-2020) Roles and Responsibilities Many roles are involved in the Request Fulfillment Process. This section defines the roles used throughout this document in terms of their responsibilities. Role Description Definition of Responsibility Service Requestor To submit request and provide required information, and any additional information during the lifecycle of the request. Service Approver To review service request details. To approve or deny the submitted request. This may be done in advance for requests that are determined to be standard and not requiring direct approval. For services requiring a predetermined approver, the approver will be entered automatically or manually. Some products and services require a secondary approval. First Level Support, Enterprise Service Desk Specialist To record, classify, and log service requests based on user interactions. To fulfill requests and/or assign to appropriate Service Support Provider. Provide status updates to users and customers. Review and monitor progress of service requests. Service Support Provider (SSP) Any organization that delivers a standard service or product to a customer or user. Responsible for the provisioning of products or services requested within the Service Level Agreement. Responsible for the delivery of the product or service requested by service requestor. This role is carried out by various organizations in IT and outside of IT based on products or services requested. Responsible for the provisioning of products or services requested within the Service Level Agreement. Responsible for the delivery of the product or service requested by service requestor. This role is carried out by various organizations in IT and outside of IT based on products or services requested. Process Owner Accountable for ensuring that a process is “fit for purpose.” The Process Owner’s responsibilities include sponsorship, design, change management and continual improvement of the process and its metrics. Process Manager Responsible for operational management of a process. The Process Manager's responsibilities include planning and coordination of all activities required to carry out, monitor and report on the process. Process Practitioner Responsible for carrying out one or more process activities. Working with other stakeholders, such as their manager, co-workers, users and customers, to ensure that their contributions are effective. Creating or updating records to show that activities have been carried out correctly. Service Owner Accountable for delivery of specific IT products and services assigned to the group in support and delivery of the service. Responsible for the quality and integrity of request fulfillment. Service Owners are instrumental in the development of service strategy and are responsible for the content of request fulfillment. 2.148.3.1.4 (05-29-2020) Program Management and Review Policies outline a set of plans or courses of action that are intended to influence and determine decisions or actions of a process. Policies provide an element of governance over the process that provides alignment to business vision, mission and goals. Process Management Statement: The Request Fulfillment process will have a single Process Owner and a separate Process Manager responsible for implementation and ensuring adherence to the process. The process will be reviewed regularly to ensure that it continues to support the business requirements of the enterprise. The process will be designed and developed based on ROI to the business. Process metrics will be focused on providing relevant information as opposed to merely presenting raw data. People: Statement: Roles and responsibilities for the process must be clearly defined and appropriately staffed with people having the required skills and training. The mission, goals, scope and importance of the process must be clearly and regularly communicated by upper management to the staff and business customers of IT. All IT staff (direct and indirect users of the process) shall be trained at the appropriate level to enable them to support the process. Rationale: It is imperative that people working in, supporting or interacting with the process in any manner understand what they are supposed to do. Without that understanding [Process Name] will not be successful. Process: Statement: Modifications to the Request Fulfillment process must be approved by the Process Owner. The design of the process must include appropriate interfaces with other processes to facilitate data sharing, escalation and workflow. The process must be capable of providing data to support real-time requirements as well as historical/trending data for overall process improvement initiatives. The process must be fully documented, published and accessible to the various stakeholders of the process. The process will be reviewed on a periodic basis in order to ensure it continues to support organizational goals and objectives (continuous improvement). The process must include Inputs, Outputs, Controls, Metrics, Activities, Tasks, Roles and Responsibilities, Tool and Data requirements along with documented process flows. The process will be kept straight forward, rational, and easy to understand. Rationale: The process must meet operational and business requirements. Technology and Tools: Statement: All tools selected must conform to the enterprise architectural standards and direction. Existing in-house tools and technology will be used wherever possible, new tools will only be entertained if they satisfy a business need that cannot be met by current in-house tools. The selection of supporting tools must be process driven and based on the requirements of the business. Selected tools must provide ease of deployment, customization and use. Automated workflow, notification and escalation will be deployed wherever possible to minimize delays, ensure consistency, reduce manual intervention and ensure appropriate parties are made aware of issues requiring their attention. The tools used by this process are the following: HP Service Manager Rationale: Technology and tools should be used to augment the process capabilities, not become an end themselves. 2.148.3.1.5 (05-29-2020) Program Controls Activities involved in ensuring a process is predictable, stable, and consistently operating at the target level of performance. 2.148.3.1.5.1 (05-29-2020) Controls Process controls represent the policies and guiding principles on how the process will operate. Controls provide direction over the operation of processes and define constraints or boundaries within which the process must operate. Name Description Audits The frequency of configuration audits Policies Policies and criteria for the inclusion of a component and its attributes in the CMS. Security Policies Security policies governing access to the CMS. Scope The scope of the Configuration Management process. Includes identification of what is included in and what is excluded from the Configuration Management process. Change Management Policies Change Management Policies and procedures. Management Reports The frequency and distribution for regularly produced management reports. 2.148.3.1.5.2 (05-29-2020) Metrics Management will regularly review quantifiable data related to different aspects of the Request Fulfillment Process in order to make informed decisions and take appropriate corrective action if necessary Examples of Key measurements are: Service Level Agreements met Operational Level Agreements and Underpinning Contracts fail to meet negotiated time frames for fulfillment of requested service Percent On-time for Standard Requests Requests completed at First Level 2.148.3.1.5.3 (05-29-2020) Tailoring Guidelines This process may not be tailored to meet specific project requirements. 2.148.3.1.6 (05-29-2020) Terms/Definitions/Acronyms Terms/Definitions/Acronyms 2.148.3.1.6.1 (05-29-2020) Terms and Definitions Terms and Definitions Term Definition ACD Front End Message A message to be played back to customers contacting the Customer Service Desk via the toll-free phone number. Artifact A work product created by a process or procedure step, e.g., plans, design specifications, etc. Catalog Entries in the Service Catalog that are associated with a specific product or fulfillment service that needs to be delivered. Entry Criteria The elements and conditions (state) necessary to trigger the beginning of a process step. EOD End Of Day. Escalate The action taken in HP service Manager to change an interaction into an incident. May also refer to: Managerial Escalation when an incident is elevated to management to assist in resolution. This could involve a change in the impact or urgency if the event warrants a more immediate response. Or Technical Escalation when an incident is transferred to a higher service level technician to assist in resolution. This could involve change in the assignment if event warrants a different skill set. Event The occurrence of a specific, detectable action or condition. For example, the opening of a change or task, an approval, or an update. Exit Criteria The elements or conditions (state) necessary to trigger the completion process step. FIFO First In – First Out. IFrame Message A message to be displayed to customers via the Employee Self-Service website. Impact The value measure of the effect on the IRS Business Operations of an Incident, Problem, or Change. Impact and Urgency are used to assign Priority. Incident Incident records are logged from an interaction by the Service Desk. The incident will be associated to the call incident and assigned to a Service Support Provider for incident resolution. Information Alert (Info Alert) E-mail notifications to relay information to internal and external customers. The templates used to distribute this information are General (information only) Scheduled (scheduled outages), Unscheduled Outages (major system outages), CADE2 Elongated Day/Week and End of Day (daily processing). Issue A contact or event. Knowledgebase A published source of approved definitive workarounds and solutions for known errors commonly experienced. Integrates with interaction, incident, and problem management so that users are able to search for and use knowledge articles developed from prior incidents or problems to resolve a new instance of the same type of incident. Known Error A Problem that has a documented Root Cause and a Workaround or solution that is documented. Known Errors are created by Problem Control working on Problems and are managed throughout their Lifecycle by Error Control. Known Errors may also be identified by Development or Suppliers. Priority The sum of the Impact and Urgency assigned to an incident are used to determine Priority. Problem A new event for which no known workaround or solution has been developed and documented in Knowledge Management by an approved source. The cause is not known at the time a Problem Record is created, and the Problem Management Process is responsible for further investigation. Problem Management The process of identifying Problems and converting them to Known Errors by developing solutions or workarounds proactively before they become incidents or after they become incidents. Request One or more tasks (line items) that must be performed to deliver or execute a product or service. Resolution The process taken to resolve (fix) an issue. Also the point at which an event’s effects are resolved for the user by implementing a workaround, solution or providing a service but before the event is closed. Role A set of responsibilities, activities, and authorizations. Status The current stage in the Lifecycle of the associated Configuration Item, Incident, Problem, etc. Tool Job aid for a specific purpose, e.g., Checklist, template, application, etc. Underpinning Contract (UC) A contract between an IT service support provider and a third party. The third party provides goods or services that support delivery of an IT service to a customer. The Underpinning Contract defines targets and responsibilities that are required to meet agreed service level targets in one or more service level agreements. Urgency The value ranking of the Incident, problem or change within the impact category it is assigned. The lower the value number the sooner it must be addressed. Impact and Urgency are used to determine the Priority. Example 2 urgency with a 4 impact is done before 3 urgency with a 4 impact within the same starting period for FIFO. Work Request Management System (WRMS) The Work Request Management System (WRMS) is the authoritative, centralized database and repository for work requests. WRMS maintains, distributes, and tracks work request and its associated documentation, attachments and responses. It is also a management and reporting tool. 2.148.3.1.6.2 (05-29-2020) Acronyms Acronyms and Description Acronyms Description ACIO Associate Chief Information Officer CIO Chief Information Officer CSSC Customer Service Support Center CTO Chief Technology Officer FIFO First In – First Out IPM Integrated Process Management IRM Internal Revenue Manual IT Information Technology ITIL Information Technology Infrastructure Library ITPAL Information Technology Process Asset Library MSLA Master Service Level Agreement OLA Organizational Level Agreement PD Process Description PR Procedure SLA Service Level Agreement SLR Service Level Review SOP Standard Operating Procedures UC Underpinning Contract UNS User and Network Services WR Work Request (formerly known as UWR) 2.148.3.1.7 (05-29-2020) Related Resources The following resources are either referenced in this document or were used to create it: Service Desk Procedures Incident Management Procedures ITIL V3 Legacy IRM 2.14 2.148.3.1.8 (05-29-2020) Training Service Request Processing Training Supplemental training program for support organizations for specific products or services provided 2.148.3.2 (05-29-2020) Process Workflow Service Catalog Management, Incident Management Process, Service Desk Function, Demand Management Process and Change Management Process are all inputs to: Request Fulfillment Step 1 - Submit Request Step 2 Approve Request Asset Management Process and Demand Management Process are inputs and outputs of Step 3 Provision Request Configuration Management is an input and output of Step 4 Close Request END Process Steps Submit Request, Approve Request, Provision Request, Close Request Step 1: Submit Request Purpose The purpose of this process step is to record the details of the request and to link user information in order to log the service request. Roles and Responsibilities The Service Requestor is responsible for providing accurate information related to the service being requested and to only request services they are entitled to request. To assign an approver based on their management chain if required. The First Level Support Enterprise Service Desk Specialist is responsible for recording, classifying and logging service requests based on customer and user interactions. A determination is made on whether the request can be fulfilled at this level, moved to approval process, or assigned to Service Support Provider(s). Entry Criteria Requests are submitted in the following methods: Order from the Product and Services Catalog via the web Contact the Enterprise Service Desk Work Request Request for Change (RFC) Input Request details Process Request Log request Assess request Output Request for products or services Interaction Exit Criteria This process step is complete when the service request is created Step 2: Approve Request Purpose The purpose of this process step is to provide approval if appropriate for the provisioning of the product or service requested. Roles and Responsibilities The Service Approver is responsible for ensuring entitlement and validity of the request. The approver is responsible to approve or deny the request in a timely manner or the request will be rejected Entry Criteria Generally, approval occurs after the following: An interaction has been recorded The interaction is determined to be a request for a product or service The product or service requested is listed in the Catalog of Services offered The product or service request is a valid request that the requestor is entitled to make Input The following are inputs to this process step: Interactions from Recording Procedure identified as service requests Examples of service requests: Password resets Requests for reports or documentation Request for standard and entitled hardware or software items Request for a standard services IT performs Request for access to IT services or systems Requests for network toner Other standard requests as identified in the Catalog of Services Process Activity Approve Request Route Request Output The following are outputs to this process step: An approved service request routed directly to the Service Support Provider A disapproved service request (closed request) Data related to the service request approval or denial Exit Criteria This process step is complete when a service request is approved or denied and moved to the next step: A denied request is closed An approved request is routed to the Provision Request step Step 3: Provision Request Purpose The purpose of this process step is to deliver standard IT products or services based on the Service Level Agreement Roles and Responsibilities The Service Requestor is responsible for providing accurate information related to the product or service being requested and to only requests products and services they are entitled to request. The Service Support Provider is responsible for delivering the product or service requested to the service requestor. They possess unique technical skills, knowledge, mobility or access to an inventory of resources required to fulfill the delivery of the product or service requested. They follow documented procedures related to the products or services requested using the approved instructions in the Knowledgebase. The Service Owner is responsible for specific IT products and services assigned to the group in support and delivery of the service, and is responsible for quality and integrity of the request fulfillment. Entry Criteria Generally, delivery occurs after the following: A service request has been approved The service request is routed to the Service Support Provider that provides the requested product or service Input The input to this process step is an approved IT request for a product or service. Process Activity Receive Request Assign Request Fill Request Output The following are outputs to this process step: A closed service request Data related to the closed service request A valid requested product or service delivered to the requestor Exit Criteria This process step is complete when: A service request fulfillment is confirmed A service request is withdrawn by requestor Step 4: Close Request Purpose The purpose of this process step is the close a completed (fulfilled) request or to close a requestor cancelled request. Roles and Responsibilities The Service Support Provider is responsible for closing the request after fulfillment. They communicate with the Service Requestor and receive concurrence to close the request. They use the tool to close the request The Service Requestor is responsible for timely communicating with the Service Support staff. Upon receiving the requested product or service, Service Requestor provides concurrence to close the request. Entry Criteria Generally, request closure occurs after the following: A service request has been fulfilled Requestor rescinds the request (automated closure by the tool) Process Activity Close Request Output The following are outputs to this process step: Closed requests for IT products and services Cancelled requests for IT products and services Data related to closed requests Data related to cancelled requests Exit Criteria This process step is complete when: Requests for products or services have been closed or cancelled 2.148.3.2.1 (05-29-2020) Main Process Diagram Request Fulfillment Process Flow Diagram Figure 2.148.3-1 Service Catalog Management, Incident Management Process, Service Desk Function, Demand Management Process and Change Management Process are all inputs to:Request Fulfillment Step 1 - Submit RequestStep 2 Approve RequestAsset Management Process and Demand Management Process are inputs and outputs of Step 3 Provision RequestConfiguration Management is an input and output of Step 4 Close Request END Please click here for the text description of the image. 2.148.3.2.2 (05-29-2020) Inputs Generally, the Request Fulfillment procedure occurs after the following events have taken place: Order from the Service Catalog via the web Telephone Call to the Information Technology Service Desk Demand Management - Work Request Change Management - Request for Change (RFC) The following are inputs to this Request Fulfillment procedure: Request detail Interactions from Recording Procedure (IT Service Desk Interaction Classification and Initial Support) Approved requests for products or services Approved Work Requests (WR) Approved Requests for Change (RFC) 2.148.3.2.3 (05-29-2020) Outputs The primary outputs of this Request Fulfillment procedure are: Completed (closed) requests for IT products and services: Cancelled requests for IT products and services Data related to closed requests Data related to cancelled requests The Request Fulfillment procedure exits when request for products or services are: Denied by approver Provisioned (request filled) Cancelled 2.148.3.2.4 (05-29-2020) Activities This Procedure covers activities as follows: ID Name Description SACM 1.0 Submit Request The primary objective of Submit Request is to record the details of the request and to link user information in order to log the service request. SACM 2.0 Approve Request The purpose of this process step is to provide approval if appropriate for the provisioning of the product or service requested. SACM 3.0 Provision Request The purpose of this process step is to deliver standard IT products or services based on the Service Level Agreement SACM 4.0 Close Request The purpose of this process step is the close a completed (fulfilled) request or to close a requestor cancelled request. 2.148.3.2.5 (05-29-2020) Procedure This document defines the step-by-step instructions on how to conduct the activities used to implement the Request Fulfillment procedure in Information Technology. The purpose of a procedure document is to institutionalize and formalize the preferred method of performing tasks that staff is using. The objective is to have everyone using the same tools and techniques and follow the same repeatable steps so that the organization can quantify how well the procedure is working and train future staff members who may not currently know the routine. Ensuring consistency is a critical component for ensuring optimum efficiency. Tailoring of this procedure in order to meet the individual needs of each project is covered in the Tailoring Guidelines section of this document. For the purpose of this document, roles such as Service Approver, First Level Support, and Service Support Provider are provided to describe a set of responsibilities for performing a particular set of related activities. 2.148.3.2.5.1 (05-29-2020) Procedure Flow Diagram Request Fulfillment Overview Diagram Figure 2.148.3-2 START A1 Submit Request Decision: Does Request Require Approval If No go to A If Yes, move to A2.1 Receive Request Service Approver Decision: Approve or Deny Request If denied, move to A2.2 Denied Request and A2.3 Request Closed by ToolIf Request Approved, move to Approved Request RoutingDecision: IT Service Desk or Service Support Provider If IT Service Desk, move to A3.1 Receive Request, A3.2 Validate RequestDecision: Determine Provisioning Path If IT Service Desk, move to A3.3 Fill Request, A3.4 Go to Closing Procedure. If Service Support Provider, Move to A3.5 Determine Service Support Provider, A3.6 Assign to Service Support ProviderService Support Provider Receives Request A3.7, Validates Request A3.8 and Fills Request A3.9 and Moves to Closing Procedure A3.10Emergency Equipment Provisioning Requests are initiated in the Service Desk swim lane A3.1.1 and move to Receive Request A3.1, Validate Request A3.2 and Determine Provisioning Path. If filled by IT Service Desk move to A3.3 and A3.4 If filled by Service Support Provider follow A3.5 Determine Service Support Provider, A3.6 Assign Request, A3.7 Receive Request, A3.8 Validate Request, A3.9 Fill Request and A3.10 Move to Closing ProcedureApproved Work Requests from Demand Management are inputs to Request Fulfillment and follow the provisioning path determined by the type of requestClosing Procedure A4 IT Service Desk and Service Support Providers gain Service Requestor Concurrence A4.1 IT Service Desk and Service Support Providers use the tool and follow SOPs to close Requests END Please click here for the text description of the image. 2.148.3.2.5.2 (05-29-2020) SACM 1 Configuration Management Planning This section delineates the activity steps, including roles and tools or templates, needed to perform each step of this Procedure. ID Task Name and Description Role RACI Duties SACM 1.1 Submit Request - Service Requestor (User) submits request (A1.1). Service Requestor I User submits request to the Information Technology staff. Requests can be submitted via Web, phone, e-mail or self-service. SACM 1.2 Tool determines if request requires approval System C System routing determines if approval is needed SACM 1.3 If approval is required, user inputs approver name into tool. Service Requestor Service Approver I R Tool routes request to Service Approver SACM 1.4 If approval is not required, request is routed to either Enterprise Service Desk or Service Support Provider. Enterprise Service Desk Specialist Service Support Provider C R Routing is based on type of product or service requested. Figure 2.148.3-3 Request Fulfillment Procedure Submit RequestSTART - SACM 1.1 Submit RequestDecision: Is Approval Required: If yes, proceed to SACM 1.2 Approve Request. If no, proceed to SACM 1.3 Provision Request.Demand Management Process: Approved WR Disposition by RADM. Proceed to A3 Provision Request Please click here for the text description of the image. ID Task Name and Description Role RACI Duties SACM 2.1 Approve Request - Service Approver receives notification of request (A2.1) Service Approver R Service Approver is responsible for ensuring entitlement and validity of the request. SACM 2.2 Service Approver reviews request. Based on the request and user entitlements, determines to approve or deny request Service Approver R The approver is responsible to approve or deny the request in a timely manner or the request will be rejected. SACM 2.3 Denied Request (A2.2), Proceed to A2.3 (Request Closed by Tool) Service Approver R Request will be Closed by Tool SACM 2.4 Approved Request Service Approver R Request will be routed to Enterprise Service Desk. SACM 2.5 SLA timeframe of Request (A2.3) Service Approver R The request is not approved within SLA timeframes, the request is closed. Figure 2.148.3-4 Request Fulfillment Procedure Approve RequestSTART Activity A1 Submit RequestA2.1 Receive RequestDecision: Approve Request: If yes, proceed to A3 Provision Request. If no, proceed to A4 Close Request. Please click here for the text description of the image. ID Task Name and Description Role RACI Duties SACM 3.1 Provision Request - Enterprise Service Desk Provisioning (A3.1) Requests are provisioned by Enterprise Service Desk Specialist (A3.1 to A3.6) or by Service Support Providers (A3.7 to A3.10), depending on the specific request. Note: Expedited and Emergency provisioning timeframes are covered by Service Level Agreements and are detailed in the knowledge base. Enterprise Service Desk Specialist R If request is approved, the system assigns request to the Enterprise Service Desk. Enterprise Service Desk Specialist receives request. Requests are routed to ESD or Service Support Provider(s) after approval from Service Approver or directly from Service Requestor for requests that do not require a Service Approver. (A3.1) SACM 3.2 Enterprise Service Desk Specialist validates user entitlement to the requested product or service. Enterprise Service Desk Specialist R Specialist validates availability of requested product or service. If user is not entitled or product/service is not available in the Service Catalog, Specialist refers request to BSP exception procedure described in the knowledgebase. (A3.2) SACM 3.3 Service Desk Specialist reviews request. Enterprise Service Desk Specialist R Based on knowledgebase and SOPs, determines provisioning path. SACM 3.4 Is request filled by Service Desk Specialist? Enterprise Service Desk Specialist R If yes, proceed to (A3.3) Fill Request SACM 3.5 Is request filled by Service Support Provider(s)? Enterprise Service Desk Specialist R If yes, proceed to (A3.5) Determine Service Support Provider SACM 3.6 If request meets criteria for fulfillment by ESD Enterprise Service Desk Specialist R Service Desk Specialist follows knowledgebase and SOPs to fill request. (A3.3) After request has been completed (A3.4), move to Close Request SACM 4.1 (A4) SACM 3.7 If Request is not filled by Enterprise Service Desk, Enterprise Service Desk Specialist R Specialist follows knowledgebase and SOPs and determine the appropriate Service Support Provider. (A3.5) Assign request to appropriate Service Support Provider. (A3.6) SACM 3.8 Provision Request - Service Support Provider Provisioning (A3.7) Requests are provisioned by Enterprise Service Desk Specialist or by Service Support Providers, depending on the specific request. Service Support Provider R Service Support Provider receives request (A3.7). Requests are routed to Service Support Provider(s) after: Approval from Service Approver, or Directly from Service Requestor for requests that do not require a Service Approver, or Assignment from Service Desk in (A3.6) SACM 3.9 Service Support Provider validates user entitlement to the requested product or service. Service Support Provider R Service Support Provider validates availability of requested product or service. If user is not entitled or product/service is not available in the service catalog, Service Support Provider refers request to BSP exception procedure described in the knowledgebase. (A3.8) Review request and ensure product or service is provided by Service Support Provider. If not provided, assign request to appropriate group or Service Support Provider for provisioning. (A3.9) SACM 3.10 Service Support provider follows knowledgebase and SOPs Service Support Provider R Service Support provider follows knowledgebase and SOPs to fill request. (A3.9) Provides Service Requestor with requested product or service (A3.9) SACM 3.11 After request has been completed (A3.10), Service Support Provider R move to Close Request SACM 4.1 (A4) Figure 2.148.3-5 Request Fulfillment Procedure - Provision RequestSTART Input from A1 Submit Request and A2 Approve Request stepsDecision Approved Request Routing: If worked by Enterprise Service Desk, proceed to A3.1 Receive Request, then A3.2 Validate Request, determine provisioning path, A3.3 Fill Request, A3.4 Proceed to Close Request, if provisioned by Service Support Provider, proceed to A3.7If worked by Service Support Provider, proceed to A3.7 Receive request, A3.8 Validate Request, A3.9 Fill Request and A3.10 Close Request Please click here for the text description of the image. ID Task Name and Description Role RACI Duties SACM 4.1 Close Request (A4) After request has been completed, move to Close Request (A4) Process Practitioner R Validate that the product or service has been provided to Service Requestor. Gain user concurrence to close the request. (A4.1) Using the system, follow the knowledgebase and SOPs to close the request. (A4.2) Figure 2.148.3-6 Request Fulfillment Procedure: Close RequestSTART Activity A2, proceed to A4.2 Close Request then ENDActivity A3, proceed to A4.1 Service Requestor Concurrence, A4.2 Close Request, then END Please click here for the text description of the image. More Internal Revenue Manual