Originally posted on the Synertrade blog in October, 2018.
A few months ago we penned a piece on the back office and how it powers platforms. We indicated that the only way a platform could deal with the facts that
- (Procurement) workflows are not static and change over time, whether or not you want them to or not;
- the type of data you need to ingest, as well as the quality and representation thereof changes over time; and this means that
- RPA requirements also change over time
is if such a platform had a great back office. A back office with functionality that allows you to do more than just define users, look and feel, and the categorization schema. A back office that allows an administrator to update the master schema, data harmonization rules, organizational hierarchy, workflow processes, approval chains, and RPA workers. And so on.
But this is just platform maintenance. A platform needs to evolve over time. As per Sourcing Innovation’s recent series on 2020 is Fast Approaching — Better Get on Your Tech Capabilities (Part I, Part II, Part III, and Part IV), 2020 is almost here and the magnificent picture of Procurement in 2020 that all the big analyst firms and thought leadership vendors painted between 2008 and 2013 (check the modern Wayback Machine if you don’t remember, unless you have the original WABAC machine) has not materialized. To be blunt, the picture today, for the most part, is not much better than it was ten (10) years ago. There have been few advances in platform capabilities, although there has been considerable advances in usability and integration. Source to Pay offerings, non-existent in the best-of-breed focussed world (where there were a couple of S2C and a couple of P2P offerings) of a decade ago, are now the norm. And they are quite useable. But are they more powerful?
Consider the eight capabilities mentioned in Sourcing Innovation’s recent posts which were supposed to be, more-or-less, common place. How many does your platform have? Maybe a couple if you are lucky. Maybe. But let’s review the capabilities you should have.
- True Invoice Automation (with human intervention necessary on less than 2%)
- Supplier Identification
- Automated Supplier Discovery
- RFX Process Automation
- Should Cost Modelling
If your platform doesn’t have these capabilities, or doesn’t have them to the extent it should (and we can guarantee no platform yet has all of these capabilities to the extent it should, the best you can hope for is a platform actively working towards the goal), the only way you’re going to get them is if the platform has built-in foundations for evolutionary capabilities.
What are these necessary capabilities?
As previously discussed, workflow automation, schema extensibility, and RPA (robotic process automation) are key. But so are open integration (and a fully exposed and extensible API), unlimited supplier (pool) access, and extensible cost and product modelling. These are key capabilities that many platforms are missing, and, key capabilities that, when present, are found in a back-office that powers the platform. (And that’s why the back office will power platform evolution too.)
Most platforms, even those that tout integration, don’t have truly open integration. There is a limited API, and if the external platform or data feed can’t map to it one-to-one, there is no true integration — only what can be mapped.
Most platforms have their own S-MDM (Supplier Master Data Management) capability and some either offer their own network or integrate with one. But it’s still very closed. Right now there are a number of networks, a number of directories, and a number of collective initiatives out there, each of which is controlled by a vendor using a different (often proprietary) technology. There’s no real openness. A vendor must commit to not building its own network of any kind, but integrating with whatever network its suppliers are on that they want to use.
Only a few platforms have should-cost modelling and bill of materials capability even today — even though, at some point in the supply chain, every product is a bill of materials and every service is a collection of task-based service offerings. Only a platform that allows these common components to be defined and re-used is going to provide an organization with evolutionary offerings.
So when you go out to select your S2P platform, if you want a best-of-breed platform that will not only offer the best of what’s available today, but meet your needs tomorrow, be sure to select one with a back-office capability that, in addition to the key requirements outlined last time, also allows for true open integration, for true supplier network/portal interoperability, and true, composable, bill-of-material based should-cost modelling capability. Otherwise, there will be limits to what the platform can do and you will never get a true strategic offering from the vendor and never, ever, reach cognitive support capabilities.