… 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 starting, and we are beginning with the 27 Intake elements organized into the categories of “Breadth of Demand Requests/Intake Management”, “Routing and Task Assignment”, “Tracking and Progress Monitoring”, and “Approvals and Stakeholder Evaluation”.

Before we begin, we should note that there are some fundamental requirements for intake, 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 37.

With respect to the core requirements, the RFI doesn’t (explicitly) call out

• a portal — if you don’t have an application that can be used as intake, then you need to build a portal anyone can access
• support for project management — procurement should be supporting projects, that can’t be overlooked (which is why SI prefers to discuss intake-project-orchestrate as a category when it actually discusses intake & orchestrate)
• specific support for budget management — and if you want to support procurement and finance (which should be one of the goals of orchestration, right?) it should!
• policy tracking and management — one of the biggest issues that users have with procurement systems and processes and policies is that they don’t know where they are, or understand them, and/or know how to comply with them quickly and easily (and those are the reasons that procurement is always bypassed, ignorance and understandable laziness — they don’t know and they don’t want to put in the effort to learn archaic systems and processes just to order a laptop or do their job); there is an entry on compliance, but it has to go beyond to policy identification, enforcement, guidance, and explanation; and there is an entry on general procurement requests, but they may or may not be policy related; moreover, it has to go beyond just procurement policy to any relevant policy that would come into effect as a result of a procurement under the policy
• no explicit support for direct procurement — not all intake / orchestrate applications can support direct, so this cannot be overlooked

So those are some obvious weaknesses.

There are also some not-so obvious weaknesses in the RFI when you dive in deep.

• no core intake for data augmentation & analytics — the most powerful application in any enterprise space is one that can manage, augment, and analyze data to find new insights; this cannot be overlooked
• routing is not just application and approver routing, but also requester — some requests will be team efforts (especially if you start branching into direct) and the team members will need help coordinating their efforts to complete the project in a timely manner
• progress monitoring needs to be dynamic and support status monitoring of parallel workflows — not all processes are linear

But there are also some strengths in the RFI.

• intake is different for procurement/sourcing, supplier, and contracting, and this is well recognized
• intake needs to support life-cycles and adapt to the nature of the request, and request lifecycle management is explicitly called out
• guided buying is explicitly called out, removes the most common excuses for platform avoidance (too hard to use, needs specialized training that is forgotten if the platform is only used occasionally, takes too long to fumble through it)
• makes it clear that intake needs to adapt to function (but should go beyond just procurement, which should also be included in not-so-obvious weaknesses)
• makes it clear that updates should be available in (near) real-time, or at least capable of being requested in (near) real-time
• makes it clear that workflows need to be collaborative (or there’s no value in them beyond the existing tools)
• calls out resolution/dispute management — which is a common need in Procurement that is not always adequately addressed by other systems

Overall, we’d say the ZIP sponsored RFI is adequate for intake. It’s not great, as there are some core requirements that aren’t covered. But it’s not bad, because, especially for indirect and services, it has some strengths and covers the core reasonably well.

So how does it do on orchestrate? We’ll tackle that in Part 3.