The continued growth in the adoption of procurement-to-pay (P2P) or source-to-settle (S2S) suites in the last few years is testament to the significant value they deliver to procurement teams in businesses of all sizes.
Exercising control of the procurement process enables businesses to achieve continuous cost savings, purchasing compliance and a level of automation of repeat processes in accounts payable.
Perhaps inevitably, organisations that have invested heavily in P2P solutions would like them to do more to help some of the underlying issues that procurement teams (and the business buyers they support) face.
And this is where the problems begin.
One of the most common scenarios is to have the P2P system become the master for supplier data and the single portal for all suppliers to the business.
Mature organisations, often those that have been on the long, painful and ultimately fruitless journey of trying to implement supplier management in their P2P suite, have realised that in businesses with any sort of complexity – certainly any with more than, say, $1B in revenue – P2P suites should focus on what they’re great at, and supplier management should be treated as a separate (though tightly integrated) discipline.
Here are two reasons and three consequences that we’ve seen time and time again.
Firstly, suites aren’t designed for the huge variety in the supplier base. Sure, suppliers have in common that they sell you products or services and you pay them, but that’s about where the commonality ends.
Large multinationals have indirect suppliers (usually managed through P2P), direct suppliers (often managed through ERP and supply chain applications), suppliers that are global strategic partners, and others that are occasional low-value purchases – not to mention local, state and national government departments.
They have complex relationships with suppliers where any given company might be supplying multiple separate business units in the buying organisation, selling different products, at different prices, with different service levels, payment terms and compliance and risk requirements, and so on.
Some of the information relating to that supplier will be common – company name, HQ address, etc – but some of it will be specific to the buying unit. This has significant implications for who can add or modify what data relating to the supplier.
Any ProcureTech leader that has encountered these issues in the real-world will shudder at the thought of trying to shoe-horn this complexity into a P2P system that’s designed to manage purchase transactions.
Secondly, integration with the company’s ERP is essential if you’re to enjoy the benefits of automated supplier on-boarding and management, but it’s deeply problematic for the P2P suite.
For supplier data used in transactions, the P2P is subservient to the ERP vendor master – as you might expect given that the ERP controls the payment to the supplier. But as soon as you have a second ERP instance, even if it’s from the same vendor (and it so often isn’t), your P2P will have a second vendor master – resulting in duplicated supplier data, resulting in inaccurate or incomplete analytics, as well as inefficiencies for the business user and procurement team.
Using a separate, specialist supplier management platform, which is designed to integrate with both ERP and P2P systems, resolves these conflicts and allows you to be the owner of the master record for each supplier, therefore solving this problem.
Why does this matter?
Well, the business likely embarked on a supplier management program in order to automate (as much as is possible) the supplier on-boarding process, for 100% of its suppliers, in order to remove the needless inefficiencies of the manual process your business customers, buyers and suppliers go through.
It’s also often the case that the business wanted greater control of risk in the supplier base – whether that’s financial, fraud, compliance or supply risk – hence the need for 100% supplier inclusion.
And it’s also often to provide deep insights into spend, risk, efficiency and supplier performance in order to make critical business decisions.
Attempting to achieve one or more of these goals with a P2P suite often results in:
Significant project delays, sometimes endless. The P2P suite vendors, no different from many enterprise software categories, are quick to promise what’s possible, usually in good faith, but are more reluctant to acknowledge when a given use case that they hadn’t dealt with before can’t be supported.
And here’s the thing, if you’re trying to include 100% of suppliers – and you have to – then there will always be use cases that the vendor hasn’t thought of, which means the system must be designed to extend the data model and workflow to accommodate every possible variation, and P2P suites just aren’t built for this task.
With delay comes cost. Rather than cutting losses, customers tend to try and work with the vendor and / or their (expensive) implementation partner to figure out workarounds. This inevitably means the project hours wrack-up, systems due to be replaced must be extended, and anticipated cost savings or other financial benefits get delayed.
And thirdly, with compromise almost always comes an acceptance that parts of the process will have to continue as manual steps. Validation rules for a subset of suppliers will have to be handled offline, performance management assessment will happen in Excel using an export, which will have to be de-duped first, so on and so forth.
The importance of the P2P suite in a modern buying organisation inside a large, complex business, is undeniable, but experience in recent years has shown that a system designed to manage spend, invoicing and transactions – while superficially similar to a true supplier management platform – really shouldn’t be forced so far out of its comfort zone. It’s not a mistake that many procurement leaders make twice.