In our last post we noted that many providers that were pushing suites, as well as many that want to compete with those vendors and push the envelope a bit, have stopped pushing suites and started pushing platforms as suites have started to show the cracks in their armour and everyone wants to sell the shiny, crack-free, solution. Hence the platform.

But what is a platform? Traditionally it is a raised platform for people, animals, and objects to stand upon. In the computing realm, it is commonly defined as a framework for software applications to run on. Which is a useless definition as “framework” is ill-defined and too vague to be useful.

So what is a framework? Traditionally, this is an enclosure or structure designed to support something, and the definition changes depending upon what you want to support. In computing, it could be a software framework — a collection of classes and libraries to support the development of applications with common functionality, an enterprise architecture framework — a configuration of software and communication protocols that support a pre-set class of applications and deliver models, and hardware frameworks that are pre-configured to support a specific software framework (OS, enterprise architecture, etc.).

And, as hinted in the previous paragraph, the problem is compounded by delivery models — on premise, hosted ASP (often disguised as SaaS), and SaaS (which could be multi-tenant at the application, database, or instance level, each with advantages and disadvantages), And then there is “the cloud” to consider and the extent to which the SaaS platform takes advantage of real-time scalability, fail-over, and back-up options.

When you get right down to it, there is not only no common definition of what a platform should do, but even what a platform is and what it should address!
And any definition that would be put forward by a vendor or analyst would likely need to change slightly depending upon what Supply Management processes are being supported.

So the answer is, at least for now, a “platform” is whatever the vendor wants it to be, and not necessarily what you need it to be. And while you might need a “platform”, you do not necessarily want the “platform” that any particular vendor is going to sell you.

And in order to figure that out, you are going to have to define what you need the “platform” to do, which will dictate some key requirements and help you select a “platform” that actually provides you with a solution versus just adding as many problems as it solves (like first generation suites).

So how do you do that?

Stay tuned.

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?