As in almost every field where business and technology collide, one unfortunate side effect always seems to be a super-proliferation of jargon - very often created by service providers to generate new 'spaces' which they can aspire to 'own'.

The result is invariably fragmentation and confusion; a glut of terms that come to mean different things to different people. So below, I have tried to give Wax Digital's round up of how we apply the most common terms:

»       eProcurement (or e-procurement): The umbrella or catch-all term for all electronic purchasing and sourcing activities.

»       Source-to-Pay: As above, but describes a little more accurately the entire eProcurement cycle, from sourcing right through to payment of a supplier invoice.

Below these two umbrella terms sit another couple of collective nouns:

»        eSourcing (or e-sourcing): Covers a range of activities and technologies specifically around the tender, auction and contract management lifecycle.

»        Purchase-to-Pay (P2P): Once suppliers are sourced and contracts in place, purchase-to-pay facilitates the electronic raising of requisitions through to payment of invoices.

eSourcing typically accommodates the following core activities:

»        eRFx (or electronic tendering): Creating tender documents electronically, distributing them to suppliers and collating the responses with automated score carding to identify the most suitable suppliers/best responses.

»        eAuction (or e-auction): Time-based events in which suppliers compete against one another for supply of a defined set of goods and/or services.

»        Contract management: Electronic negotiation, storage and ongoing management of supplier contract documents.

Purchase-to-Pay includes:

»        Product Data Management (electronic catalogues): Providing an environment for users to search and select products and services for purchase, typically with the facility for suppliers to manage and maintain that data.

»        Purchasing: Typically the business rules that are applied to requisitions – eg budgeting, approvals etc – that result in authorized and correctly coded purchase orders.

»        Electronic Document Interchange (EDI or web EDI): The technology for distributing purchase orders electronically, through goods receipting, returns etc, to final electronic invoice.

»        Invoice Matching: Workflow processes to handle invoice discrepancies, or to deal with invoices that are not submitted electronically by suppliers.

»        Spend Analysis: Analysing spend patterns across one or more systems in order to power more effective strategic sourcing activities.

As a provider of sourcing and spend management solutions into big businesses, we see our fair share of major ERP implementations and integrating with them – whether that be with a single version of SAP or half a dozen different systems across a group – is a critical part of every project.

What we see is that, almost without exception, major organisations have spent more time and money installing these systems than was originally planned. The stories are long and familiar and most of the users of these systems are still reeling from false promises, over engineered applications, lack of suitable functionality and late delivery.

So what are solution providers like us and the IT departments we work with doing to recover from this situation?

Well, it’s no magic bullet, but the still recent phenomena of the service oriented architecture (SOA - take a look at http://www.soa-consortium.org/ for more details) really could represent a brave new world for IT and Business Process Management (BPM).

The principals of SOA are based around close collaboration between IT and business user, designed ultimately to give business users what they really want, and are now backed by just about every major IT vendor in the world.

Just compare some of the reasons we have failed in the past with ERP and match these up against the main characteristics for SOA and some of the answers become apparent.

»       ERP – large, one size fits all

»       SOA – small, agile fit for purpose

»       ERP -  over engineered, ‘one size fits all’, lots of redundant functionality

»       SOA – designed to fit, easy to use

»       ERP – Expensive, large commitment

»       SOA – as required, bite size chunks

»       ERP – No user input – ‘That’s how it works’

»       SOA – engineered jointly (IT and User)- exact fit usage

»       ERP – Changes are expensive and not encouraged

»       SOA – built to change, cost effective

Another key value driver is that SOA can be used as a wrapper around unusable, badly implemented functions, maintaining the link with the ERP (ERP will see no difference) but giving the user extended easy to use functionality. So extending this to a whole organisation you can, in 'lego brick' style, build fit for purpose functionality around the ERP without having to go through all that pain again.

Which is where we sit as an eProcurement and spend management provider, delivering rapid deployment and high value returns by seamlessly extending the reach of the installed ERP system(s).

The benefits of this kind of approach are pretty clear:

»       Implementation at the speed you can afford

»       High ROI can be attacked first

»       Easy to justify smaller amounts of work

»       New functionality can be bolted on

»       Existing investment not compromised

»       Business user have a say and get what they want

»       Can be implemented with web services – talk to anything!

»       Short implementation timescales – quick results!

Most of this can be summed up in the following associated article http://www.mcsolutions.co.uk/article/10191/SOAs-apprentice.aspx which looks at this issue in much greater detail.

In summary, SOA means the IT community is in real danger of giving the users what they want. How’s that for a thought!