Internal Revenue Manual
IRM 2.148.3 — Request Management Process
Part 2. Information Technology
Chapter 148. IT Support Services Management Section 3. Request Management Process 2.148.3 Request Management Process Manual Transmittal February 05, 2024 Purpose (1) This transmits revised IRM 2.148.3, IT Support Services Management, Request Management Process. Material Changes (1) Revised document with the following changes: Changed IRM section title from Request Fulfillment to Request Management Changed all references to Request Fulfillment to Request Management Changed all references to Enterprise Service Desk to IT Service Desk Updated new Chief Information Officer IRM 2.148.3.1.8 Removed Training Section IRM 2.148.3.2.5.2 Changed SACM 1 Configuration Management Planning to Request Management IRM 2.148.3.1 Program Goals - verbiage change IRM 2.148.3.1.1 Background - verbiage change IRM 2.148.3.1.1.1 Process Description - verbiage change IRM 2.148.3.1.1.2 Goal - verbiage change IRM 2.148.3.1.1.3 Objectives - verbiage change IRM 2.148.3.1.2 Authority - Changed Process owner from Customer Service Support Division to Service Improvement IRM 2.148.3.1.3 Roles and Responsibilities - verbiage changes to Service Requestor, Service Approver, First Level Support, Service Support Provide, and Service Owner IRM 2.148.3.1.4 Technology and Tools - Statement - changed HP Service Manager to IRWorks IRM 2.148.3.1.5.1 Controls - removed table IRM 2.148.3.1.5.2 Metrics - changed verbiage IRM 2.148.3.1.6.1 Terms and Definitions - updated table to reflect current terms and definitions IRM 2.148.3.1.6.2 Acronyms - updated acronyms table IRM 2.148.3.1.8 Training - removed section, no longer required in template IRM 2.148.3.2 Process Workflow - updated verbiage IRM 2.148.3.2.2 Inputs - updated verbiage IRM 2.148.3.2.3 Outputs - updated Verbiage IRM 2.148.3.2.4 Updated Activity ID from SACM to correct step name IRM 2.148.3.2.5.2 SACM 1 Configuration Management Planning - Changed to Request Management and updated all Procedure steps to align with Request Management Effect on Other Documents IRM 2.148.3 dated May 29, 2020 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 (02-05-2024) Kaschit Pandya Acting, Chief Information Officer
Program Scope and Objectives
2.148.3.1 (02-05-2024) Program Scope and Objectives Overview - This IRM describes the formal process for managing the Enterprise Information Technology (IT) Request Management 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 Management. Program Owner - UNS is the program owner for Request Management. 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 - To provide an operational definition of major components and how to perform each step in the process. It also describes logical steps essential to successfully completing the process and achieving its desirable outcome.
Background
2.148.3.1.1 (02-05-2024) Background Request Management Process description describes what happens within the process and provides an operational definition of major components and activities performed to achieve a given purpose. Tailoring of this process to meet the individual needs of each project covered in the Tailoring Guidelines section. This document describes the formal process for implementing the requirements of the Request Management Process. For this document, roles such as Service Requestor, First Level Support, Service Owner, Service Support Provider, etc. 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 Master Service Level Agreement (MSLA) for the product or service and requester's entitlement.
Process Description
2.148.3.1.1.1 (02-05-2024) Process Description Request Management is the process responsible for tracking and recording requests throughout the request lifecycle. This document describes the major steps within Request Management Process, which include. Step 1 - Submit Request Step 2 - Approve Request Step 3 - Provision Request Step 4 - Close Request
Goal
2.148.3.1.1.2 (02-05-2024) Goal Specific Process Goals: Properly logged Requests Properly approved Requests Properly routed Requests Resolution meets the requirements of the Master Service Level Agreement (MSLA) for the Customer
Objectives
2.148.3.1.1.3 (02-05-2024) Objectives This document describes a set of interrelated activities, which transform inputs into outputs, to achieve a given purpose and states guidelines all projects should follow regarding the Request Management Process. The document also includes process goal and objectives, metric, role definitions, policies, and other process related attributes. The format and definitions used to describe each of the process steps of the Request Management Process described below: Purpose - The objective of the process step Roles and Responsibilities - The responsibilities of the individuals 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 modified to become an output Process Activity - The list of activities that make up the process step Output - Data or material 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
Authority
2.148.3.1.2 (02-05-2024) Authority All proposed changes to this document should be directed to User and Network Services (UNS), Service Planning and Improvement (SPI) Service Improvement (SI).
Roles and Responsibilities
2.148.3.1.3 (02-05-2024) Roles and Responsibilities Many roles are involved in the Request Management Process. This section defines the roles used throughout this document in terms of their responsibilities. Role Description Definition of Responsibility Service Requestor Responsible for submitting request, assigning an approver if required, providing required information, and any additional information during the request lifecycle. Service Approver Responsible for reviewing service request details to approve or deny the submitted request in a timely manner. May happen in advance for requests that are determined to be standard and not requiring direct approval. For services requiring a predetermined approver, the approver is entered automatically or manually. Some products and services require multiple approvals. First Level Support IT Service Desk Specialist Responsible for recording, classifying, logging service requests based on user interactions and fulfilling requests and/or assigning to appropriate Service Support Provider. Provide status updates to users and customers. Service Support Provider (SSP) Any organization who delivers a standard service or product to a customer or user. Responsible for provisioning of products or services. Responsible for product delivery or service requested by service requestor. This role carried out by various organizations in IT and outside of IT based on products or services requested. Process Owner Accountable for ensuring 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 stake- holders, such as their manager, co-workers, users, and customers, to ensure contributions are effective; creating or updating records to show activities 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 Management. Service Owners are instrumental in development of service strategy and are responsible for Request Management IRM content.
Program Management and Review
2.148.3.1.4 (02-05-2024) Program Management and Review Policies outline a set of plans or courses of action 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. Name Description Process Management Statement: The Request Management process will have a single Process Owner and a separate Process Manager responsible for implementation and ensuring adherence to the process. The process is reviewed regularly to ensure it continues to support the business requirements of the enterprise. The process was designed and developed based on Return on Investment (ROI) to the business. Process metrics will focus on providing relevant information as opposed to merely presenting raw data. People Statement: Roles and responsibilities for the process clearly defined and appropriately staffed with people having the required skills and training. The mission, goals, scope, and importance of the process 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 at the appropriate level to enable them to support the process. Rationale: It is imperative people working in, supporting, or interacting with the process in any manner understand what they are supposed to do. Without that understanding Request Management Process will not be successful. Process Statement: Modifications to the Request Management process 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 supporting real-time requirements as well as historical/trending data for overall process improvement initiatives. The process fully documented, published and accessible to the various stakeholders of the process. The process reviewed on a periodic basis 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 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 used wherever possible, new tools only entertained if they satisfy a business need that current in-house tools cannot meet. 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 deployed wherever possible to minimize delays, ensure consistency, reduce manual intervention, and ensure appropriate parties made aware of issues requiring their attention. Tools used by this process are the following: IRWorks Rationale: Technology and tools used to augment the process capabilities, not become an end themselves.
Program Controls
2.148.3.1.5 (02-05-2024) Program Controls Activities involved in ensuring a process is predictable, stable, and consistently operating at the target level of performance.
Controls
2.148.3.1.5.1 (02-05-2024) 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.
Metrics
2.148.3.1.5.2 (02-05-2024) Metrics Management will regularly review quantifiable data related to different aspects of the Request Management Process to make informed decisions and take appropriate corrective action if necessary. Metrics used for the quantitative and periodic assessment of a process. They should be associated with targets that are set based on specific business objectives. Metrics provide information related to the goals and objectives of a process used to take corrective action when desired results not achieved and can drive continual improvement of process effectiveness and efficiency. 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
Tailoring Guidelines
2.148.3.1.5.3 (02-05-2024) Tailoring Guidelines This process is not tailored to meet specific project requirements.
Terms/Definitions/Acronyms
2.148.3.1.6 (02-05-2024) Terms/Definitions/Acronyms Terms/Definitions/Acronyms
Terms and Definitions
2.148.3.1.6.1 (02-05-2024) Terms and Definitions Terms and Definitions Term Definition Artifact A work product created by a process or procedure step, e.g., plans, design specifications, etc. Entry Criteria The elements and conditions (state) necessary to trigger the beginning of a process step. Exit Criteria The elements or conditions (state) necessary to trigger the completion process step. Incident Incident records logged by the Service Desk. The incident will be associated to the call incident and assigned to a Service Support Provider for incident resolution. Knowledgebase A published source of approved definitive work- around and solutions for known errors commonly experienced. Integrates with incident, and problem management so that users search for and use knowledge articles developed from prior incidents or problems to resolve a new instance of the same type of incident or request. Request Documented record of the request for product or service. Role A set of responsibilities, activities, and authorizations. Service Catalog Approved products and services available for provisioning. State The current stage in the Lifecycle of the request. 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 required to meet agreed service level targets in one or more service level agreements. 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.
Acronyms
2.148.3.1.6.2 (02-05-2024) Acronyms Acronyms and Description Acronyms Description ACIO Associate Chief Information Officer CIO Chief Information Officer CSS Customer Service Support CTO Chief Technology Officer IRM Internal Revenue Manual IT Information Technology MSLA Master Service Level Agreement OLA Organizational Level Agreement SOP Standard Operating Procedure UC Underpinning Contract UNS User and Network Services WR Work Request (formerly known as UWR)
Related Resources
2.148.3.1.7 (02-05-2024) Related Resources The following resources are either referenced in this document or used to create it: Service Desk Procedures Incident Management Procedures Legacy IRM 2.14 IRM 2.148.3
Process Workflow
2.148.3.2 (02-05-2024) Process Workflow Service Catalog Management, Incident Management Process, Service Desk Function, Demand Management Process and Change Management Process are all inputs to Request Management. 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 requested, to only request services entitled to request, and to assign an approver based on their management chain if required. The First Level Support IT 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 should be fulfilled at this level, moved to approval process, or assigned to Service Support Provider(s). Entry Criteria Requests submitted in the following methods: Order from the Product and Services Catalog via the web Contact the IT Service Desk Work Request Request for Change (RFC) Input Request details. Process Request Log request. Assess request. Output Request for products or services. 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 request will be canceled. Entry Criteria Generally, approval occurs after the following: Requests are submitted for a product or service The product or service requested is listed in the Catalog of Services 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: Inputs are information collected and documented during the Submit Request step Process Activity Approve / Deny Request. Output The following are outputs to this process step: An approved request routed directly to the Service Support Provider A disapproved request (closed request) Data related to the request approval or denial Exit Criteria This process step is complete when a request 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 Master Service Level Agreement. Roles and Responsibilities The Service Support Provider is responsible for delivering the product or service requested. The Service Owner is responsible for specific IT products and services assigned to the group in support and delivery of the service. They are responsible for ensuring the product or service is fit for purpose and fit for use. Entry Criteria Generally, delivery occurs after a request is approved and routed to the Service Support Provider responsible for the 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 request Data related to closed request A valid requested product or service delivered to requestor Exit Criteria This process step is complete when request fulfillment is confirmed or withdrawn/cancelled by requestor. Step 4: Close Request Purpose The purpose of this process step is a completed (fulfilled) request or cancelled request. Roles and Responsibilities The Service Support Provider is responsible for closing the request after fulfillment by communicating with the Service Requestor and obtaining concurrence to close the request. Service Requestor is responsible for providing concurrence to close the request. Entry Criteria Generally, request closure occurs after a request is fulfilled or the Requestor rescinds (cancels) the request. Process Activity Fully documented closed 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 The fulfilled or closed Request is fully documented.
Main Process Diagram
2.148.3.2.1 (02-05-2024) Main Process Diagram Request Management 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.
Inputs
2.148.3.2.2 (02-05-2024) Inputs Generally, the Request Management 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 Management procedure: Request detail Approved requests for products or services Approved Work Requests (WR) Approved Requests for Change (RFC)
Outputs
2.148.3.2.3 (02-05-2024) Outputs The primary outputs of this Request Management 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 Management procedure exits when request for products or services are: Denied by approver Provisioned (request filled) Cancelled
Activities
2.148.3.2.4 (02-05-2024) Activities This Procedure covers activities as follows: ID Name Description Step 1 Submit Request The primary objective of Submit Request is to record the details of the request and to link user information to log the service request. Step 2 Approve Request The purpose of this process step is to provide approval if appropriate for the provisioning of the product or service requested. Step 3 Provision Request The purpose of this process step is to deliver standard IT products or services based on the Master Service Level Agreement. Step 4 Close Request The purpose of this process step is the close a completed (fulfilled) request or to close a requestor cancelled request.
Procedure
2.148.3.2.5 (02-05-2024) Procedure Defines the step-by-step instructions to implement Request Management in Information Technology. The purpose of a procedure document is to institutionalize and formalize the preferred method of performing tasks. 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 to meet the individual needs of each project is covered in the Tailoring Guidelines section of this document. Roles such as Service Approver, First Level Support, and Service Support Provider describe a set of responsibilities for performing a particular set of related activities.
Procedure Flow Diagram
2.148.3.2.5.1 (02-05-2024) Procedure Flow Diagram Request Management 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.
Request Management
2.148.3.2.5.2 (02-05-2024) Request Management 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 Step 1 Submit Request - Service Requestor (User) submits request (A1.1) Service Requestor I User submits request to the Information Technology staff. Requests submitted via Web, phone, e-mail, or self-service Tool determines if request requires approval System C System routing determines if approval needed If approval required, proceed to A2 Approve Request Service Requestor Service Approver I R Tool routes request to Service Approver If approval not required, proceed to A3 Provision Request IT 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 Step 2 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 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 (11 Business Days) or the request rejected Denied Request (A2.2), Proceed to A4 (Request Closed by Tool) Service Approver R Request will be Closed by Tool Approved Request Proceed to A3 Provision Request Service Approver R Request will route to IT Service Desk 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 Step 3 Provision Request - IT Service Desk Provisioning (A3.1) Requests provisioned by IT Service Desk Specialist (A3.1 to A3.6) or by Service Support Providers (A3.7 to A3.10), depending on the specific request IT Service Desk Specialist R If request approved, the system assigns request to the IT Service Desk. IT Service Desk Specialist receives request. Requests route 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) (A3.2) IT Service Desk Specialist validates user entitlement to the requested product or service IT Service Desk Specialist R Specialist validates availability of requested product or service. If user 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) IT Service Desk Specialist reviews request IT Service Desk Specialist R Based on knowledgebase and SOPs, determines provisioning path Is request filled by IT Service Desk Specialist? IT Service Desk Specialist R If yes, proceed to (A3.3) Fill Request (3.3) IT Service Desk Specialist Fulfills the Request IT Service Desk Specialist R Service Desk Specialist follows knowledgebase and SOPs to fill request (A3.3) After request completed (A3.4), move to Close Request 4.1 (A4) (3.5) Is request filled by Service Support Provider(s)? IT Service Desk Specialist R If yes, proceed to (A3.6) Determine Service Support Provider and Assign Request (3.6) IT Service Desk Specialist follows Knowledge and Assigns to Service Provider IT Service Desk Specialist R Specialist follows knowledgebase and SOPs and determine the appropriate Service Support Provider (A3.7) Request - Service Support Provider Provisioning Requests provisioned by IT 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 route 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) (3.8) 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 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 provided by Service Support Provider. If not provided, assign request to appropriate group or Service Support Provider for provisioning (A3.9) (3.9) 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) (A3.10) After request completed Proceed to A4 Service Support Provider R Move to Close Request (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 Step 4 Close Request (A4) After request completed, move to Close Request (A4) Process Practitioner R Validate that the product or service 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.
Source: official text