Category Archives: rants

Bells and Whistles Lead to Cells and Thistles! Part I

I’ve been hearing and seeing two things lately:

  • smaller vendors telling me they’re struggling to close / losing deals because their potential customers are telling them they are leaning towards the bigger/splashier vendor with more “Bells and Whistles”
  • vendors getting lots of (and possibly too much) funding are focussing heavy on bells and whistles (because they believe it will help them sell fast and meet the significant, and often unrealistic, sales targets of the investment firm[s])

So I have to address this because if you select a solution based on bells and whistles, expect to end up in a cell while your fingers bleed from the thistles that prick you every time you try do something that’s not the primary, simple, use case. This then leads to usage of your purchase declining quickly, causing you to end up with another piece of shelfware before you get even halfway through the initial contract subscription.

Now, to help you understand I’m not making this up for clicks and shares, we’re going to dive into some of the most common bells and whistles and why, in the best case, they’re a complete waste of money and, in the worst case, the thorn prick will end up being so painful that your team will simply stop using the software. We’re going to do this across source-to-pay.

Intake

Everyone’s gotta have it because, apparently, it’s brand new and Zip invented the category a few years ago. This is, of course, complete bullsh!t because

  1. Coupa has had full intake since Procurement Independence Day in 2006. You just didn’t know because when Robbie took over the Coupa factory, licensing switched from enterprise size to per user, and the cost was too much to give non-Procurement users a license so you didn’t see the intake that was there. (And to that effect, if Zip is pricing per user, how is this better?)
  2. Zycus had one of the first modules dedicated to intake, iRequest, over a decade ago

Moreover, everyone has to have Gen-AI intake, because, apparently, using a few drop downs to figure out what a user wants is too difficult for the average iZombie who has been zombified by ChatGPT over-dependence.

While this is useful to parse an initial request from a user — do they have a question, want a report, or want to make a requisition (and if so, is it from a catalog or do you have to go to market) — beyond that initial parsing (which will never achieve an initial parsing accuracy beyond 90%, so at least 1 in every 10 requests will have to be rephrased for the system to get it right), it goes from useful to painful to useless.

Here are a few examples:

  • Policy Question: as we’ve said before, Gen-AI has two strengths: large corpus search and summarization and natural language processing; in this circumstance, if the success rate is 90%, it’s mostly useful, but to be honest, if you know the right terminology, elastic search will work just as well, retrieve the exact clause, and never hallucinate a response. Summary: sometimes useful.
  • Catalog Buy: good luck with this because you’ll spend at least 5 minutes trying to order a box of gloves, and I kid you not — see this post where we illustrate how it will take you five minutes to explain to the Gormless AI what you want when you could place an order in a well-defined catalog in 15 seconds with 3 words, 1 number, and 4 clicks. Nothing will drive your users to maverick purchasing off of Amazon, BestBuy, and even Walmart faster than a Gen-AI intake portal. Summary: painful.
  • Analytics Request: while it’s great for a simple “how much am I spending on supplier S” (especially if that total exists in a spend cube), the fact that Gen-AI is very bad at math (to the point that you can ask the same question twice in a row and get a different answer), and not so great at parsing very specific requests such as how much did we spend with supplier S on steel products last quarter which makes it all but useless — even Gartner, the ring leaders of the Gen-AI lovefest, have predicted that “conversational analytics” will completely leave the ProcureTech vernacular in two years. Summary: useless.

… but this is just the beginning. We’ll continue with the Source to Pay process in Part II.

In ProcureTech, Stop Caring What Gartner, Forrester, or IDC Thinks!

I shouldn’t have to address this again, but every year multiple vendors reach out and ask how to get on these vendors maps because they believe it’s the only way to get more market visibility and/or be selected by certain customers, including you. It’s not the only way to get visibility and if a vendor can’t convince a potential customer from thinking that only map companies are good, I’ll tell them this right now — that’s not a customer they want (because that vendor will be out on the renewal with whatever vendor overtakes them in the map when the CPO changes in 3 years, because companies without vision to look beyond a meaningless map don’t keep real talent, and only real talent will identify and select the best solution and ensure that solution is kept over time).

But I digress — this post is about you, the potential customer, and why you need to STOP caring what Gartner, Forrester, or IDC thinks.

First of all, we’ve said it before, and we’ll say it again: It’s NOT the Analyst Firm. It’s the Analyst!.

In addition to all of the skillsets and education that an analyst needs to have to get it right, which we covered in detail in that post, the analyst needs a lot of relevant experience, and history in the ProcureTech space, to make sense of the ProcureTech world today. Ask yourself: how many of the analysts with the right education have at least 10 years in our space? The answer is very few. How many have 20 years in (independent) analyst roles? You can count them on your fingers. I know of myself, Jon Hansen, Pierre Mitchell, and Chris Sawchuk with 20 years of (independent) analyst experience in our space and a deep technical (STEM) education. Everyone else who started covering this space day in, day out two decades ago has moved on or retired. Now, of these analysts, how many have also built actual solutions in the ProcureTech space, connecting the dots between the education, theory, and practice? Two of us — myself and Jon Hansen. (But we should note that Pierre and Chris spent part of their careers on solution advisory consulting and implementation guidance, and have deep knowledge about the implementation and integration requirements, which is also very unique and useful in technology selection.)

Now remember the second point: Vendors Have Lured Big Analyst Firms Astray and that you’re not getting a map of the best solutions, but the best solutions from the analyst firm’s pool of vendor sponsors and research subscribers, where the reality is that only the big, established, cash-rich companies can afford the high-priced subscriptions that keep them in front of the overworked analysts who have to spend over half of their time taking inquiries or keeping high paying subscription customers happy. (Whereas analysts at smaller firms or independents get to focus on studying and understanding the solutions, not general inquiries or whether or not the contract [or pricing model] is good.)

This means that these big firm analysts are not spending a lot of time, if any, looking at the up-and-coming mid-sized companies that have not only been around long enough to develop mature enterprise solutions, but solutions that are more modern, more powerful, more usable, and more intelligent (with embedded analytics, RPA, and the right AI for the task at hand), and possibly (much) better for you. Moreover, if the enterprise is a mid-market company, or able to go with a best-of-breed as a bolt-on to their enterprise ProcureTech platform, they’ll never know about the majority of these solutions (as only the overfunded startups will have the money to get the big analyst firm attention, and these vendors often have more financial stability problems than the smaller vendors who are bootstrapping or taking minimal funding and actually have stable, happy, paying customers keeping them afloat).

Third, and most important, it’s not the best rated solution, it’s the best solution for your organization. Not only is it the case that this solution is very likely not on a map of only 20 companies (when there might be 100 companies that offer that solution), but it might also be the case that it is the lowest ranked solution on those maps — especially when these maps tend to rate solutions on a lot of subjective factors that match what the analyst thinks are the most relevant for an average organization, whereas you are a specific organization which has a specific set of relevant factors that you care about, with specific requirements for those factors. The more divergence between your factors and the analysts’, and your scale and theirs, the worse the map is for your needs, and the worse the solution you select will be.

The only maps you should care about are those that rank solutions solely on the tech capabilities and/or the customer rankings. But only so far as potential solution identification, not selection. Maps that concentrate on pure tech (like Spend Matters Solution Map) allow you to identify vendors that have the tech foundations, giving you a starting pool, but don’t allow you to identify vendors that have a solution — because a solution is tech and appropriate process support and integration capability and support and culture and whatever else transforms another piece of potential shelfware into a solution that will be used daily by your employees.

Note that we used the word “potential” for a reason. No map (including Spend Matters) is complete, so you will need to look at multiple sources (like ProcurementSoftware.site and the upcoming Art of Procurement ProcureTech 100) to put together a complete list of vendors to consider. Then you will have to cross reference with real analyst vendor write-ups (which can include the hundreds of write-ups here on this site if one or more of your potential finalists are included) to whittle down that list to the best starting set for your best practice technology RFP (of which we have a lot of advice on how to write that on this site as well).

At the end of the day, it’s about what solution will work for you, not about which solution is on which map!

Your RFPs, That Go To the Wrong Vendors, Suck Because CONTEXT MATTERS!

We briefly covered this in our post on how There are No Simple Answers Because CONTEXT MATTERS, but we feel we have to call it out and cover it again in its own post because, over the past few weeks, the doctor has

  • been asked multiple times for a list of the best vendors for X that just need to do A, B, C
  • been told that Gen-AI can help a client write better RFPs (and that he would like to see the new Gen-AI capabilities in the sourcing/procurement/services/contract management application, which, FYI, he wouldn’t)

when the reality is that:

  • there is no way he can give a short list of relevance without understanding at least the
    • company size, geography, and industry
    • existing S2P/ERP ecosystem and maturity
    • primary pain points

    because

    • company size can dictate minimum vendor size; geography presence, language, or cultural skills; and industry key capabilities that a platform will need
    • unless it’s a rip and replace project, the new module/solution will have to play in the existing ecosystem
    • and nothing defines what is needed more than the pain (not a random list of features that the buyer doesn’t really understand and just assumes will solve their problem)
  • as we have repeatedly explained, there is no Artificial Intelligence, Gen-AI is as dumb as a doorknob, and it doesn’t write better RFPs (although it may write better English) — not even close

Now, we really want to dive into this second point.

You can NOT write a good RFP if you don’t know:

  • what your pain points are
  • why you have them (i.e. process, system, and/or data issues)
  • where gaps need to be filled in your current system landscape (and what that landscape is)
  • how advanced your employees are in their TQ (Technical Quotient) and Procurement maturity
  • who will be using it and for what
  • when it is used in workflow-based processes

And, guess what, Gen-AI doesn’t know that, and doesn’t even know how to elicit that. For an RFP builder to be useful, it has to help you gather this. Which means experts need to encode it with methodologies and questions to elicit all this. Only then can Gen-AI LLMs be used to actually construct an RFP in natural language. So if all the vendor has is a nice shiny LLM wrapper, they have nothing useful. Remember that.

AI Employees Aren’t Real! Don’t Believe The Lunacy!

This should be so obvious that it shouldn’t need to be said, but with multiple companies still promising to (soon) deliver “AI Employees”, it apparently needs to be said.

First of all, why it should be obvious:

  1. There is no Artificial Intelligence. The tools are as dumb as a doorknob. The best you can get is Augmented Intelligence, which, by the way, is what you really need because it can provide almost instantaneous insights that would take a traditional analyst with traditional tools days to weeks (or months) to discover.
  2. An employee is a person. A PERSON! Not a piece of software.
    (As we don’t have AI, we don’t have autonomous robots, so we can’t even have the theoretical argument about whether or not a robot should be recognized as a person for legal means.)

Secondly, we’ve already seen how autonomous software agents don’t work (because they are not intelligent or people). Klarna, one of the first companies to fire the majority of its customer support team with the false claim AI can do that, quickly found it it really can’t and now has to hire back hundreds of support agents because what AI was really doing was the work of 700 really bad agents! And their customers didn’t want to talk to these bots (essentially because of how dumb and useless they were).

Thirdly, there have been no, and nor will there be with existing algorithms, stacks, and technologies, any magical emergence that will suddenly allow these “AI agents” to become intelligent and be able to perform their tasks autonomously. Because

  1. if Neural Networks were the right models, today’s models (constrained to commercial compute capacity) would put them on par with a pond snail, maybe a sea slug;
  2. compute power doesn’t double year over year anymore; Moore’s law is quickly becoming a historical footnote due to quantum limits; and
  3. there’s no more data to train them on — the big AI tech plays have already illegally stolen all of the copyrighted data on the internet, and that’s still not enough (and AI generated data just worsens performance because it’s not real, or good, data).

Moreover, we don’t need AI Employees. What we need are more productive employees! Employees that don’t waste up to 80% (or more) of their time doing more-or-less nothing but data wrangling trying to turn data into knowledge and knowledge into the insights needed to make a decision. Tasks that are purely tactical calculations and conversions that are precisely what computers were built for. Computers can do trillions of calculations a second error free, while we can only do a few, and not necessarily error free.

Which means what we really need are Augmented Intelligent Agent Assistants that do the computational tasks we need done and either

  1. automate processing that we would do almost thoughtlessly if we determined that the appropriate conditions were met or
  2. present us with the data, knowledge, and insights we need to make a decision and take action, including suggestions for that action if there are standard response patterns

Because, when the 80% time wasting tactical data processing is taken off of our plates, we will be at least 5 times as effective with these Automated Intelligent Agent Assistants, and that is what will propel organizations forward. Not dumb tech, and definitely not false promises of fake AI Employees that do not, and fundamentally cannot, exist.