03 Jun 2016 Things you thought you knew about e-procurement that you don’t #4 – your existing ERP is your e-procurement
Using an ERP for purchasing is like not buying a family car because you already have an battle tank in the yard. Sure, it will get you to the mall but is it the ideal vehicle?
To understand why ERP procurement modules should not necessarily be used in place of a standalone e-procurement product it is important to understand how ERP systems have evolved.
The ERP systems comprise a number of modules which have as their key focus the sanctity and primacy of the general ledger. The purchasing modules are designed to ensure that the purchasing information which is needed for financial purposes is available to the core finance module. It is concerned with inward data flows and is internally focused on the needs of finance professionals.
But purchasing is not an inwardly facing financial process; it is a distinct and externally focused activity which has internal financial consequences.
ERP systems began as a means of drawing together elements of manufacturing enterprises’ business, often on a worldwide business, in order to manage production planning and scheduling together with the other elements enabling control of production cost and planning. Over time, smaller businesses and public sector bodies, which are not worldwide manufacturing enterprises, have purchased multiple instances of ERPs despite their actual need being, in the first instance at least, for an accounting system of record.
There are a number of problems raised.
– It is not the purpose or context for which ERP systems were originally designed or the context in which they function to best purpose;
– By incorporating multiple layers of functionality, which have a tendency to be defined by reference to the needs of either the production process or the ledger, they tend to sub-optimise performance of the modules. Generally, the modules of ERP systems are not themselves best of breed instances of software for those functions;
– Even if “full integration” of modules is desirable (an assertion which begs the question), the promise of “full integration” is itself problematic if the functionality being “integrated” is not best of breed;
– The costs of “full integration” in the context of “configuration” can be overlooked and not compared with costs of interfacing with best of breed modules;
– A potential single point of failure is introduced.
Possibly worse than all of these, ERPs tacitly assume transactional purchasing is a “back office” activity, and miss entirely the different needs of end-users in the “front office” for flexible tools to request the goods and services they require to do their jobs.
One of the effects of treating the purchase order module of an ERP as the transactional purchasing engine is that two separate functions become confused – conduct of the
