… because, as we noted in Part 1, while it looks great on the surface, in our space, looks can be deceiving and what you get may NOT be what you want. (And you’ll have to read this full series to find out if it’s good, bad, both, or neither.)

In Part 1, we discussed how Zip issued a public challenge to check out their RFI (making it irresistible to the doctor who has been rallying against vendor RFIs since they first hit the scene big time with Procuri’s 2006 releases, how the doctor had doubts that this would be the first RFI to get it totally right, and how it was starting off with five strikes right off the bat (observable from a first quick read … but that we would review it in detail because there could be value in it if used and/or referenced appropriately (either for self-education and/or a foundation for a larger, wider evaluation effort) and only a fair, detailed review would surface that. So, this is what we are concluding g with the 14 Shared elements organized into the categories of “Configurability”, “Integrations”, and “Analytics”.

In Part 2, we tackled Intake: the strengths, the weaknesses, and the not so-obvious weaknesses.

In Part 3, we tackled (core) Orchestrate: the strengths, the weaknesses, and the not so-obvious weaknesses.

Before we begin our discussion of the Project/Process Management capabilities that are needed to take the offering beyond a pay per view of YOUR data and more solution sprawl (not less), since you don’t want to be asking where’s the beef after adopting a solution, we will remind you that there are some fundamental capabilities that are necessary that were specifically called out in part 35 and part 38 of our 39 Steps … err Clues … err Part Series on Source to Pay.

Sadly, there aren’t any in this RFI. There are only shared capabilities that cross between intake-and orchestrate in the configurability, integrations, and analytics sections. This means that there is no coverage at all of:

• project management beyond task and workflow management — there should be extensive support for phases, milestones, obligations, and distributed management of hierarchical projects in construction, commissioning, and other projects that require multiple projects to be synched between multiple service providers
• KPIs — critical for project and process management requires that there be native support
• project and process templates — to allow workflows to be preconfigured through system drag-and-drop
• dynamic project and process shifting — if the situation changes, the type of sourcing / procurement / contract / etc. project might need to change; and it should be a seamless transition, with all appropriate data, settings, etc. automatically transferred into the new structure

With respect to what is covered for shared requirements in the RFI, the following are quite weak:

• configurability beyond workflow — it’s not just the workflow, it’s the data model as well, for example
• data type data feed integrations — the platform should understand the different types of data it will be processing and support unknown integrations
• m-way integrations — as indicated above, processes are not always simple and restricted to two systems
• real analytics — pre-configured simple out-of-the-box reports are NOT analytics; the power of multi-system multi-source data integration and orchestration is the insightful analytics it can power

However, the following are some strengths of the RFI.

• workflow configurability — mentions parallel approval support, escalation paths, conditional logic, and no-code editing
• multiple workflows — and automatic assignment on procession initiation
• in-flight workflow adjustments — workflows should be capable of being upgraded or reconfigured at any time (without breaking anything)
• ERP integrations — ERP is never going away, and even if it’s not used for any core procurement processes, it is still used to support the supply chain and the true power of intake-to-orchestrate is beyond S2P
• collaboration — S2P is about collaboration — through whatever platforms the organization uses, including Slack, Teams, etc. in addition to the S2P tools the organization tools
• integration monitoring — the platform should monitor integration status, including the last access/synch with every data source, the synch schedule, and system response time

Overall, the overlap is ok, but the support for project and process management assessment is almost nonexistent in the RFI. As per our last post, it is clear the focus of the RFI was intake, not orchestrate, and a whole section needs to be added on project and process management — especially when the true value of intake to orchestrate is going beyond just taking requests and managing S2P solutions to support end-to-end project and process management beyond S2P and upstream into the supply chain and through finance downstream to sales.

SUMMARY

At the end of the day, it’s a good foundation to educate yourself on what intake solutions in S2P should functionally do and how to compare them in a consistent manner, but it’s not nearly enough to evaluate intake-to-orchestrate solutions.

It’s also a good foundation upon which Spend Matters could build an intake-project/process management-orchestrate Solution Map if they addressed all of the points in the last three articles, fleshed out the necessary capabilities more, and refined the scale.

However, it’s certainly not enough to evaluate a provider’s suitability for your organization, as partially pointed out in Part 1. First of all, it doesn’t address all of the capabilities that you are likely to need in a solution. Secondly, as hinted in part 1, it’s not just the functionality, it’s the capability of the platform to support your processes — that’s not just functionality. Thirdly, once you confirm the tech meets baseline (and trust the doctor when he says that multiple platforms will), you have to go beyond the tech to whether or not they will enable YOUR organization with the processes YOUR organization needs with the systems YOUR organizations uses with interfaces appropriate for YOUR people and whether or not they custom integrate new solutions on an ongoing basis for you, be available on your working hours, support the languages of the third parties you need to work with, or culturally be a good fit for your organization. And that’s just the baseline requirements for a good solution RFI — which will always need to be customized to your business.