Central Procurement
With Central Procurement, different backend systems (on-premises and cloud) can be connected to a central S/4 Hana hub system and special functions as well as Fiori apps can be used for central processing of purchasing documents. Anyone who manages their master data in different ERP systems knows that harmonizing the data in a central application is an immense challenge. The complex mapping between the many SAP and non-SAP systems as well as an error-prone replication model lead to data inconsistencies and sometimes time-consuming manual post-processing.
Even companies that use SAP SRM are faced with the question of what central procurement will look like after the announced end of support in 2027. SAP provides the answer with S/4 for Central Procurement. With this product, users control and manage strategic and operational procurement processes centrally.
What is new about the system architecture is that Central Procurement is integrated directly into the core of S/4 as a procurement module and is activated via customizing settings. In the multi-backend scenario, an S/4 system is set up as a central hub that establishes a connection between various SAP, non-SAP, cloud or on-premises systems. In this way, purchase requisitions, orders, inquiries and contracts from various backend systems can be processed centrally, and shared service scenarios can also be mapped.
A major optimization compared to SRM is the type of communication between the backend and the central hub system: Here, data is no longer replicated between two systems, but synchronized via staging tables in the Cen-tral Procurement Hub (CPH). Document changes via the CPH Fiori apps usually also directly trigger the change of the respective backend document.
Backend and hub system
Another feature of Central Procurement is that the business logic remains in the back-end system and is also applied directly in central processing. For example, a purchase requisition is created in the back-end system and processed in the Central Procurement Hub, taking into account the relevant ERP logic. In this way, for example, purchase orders from different ERP systems can be processed centrally, which have country- and process-specific conditions and properties.
Central Procurement maps various business functions - so-called scenarios - which are activated individually depending on the business requirements. The scenarios map the processes from central sourcing to central purchasing to central invoicing. In the cen-tral acquisition scenario, for example, requirements from different back-end systems can be determined and managed. The harmonized procurement process thus enables simplified one-stop shopping with preassigned master data for all employees via central requirements management.
The approval of requirements is carried out centrally via flexible workflows. Employees can track the status of their own purchase requisitions at any time and confirm receipt of the goods with just a few clicks. Various upstream systems such as Ariba Guided Buying for catalog purchasing can be connected here via predefined interfaces. The central shopping cart approach familiar from SAP SRM has been consistently developed further in Central Procurement and offers SAP customers numerous options for mapping their individual procurement scenario.
With the app "Manage purchase requisitions centrally" in Central Purchasing, the Central Procurement Hub offers the purchaser a central access point to all requirements of the connected systems as well as their follow-on documents. Thus, the purchase requisitions and purchase orders of the backend systems are processed centrally, the sources of supply for the documents of the backend systems are assigned centrally and the creation of the follow-on documents such as purchase orders, tenders or contracts is triggered directly from the app. It is important to note that the actions in the Central Purchasing app directly trigger the change in the backend. The purchase requisition in the Fiori app is only to be understood as a "proxy purchase requisition" that works without document replication into the hub system.
The central sourcing scenario allows requirements to be bundled from the connected systems and transmitted to the bidders in the form of invitations to tender: Volumes are bundled from different systems in order to negotiate them centrally. The RFQs are created as follow-on documents to purchase requisitions, for example. Central Sourcing also enables internal processing of tenders or direct interaction with suppliers via Ariba Sourcing. Purchase orders, contracts and other follow-on documents are triggered directly from the app. Compared to Central Purchasing, Central Sourcing documents are only created in Central Procurement Hub. The "Internal Sourcing Request" (RQ) is where quotes are entered; the "External Sourcing Request" (RE) is the interface to Ariba or other external platforms.
The centrally negotiated purchase contracts are then distributed to the backend systems via central contracts and volumes are broken down. The process is as follows: When central contracts are created, distribution details are defined at header and item level as required. Central Contracts then distributes the approved central contracts to the back-end systems. They now trigger the creation of local purchase contracts. With the so-called "contract hierarchies", SAP introduces another level for grouping company codes, where each group represents a subsidiary, location, branch, etc.
This group configuration then uses the Fiori app "Manage Central Procurement Contracts" to create central procurement contract hierarchies. The call-off orders created in the back-end systems are imported into the Central Procurement Hub so that contract exhaustion can be monitored cen-trally. Other features of the Central Contracts module include: Mass Change Function, Central Conditions or Commodity Pricing. In this way, the bundling potential of cen-tral negotiated contracts can be efficiently implemented in the company.
To gain an overview of local invoicing processes, globally operating companies need a uniform structure in financial accounting. With Central Invoice Monitoring, invoice processes are centrally monitored and managed. The main functions include: central management of all backend supplier invoices, drill-down and editing of backend documents, and interfaces for integration of the Ariba Supplier Network, which is used, for example, for automatic invoice creation and verification. With these modules, Central Procurement covers the entire purchase-to-pay process in a multi-backend scenario.
Fiori, monitoring and analysis
In addition to the Fiori apps for mapping processes within individual scenarios, Central Procurement includes various Fiori apps for monitoring and analysis functions. For a better overview, the key figures can be displayed graphically as bar, pie or line charts and can be configured individually. Central Procurement thus offers various options for central analysis, provides a real-time overview, and highlights optimization potential.
Numerous SAP and non-SAP systems can be integrated into the complex system landscape of central procurement. Monitoring tools such as Central Procurement Operations Monitor are available for the central monitoring of these interfaces: Here, all business scenarios, compatibility and communication statuses of the integrated systems can be monitored and analyzed in one application. The app displays the overview maps for the scenarios: central demand determination, central contract management and central purchasing. From each map, navigation to the detailed application is possible to view the problems and their causes.
Each of the above scenarios allows integration of other innovative applications, such as SAP Ariba, which make the purchasing process user-friendly and intuitive. For example, Ariba Guided Buying allows users to semantically search purchasing catalogs, displaying all relevant and up-to-date content and finding the product they need faster. Other applications such as Ariba Sourcing, Ariba Contracts and others can be connected to the corresponding apps of the Central Procurement scenario.
So if you want to use a central procurement tool from SAP, there will be no way around Cen-tral Procurement from 2027 at the latest. The time of activation - as part of the S/4 transformation or already before the S/4 conversion in a separate project - is a decision that requires a high level of specialist and technical knowledge and is best made with a partner. On the one hand, with the first variant all new functions are available immediately after the -go-live, on the other hand, such a conversion is also an additional construction site in an already demanding transformation process to S/4.
If the decision is made to continue using SRM for the time being and to replace it with Central Procurement at a later date, the S/4 transformation project will be relieved, but at the same time new interfaces will be required to connect SRM to S/4. Company-specific process and organizational characteristics should also be taken into account in the decision-making process. Here, therefore, it is necessary to examine the advantages and challenges of both options in order to make the right strategic decision.
