SAP SRM

SRM covers supplier-facing procurement beyond basic purchasing: self-service requisitioning, strategic sourcing and bidding, contract management and supplier collaboration. It aimed to streamline and control indirect and strategic procurement across the organisation.

One clarification on scope, because the boundary with materials management confuses people. MM handles the operational purchase order, receipt and invoice. SRM sat in front of that, covering how the need was raised and how the supplier was chosen, and it created documents that MM then executed. That division is the same wherever the front end lives today.

• Self-Service Procurement: employee requisitioning.
• Strategic Sourcing: RFx, bidding, auctions.
• Contract Management.
• Supplier collaboration.

Being straight about this saves somebody a wasted specialisation. Classic SRM is a legacy product. New implementations go to Ariba for sourcing and supplier collaboration, or to the procurement capability inside S/4HANA itself, which absorbed a good deal of what SRM used to add.

That does not make it irrelevant. A number of organisations still run it, those systems need support, and migrating away from SRM is itself a stream of work. But somebody choosing what to learn should know they are learning a maintenance skill rather than a growth one.

What genuinely transfers is the process knowledge. Self-service requisitioning, catalogue management, sourcing events, contract management and supplier onboarding are the same problems in Ariba, in S/4HANA and in any competitor's product. The screens change and the questions do not.

So the useful way to read this page: learn what these capabilities are for, and expect to apply that understanding somewhere other than SRM.

Self-service procurement lets an employee raise their own requisition from a catalogue, rather than emailing a buyer. The gain is buyer time and compliance; the dependency is catalogue coverage, because an empty catalogue sends people back to free text.

Catalogue management holds what can be bought and at what price, either as content loaded in or as a punchout to the supplier's own site. Keeping it current is the ongoing job that decides whether any of it works.

Sourcing and bidding runs the competitive exercise before a contract exists: an event, supplier responses, comparison, award.

Contract management holds the resulting agreement with its terms, value and expiry, and purchases are released against it rather than negotiated again.

Supplier self-service gives the supplier a place to confirm orders, send shipping notifications and submit invoices, which removes a class of exception from invoice verification.

Each of these exists because the alternative is a person doing it in email, and each depends on somebody maintaining data for it to be worth having.

SRM integrated with MM (purchase orders, goods receipts) and FI. In modern landscapes, its role is filled by SAP Ariba (cloud sourcing, procurement and the Ariba Network) and by S/4HANA’s own sourcing and procurement, integrated together, so learning gravitates toward Ariba and S/4HANA procurement.

The integration shape is worth knowing because it is the same wherever this function lives. Master data flows outward: suppliers, materials, cost centres, account assignments. Documents flow both ways: requisitions or orders out, confirmations and invoices back. And the perennial design question is which system owns the order, because a document existing in one and not the other is the most common support issue in any procurement front end. See SAP CO for where the resulting spend is analysed.

Learn SRM through its core processes, its master data and configuration, and its integration with the rest of the SAP landscape. Hands-on practice cements it.

Since much of the SRM work now is moving off it, the shape of that project is worth knowing.

Decide the destination per capability. Self-service requisitioning and catalogues usually go to a cloud buying product or to the requisitioning capability in S/4HANA. Sourcing and contracts go to Ariba. Supplier collaboration goes to the business network. It is rarely one target for everything.

Master data first. Suppliers, materials and catalogue content have to exist in the destination, cleansed, before anything transactional moves. This is the same finding as every other migration and it is still the item that slips.

Open documents. Requisitions and orders in flight have to be either completed in the old system or migrated, and completing them is nearly always cheaper than migrating them.

Approval logic is rebuilt, not moved. Workflow in SRM does not translate, and the migration is a chance to simplify chains that grew by accretion.

Suppliers have to be brought across, which is a campaign rather than a data load if the destination is a network they must join.

The honest sequencing advice: run both for a period rather than attempting a single cutover, because procurement stopping is more disruptive than most functions stopping.

• Extended classic, classic or standalone. The deployment scenario decides where the purchase order actually lives, which decides where everything is reconciled. Knowing which one a system uses is the first question on any SRM engagement.
• How long to keep it. Maintenance horizons make this a scheduled decision rather than an open one.
• What to migrate and what to retire. Some capabilities have a clear successor and some were never used, and a migration is the chance to find out which.
• Whether to move at all yet. A stable system with no pending change is not urgent, and the deadline is what makes it a plan rather than a preference.

The single most useful thing to establish about any SRM system is which deployment scenario it runs, because it decides where documents live and therefore where every reconciliation happens.

Classic. The shopping cart is created in SRM and the resulting purchase order is created in the ERP backend. Procurement documents live in MM, which is where buyers and finance already work, and SRM is the front end only.

Extended classic. The purchase order is created in SRM and a copy is replicated to the backend. SRM holds the leading document, which gives it more capability and creates two versions of the same order that must stay in step.

Standalone. Everything lives in SRM, including goods receipt and invoice, and only the accounting reaches the backend. Used where the backend is not SAP at all.

The consequence is practical: a question like "where do I find this purchase order" or "why do these two systems disagree" has a different answer in each scenario, and diagnosing without knowing which one you are in wastes the first hour.

• Learning features, not the end-to-end process.
• Ignoring integration with finance and neighbouring areas.
• Skipping master data/configuration the process depends on.

• Specialising in SRM as a growth area. It is a support and migration skill, and the process knowledge is what transfers.
• Catalogues loaded once. Coverage decays, and people go back to buying around the system.
• No agreement on which system owns the document. See BPC and BW for where procurement data ends up being reported.

• Not knowing which deployment scenario a system uses. It decides where the purchase order lives, and every reconciliation question depends on the answer.

Knowing the capabilities is the transferable half, and configuring a procurement process end to end in whichever product a client actually runs is the part you do in the course.

The transferable part of this page is the process knowledge rather than the product. Self-service buying, catalogues, sourcing, contracts and supplier collaboration are the same problems wherever they are implemented.