Build your own P2P – madness or genius in the procurement world?

Checking their website, it tells me that SAP opened their first office in the UK in 1987. And I believe I visited it that year – Aylesbury or somewhere like that?  At Mars Confectionery we had decided that it was about time we got a “purchasing computer system”,  so as the youngest senior manager in the Division (hence assumed to know something about computers... no, don't laugh...) I went to talk to SAP, along with a lady from the Mars internal computer services division.  (She played on the wing for the England Ladies Rugby Team, and there will be more about her in my autobiography, “Interesting People I Have Known” to be published when I'm very, very old).

The current England Ladies Team winning another Grand Slam this year

Anyway, moving on, Mars decided to develop their own system – might that have been partly because the computer services division saw it as a good revenue earning project? I couldn’t possibly comment. But I left not long after that, and I have a suspicion that by the time it was built and implemented some years later, the technology world had moved on considerably, and I’d guess it probably didn’t look like the smartest move in retrospect. But at that time, you could just about make the case for a DIY approach, given the lack of maturity of products available in the market.

Of course, no-one would build their own purchase to pay system now would they? Not with all the options available on the market, the maturity and capability that’s available off the shelf, and the relatively lower cost than we would have paid all those years ago.

But wait!

I have it on good authority, that a very, very large global company (global top 100) is looking to “build their own” P2P system – with the help of the one of the global giant IT / consulting firms of course. That seems astonishing to be honest – but let’s try and think objectively about the pros and cons of such a move.

Issues with build your own

  • Very large and possibly open-ended cost
  • Dependent on the ability of the IT firm
  • Long lead times with little guarantee of hitting any initially quoted timescales
  • High-risk – a solution that is by definition untried, unproven
  • No automatic upgrade path (with costs defrayed across multiple users) – further costs inevitable and unending
  • No available pool of expertise – technology or procurement – familiar with the system
  • Potential integration issues with other technology

Positives

  • Ability to specify – and hopefully get – just what you want to meet your needs
  • A major project that will occupy lots of time and people within the firm for years (good for the people, not necessarily the firm)
  • ummmm...

You can probably tell which side of the argument I’m coming down on. It seems like a surprising strategy to say the least – but we’re very open to any further thoughts or explanation as to why this would be the right way to go.

Or.. is it another example of Stupid Sourcing?

And this time, from a procurement function itself, rather than a misguided bunch of non-procurement stakeholders!

First Voice

  1. Final Furlong:

    A few years ago, I was told a fascinating story about a ‘self-build e-procurement initiative in the ’90s.

    Just around about the time Ariba launched its initial product (featuring the colours of its owner’s favourite American football team, the 49ers) a large UK building society presented its home-grown procurement system at the FSPF. They had installed 2 systems – one at Leeds and the other at Halifax. They couldn’t get the systems (which were identical) to talk to each other because the databases were ‘proprietary’ and much would have to be rewritten to achieve the objective. The topic of ‘installing a web-based front end’ also came up and it was met with a shrug of the shoulders (“erm…”). I’m told that a few years later (and significant cost) they implemented Ariba.

    Stranger things have happened…

Discuss this:

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