Intro:
ORGA had invested in a best of breed pure-play e-procurement application. With the imminent direction to go towards mySAP Supplier Relationship Management (my SAP SRM) for MRO (maintenance, repair, and operating inventory) items, the spend through the application did not deliver the promised benefits - not because the application could not handle it, but because the application failed to inculcate user descipline and entailed high licensing costs. Another reason why the move towards SRM/EBP is on hold within Org.A. This initiative is being kept on hold owing to tactical reduction in the spend being directed through this BOB application to slowly give way to its replacement. Punch-out/round-trip supplier spent was minimal through these and the use of an existing network; though a critical need, can be done without. This was so as the maintenance of internal catalogs still proved to be more cost effective and Org.A friendly and reduced the dependednce on the product vendor. Though this BOB vendor now opened up its supplier network for transmission of POs generated through SAP applications, it still did not make too much sense as Org.A's key suppliers like Corporate express, Greybar and Boise Cascade have a very close working relationship with Org.A. As the spending on catalog suppliers is low and the usage of a commerce services network is not so huge (the actual spend value and volume), ORGA is toying with creating an xApp customized to Org.A's business need to streamline costs and reduce ad-hoc spending. This also meant doing away with the existing middleware application which the BOB application coupled with. Having evaluated the options of retaining or replacing the BOB application, Org.A is taking a cautious approach with SAP SRM/EBP as well. None of these applications covered the resuirements to a T. That forms the business case for such an initiative POC. I call this idea Kill BOB(sorry, Bob!).
That leads us to architecting an ESA roadmap with the SAP NetWeaver platform to resolve a business issue for Org.A. In this multi-part blog series of “The Architect’s World”, I will cover multiple processes, tackle each one of these processes from a NetWeaver standpoint and from an ESA initiative standpoint - with the following six goals:
1. How to leverage the SAP NetWeaver platform to enhance business processes
2. How to utilize the same to do away with best of breed applications
3. How to retain key home-grown applications, yet align with the ESA roadmap
4. How to consolidate business processes and applications to enhance productivity
5. Approaches to make the best use to carve an ESA roadmap for the years to come for an organization
6. Mainly, to explore new ideas
Idea #2:
Process #1: The procure-to-pay process:
Platform Approach #2: The Custom build approach to replace best of breed:
The busines drivers for a "Rip-and-replace" approach towards CAF:
Just by having a BOB application does not underline the fact that all custom business requirements are met within an Organization. Org.A is no exception. Despite having used this application for the past five years, the promised land is yet elusive. Some of the key issues being faced by them currently with the BOB application are as follows (Refer Creating a Comprehensive Collaborative Platform with SAP NetWeaver - 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 thirdparty 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
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 Workaround: ORGA needs to have the catalog manager play a more important role in negotiating with punch-out ready suppliers, thereby completely eliminating the need for catalog maintenance and ruling out any spending on development or procurement of third-party applications. But the feasibility of this is being debated as the moot point becomes: Would the increased use of punch-out/round-trip enabled customers make ORGA overly dependant on the application vendor?
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 didn’t 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 ten 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?These issues are a sample of what Org.A was trying to address and evaluating the key vendors to see if this can be plugged. With the logical forward move towards Analytics and BI reporting, coupled with a forward thrust towards streamlined sourcing (and heaven forbid! - a digital marketplace!), the solution being designed needs to be scalable enough to accomodate these ideas as a plan over the years to come. This gives a logical definition to Org.A's ESA initiatives with the SAP NetWeaver platform.
Potential ESA Candidates:
Candidate one could be - while creating a catalog requisition, if the suppliers are many and are hosted inetrnally, could an enterprise service do a comparison of the prices internally and check the product availability real-time for the requisite quantity in bulk from the suppliers? Can it be scaled in the future to place a RFQ and initiate a bidding process based on key criteria through an sourcing engine if the items are not available?
Another candidate for using an enterprise service could be - the invoice matching and posting process for P-Cards that are in use at Org.A. For all P-Card entries ciming in from Amex, if there could be an enterprsie service that matches these invoices from Amex and the POs within Org.A in the future.
Outro:
Org. A is now contemplating building its own solution as this space would give it the necessary time and breating space for going live. Despite the fact that ORGA uses the best-of-breed solution for MRO procurement, there will always be a host of requirements that will need to be addressed from a systemic standpoint for which Org.A would not like to bank on an external vendor. This becomes an ideal hunting ground for the corporate IT folks within Org.A, who are open enough to explore such ideas. The build solution would cost Org.A close to 1/4th of what it cost to buy the BOB application. This exludes the implementation, upgrade and maintenance costs. The platform now opens up the possibilities. But it doesn't mean that you thrown in ESA everywhere - just because the platform enables us to.
