In the beginning, there was the spreadsheet.

Organizations would send or fax out long, detailed RFQs asking for detailed bids and bid breakdowns for their (complex) sourcing needs, wait for the couriered or faxed responses, spend days (or weeks) entering all of the data into an early spreadsheet application (like Lotus 1 2 3), do their analysis, select one or more vendors for an award, begin negotiations, and eventually cut a contract.

Then, in the very late 1990s / early noughts, RFQ and basic e-Auctions hit the scene. Bid collection was automated, side-by-side comparisons were automatic, and organizations could quickly see who they wanted to work with.

And then, within a few years, there were contract creation and management solutions they could use to author, store, track, and manage the contract.

Then they needed to send out POs against the contract, collect invoices against the PO, match, and manage these e-Documents, so they acquired an e-Procurement or an EDI solution (connected to their ERP) to do so.

At this point they had a slew of solutions that all needed data from the precursor application in the business process and all needed to feed data into the next application in the business process workflow. A few of these solutions supported integration with the previous or next application, but many didn’t and the data re-entry nightmare became as bad as the data entry nightmare when all the organization had was a spreadsheet.

But then suite providers, who offered a set of complementary modules that digitized an entire process end to end (such as sourcing, procurement, etc.), hit the scene and the data re-entry problem was marginalized as all of the modules were integrated, data flowed through the suite end-to-end, could be pulled in automatically from a file that followed a standard format, and could be pushed to an ERP and/or exported to standard format and once IT mapped the export to the next system in the workflow, the process could be automated and manual intervention was only required on exception or on update.

This worked well, and for many smaller companies continues to work well, but as companies continue to advance in Procurement maturity, and need to find new ways to extract and create supply chain value, the cracks in the suite armour begin to show.

The issues with a traditional Sourcing / Procurement suite include:

internal data / data structure is typically not exposed

e.g. a S2C (Source to Contract) will be set up to accept supplier (master) data and export contracts and meta data, but (losing) bids, auction history, negotiation audit trails, etc. will typically not be configured as (standard) reports and exports and may not be extractable in any automated fashion

the artifacts required for related processes and functions are rarely addressed

e.g. a P2P (Procure to Pay) will be used to procure not only goods and services for re-sale and goods and services for consumption, but internal assets such as equipment, licenses, etc. that need to be tracked and managed in an asset control system; the P2P system should collect all of the necessary data, but typically doesn’t nor does it connect or push data to the asset system, meaning purchases just get lost

the workflow is typically fixed to the process the system was built to support

e.g. most companies built solutions to address problems encountered in the companies the founders worked for or the companies that adopted the beta solutions; this not only resulted in some platforms being very good for commodities for re-sale but poor for MRO, very good for direct materials but poor for services, etc. but also resulted in solutions that really only worked for one or two verticals as the sourcing process used by a finance institution (even for similar types of goods or services) was very different than the sourcing process used by a CPG company …

And so on.

So now the leading providers who recognize this are not selling suites, they are selling “platforms”. But what is a platform anyway?