Monthly Archives: June 2024

Don’t Zip Through the Zip-sponsored Spend Matters authored Intake and Procurement RFP! [2024] (Collected Links)

Don’t Zip Through the Zip-sponsored Spend Matters authored Intake and Procurement RFP!

BONUS

BONUS 2

DEAR ENTERPRISE PROCUREMENT SOFTWARE BUYER: THERE ARE NO FREE RFPs!

This shouldn’t have to be said (again), but apparently it does since Zip has relaunched the FREE RFP madness in Source-to-Pay (that began in 2006 when Procuri first aggressively launched the Sourcing, Supplier Management, Contract Management, and Spend Analysis RFPs) with an RFP that is intake heavy, orchestrate light, process deficient, and, like many RFPs before, completely misses some of the key points when going to market for a technology solution. (Especially since there isn’t a single FREE RFP template from a vendor that isn’t intrinsically weighted towards the vendor’s solution, as it’s always written from the viewpoint of what the vendor believes is important.)

the doctor has extensively written about RFPs and the RFP process here on SI in the past, but, at a high level, a good RFP specifies:

  • your current state,
    it does NOT leave this out leaving the vendor to guess your technical and process maturity
  • what you need the solution to do
    NOT just a list of feature/functions
  • what ecosystem you need the solution to work in
    NOT just a list of protocols or APIs that must be supported
  • where the data will live
    and, if in the solution, how you will access it (for free) for exports and off-(vendor-)site backups, do NOT leave this out
  • what support you need from the vendor
    NOT just whether the vendor offers integration / implementation services and their hourly / project rate
  • any specific services you would like from the vendor
    NOT a list of all services you might want to buy someday
  • what the precise scope of the RFP is if it is part of a larger project
    NOT a blanket request for the vendor to “address what they can”
  • what regulations and laws you are subject to that the vendor must support
    NOT just an extensive list of every standard and protocol you can think of
  • what languages and geographies and time zones you need supported
  • any additional requirements the vendor will need to adhere to based on the regulations you or the vendor would be subject to and additional requirements your organization puts in place
    NOT endless forms of every question you can think of that might never be relevant
  • your goal state,
    it does NOT leave the vendor to guess what you are looking for (note that “goal” defines what you want to achieve, it is up to the vendor to define how they will help you achieve it)
  • what (management) processes you use to work with vendors — and —
  • what collaboration tools you make available to vendors and what your expectations are of them

And it is only created after a current state assessment, goal state specification, and key use-case identification so that it is relatively clear on organization needs and vendors have no excuse to provide a poor response.

Furthermore, a good RFP does NOT contain:

  • requests for features/functions you don’t currently need (but you can ask for a roadmap)
  • specific requests for a certain type of AI/ML/Analytics/Optimization/etc. when you don’t even know what that tech actually does — let the vendor tell you, and then show you, how their tech solves their problem
    (after all, there are almost NO valid uses for Gen-AI in S2P)
  • specific requests on the technology stack, when it doesn’t matter if they use Java or Ruby, host on AWS or Azure, etc.
  • requests for audits (tech, environmental, social welfare, etc.) when you haven’t selected the vendor for an award, pending a successful negotiation
  • requests for service professional resumes when you haven’t selected the vendor for an award that includes professional service, pending a successful negotiation
  • requests for financials, when you haven’t selected the vendor for an award pending a successful negotiation
    (because these last three [3] will scare some vendors off and possibly prevent the best vendor for you from even acknowledging your RFP exists)

And, a good RFP, goes to the right providers! This means that you need to select providers with the right type of solution you need before you issue the RFP, and then only issue to providers that you know offer that type of solution. (You can use analyst reports here if you like to identify potential vendors, but remember these maps cannot be used for solution selection! You will then need to do some basic research to make sure the vendor appears to fit the criteria.)

And if there are a lot of potential providers, you may need to do a RFI — Request for Interest / Intent (to Bid) — where you specify at a high level what the RFP you intend to issue is for, and if you get a lot of positive responses, do an initial call with the providers to confirm not only interest but the solution offered is relevant to your organization. (After all, at the end of the day, as The Revelator is quick to point out, it’s as much about the people behind the technology as the technology itself if you expect to be served by the provider.)

And even if you don’t need to an RFI before the RFP, you should still reach out to the vendors you want to respond, let them know the RFP is coming, and let them know you’ve done your research, believe they are one of the top 5 vendors, and are looking forward to their response. (Otherwise, you might find you don’t get as many responses as you’d hope for as vendors prioritize RFPs that they believe they have a good shot at winning vs. random unexpected RFP requests from unknown companies.)

At the end of the day, if you don’t know:

  • what the main categories of S2P+ solutions are
  • what the typical capabilities of a solution type are, what’s below, average or above
  • who the vendors are
  • how to determine your current state of process maturity (and how that compares to the industry, market, and best-in-class) and what a solution could do for you
  • how to evaluate a vendor’s solution
  • how to evaluate a vendor overall
  • how to write a good RFP that balances core business, tech, and solution requirements to maximize your chances of finding a good vendor for you

and the reality is that you most likely don’t (as less than 10% of Procurement departments are world class, as per Hackett research going back to the 2000s where they also determined the typical journey for an organization to become best-in-class in Procurement was 8 years, and that’s the minimum requirement to write a world-class technology RFP), then you should engage help from an expert to help you craft that RFP, be it an independent consultant or firm that specializes in Procurement transformation.

It is also critically important that the firm you select to help you needs to be neutral (not aligned with one solution provider who refers implementations to them in return for potential customer referrals) and that the firm does not rely on analyst maps either!

If you want help, the doctor has relationships with leading, neutral, firms on both sides of the pond who can help you, and who he will work with to make sure the technology / solution component is precisely what you need to get the right responses from vendors. Simply contact the doctor (at) sourcinginnovation [dot] com if you would like help getting it right.

Simply put, getting help with your technology RFP is the best insurance money you can spend. When you considering that, all in, these solutions will cost seven (7) or eight (8) figures over just a few years, you should be willing to spend 5% to 10% of the initial contract value to make sure you get it right. (Especially when there isn’t a single Private Equity Firm that wouldn’t invest in a technology player without doing a six [6], if not seven [7] figure due diligence first … and sometimes the firm will do this and then walk away! At least in your case, when you work with someone who can identify multiple potential vendors, you’re certain to find one at the end of the day.)

Don’t Zip Through the Zip-sponsored Spend Matters authored Intake and Procurement Orchestration RFI, Part 4: Project/Process Management

… 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.

Don’t Zip Through the Zip-sponsored Spend Matters authored Intake and Procurement Orchestration RFI, Part 3: Orchestrate

… 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 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.

Don’t Zip Through the Zip-sponsored Spend Matters authored Intake and Procurement Orchestration RFI, Part 2: Intake

… 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.