By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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:
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.
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 firstname.lastname@example.org if there you require further clarifications.
Dig Deeper on SAP supplier relationship management software
Related Q&A from Sachin S. Sethi
An SAP SRM user is looking to update an SRM URL process when implementing or changing a catalog in a live environment in SAP SRM.continue reading
An SAP SRM user wants to know how to set Confirmation and Invoice as the default options in a limit-order shopping cart.continue reading
An SAP user wants to know the benefits of implementing SAP SRM, and if it's necessary to also implement SAP BI, XI and MDM at the same time.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.