… 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.)
Post Edit: The summary on LinkedIn has been removed. You can read why in the Social Media Policy. See this post for Zip Solution Coverage.
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 continuing, and this post will focus in on the 10 pure Orchestration elements organized into the categories of “General” ad “Source-to-Pay”.
This follows Part 2, we tackled Intake: the strengths, the weaknesses, and the not so-obvious weaknesses.
Before we begin our discussion of orcehstration, we should note that there are some fundamental requirements for orchestrate, as outlined here on SI in our 39 Steps … err Clues … err Part Series on Source to Pay, and they were specifically called out in part 35 and part 39.
With respect to the core requirements, the RFI doesn’t (explicitly) call out
- self-serve integrations — no system will integrate with everything out of the box (not even close to be honest) and you will often need to create and manage your own integrations
- low-code integrations — the average person who will need to do the integrations will not be a technical coder
- workflow automation — the whole point of orchestration is configurable rules-based automation, so the workflow automation needs to be highly configurable
- data stream automations — it calls out non-S2P integrations, but doesn’t specifically call out data stream — sometimes third party data is way more relevant than third party applications
- data model discovery — it’s more than data harmonization, much more
So those are some obvious weaknesses.
There are also some not-so-obvious weaknesses in the RFI when you dive in deep.
- multi-dimensional integrations — not just bi-directional between S2P systems, but also between third party data feeds and the ERP to support complex data management and harmonization requirements
- full-fledged data management — not just harmonization as discovery, harmonization, and enrichment are all important
- orchestration S2P is more than just punch-out, vCards, supplier onboarding, contract risk, and events — for procurement, there’s also federated catalog management and (other) payment method integration; for sourcing, there’s also services and direct event support (not just indirect buys); for supplier management, it’s way more than onboarding — it’s relationship, compliance, risk, and performance management; for contracts, it’s the award through the negotiation to the execution management (not just supporting an e-filing system); etc.
And, of course, as with intake, there are some strengths in the RFI.
- integrations for orchestration — it’s not just integrating for intake, it’s integrating for process management
- orchestration protocols — sometimes part of a process has to be completed within a (legacy) application; there should be support for smooth process handover and user login to the application, as well as handover back to the orchestration application and user transition back when the process is completed
- contract risk — explicitly called out shows there is an understanding that proper contract management is more than just an e-filing cabinet and an orchestration platform for S2P should support the more important aspects
Overall, it’s okay, but not great as it is clear the focus of the RFI was intake, more thought needs to be put into the orchestration core, and the orchestration core fleshed out more to truly evaluate how good a solution is — especially when the true value comes from going beyond S2P, even if it’s just allowing Procurement to understand the upstream and downstream ramifications of a decision.
So what about the shared capabilities between intake and orchestrate? Do they improve the overall RFI? We’ll tackle that in Part 4.