You Don’t Need AI and Agents. You Need Solutions That Solve Your Problems.

In our last two posts we told you that not only is AI and Agent(-based) tech not new, because:

  • AI, which really stands for “algorithmic improvement”, is at least 69 years old (and is just the label that is slapped onto every algorithm that was, and is, slightly more advanced than the algorithm that came before)
  • there’s fundamentally no difference between RPA, that we’ve had since the early 90s, and an “agent”
  • the “orchestration” hype machine is not new either, not even on the web; WWW: 1989; CORBA: 1991
  • all automation is based on workflow, a concept that dates back at least until 1921 and was found in early MRPs in the 1970s

but that:

  • slapping an LLM-powered chatbot doesn’t make it innovative or new,
  • you need a solution, not a platform for building one (and that’s all you get with these new Agentric AI startups), and
  • you shouldn’t pay for the privilege of developing a vendor’s solution for them (as that is what you are paying them for)!

At the end of the day, you need a solution that aligns with Procurement’s needs. And if the vendor is not capable of providing such a solution that has already been built and demonstrated in real companies to solve the problems you need to solve, then a Procurement department shouldn’t even be talking to the vendor (and definitely should not let them participate in an RFP).

Right now we have technology failure rates at an all time high. The last major study (from Bain) puts them at 88%, but there are plenty of indications (from multiple smaller, less reliable studies and statistics from smaller consulting firms called in to analyze a situation after the fact) that the rate could now be as high as 92%. That means you have roughly a 1 in 10 chance of succeeding with your ProcureTech project, and your chances go down if you choose a vendor without a suitable, proven technology.

We have to stop being blinded by the hype constantly shoved at us by the AI and orchestration players and go back to basics. Define what we need, how it has to support us, and evaluate existing stacks against those requirements. Design appropriate RFPs that focus on actual process needs, not feature functions; enhancement of existing ecosystems, and not full blow replacements (as big-bang implementations always result in big booms, and have caused about half of the greatest supply chain failures of all time); and critical system and data feed integration against your existing, not just general capability.

Script the key requirements for demos and ensure that the first demo demonstrates all of the requirements before they make the cut for the second, where they can tackle the nice-to-have requirements and show off their unique capabilities.

Ensure that there is a well thought out and laid out implementation plan that clearly lays out who will do what, when, and what is expected from the other parties at each phase, and when the necessary requirements need to be met. Specifically, what resources will be needed from you, when, and for how long. What APIs / integration access points will be needed, when, and how will testing be done. What IT resources will be needed to support. If a third party is being used for the implementation, what support will they need from you and the vendor and what commitment is there that the vendor will provide all the necessary support on time and respond to the SLAs if something goes wrong?

And ensure you have a project assurance plan in place with a third, or fourth, party helping you manage the vendor(s), manage the project requirements on your side, and keep all parties in lock step. And you need to make sure you budget for this, because it won’t come out of the vendor’s budget. (But since the #1 goal of the vendor is to make their numbers before the investors kick the sales reps and/or the management team to the curb for not meeting unrealistic expectation, you can’t rely on the vendor to ensure everything is to your liking.)

We have to remember that, these days, too many Procurement solution providers are treating the market as a necessity (or a luxury). If I’m hungry, and you’re the only one with food, then, since I need to eat, I have to adapt to what you have. (And if I’m rich, then I need to be cool and therefore must need to eat at your five star restaurant to be cool … )

This is despite the fact that NO company needs ProcureTech! Even though it has existed for over 25 years, many companies are still functioning without it today. (And some have functioned without it for 25, 50, 100, or more years.) While they are worse for wear running off of email, Excel, and decades old ERP, especially compared to their peers, the fact that they are managing, somehow, proves that they don’t need it. They want it because they know it will make them more efficient and effective, but they don’t need it. But vendors have forgotten this, so ProcureTech departments should take the time to remind them during the process that they’ve survived X years without it, so there’s no reason for them to rush the process until the vendor has proven they are the solution.

Which means that a Procurement should ONLY buy ProcureTech IF it makes their life better, and that they should only buy from VENDORS who have existing tech that makes their life better. It’s the job of the vendor to build this tech and demonstrate that it works, NOT the buyer. A good vendor with solid tech who has been building that tech for half a decade or more will easily, and happily, do that, while a new startup with nothing but a low-code platform that cobbles together random LLMs/LRMs won’t be able to (as they have to “develop” it with you). Choose the former.