Procurement Systems – Build or Buy? Read our Paper, See the Arguments

Our recent Paper looking at eProcurement choices faced by public sector organisations also has a read across to private sector in a number of aspects. Implementing the eProcurement Mandate - Technology Choices and Key Decision Factors” can be downloaded here, free on registration, and it is sponsored by Vortal, a leading provider of eProcurement software in Europe and beyond.

But there are some issues we cover in the paper that are applicable and interesting we hope to private sector buyers as well as those in the public sector. For instance, we look in some detail at the question of build versus buy; some organisations will face a choice in terms of eProcurement or indeed other software in terms of whether to buy a proprietary system from an established software firm, or to build their own system.

When the “build” option is chosen, that could be done purely by internal resources, although that seems unlikely that most public organisations would have that sort of skilled resource. So more often, building a bespoke system mean engaging a consultant or software development firm to lead on that activity.

The Spend Matters advice, based on many years of working in procurement and with procurement technology, is in the vast majority of cases, to buy an existing system. Indeed, it is hard to imagine when building your own would be the right solution – it would be an unusual situation. Yet some organisations choose that option – is that out of vanity? A misguided belief that “we’re unique"? Or someone trying to create a nice job for themselves for years to come?

You can decide that yourself, but here are just some of the factors to consider, taken from the paper – but read the whole thing here.

  • Delivery risk: there is a proven market of successful and competent software firms around Europe and beyond that provide this sort of product. Any bespoke software development carries the element of risk that does not apply for existing providers and products.
  • Cost: an existing solution will have transparent and known costs. A competitive process should be used to source the technology, driving value for money. Building a new system can and often does lead to large and virtually open-ended costs, as the buyer is often hit by cost overruns, unexpected add-ons, and so on.
  • Functionality: by definition, any internally developed solution is unproven, with inevitable doubts about its capability and functionality. This is a high-risk option compared with using a proven solution.
  • Lead times: in terms of development and implementation, they are almost certainly much longer for the internal option, with little guarantee of hitting any initially quoted timescales.


Share on Procurious

Discuss this:

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.