In a recent Procurement Insights posts, THE REVELATOR tells us that a 2007 challenge is finally being addressed in 2025, and he’s right in that it’s being addressed, but parts of the problem are still not being solved. But before we can dive in too deep, let’s review the four points from his 2007 post on the Change Management Myth.

The core of his eighteen year old post was the statement that many failures stem not from resistance to change itself but from deeper systemic issues in how technology is deployed, which is often the case because, when the system selected is the one with backing from the core team, there is obviously some desire to change, but something is preventing that change from happening. Based on interviews and discussion with third parties, including one with a professional who had over a decade of public sector Procurement system implementations at the time (remembering that the first procurement system only went live twelve years before his post eighteen years ago), he identified four key reasons why automated procurement systems fell short and resulted in poor adoption and outcomes.

These four reasons were:

• lack of technical savvy and cultural understanding
• procurement module was an ERP afterthought
• lack of process mapping/improvement before automation
• discrepancy between promises and delivery

While technology has improved greatly, as far as I’m concerned, two of these still aren’t being solved because the technology that is addressing the issues are not solving the fundamental problems. In THE REVELATOR‘s post, he points to an AI-powered “digital team member”^* agent solution (and one custom built for the SAP ecosystem) as an example of a technology that addresses the four problems (but we will not name it as we don’t want to be negative on a particular technology that does offer some value to customers in Ariba jail). Our goal of this article to address the statements he is making and the fundamental requirements to solve the problems that still plague our space).

According to THE REVELATOR, each of the problems are addressed for the given reasons:

• lack of technical savvy and cultural understanding because these platforms minimize the need for advanced skills with conversational interfaces and email integrations that don’t require extensive training and that “implicitly teach the why” by delivering immediate value
• procurement module was an ERP afterthought because this technology is purpose built for procurement, enhancing the across-the-board experience by implementing and supporting “best practice” out of the box
• lack of process mapping/improvement before automation because it inherently improves processes by AI-triage, prioritization, and workflow embedding while analyzing data in seconds, eliminating manual entry, and supporting iterative testing
• discrepancy between promises and delivery because seamless integration allows for instant impact, results, and measurable ROI

And each of these approaches is an approach that addresses the problem. However, it does not solve two of them, and that can lead to even worse errors being made then before. Namely, it doesn’t do anything for:

• lack of technical savvy and cultural understanding because guiding a person through a process, which is the one statistically estimated (i.e. guessed) to be the correct one, does nothing to address their lack of technical savvy or Procurement understanding, and, in fact, if it makes the process too easy or, on the easy test cases, gets the process too right, it leads the user into a false sense of security, just like vibe coding (which results in over half of the code being produced having serious security issues) or vibe physics (which sometimes results in delusions and sometimes even early stage “ChatGPT” psychosis), except in this case the user will happily authorize a million dollar purchase for the wrong product if the system doesn’t detect it’s the wrong product
• lack of process mapping/improvement before automation is not solved by slowly “learning” processes post implementation, and letting the system guide you on “corrections” because probabilities are not certainties, and if you don’t do pre-implementation process and data mapping, and understand the state of your data (and, if necessary, cleanse and enrich it), the system could make very wrong decisions (because it can only compute on the data it has, and if that data is bad, the recommendations will be very bad)

Not only does too much AI not solve the problem, but it actually exacerbates it. While we do want Augmented Intelligence, we want carefully designed, selected, evaluated, and implemented Augmented Intelligence where we can have very high confidence in everything it does because we pre-verified it, understand its limits, validated its data, and never apply it inappropriately. Plus, we want it to support our thinking and analysis, not have us support it when we have no clue where it’s coming from.

At the end of the day, we want better educated and trained personnel, because then they will know what tool to use where, how reliable the answer will be, and when a process can be fully automated vs. when you need manual checks. And then we want to give them the technology that makes them up to 10 times as efficient at their job by automating all of the tactical data collection, processing, analysis, and summarization so they can review everything they need to make the right decisions, select the right options in the system, and then have the system automate the tactical processes that come after. That’s not being guided by AI, that’s guiding the AI. That’s not just a semantic difference, it’s a significant process difference that can have a significant impact on Procurement efficiency and effectiveness.

^* Let us remind you that AI Employees Aren’t Real!