In our last two-part series that asked “what is a platform”, we noted that whereas “suite” was pretty easy to define, as it is just a collection of related, and hopefully tightly integrated, modules that address the key steps of a process such as sourcing (or S2C, source-to-contract) or procurement (or P2P, procure-to-pay), platform is hard to define because you have to consider the competing definitions (development framework, enterprise application framework, hardware configuration, etc.) and delivery models (on-premise, hosted ASP, SaaS) and how they can be bundled and/or used to frame a solution space.

We also noted that in order to select the right platform, you needed to define what you needed the platform to do. And to add more confusion, you also need to define any constraints on how you need the platform to do it. Two tasks that are not easy to accomplish. But we can give you some advice on how you can get started.

First, define the problem you are trying to solve.

Not simply the business process at a high level, such as sourcing, procurement, or logistics, but the problems you are experiencing that need to be solved. Is it a paperwork nightmare in procurement, an inability to source efficiently, an inability to track organizational assets and services once requisitioned, an issue with inventory management on the sales side, etc. You can’t even select the right solution unless you know your major pain points, so how could you expect to select the right platform?

Next, outline the preferred process you would like to solve it.

In particular, how should the process work. For example, does all procurement have to begin with a requisition, or is a purchase order from an approved individual enough? How is it flipped to an invoice, and how are the costs verified? In addition, how do invoices come in, how are they matched, and how is this process automated, especially if the organization receives tens of thousands of invoice a month? Does the comparison happen before or after goods receipt? And what is the process if a goods receipt doesn’t materialize x days before the invoice is due? And if the number of invoices are large, with an average error and incompletion rate of 15%, how are the gaps filled in and the errors identified for flip back to supplier with an explanation?

Then document all of the data inputs you need, the artifacts that you need generated, and the data outputs that are required by affected parties.

If you are primarily sourcing direct materials, you will need a bill of materials from engineering along with the cost breakdown that is required, the inspections and certifications that need to be captured, and the timelines that need to be met. If you are sourcing services, you need position descriptions, certification requirements, other validations that must be performed, on so on. Reports will need to be generated, audit trails maintained, and so on.

Follow this with discussions with IT, Finance, Engineering, or any other department that needs to support Procurement in the process.

You will need to find out if there are any restrictions or constraints on an adopted solution dictated by current technology, processes, or third party support … such as systems that need to be integrated with, data that needs to be collected, audit trails that need to be logged, and reports that need to be generated for compliance. Systems can be a big problem — do certain APIs need to be supported, are you restricted to certain technology stack, or do you need certain hardware?

Then go beyond the immediate problem and process to identify other processes and problems that could be impacted by any solution to the problem.

For example, where Procurement is involved, inventory, assets, and accounts payable are clearly impacted. These use different processes and systems which may or may not have been identified in previous steps.

While these steps on their own may not necessarily help you identify the right platform, it will definitely help you identify which platforms are not appropriate to the need at hand and zero in on those that need a closer look.

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?