Scenario decision criteria
I'm new to EBP and we're considering SRM/EBP for global eProcurement along with a global SAP R/3 project. What are the decision criteria for selecting a scenario? How does scenario decisions affect the communication to the supply chain?

    Requires Free Membership to View

    When you register, you will start receiving targeted emails from my award-winning team of editorial writers. Our goal is to keep you informed on the hottest topics and biggest challenges faced by SAP professionals today.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSAP.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSAP.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

I'll presume that when you're referring to "selecting a scenario" you're specifically referring to the implementation scenarios for SRM/EBP. My responses are based on this presumption.

The following scenarios are supported for EBP/SRM:
Classic Scenario:
The majority of SAP SRM implementations today in the US are implemented as a Classic Scenario. Here is a very tight integration with the SAP R/3 system. The Leading Purchase Order document is created in the R/3 system. A number of organizations have chosen this implementation scenario as it provides the advantage of having the least impact on your existing backend processing. You can utilize the functionality in EBP to allow users to shop in an online mode with use of eCatalogs and once the shopping is completed you can leave your existing backend processing as it is, ie. PO Transmission, GR, Invoice processing can all stay the same as it was. Plus, for enterprise reporting purposes, all documents can reside in R/3 as before.

Extended Classic Scenario:
Although there are not a lot of organizations utilizing this implementation scenario, nevertheless it is very useful. SAP did not support this scenario until EBP release 3.0 and therefore you don't see a lot of organizations using this. Here the leading Purchase Order Document is created and saved in the Enterprise Buyer System itself. And a copy of the original document is sent into the backend SAP R/3 system. This could be useful for your org, if you wanted to complete all purchasing activities with the EBP system itself but still wanted to send the eventual PO document to SAP R/3. Here the transmission of the PO and other documents received from the vendor are conducted from EBP system. So that could mean some additional work as you'd have to re-do any EDI/XML transmissions you might be doing from R/3 in EBP.

Standalone Scenario:
This scenaio has been used primarily by organizations that do not have an SAP R/3 core system, or that are not directly interfacing to it. A few organizations selected this also because their SAP R/3 system was being upgraded at the time of their implementation and they did not want to interrupt that process. Once the R/3 system was upgraded, they're looking at interfacing it with re-deploying their implementation in a Classic or Extended Classic mode. The P-Card functionality has been another driving factor for companies to select this scenairo, as Standalone is the only scenario that supports the P-Card functionality till release 3.5. Also some organizations have some business units that have a SAP R/3 system while others do not. For such scenarios, a Standalone works well for the business units that dont have a core SAP R/3 backend.

Please note that based on the EBP/SRM release the scenario implemented affects the additional SRM components that you'd want implemented.

I hope this helped and hopefully this is what you were looking for. You can reach me at sachin.sethi@sealconsult.com if there you require further clarifications.

This was first published in October 2003

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.