Integrating SAP MM and P2P: When ERP and E-Procurement Must Do a Two-Step ‘Buy’ Together

integration alphaspirit/Adobe Stock

The devil is always in the SAP details — especially when it comes to making ERP and third-party e-procurement and e-invoicing systems work together in a harmonized “two-step” purchasing process.

Spend Matters recently spoke with a large procurement organization whose IT group is supporting 50 locations globally with an SAP implementation, as well as a third-party purchase-to-pay (P2P) solution and supplier network deployed on top of it, leveraging the underlying MM components for core automation.

The lessons we learned from the discussion speak to the importance — and beauty — of thinking through all of the details when it comes to thinking through ERP and procurement systems integration, especially when multiple systems will be handling different aspects of transactional procurement.

Background

The organization in question is what we might describe as a “semi-centralized” procurement organization with the corporate procurement function working out of a U.S.-based headquarters. Yet individual sites buy items specific for their own locations, while the centralized function drives the purchase of large spend items that cut across multiple sites.

The procurement organization leverages a single SAP version, which serves global operations. After evaluating SAP for transactional procurement, it decided to leverage a hybrid deployment model using a SAP MM (all requisitions are handled in SAP even if they do not originate there) and a best of breed procurement front-end. Technically speaking, the manufacturer is using SAP MM as their ordering tool (inclusive of workflow, business rules, PO processing, receiving, matching, invoicing, payment and master data management), but the third-party application as the front end for purchasing and business users to search and shop (including the requisitioning, invoice capture and catalog management capabilities the vendor provides).

Non-Trivial Integration

The integration of the two systems would prove non-trivial from a business process perspective (although one could argue the technology was the easy piece). The company told Spend Matters that while automation itself is never an easy task, the key is that “all systems have to be prepared (to receive and process all the information), as well as the organization.”

There are always common challenges when a company does this type of integration. In the case of this manufacturer, here are some challenges and discoveries that the integration of SAP with standalone e-procurement and the associated business process changes brought with it:

  • The organization (along with the support of its e-procurement partner) had to make data customizations to integrate the SAP “store room” model with the new third-party shopping/requisitioning process. This required making sure all the information captured mapped to the specific SAP processes and fields required for approval, document creation, workflow, business rules and matching
  • Switching from a p-card (the previous payment model) to a PO-based model integrated with SAP approval and payment runs generated extra workload for the organization (which it did not plan for), including the invoice management process “post PO,” which created additional workload
  • Creating an automated approach to managing taxes and freight required a full redesign of the inbound invoicing (and invoice receipt) process
  • Supplier onboarding requirements expanded to move beyond basic accounts payable (A/P)-centric data fields for collection, management and maintenance to enabling a broader catalog management process (uploading of catalogs, validations, etc.)
  • Suppliers would sometimes submit information incorrectly (e.g., submitting wrong tax information in specific fields), which would slow invoice processing times and require procurement and A/P touch points
  • Requisitioning and ordering automation surfaced broader process and compliances challenges, which the company previously missed when using SAP alone — and required internal process redesign efforts to fix

However, with challenges come benefits, too. Benefits that could vary from case to case, but at the end should simplify the user's work and improve the company's productivity. Here are some of the benefits discovered in this case scenario:

  • Improved user experience while purchasing made possible by incorporating a best-of-breed procurement front-end
  • Improved process automation, which brought efficiencies and effectiveness to the procurement processes
  • Improved P2P business processes towards better practices, such as:
    • Requisitioning and ordering compliance with the organization's policies and procedures
    • Order management and analytics with a PO-based model
    • Two- and three-way match process (plus effectiveness)
    • E-invoicing data management
    • Supplier management with a more integrated approach.

While the procurement team was ultimately happy with its choice to combine SAP’s own purchasing technology native in the ERP modules with a best-of-breed procurement front-end (buyer and supplier interface), the manufacturer realized that there was no way to virtually paper over existing system requirements or business processes that were either established, required or missing entirely.

This case scenario represents an important lesson regarding challenges and benefits that any procurement organization could face in a P2P path that plans to leverage existing ERP elements as part of a new deployment.

Voices (2)

  1. Lorenzo Martinelli:

    Excellent article !!!
    Really useful to share these kinds of customer use case stories.
    THANK YOU!!!

  2. Bill Kohnen:

    Very helpfull article. While you did not say so I presume they did not choose Ariba which arguably should integrate well with SAP MM and Payables.

    Also raises increasing importance of vendor master record information which I have to admit as an “experienced” Purchasing person I never used to care about – I just wanted to get the PO placed and of it was a new vendor AP would sort it out.

    The one thing that I am surprised about is that the implimentation created more work on the Backend with invoices. Unless they really were just using PCards for everything with no matching or reconciliation.

    Not sure if you can say but in your view was the
    ” extra work” what would be considered normal for others. Secondly was the extra work ongoing or once suppliers and the system were trained did it go down?

    Again really great info and applicable to any solution.

Discuss this:

Your email address will not be published. Required fields are marked *