Best-of-breed (BOB) applications, unlike what the name suggests, do not really solve all business issues faced by customers. Fine, given the fact that organizations went ahead with investing in the same as some solutions available from SAP were really not solving some of the core business issues. Today, some of the same BOBs are getting themselves certified on the SAP NetWeaver platform. Despite a solution existing from SAP on the same space, BOBs are certifying themselves to be powered by SAP NetWeaver. A contradiction maybe. This certainly warrants a discussion within Org.A when it evaluates its core e-procurement engine today being addressed by a BOB solution vis-à-vis its move towards SRM. Before we get down to the brass-tacks of talking about a solution, let us try to see where Org.A has an issue with BOB today. After all, xApps are business solutions, not run-of-the mill technical solutions.
Best of breed applications tried to address the above space by streamlining spend across the board for MRO items. These BOB applications were loosely integrated with the core ERP applications. On one end of the spectrum Org.A has BOB applications that provide point solutions but are expensive to maintain and involve high costs of implementation and licensing. On the other, they have their plans with mySAP SRM. The middle-path that Org. A is looking at is a space for applications that keep the bells and whistles out of the application, yet, help align an organization to the SAP NetWeaver and ESA roadmap, without having to invest in either suite fully by still allowing customers to enable the reduced spend through an application without the bells and whistles from both worlds. Enter xPRO in the Architects World.
Consider the following issues that Org.A has with BOB in the e-procurement space with BOB. So whoever said that BOB would be the panacea? (refer CCCP III):
Business Issue #1:
While faxing purchase orders to suppliers by EDX, fax or any other method, how does ORGA transmit the terms and conditions, which run into pages, to the existing suppliers? Should ORGA invest in additional third-party fax software? EDI purchase orders will have the same problems.
Business Issue #2:
Application limitations force ORGA to be rigid about purchase order changes. It does not handle change/cancel purchase orders and push them to the backend SAP R/3 4.6C as needed, and version the same purchase order with changes; visibility of future versions not been made available to ORGA; huge technical investment may be needed to meet this now.
Business Issue #3:
Items available as catalog items being requisitioned as ad hoc requisitions at a higher cost. The idea is to save costs by streamlining indirect purchasing, not automating inefficient and redundant processes. The practice of having catalog items being requisitioned as ad hoc requisitions should be stopped, and the application vendor proposes a contract management application on top of the eProcurement application, which will require an upgrade to make it compatible. And the same will be made available at a future point in time and will mean additional cost.
Business Issue #4:
Fixed assets/capital asset MRO purchases linked to projects, no way any standard application can handle this. Custom BAPIs are being called through integration events that run at regular intervals. Add to this frequent changes to the capital purchase projects with respect to Work Breakdown Structure (WBS) elements in the underlying mySAP ERP application, and this may lead to discrepancies regarding MRO purchases tagged to capital projects. A time-based data pull will not help. A requisitioned will have to wait for 12/24 hours for the correct data to show up.
Business Issue #5:
Catalog searches take a very long time to execute, making the requisitioning process an arduous one.
Business Issue #6:
Since ORGA is not implementing the P-Card process now, they have a few P-Card suppliers and their reconciliation is to be handled manually on a month-to-month basis outside the system. But since we are running in an integrated environment that pushes all POs to the underlying mySAP ERP application, this doubles our work to have another manual process for the POs coming from suppliers like Boise Cascade or Grainger. And these are non-punchout catalog items (which forms the majority of the spending).
Business Issue #7:
There is absolutely no way to monitor spending across various cost centers and put a cap to streamline processes around allocation usage to help curb spending. If ORGA is to monitor costs based on cost centers and have a cap on their budgets, ORGA cannot do that with the existing application functionality. Reports are rudimentary and manual.
Business Issue #8:
Allow the vendors to select and process their invoices over the extranet on their own. After acknowledgement by Accounts Payable staff, allow SAP and non-SAP users to access their own invoices and approve them. There needs to a filter based on user type. Send notification to vendors about clarifications and payment confirmations. Allow AP users to retrieve the invoices from one screen; the current application does not support it.
Business Issue #9:
ORGA imports commodities from ORGB, ORGC, and other business partners from different geographical boundaries, to be re-sold in the US market. Can ORGA have a streamlined process custom built around it? Right now, all work is manual.
Business Issue #10:
Catalog management becoming too huge to be monitored and maintained with delays in new price lists from suppliers like Boise, Mutual Engraving, etc. Decision makers became too myopic with application capabilities, enhancements, and third-party applications.
Business Issue #11:
In any approval hierarchy for a requisition, one has approvers and watchers. An approver can be a watcher in some cases, and vice versa. Opening each and every purchase requisition in my inbox, after logging in, does not tell you whether you are an approver or a watcher. The application didnt support this. And valuable time of key approvers was spent on clicking and understanding their role in the PR process. This is an application limitation.
Business Issue #12:
ORGA has a six accounting segment structure, some combinations may be valid and existing, some may be valid and non-existent, while others may be invalid. If there is no accounting segment validation happening in the eProcurement application, many purchase orders will not be reflected in the underlying SAP R/3 application. These purchase orders, though sent to the suppliers as fax or EDI, cannot be pushed into the underlying SAP R/3 leading to a situation where you have invoices coming in, but no purchase orders to settle against in SAP R/3.
Business Issue #13:
During a product requisitioning cycle, a requisitioner can receive goods, or central receiving can do the same. This leads to effort duplication one receives, the other approves. With services (which form 57% of all requisitions in ORGA), it is the other way round. Business needs dictated central receiving to receive all goods in the dockyard, and the requisitioner to receive all services. There was no need for a receipt approval.
Business Issue #14:
Consumption orders intra-company orders on MRO items, how can ORGA automate this process flow?
Business Issue #15:
ORGA purchases chemical items as well under this category, and there is no automated process within the existing application to capture and validate their toxicity numbers from the Dangerous Goods Regulations (DGR) list. The toxicity number is required for declaration purposes. How do we ensure that all chemical items that are requisitioned have a toxicity number?
The middle path Bring it on – xPRO:
So, is BOB really worth it? Do Punch-Outs/Round-trips really make sense? Do P-Card spend really justify the investment in BOB? Does SOX compliance, which can be introduced in a more cost-effective way with a custom solution, be really driven through BOB? Consider xPRO as a web-based e-Procurement tool that is designed to facilitate, integrate and streamline the entire procurement process from consumer to supplier and back. To be built as an xAPP using the SAP NetWeaver platform, xPRO should be designed to be a scalable e-procurement solution that will help companies replace best-of-breed applications aligned with Org.As ESA roadmap. xPR) should provide Org.A with an alternative to do away with expensive best-of-breed applications and leveraging mySAP SRM components to lower TCO with the SAP NetWeaver platform, aligned with Org.As ESA roadmap.
The business proposition is to provide a solution for buying products and services to reduce costs of goods and services and increase user productivity using guided procedures or best practices, support a user-friendly and powerful approval workflow engine, enforce established procurement processes and standards while enabling a simple, quick and straightforward process for creating requisitions and processing orders. On one hand, you have customers who would be on the BOB applications, in the SAP landscape wanting to do away with BOM and related middleware. They have no choice but to go the SAP way, they would try to delay their SRM adoption for 3-4 years. An xPRO solution would expedite the move towards SRM or at least do away with BOB. On the other, you have customers who are on BOB, need that push towards an interim solution before they go the whole hog with SRM. xPRO fits in here. Another perspective you have customers who want to do away with BOB but not to go with SRM/EBP because of the cost or too many bells and whistles. xPRO could benefit Org.A by being the crossroad solution. Ill discuss this in CAF context in my next blog.