SAP SRM Technical Scenarios – Decision Matrix (2010 re-print)

[SergueiZabrodsk]

Author's note March 2024

This is a re-print of my 2010 SDN article on the new SAP Community platform. While the SAP SRM system is on its sunset path, the decision matrix methodology described here can be applied to any complex decision making process that requires comparison of multiple decision criteria across a range of alternatives.

Introduction

The choice of a (primary) technical scenario is a key early decision on any SAP SRM project. This decision impacts many solution aspects, including available functionality, configuration, development, testing, training and support.

Hybrid/combination scenarios are possible, but here we are going to focus on the known differences between scenarios, in view of selecting the main or primary scenario. We will start off by listing general suitability of each scenario.

Generally, the Classic scenario is suitable for organizations that:

• have a large user base in the SAP ERP system; and/or
• have their professional purchasers using SAP MM Purchasing application and want to continue using it; and/or
• have established supplier document collaboration mechanisms in SAP ERP (e.g. EDI) and want to continue using them.

Generally, the Extended Classic scenario is suitable for organizations that:

• want their professional purchasers to work primarily in SAP SRM; and/or
• want to utilize complete sourcing capabilities of SAP SRM; and/or
• want to use out-of-the-box new communication methods with their suppliers (e.g. XML); and/or
• do not have the need to create SAP MM Purchase Requisition or Stock Reservation from the SAP SRM Shopping Cart

Generally, the Standalone scenario is suitable for organizations that:

• do not have a productive SAP MM system; or
• want to free their SAP MM system from all purchasing activities for a certain group of users or commodities; and/or
• do not have the need to create SAP MM Purchase Requisition or Stock Reservation from the SAP SRM Shopping Cart

Decision Matrix

Methodology and Decision Criteria

The selection of a (primary) technical scenario is a complex exercise involving the consideration of business requirements, inherent scenario limitations and best practices. This exercise can be facilitated by using a decision matrix. The decision matrix below lists potentially relevant decision criteria on the left, and provides a sample explanation/analysis of how well each scenario meets each criterion (based on the current knowledge of standard functionality and best practices). In the next step, we will assign a weight factor to each decision criterion, and assign scores for each scenario/criterion combination – to be able to calculate the best option.

Decision Criteria	Criterion #	Classic	Extended Classic	Standalone
Leverages the SAP Materials Management Procurement functionality (e.g. already in place).	1	Fully leverages the SAP MM Procurement functionality, including all Purchase Order processing functions. No need to implement and support these functions separately in SAP SRM.	Partially leverages the SAP MM Procurement functionality, including creation of a PO copy, and ability to process Goods Receipt / Service Entry, Logistics Invoice. Some functions (e.g. PO processing) need to be implemented and supported separately in SAP SRM.	Does not leverage the SAP MM Procurement functionality. All MM-related functions (e.g. PO processing, GR processing) need to be implemented and supported separately in SAP SRM.
Minimizes user training impact (e.g. for an organization with existing SAP MM)	2	Professional purchasers do not have to learn SAP SRM functions (e.g. Purchase Order processing).	Professional purchasers have to learn at least some SAP SRM functions (e.g. Purchase Order processing). It has to be noted that SRM has an intuitive user interface.	Professional purchasers have to learn at least some SAP SRM functions (e.g. Purchase Order processing). Other users (e.g. requesters) have to be trained in SRM Goods Receipt / Service Confirmation.
Professional purchasers work primarily in SAP MM. Note: see the opposite decision criterion below – if one is important, the other is not.	3	Professional purchasers work primarily in SAP MM (e.g. processing POs).	Professional purchasers work primarily in SAP SRM (e.g. processing POs). In SAP MM they have access to a read-only copy of SRM POs, and related Goods Receipts / Service Entries.	Professional purchasers work primarily in SAP SRM (e.g. processing POs). In SAP MM there is no SRM PO or related Goods Receipt / Service Entry that they can reference.
Professional purchasers work primarily in SAP SRM. Note: see the opposite decision criterion above – if one is important, the other is not.	4	Professional purchasers work primarily in SAP MM (e.g. processing POs). In SAP SRM, they may perform some Indirect Procurement functions (e.g. assign sources of supply to incomplete Shopping Carts).	Professional purchasers work primarily in SAP SRM (e.g. processing POs).	Professional purchasers work primarily in SAP SRM (e.g. processing POs).
Support for creating an SAP MM Stock Reservation	5	An SAP MM Stock Reservation can be created from an SAP SRM Shopping Cart.	Not supported.	Not supported.
Support for creating an SAP MM Purchase Requisition	6	An SAP MM Purchase Requisition can be created from an SAP SRM Shopping Cart.	Not supported.	Not supported.
Support for creating an SAP MM Purchase Order for indirect materials from SRM Shopping Cart	7	An SAP MM Purchase Order for indirect materials can be created directly from an SAP SRM Shopping Cart.	An SAP MM Purchase Order (read-only copy) for indirect materials can be created from an SAP SRM Shopping Cart indirectly via an SRM PO.	Not supported.
Support for creating an SAP MM Purchase Order for direct materials (buying on stock) from SRM Shopping Cart	8	Direct material procurement starting from SRM Shopping Cart is supported. Note: even in the Classic scenario, the system creates the leading Direct Purchase Order in SRM and replicates it to SAP MM. Changes to this PO are only possible in SAP SRM. This is a special case.	Direct material procurement starting from SRM Shopping Cart is supported.	Not supported.
Support for creating an SAP MM Purchase Order for services from SRM Shopping Cart	9	An SAP MM Purchase Order for services can be created directly from an SAP SRM Shopping Cart.	An SAP MM Purchase Order (read-only copy) for services can be created from an SAP SRM Shopping Cart indirectly via an SRM PO.	Not supported.
Support for Request External Staff scenario (part of Service Procurement)	10	Not supported.	Request External Staff scenario is partially supported, including partial SRM-SUS supplier collaboration (on Purchase Orders only).	Request External Staff scenario is fully supported, including full SRM-SUS supplier collaboration (on Purchase Orders, Service Confirmations and Invoices).
Support for Service Procurement Classic scenario (part of Service Procurement as of SRM 7.0)	11	Service Procurement Classic scenario is fully supported.	Service Procurement Classic scenario is only supported up to the point of creating an RFx (Bid Invitation) in SRM. The follow-on SRM Purchase Order does not support services with hierarchical structures (note: this functionality is planned by SAP for future SRM releases).	Service Procurement Classic scenario is only supported up to the point of creating an RFx (Bid Invitation) in SRM. The follow-on SRM Purchase Order does not support services with hierarchical structures (note: this functionality is planned by SAP for future SRM releases).
Support for Plan-Driven Procurement (PDP) scenario (integration of external requirements)	12	Indirect material procurement in PDP is supported with some restrictions. Direct material procurement in PDP is not supported. Services procurement in PDP is supported with some restrictions. Refer to SAP Note 505030.	Indirect material procurement in PDP is supported without any restrictions specific to this technical scenario. Direct material procurement in PDP is supported without any restrictions specific to this technical scenario. Services procurement in PDP is supported without any restrictions specific to this technical scenario. Refer to SAP Note 505030.	Indirect material procurement in PDP is supported with some restrictions. Direct material procurement in PDP is not supported. Services procurement in PDP is supported without any restrictions specific to this technical scenario. Refer to SAP Note 505030.
Out-of-the-box flexible approval workflow	13	Some standard approval functionality is available in SAP ERP MM, however it is less flexible in comparison with SAP SRM workflow capabilities.	Out-of-the-box flexible approval workflow exists for SAP SRM Purchase Orders (even further improved with the introduction of “process-controlled workflow” as of SRM 6.0).	Out-of-the-box flexible approval workflow exists for SAP SRM Purchase Orders (even further improved with the introduction of “process-controlled workflow” as of SRM 6.0).
Out-of-the box support for EDI transmission of Purchase Orders	14	EDI is a standard supported transmission method for SAP MM Purchase Orders.	EDI transmission is not readily available for SAP SRM Purchase Orders. Additional conversion functions are needed. In the standard setup of Extended Classic, PO output occurs out of SAP SRM.	EDI transmission is not readily available for SAP SRM Purchase Orders. Additional conversion functions are needed.
Out-of-the box support for XML transmission of Purchase Orders	15	XML transmission is not readily available for SAP MM Purchase Orders. Additional conversion functions are needed.	XML is a standard supported transmission method for SAP SRM Purchase Orders.	XML is a standard supported transmission method for SAP SRM Purchase Orders.
Support for creating an SAP MM Goods Receipt / Service Entry	16	Creation of an SAP MM Goods Receipt / Service Entry is fully supported.	Creation of an SAP MM Goods Receipt / Service Entry is fully supported.	Not supported.
Support for SRM-SUS supplier collaboration	17	Not supported.	SRM-SUS supplier collaboration is partially supported: Purchase Order communication is supported, while Goods Receipt / Service Confirmation and Invoice communication are not supported (SAP Note 543544). Note: a consulting solution is available from SAP to enable full SRM-SUS support in Extended Classic.	SRM-SUS supplier collaboration is fully supported in the Standalone scenario.
Support for MM-SUS supplier collaboration	18	MM-SUS supplier collaboration is fully supported including materials and services (as of SRM 7.0).	Not supported.	Not supported.
Support for Procurement Card as a payment method	19	Not supported.	Procurement Card is fully supported as a payment method in Extended Classic (as of SRM 6.0).	Procurement Card is fully supported as a payment method in Standalone.
Minimizes transactional data redundancy	20	Minimal data redundancy – the document flow is streamlined from SAP SRM to SAP MM without extra copies.	Purchase Orders are mirrored in two systems – SAP SRM and SAP MM, thus creating some redundancy.	Minimal data redundancy – the document flow occurs mostly within SAP SRM.
Promotes technical stability (especially important for environments with heavy transaction volumes)	21	Perceived to be the most stable scenario from the technical perspective for the following reasons: ·      the largest install base among SAP SRM customers ·      more functions rely on the “industry icon” SAP ERP application	·      relatively large install base among SAP SRM customers (but smaller than Classic) ·      less functions rely on the “industry icon” SAP ERP application (compared to Classic)	·      relatively small install base among SAP SRM customers ·      most functions rely on the “new dimension” SAP SRM application, which has rapid development cycles and has been on the market less than SAP ERP ·      fewer interfaces promote stability “within a unit”
Minimizes technical complexity	22	The least complex of all scenarios from the technical implementation and support standpoint due to a number of factors, including heavy reliance on established SAP MM functions.	More complex scenario to implement and support compared to Classic due to a number of factors, including less reliance on established SAP MM functions.	The most complex scenario to implement and support mostly because of an isolated environment that does not leverage SAP MM functions (“build from scratch”).
Minimizes impact on reporting (e.g. SAP BI)	23	project-specific assessment	project-specific assessment	project-specific assessment
Minimizes cost impact	24	project-specific assessment (may include build, support, training efforts, user licenses, etc.)	project-specific assessment (may include build, support, training efforts, user licenses, etc.)	project-specific assessment (may include build, support, training efforts, user licenses, etc.)
In line with the current procurement application roadmap / vision	25	project-specific assessment	project-specific assessment	project-specific assessment

Calculation Example with Scores and Weights

A ‘score’ awarded to each scenario for a given decision criterion is meant to quantify the extent to which the scenario meets the criterion. The scores provided in the example below are based primarily on the existing knowledge of standard functionality and best practices, and are largely firm. However, it is highly advisable to re-evaluate the validity of these sample scores when going through this exercise on each new project.

A ‘weight’ assigned to each decision criterion reflects the importance of the criterion to your particular SRM implementation, and is completely arbitrary. The weights provided in the example below are just for illustrative purposes, and can be flexibly adjusted depending on the perceived value for the implementation at hand.

Both scores and weights can be given an arbitrary range (e.g. 1-10 or 0-100). The following ranges are used in the example below:

• Weight (0-10): 0 – not relevant, 5 – average importance, 10 – most critical.
• Score (0-5): 0 – decision criterion not met, 3 – decision criterion partially met; 5 – decision criterion fully met.

The table below provides a calculation example for the decision matrix presented above. ‘Weighted score’ for a criterion/scenario combination is determined by multiplying the criterion weight by the corresponding scenario score. The resulting weighted scores are then summed up to arrive at the ‘total weighted score’ for each scenario. The scenario with the biggest total weighted score wins :).

Criterion #	Weight [0-10]	Classic: Score [0-5]	Classic: Weighted Score	Extended Classic: Score [0-5]	Extended Classic: Weighted Score	Standalone: Score [0-5]	Standalone: Weighted Score
1	9	5	45	3	27	0	0
2	8	5	40	3	24	2	16
3	6	5	30	1	6	0	0
4	0	1	0	5	0	5	0
5	3	5	15	0	0	0	0
6	3	5	15	0	0	0	0
7	8	5	40	3	24	0	0
8	0	5	0	5	0	0	0
9	8	5	40	3	24	0	0
10	3	0	0	3	9	5	15
11	3	5	15	1	3	1	3
12	2	3	6	5	10	3	6
13	2	2	4	5	10	5	10
14	5	5	25	0	0	0	0
15	3	0	0	5	15	5	15
16	5	5	25	5	25	0	0
17	2	0	0	3	6	5	10
18	6	5	30	0	0	0	0
19	1	0	0	5	5	5	5
20	5	5	25	4	20	5	25
21	9	5	45	4	36	4	36
22	5	5	25	4	20	3	15
23	4	5	20	4	16	5	20
24	9	5	45	4	36	2	18
25	9	5	45	3	27	0	0
Totals			535		343		194

Relevant SAP Notes

Some relevant SAP Notes are listed below:

• 505030 - Restrictions for the integration of external requirements
• 543544 - SUS: Extended Classic Scenario for EBP not supported
• 627542 - Grouping not supported in 'classic scenario'
• 700350 - Supplier Enablement: Technical scenarios integrating SUS
• 752586 - Customer fields in extended classic scenario
• 841141 - Valuated goods receipt in SRM
• 861889 - Limitations on limit and service PO's in case of ECS
• 868192 - Consulting solution: MM-SRV-SUS service procurement
• 1028264 - Consulting solution: Additional function for SRM-SUS

Closing Comments

Please keep in mind:

• The score calculation can be easily done in any spreadsheet application.
• The analysis and examples presented here are for illustration purposes only and have to be validated on a project-by-project basis.
• The decision matrix methodology presented here is not limited to the task of choosing SRM technical scenarios. It can be applied to any complex decision making process that requires comparison of multiple decision criteria across a range of alternatives.