Intro:
Taking out best of breed applications from an existing system landscape is easy, if you have to only talk about it. It is a different ballgame when you are part of a team that has to actually do it. But, nonetheless, this is an activity that will have to be done if the roadmap towards ESA is to be achieved. In this blog, let us take a sample application and see if it can be done. Let us take the example of a sample best of breed e-procurement application and see what all approaches exist in trying to take it out of Org. A’s landscape if this thought is to be made a reality. Org. A has been running a best of breed e-procurement application since year 2000 and the thought process is to see what makes sense to reduce TCO to align with the ESA roadmap. The PIPA model may sound corny, though it is being propagated by the SAP ESA folks. One of my client touch points told me that it was a Pathetic Interpretation of their Procurement Application, but you have to let the acronyms grow. So, let us discuss the "taking out" of this e-procurement application. And it does make sense.
The Business Considerations for Org. A’s procurement Division:
Creating a business case for taking out the e-procurement solution to cut down on the license costs is important. For this, assume that, you, as the ESA/Solution Architect have the responsibility to see what could be the best fit for snuffing out such a solution. The business and application drivers that you would need to evaluate could be as follows:
Q: Purchase requisitions: How many catalogs are hosted internally by Org. A? How many Punch-out/Round-trip suppliers exist ? How many ad-hoc requisitions are created by the requisitioners in Org. A? (Weekly/monthly/quarterly)? How many e-forms/Business forms exist in the Organization today? How many BAPI/RFC calls are made through customizations?
A: Purchase requisitions: If the number of Internally hosted catalogs are high with the Punch-Out suppliers being able to be done away with, if the number of ad-hoc requisitions is high within the organizations and if the e-forms/business forms ordering is not such a critical activity (which it may not be), the BOB application can be done away with. The Spend through the nature of purchase is critical here. In Org. A, the spend through internally hosted catalogs is higher and the MRO spend streamlining never really happened – as predicted before.
Q. Spend: How much of the spend is converted through catalogs? (Value & Volume of the requisitions), How many are the converted Ad-hoc requisitions (Value/Volume/Commodity Code/Supplier) that are changed by the buyer at the end of the approval chain?
A. Spend: As seen in Org. A, if the number of requisitions being created internally are ad-hoc, despite suppliers and contracts existing for procurement with pre-negotiated prices with selected suppliers exist, there is something wrong with process adherence within the procurement organization. This creates a business/technical case for snuffing this application out.
Q. Usage of the Supplier Network: How many CC:DO orders and Direct Orders are raised internally within Org. A? Is the use of the Supplier Network for routing Purchase Orders via EDI/Fax/e-mail traditionally dependant on the network?
A. Usage of the Supplier Network: With the Purchasing Department-Suppliers aligned primarily towards receiving orders by fax, Org. A can actually leverage the use of its internal fax server to route the purchase orders without the need for the supplier network. The Supplier network never really worked out as the global catalog for Org.A. The use of the Commerce Services network was found to be too high. More often than not, buyers were taking printouts of the purchase orders from the underlying R/3 systems and having them faxed out manually! This provides the case of doing away with the dependence on the Supplier network.
Q: Nature of PRs and usage: The use of “on-behalf-of” requisitions is fairly low within Org. A. The number of partitions and variants within Org.A were well planned in the very beginning – Underlying R/3 was always the core in Org.A (this will be more or less the same-situation-case in all organizations). The more pertinent question becomes – how many services vis-à-vis goods are procured through this best of breed application? How many suppliers drive the same?
A: Nature of PRs and usage: Some process workarounds may address the need for addressing cases where the “on-behalf-of” applications are created. Mostly, it is a 50%-50% stated case for goods and product procurement within this application. Interestingly, the number of streamlined suppliers is very less and no specific complicated rules exist for receiving the same. This makes the case for the replacement much easier.(e.g. Boise, Graybar, Grainger etc.)
Q: Approval rules: Most important is to figure out the nature of approval rules, or the complications around the same, that need to be figured out. Org. A has anyways customized the approval engine of the best-of-breed application to an extent that it now provides a gui-based tool for approval rule creation on the fly. Needless to say, this is one of the key considerations in this exercise. Rules exist around commodity codes, roles, dollar-values and suppliers.
A: Approval rules: This customized area leaves the room open for a Lotus-Notes Integration, or the integration of an existing 3rd party approval rule engine, or a custom java approval engine or ABAP workflow usage could be a solution.
Q: Fixed Assets related purchasing: One important area of customization to be figured out in the existing scenario is the way PRs raised that need to be associated to WBS elements in the PS module of R/3 that need to be created time and again and validated for attaching to Fixed Assets purchase/Maintenance of the same would need to be figured out. Then again, it may not be a rocket-science solution attached to the same with custom integration events that in turn call BAPIs in R/3 to create and validate the same for users to attach PRs to the specific WBS elements. Another similar black-box would be the validation of accounting segments that would need to be validated/created the similar way.
A: Fixed Assets related purchasing: Key point to note here is the BPM-like concept that exists over here that does an accounting combination validation – if the combination is valid and exists – no problem, if it is valid and doesn’t exist – call a BAPI to create it in R/3 and let the PR pass through. Else throw the user out. Important here is to figure out the custom best or breed solution custom objects – invariably, you would see that it all boils down to BAPIs!
Many other points: Several other factors that would come to the mind would need to be figured out. Eg. How are other validations done? How do they attach capital Purchases to WBS elements in SAP PS? Are there any BAPI calls for the same? How soon does the integration event run – what frequency? Any UI changes that exist? Like for toxic items, DGRs etc. how are they handled? Any receiving rules? How does receiving work – for services and goods? Tolerance? Any catalog filters in place? What is the change/cancel PO process internally? Any integration with 3rd party tools? Transmission of Purchase Orders through e-fax? Roadmap with this Best of breed application – a move to mySAP SRM? Would a hosted solution make sense? What is the P-Card usage within Org. A? How is the process for invoice settlement and PO matching taken care of within the application today? If there are planned upgrade for the application, what are the benefits being sought? Are there any existing PO Layout changes? How frequently do catalog changes take place? How does Org. A stop ad-hoc requisitions being created? How is user management handled today? How are issues like password reset handled? What are the nature of issues that have been logged at the help-desk? What is the volume – what are the severity levels for the same? How is Invoice settlement by Suppliers taken care of , or it is taken care of by the application at all?
There are many other considerations, yes, but these would be the most important ones in this case.
Solution considerations :
So, despite the fact that Org. A uses the best-of-breed solution for MRO procurement, there will always be a host of requirements that will need to be addresses from a systemic standpoint. Therefore, the some discussion points within ORGA become:
Are such point solutions really worth it? Cannot SAP NetWeaver be used to do away with such point solutions and let us build our own xAPPs using the CAF framework? Or would an approach with SAP solutions be worth it? Or, if the touted benefits through such solutions more hyped up for Org. A, would a customized approach leveraging ESA be more appropriate?
Of course, there will be a lot of gaps in the xAPPs that one may want to build based on ORGA’s requirements. They will require a huge amount of custom development by a third party vendor. But over a period of five years, does a Spend Management Solution built as a xAPPs make more sense if other products from the application suite of a best- of- breed solution provider are not on the radar?
Punch-Outs/Round-trips and Catalog maintenance will be the immediate issues. But how can the use of Contracts be leveraged within SAP R/3 to consolidate processes by the Org. A Procurement Division? What is the best way forward? Best-of-breed application or xAPPs or SRM?
With a Commerce Solution services now being made available to all SAP and Oracle customers, does SRM start making sense? Or can the investment be postponed?
Once ORGA created a business case based on the above business issues, the need for a POC to do away with such an application and creating a POC with Enterprise Portal integrated with Lotus Workflow seems logical. Though this would mean loss of functionality such as Punch-Out or the usage of the Commerce services NetWork and do away with any specific Spend management capabilities that SRM or any other solution may offer, it is worth the cost and maintenance of some frequently ordered items in SAP R/3.
Options Available:
=> Move ahead the SRM route: Replace the best of breed application with a re-implementation approach with mySAPSRM.
=> Create a Web Application leveraging R/3: An Integrated EP frontended solution with Webdynpros on SAP R/3 with custom workflow/Lotus Notes Integration using R/3 contracts and text items for procurement.
=> An option for an xAPP with CAF: Create an application with similar look and feel as the best of breed appication with CAF using guided procedures. Example - Ariba Buyer gives you the perfect xAPP with guided procedures.
=> An MDM Solution: An Online store with MDM 5.5 SP02 and customization to select and order products and services through EP integrated with a custom workflow application. MDM is to be treated as an e-catalog forn inhouse maintenance of catalogs.
Outro:
It is not impossible to do away with best of breed applications. But it also doesn't mean that the solutions have to be designed with ESA today. The solutions can also be conceptualized for use today that may be designed for ESA compliance tomorrow. For every such application that resides in a landscape, there are ways and means to snuff them out. There would always be a bunch of skeptics within, who would try to nix such initiatives, maybe because their very existence depends on the same - professionally. But for an ESA/Solution Architect determined to lead an organization down the ESA road, it is an era of endless possibilities. And for organizations willing to walk the extra mile, a drastic lowering of costs by doing away with expensive best-of-breed applications. Of course, it is not an easy task - but is very much possible. With the SAP NetWeaver Platform, with a planned ESA roadmap - Listen to your ESA/Solution Architect.
Removing best of breed and legacy applications might not be impossible, as long as there is no dearth of ideas and inclination.
