P2P best practice out of a box

Posted by Pete Loughlin in Procurement Best Practices, Procurement Process, Purchase to Pay 22 May 2018

There’s a highly valuable anecdote that I can’t repeat. It’s all about how to successfully specify a purchase to pay solution. I say I can’t repeat it, I just can’t say who the main players are so for the sake of sharing the love, I’ll anonymise it and tell the story.

There’s a global company headquartered in Europe and they implemented company A’s P2P application. Company A is highly respected and would be a good choice 90% of the time for any large business. However, the program was a disaster and it was canned after 2 years. The software was replaced with company B’s solution. Company B is also a highly respected business that too would be a good choice 90% of the time. Second time round, the P2P implementation was a great success. Company B of course made great claims about how much better they were compared to company A. “We kicked them out” they said. “Clear proof that our solution is better” they claimed. But the claims of company B were not true. B’s solution was no better than A’s. So what happened? To understand, we have to go back to the beginning.

When they first specified their e-procurement system, the enterprise described 20 or so requirements that were essential and, as far as they knew, were unique to them. After all, their industry is different and they are special. Of course, everyone thinks they’re special and that’s for one very good reason – they are. Everyone is special. The unique and special business requirements were genuine and intelligently thought out. The problem was that they were based on existing good practice – existing good practice that had grown out of old ways of working in a world that no longer exists. Archaic processes, old legislation, a trading environment that had long since gone were all being used to specify a set of process for the future. But they knew no different and they specified these requirements as essential. In response to these requirements, company A, in order to win the business, agreed to customise their solution. As a direct result of these customisations the project became impossibly complex and it failed after 2 years.

Along came company B with a cloud-based solution and again, they were asked to accommodate the 20 or so special requirements. In contrast to company A, company B refused to customise. They explained that as their solution was being used successfully by many large, complex and diverse businesses, it was unlikely that the real business requirements could not be met “out of the box”.

 

Architect woman in working process on blueprints. Business and creativity. Architecture job

 

To cut a long story short, company B delivered a successful project. But it wasn’t because they were any better than company A. The mistake company A made was to be too accommodating. It was the complexity of the customisations that led to the failure, not any shortcomings in the software solution.

Years ago when ever anybody said “let’s just go for vanilla”, I used to respond by explaining that there’s no such thing as vanilla. You need to specify a solution accurately before it’s implemented otherwise you will have to perform expensive customisations later with all of the disadvantages that that entails. And while that’s true of an ERP system or production software designed to meet the needs of a highly specialist business, it is no longer true for software designed to accommodate generic back office processes like indirect procurement and accounts payable.
P2P isn’t rocket science and the software available to support it is mature. There is such a thing as vanilla P2P in the indirect space or what I prefer to call “best practice out of a box”. Making special demands of P2P solution providers should not be necessary. If you are dealing with the leading solution providers, it is most likely that if functionality isn’t available, it’s not necessary.

Like every rule this is not universally true but as a guiding principle, it is very useful. And not just for buyers of the software. Vendors, if they have faith in their solution, should have the confidence to say no to customisations and special requests. They should be prepared to walk away from deals that mandate unusual requests and they should do more to help buyers challenge their status quo.

Post a comment