Category Archives: Procurement Damnation

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

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.

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

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

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

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

Zip issued a strong encouragement to check out their newly sponsored Intake and Orchestration RFI, authored by Spend Matters, noting that there’s nothing that will get you smart faster that checking out how this tech works under the hood (Source) because it would take the guesswork out of your evaluation process (Source) and allow you to choose the right intake and procurement orchestration with confidence (Source).

Zip should not have issued a public challenge because the doctor has a very hard time refusing them considering he has been ranting and raving against vendor RFIs for almost two decades (since not long after Procuri# started the craze back in 2006 where they issued FREE templates for e-Sourcing, Supplier Management, Contract Management, and Spend Analysis (each with their own dedicated domain to make them look independently developed, especially since they added service provider or Procurement [but NOT source to contract] logos on the sidebar). These free templates, as has been stated many times, not only made them Procuri look, good, but better than the peers you would evaluate them against, whether or not they actually were. Since then, the doctor has NEVER found an RFX in our space written/sponsored by the vendor that doesn’t favour the vendor, or even one that is actually good as a foundation for provider selection*.

In other words, the chances of Spend Matters and Zip creating the first RFI that would allow for firm-appropriate unbiased vendor selection is pretty low, but that doesn’t necessarily mean that they couldn’t (although the doctor is going into the review doubting it) or that the RFI wouldn’t have any value if used and/or referenced appropriately (either for self-education and/or a foundation for a larger, wider evaluation effort). After all, used appropriately the Spend Matters Solution Maps are highly valuable (as you know that you are evaluating vendors that are apples-to-apples on the core functionality, know that they are all technically likely to meet your needs, and can focus on all of the other requirements of the provider). However, this means that a very careful, independent, third-party evaluation is needed to analyze the efficacy of the map being handed to you.

Especially when there are a number of easily identifiable strikes right off the bat.

  • Sole Sponsored: this means that Spend Matters would have analyzed Zip (which is one of the first “intake” to “orchestrate” vendors they covered) heavily as the foundation for building their RFI (as Zip would expect every aspect of their solution to be analyzable); so while the analysts would do their best to be unbiased, some unconscious bias will creep in
  • Forrester Scoring Scale: the scoring scale is 1 – 3 – 5; presumably this was done to allow for some room for interpretation or “half” points as “whole” points, but there are three major problems with the Forrester scale
    • it has been grossly misused to evaluate tech by people who don’t understand tech (in one of their reports, a vendor was given a 5 for software architecture if it was done in house, 3 if part of it was done in house and the rest was built on top of a third party architecture, and 1 if it was done by a third party, which is, well, WTF? who does it has NOTHING to do with how good a software architecture is)
    • it presumes there is a “best” capability that cannot be beat, which is not the case if vendors are still innovating, and could only be the case at the point the RFI was written and only IF the analysts had seen every solution on the market (which is doubtful); there is a reason scales in Solution Map only defined functionality to a “4”, some vendors kept innovating and this allowed that to be captured without needing to update the Solution Map more than every two years
    • it presumes that there is enough information for average buyers to accurately score; given that even analysts needed training and clarification before they would all score Solution Map 99% the same (even though every element was very explicitly defined, first scoring passes by new analysts were often only 90% as they often needed deeper technical explanations of requirements and/or more insight on how to question vendors to get the right answer), how likely do you think it is that buyers with limited technical solution knowledge are going to score solutions the same even if they understand what the seller is offering?
  • Intake Heavy: 49% pure intake, 30% intake-slanted (requirement could be in an intake or orchestrate RFI, but very intake-slanted); 21% orchestration; while this is not bad if you are looking for an intake solution, it is bad if you are looking for an orchestration solution, which is what you should be looking for; the doctor has explained in multiple posts how intake has no value on it’s own (including a deep take in point 11 of market madness where the doctor explained that intake is just pay for view on your data [and why should you pay to access your data]); moreover, intake is NOT new as many P2P solutions (especially those that are based on or support catalogs) have had intake built in since day 1, and Zycus released the first stand-alone intake solution [for its suite] called iRequest back in 2015; and there’s no beef (and it’s always important to ask where’s the beef) … and just adding orchestration alone doesn’t create value (because if you only buy modern applications with Open APIs, you can integrate them all directly upon purchase and not have to pay yet another license and maintenance fee for yet another app)
  • Orchestration Light: while implied by the last point, this has to be called out because the only value from intake-to-orchestrate comes from going beyond just integrating standard Source-to-Pay modules at touch points and either extending into the supply chain or enterprise, adding workflow capability not previously possible across product and service life-cycles, and/or enabling data modelling and analytics not (easily) doable with current applications — there’s one element for beyond S2P (except for, of course, the ERP backbone), workflow coverage is baseline, and analytics is defined as simple “reporting” … not nearly sufficient to capture what orchestration should be and should do
  • Focused on “DOES” and not “ENABLES: the RFI was clearly modeled after solution map which is great for allowing side-by-side comparison of solutions based on their support for certain technical functions, which may or may not be relevant for your organizational needs and does a great job of comparing how relatively advanced multiple solutions are but doesn’t tell you whether or not they will enable YOUR organization with the processes YOUR organization needs with the systems YOUR organizations uses with the interfaces YOUR people, and their TQ, can understand (and, of course, no hints at all on how to evaluate whether or not the provider can support you, 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 — you know, all the important things when selecting a solution)

Not the best of starts, especially when it’s three-strikes-and-you’re-out in baseball, but still there could be deep educational value in the RFI itself and maybe it’s a good starting point for solution comparison (or, better yet, a Spend Matters solution map module).

So, in the next three parts of this series we will evaluate each part of the RFI: Intake, Common, and Orchestrate and then give our verdict.

# Procuri was one of the first Source-to-Contract vendors that was acquired by Ariba in 2007, and then Ariba was acquired by SAP in 2012. (Also, before the RFIs, they published an 84 page book back in 2004 on Driving Business Performance with Strategic Sourcing, edited by Randy Glasbergen. ISBN 0971859841, Library of Congress Control Number 2004112419, and ASIN B000MZKZB2 if you want to track it down.) [And yes, the implication is that the doctor would expect the ZIPpy@ Procurement Handbook to be the next publication from Zip.]

* Yes, the doctor did author the Source-to-Contract Solution maps AND the common foundation for the Source-to-Pay Solution Maps while he was at Spend Matters, but these were NOT for provider selection — the purpose was to identify which vendors were relevant to shortlist in your RFI process (which should consider considerably more than the tech, but the point was to evaluate the tech alone because that is the one thing that most Procurement departments ARE NOT equipped to properly evaluate, while providing an overview of unbiased customer ratings through an aggregate score).

@ Assuming zippy (P.1, P.2) doesn’t violate a trademark of Rainbow.

More Valid Uses for Gen-AI … this time IN Procurement!

Some of you were upset that my last post on Valid Uses for Gen-AI weren’t very Procurement centric, arguing that there were valid uses for Gen-AI in Procurement and that the doctor should have focussed on, or at least included, those because why else would almost every vendor and their dog be including “AI” front and center on their web-site (about 85%+)!

Well, you’re right! To be completely fair, the doctor should acknowledge these valid uses, even if they are very few and very far between. So he will. Those of you following him closely will note that he mentioned some of these in his comment on LinkedIn to Sarah Scudder’s post on how “AI is a buzzword“.

AI is a lot more than a buzzword, but let’s give Gen-AI it’s due … in Procurement … first.

With Gen-AI you can:

1. Create a “you” chat-bot capable of responding to a number of free-form requests that can be mapped to standard types.
This is especially useful if the organization employs one or more annoying employees who always waits too long to request goods and then, after you place the order, insist on emailing you every day to ask “are they here yet” in reference to their request, even though you flat out told them the boats are coming by ship, it takes 24 days to sail the goods across the ocean once they are on the ship, typically 3 days to get them to the port, 3 to 14 days to get them on that ship, 3 to 7 days to get the ship into a dock, 3 to 4 days to unload the ship, and 3 to 4 days from the fort, for a minimum delivery time of 35 days, or 5 weeks, and asking week one just shows how stupid this employee is.

2. Similarly, you can create a “you” chatbot for RFP Question Response.
More specifically, you can create a bot that can simply regurgitate the answers to sales people who won’t read the spec and insist on emailing you on a daily basis with questions you already answered, and which they would realize if they weren’t so damn lazy and just read the full RFP.

3. Create meaningless RFPs from random “spec sheets”.
Specifically, take all those random “spec sheets” the organizational stakeholder downloaded from the internet just so you can check a box, send it out, and make him happy. (Even though no good RFP ever resulted from using vendor RFP templates or spec sheets.) Which is especially useless if you have a subscription with a big analyst firm that includes helping you identify the top 5 vendors you are going to invite to the RFP where you will focus on the service, integration, implementation, and relationship aspects as the analyst firm qualified the tech will meet your needs. (After all, sales, marketing, human resources, and other non-technical buyers love to be helpful in this way and don’t realize that just about every “sales automation”, “content management”, and “application system” has all of the same core features and you can usually make do with any one of a dozen or more low-cost “consumerized” freeware/shareware/pay-per-user SaaS subscriptions.)

4. Or, do something slightly more useful and auto-fill your RFPs with vendor-ish data.
You could use the AI to ingest ALL of a vendor’s website, marketing, and sales materials as well as third party summaries and reviews and auto-fill as much of your RFP as you can before sending it to the vendor, and then approximately score each field based on key words, to ensure that the vendor is likely capable of meeting all of your minimum requirements across the board before you ask them to fill out the RFP and, more importantly, spend hours, or days, reviewing their response.

5. Identify unusual or risky requests or clauses in a “ready to go” contract.
Compare the contract draft handed to you by the helpful stakeholder to the default ones in your library that were (co-)drafted by actual Procurement professionals and vetted by Legal and don’t have unusual, risky, or just plain stupid clauses. For example, an unvetted draft could have a clause that says your organization accepts all liability risk, you agree to pay before goods are even shipped, you’ll accept substitute SKUs without verification, etc. (because the helpful stakeholder just took the vendor’s suggested one-sided contract and handed it to you).

6. Automatic out-of-policy request denial.
Program it to just say “denied” for any request that doesn’t fall close to organizational norms.

7. Generate Kindergarten level summaries of standard reports for the C-Suite.
Got a C-suite full of bankers, accountants, and lawyers who don’t have a clue what the business actually does and need simplified reports translated to banker-speak and legalese? No problem!

Of course, the real question is to ask not what Gen-AI can do for you but what can you do without Gen-AI because the doctor would argue that you don’t need Gen-AI for any of this and that the non-Gen-AI solutions are better and more economical!

Let’s take these valid uses one-by-one:

1. You could hire a virtual admin assistant / AP clerk in the Phillippines, Thailand, or some other developing country with okay English skills to do that for 1K a month!
Furthermore, this full time worker could also respond to other, more generic, requests as well, and do some meaningful work, such as properly transcribing hand-written invoices (or correcting OCR errors), etc. And give your employees the comfort of a real, dependable, human for a fraction of the cost of that overpriced AI bullsh!t they are trying to shove down your throat.

2. Classic “AI” that works on key phrases in the hands of the admin assistant will work just as well.
It will find the most appropriate data, and then the admin can verify that the question can be answered by the paragraph(s) included in the RFP, or that the sales person actually read the RFP and is asking for a clarification on the text, or a more detailed specification. The sales person gets the desired response the first time, no time is wasted, and you haven’t p!ssed off the sales person by forcing him to interact with an artificially idiotic bot.

3. When they said the best things in life are free, they weren’t referring to vendor RFPs.
In fact, those free RFPs and spec sheets will be the most expensive documents you ever handle. Every single one was designed to lock you into the vendor’s solution because every single one focussed not on what a customer needed, but the capabilities and, most importantly, features that were most unique to the vendor. So if you use those RFPs and sheets, you will end up selecting that vendor, be that vendor right, or wrong, for you. The best RFPs and spec sheets are the ones created by you, or at least an independent consultant or analyst working in your best interest. No AI can do this — only an intelligent human that can do a proper needs, platform, and gap analysis and translate that into proper requirements.

4. Okay, you need AI for this … but … traditional, now classic, AI could do that quite well.
Modern Gen-AI doesn’t do any better, and the amount of human verified documents and data you need to sufficiently train the new LLMs to be as accurate as traditional, now classic, AI, is more than all but a handful of organizations have. So you’re going to pay more (both for the tech and the compute time) to get less. Why? In what world does that make sense?

5. Okay, you need NLP at a minimum for this, but you don’t need more. And you barely need AI.
All you have to do is is use classical NLP to identify clause types, do weighted comparisons to standard clauses, analyze sentence structures and gauge intent, and identify clauses that are missing, deviating from standard, and not present in standard contracts. And, as per our last use, do it just as well without needing nearly as much data to effectively train. Leading contracts analytics vendors have been doing this for over a decade.

6. Even first generation e-Procurement platforms could encode rules for auto-approval, auto-denial, and conditional workflows.
In other words, you just need the rules-based automation that we’ve had for decades. And every e-Procurement, Catalog Management, and Tail Spend application does this.

7. Any semi-modern reporting or analytics platforms can allow the templates to be customized to any level of detail or summary desired.
And if you have a modern spend analysis platform, this is super easy. Furthermore, if your C-Suite is filled entirely with accountants, bankers, and lawyers who don’t understand what the business does, because they fired all the STEM professionals who understood what the business actually does, then your organization has a much bigger problem than reporting.

In other words, there isn’t a single use case where you actually need Gen-AI, as traditional approaches not only get the job done in each of these situations, but traditional approaches do it better, cheaper, and more reliably with zero chance of hallucination.

At the end of the day you want a real solution that solves a real problem. And the best way to identify such a solution is to remember that Gen-AI is really short for GENerated Artificial Idiocy. So if you want a real solution that solves a real problem, simply avoid any solution that puts AI first. This way you won’t get a “solution” that is:

  • Artificial Idiocy enabled
  • Artificial Idiocy backed
  • Artificial Idiocy enhanced
  • Artificial Idiocy driven

As Sarah Scudder noted on “AI is a buzzword“, AI is a delivery mechanism which, scientifically speaking, is a method by which the virus spreads itself. This is probably the best non-technical description of what AI is ever! And the best explanation of why you should never trust AI!

Mistake X that Procurement Founders Keep Making

As part of the discussion between the doctor and Jon The Revelator on how 2005 can tell us why most AI initiatives fail in 2024, the doctor, who recently finished the first six installments of his Mistakes Procurement Founders Keep making series, noted one mistake that founders keep making that maybe he should have made more explicit.

Specifically, and this applies to founders who are techies / ex-consultants in particular who are tech first, the one big mistake that is still being made two decades later is this:

Building a “solution” without having identified the “problem” they are trying to solve.

Or, as The Revelator put it, you must solve problems before selling solutions.

(And, preferably, not a problem that was already solved, and solved better.)

While this mistake could fall under foundational market research, it also stands on its own because these tech-minded individuals think that just because the tech doesn’t appear to exist, there’s a market for it.

While the “find a new ‘solution’, figure out what it works for later” might work for PhD students (develop a new algorithm, technique, material, etc. and then figure out what it can be used for), it doesn’t work well in the business world.

While techies might think business people want cool, the reality is that business people, especially those writing big cheques, don’t care. Techies think business people want slick UX. The reality is that business people don’t care. Techies think business people want the latest and greatest tech stack. But, again, business people don’t care.

The techies fail to realize that the business people they are selling to are NOT the people in the organization who are actually going to use the solution, which could be on decades old tech, with a horrendous UI and UX, and descriptors from an 80s horror film. All the solution buyers in an organization care about is

  1. will it meet the business need,
  2. will we get it at the lowest price and,
  3. if the solution processes transactions or personal data,
    does it have all the appropriate security certifications and monitoring?

That’s it. The budget controllers only care about whether or not the solution will solve their problem efficiently, effectively, and affordably. And if you can’t demonstrate that, they won’t care whether or not they’re buying it from Someone Who’s Cool.