Objectives
When processing requests within a procurement organization at scale, managing approvals, routing, and tracking can quickly present challenges.
The Procurement Operations Desk (POD) serves as a hub where Center of Excellence (CoE) teams can consolidate requests on a single dashboard, simplifying approval activities.
To enable the POD, submit a Service Request to Support.
Once the POD feature is enabled, there are several configurations required before using the feature, including:
To use the POD, users must first be added to one or more user groups depending on their role. Each user group offers permissions specific to functionality within the POD in line with the role’s responsibilities.
The following table outlines the various POD user groups, and associated responsibilities.
| User Group | Responsibilities |
|---|---|
| Buyer Procurement Desk Administrator | Responsible for configuring and maintaining system settings tasks for the procurement operations desk. |
| Buyer Procurement Desk Director | Similar to the Manager role with added authority for assigning and reassigning requisitions and managing approval activities. Directors typically are senior management who oversees larger segments of the procurement process. |
| Buyer Procurement Desk Manager | Oversees team members' assigned requisitions, assigns unassigned requisitions, and manages approval activities. Managers ensure efficient workflow and distribution of requisitions. |
| Buyer Procurement Desk Agent | Tasked with managing the approval activities for assigned requisitions and reassigning as necessary. Ideal for staff directly involved in the procurement approval process, focusing on the day-to-day operations. |
To access the POD, login to SAP Ariba Procurement, and select the Procurement Operations Desk from the dashboard tabs at the top of the page.
Note
If the Procurement Operations Desk tab is not visible, check the More tab, or contact your system administrator to ensure you are assigned to the appropriate POD user groups.
For requisitions to reach the POD, the requisition approval process must first be modified.
When the Buyer Procurement Desk Agent is active on a requisition approval flow, the requisition is routed to the POD for further processing.
Configurations in the POD are handled via the System Settings menu. To access this menu, navigate to the Procurement Operations Desk, then select the System Settings tab.
Note
You must be a member of the Buyer Procurement Desk Administrator user group to access the System Settings.Team Management within the POD allows for the strategic grouping of users into teams based on specific operational areas, such as commodity types or geographical locations.
This feature facilitates targeted assignment of requisitions, improving processing efficiency. Setting up teams involves defining team roles, assigning members, and configuring team-specific queues to streamline requisition flow.
To set up a team, navigate to the POD System Settings, then select View team management.
In the Team management menu, a sample file can be downloaded, offering examples of how to set up teams. This file can be used as a template to create an import file. Alternatively, the Export teams button can be used to export the current teams file, which can also be used to add, edit, or remove teams or team members.
The team import file must consist of two sheets:
| Sheet | Field | Description |
|---|---|---|
| TeamHeade | Contains header level data for each team | |
| TeamName | A unique identifier for the team | |
| ManagerId | Username of the team’s manager | |
| PasswordAdapter | Password adapter of the manager | |
| TeamUsers | The list of team members | |
| TeamName | Unique name of the team (must be the same as in the TeamHeader sheet) | |
| UserId | Username of the team member | |
| PasswordAdapter | Password adapter of the team member |
Note
If you are deleting the details of a team member, ensure that there are no incomplete tasks assigned to that user. If the user belongs to multiple teams and you are deleting the details of the user for only one team, ensure that there are no incomplete tasks assigned to that user for that team.Workspaces in the POD are designed to organize specific tasks, projects, or categories of procurement by consolidating relevant information, tools, and workflows into a single, accessible area.
Requisitions are mapped to a workspace to enable team members to navigate and manage tasks more effectively.
To configure workspaces, navigate to the POD System Settings. Scroll down to Workspace settings and select View settings.
In the POD System Settings, a sample Workspaces file can be downloaded, offering examples of how to set up Workspaces. This file can be used as a template to create an import file. Alternatively, the Export button within the Workspace settings can be used to export the current Workspaces file, which can be used to add, edit, or remove Workspaces.
Note
Each source document can only be mapped to one workspace.
Queues are configurable pathways in the POD that automatically direct requisitions to appropriate approver teams based on predefined criteria, such as commodity type or purchasing unit.
To set up a queue, navigate to the POD System Settings, then select Manage Queues.
The Queue Management menu provides functionality to perform the following:
The Queue settings contain several parts:
Priority: numeric values that determine which queue must be assigned with a task if two or more queues have the same attributes. The queue with the lowest numeric value is the highest priority.
Assign type options:
| Dropdown Option | Description |
|---|---|
| Assign to member | Specify a primary owner for the requisitions. Optionally, you can specify a secondary owner who can take over the requisitions in the absence of the primary owner. If both primary and secondary users are on vacation, all incoming requisitions are assigned to the queue manager. |
| Balance workload | Specify a set of users as members of the queue to ensure that requisitions are allotted evenly to balance the workload among them. This method also considers a user's workload from documents allotted from other queues in which the user is a member. After you specify the users, the details of the users are displayed in the Add members list. In this set up, users who have turned on their vacation settings are not considered for the assignment of requisitions. If all the members are on vacation, all incoming requisitions are assigned to the queue manager irrespective of the vacation settings of the queue manager. |
| Round robin | Assign requisitions on a rotational basis where each user is assigned a requisition once in an assignment cycle. For example, if there are three users in a queue, requisitions are allotted as follows: Requisition 1 goes to the first user. Requisition 2 goes to the second user. Requisition 3 goes to the third user. Requisition 4 goes to the fourth user and so on. |
| Assign to owner | Assigns the requisitions to the queue manager. |
| Assign to team | Assigns the requisitions to the team. The queue manager has to assign the requisitions manually because the requisitions are not assigned to any team member automatically; the requisitions are available on the Unassigned tab. |
Requisition statuses are user-defined markers that offer insights into the stages of requisition approval within the POD. These statuses help in tracking the progress of requisitions more granularly.
To view the current requisition statuses, navigate to the POD System Settings. Under the Requisition status section, select See statuses.
In the POD System Settings, a requisition status sample file can be downloaded. This file can be used as a template to create an import file. Note that there is no export option. To modify or delete existing requisition statuses, simply upload a new file to override the existing settings.
Rejection reasons are predefined explanations provided by approvers when denying a requisition. These reasons help requisition preparers understand why their request was denied and what modifications are needed for approval upon resubmission.
In the POD System Settings, a requisition denial reason sample file can be downloaded. This file can be used as a template to create an import file. Note that there is no export option. To modify or delete existing requisition denial reasons, simply upload a new file to override the existing settings.
To view the current requisition denial reasons, navigate to the POD System Settings. Under the Requisition denial reason section, select View settings.
Service Level Agreements (SLAs) in the POD define the expected timeframes for processing requisitions, establishing benchmarks for timely approvals. SLAs help maintain efficiency and ensure that requisitions move through the system within the agreed-upon timelines. Configuring SLAs involves setting maximum response times for each stage of the requisition process, providing clear expectations for both approvers and requesters.
The SLA settings contain several parts:
Log in to track your progress & complete quizzes