Buyers Are Not Process Operators!

In a LinkedIn post from a while back, Garry makes a very important point: many procurement operating models still treat buyers as process operators.

Run the event. Collect the bids. Populate the template. Push it through governance. Negotiate hard. Close the file. Move on.

Tech (which may include AI but doesn’t need to as you can do quite a lot with ARPA and do it better, faster, and cheaper than humans AND Gen-AI can do it) will make the traditional buyer role less central because all of this, except for the finer points of negotiation, can be done by the tech. (The brute force points, collecting all the data to defend your offer can be done by the tech.)

Once you adopt Busch-Lamoureux Exact Purchasing, it becomes easy to not only map your categories to the octants, but identify the processes you should use for sourcing and procuring those categories, as well as monitoring the procurement activities to determine if there is a situation where a human has to intervene.

It also becomes clear what you need to do at each step.

  • Sourcing: identify what needs to be sourced vs procured, what categories and items will be included in an event, what suppliers, what products, what requirements, etc. etc. etc. — all of the decisions you can’t risk automated (which can still only be automated from encoded knowledge from prior decisions)
  • CLM: key contract requirements and acceptance criteria; etc.
  • SXM: key (compliance) requirements, key risk mitigation clauses, need for no vs. internal vs. external review, etc.
  • Analysis: historical spend/volume/prices; current prices/volume requirements; predicted prices/volume requirements; opportunities for demand shaping/control; etc.
  • e-Pro: available channels and under what conditions; what gets in the catalogue; who can buy out-of-catalogue/non-preferred; processes for overrides (to budget limits; cost limits; etc.)
  • I2P: m-way match requirements and tolerances; ok-to-pay / auto-pay requirements; when early-payment discounts can be offered/applied; etc.

As Garry states, a buyer is not a buyer — a buyer is a decision architect and makes the decisions necessary for successful Procurement. A decision architect that designs how a decision should be made. An intelligent human who maps the organization’s categories to the pocket cube of Exact Purchasing, determines what can be automated, what systems will be used to automate, what qualifies as exceptions, how those exceptions will be monitored for, and how they will be alerted.

But a buyer is more than that — it’s a decision architect and relationship management. Procurement is about managing stakeholders and suppliers. Dumb systems cannot do that. Only HUMAN INTELLIGENCE can.

In an AI-Hype world, Procurement will be measured on its success, and that success will require Human Intelligence leading Procurement to glory. So acquire real pros if you want to not only survive, but thrive in, the Age of Retardation the AI-Hype is ushering in!

Are they 2026? Or 2016? Or 2006? Procurement Trends? Part II

Tom Mills recently posted a Top 10 Procurement Trends in 2026 post on LinkedIn that made me ask Really? Basically, I’ve been reading, and writing, about the majority of the “trends” for two decades. As per my recent 34-part series on you don’t need to read another state of procurement report for five years!, nothing has really changed in the last five years. In fact, not much has changed in the last ten, if not twenty, years. All that ever changes is the tech-du-jour, which particular risk is the most prominent, which particular process is the most recommended, and whether the trend is in-sourcing solutions, out-sourcing solutions, or hybrid models.

To make this oh-so-clear, we’re going to conclude Tom’s list and provide some colour commentary!

6️⃣ AI Becomes Core but our Readiness Lags

This is the only “sort of new” trend, except it has been the “sort of new” trend for three years now, but when you realize “AI” is the “tech-du-jour”, you realize that, again, nothing has changed for the past two-plus decades because the “tech-du-jour” is always the 10th trend. And for every
tech-du-jour that becomes core, our readiness lags. Over the past 25 years we’ve had these five tech-du-jours (that tend to last for around 5 years).

  • WWW
  • SaaS
  • The Fluffy Magic Cloud
  • Predictive Analytics
  • AI

7️⃣ Data Quality and Governance as a Prerequisite

For all advanced tech, data quality has ALWAYS been central and paramount. Ever since the introduction of optimization, and in our space, strategic sourcing decision optimization (SSDO), data quality was key. With traditional (MILP) optimization, one value in one million can tank an entire model (because if a decimal point error makes one product 50X cheaper, then the allocation will obviously go to the wrong supplier). Moreover, if there are capacity constraints, minimum allocations, maximum supplier counts, etc., this will result in cascading incorrect assignments and allotments across the entire model. Then came should cost modelling, and again, without good data quality and governance, it didn’t work. Then spend analysis, which needed proper market baselines. And now AI, which is garbage in, hazardous waste out. Even with perfect data you can still get hallucinations, so you definitely don’t want even the slightest error!

8️⃣ Orchestrated Procurement Ecosystems

In Procurement, which has NOT fundamentally changed since the first manual was written 139 years ago, the story remains the same — only the names have changed! AI may be the tech-du-jour, but orchestration is the term-du-jour. But it’s not new. The automated coordination, management, and sequencing of multiple distinct processes, systems, or components to achieve a unified, higher-level goal has been a goal of Procurement for decades — except back in the 2000s the term-du-jour was “metaprise”. (And Jon W. Hansen can also fill you in on the history here.)

9️⃣ Talent as the Transformation Multiplier

We’ve been talking about this for decades. I wrote a 7-part series 20 years ago when I first started SI. Talent is not only necessary, but it’s the way you truly succeed. Talent that designs better processes, selects better technologies, and, most importantly, makes better decisions that allows the organization to be more strategic and more effective is not only transformation, but a transformation multiplier.

🔟 Procurement as an Enterprise Value Driver

Ever since AMR first started covering the space in the early 2000s, we’ve been told that Procurement is the Enterprise Value Driver. That strategic sourcing, when utilizing the right technology (namely optimization and analytics) would consistently identify year-over-year savings of 12%. That m-way matching, which ensured the payment matched the invoice matched the PO matched the contract would prevent (often unrecoverable) overspend. That spend analysis can identify real value drivers. The whole space was defined as a value driver. Nothing has changed.

The GruntMaster 6000 was engineered for longevity and has a long memory. And his long memory tells him that the more things (are purported to) change, the more they stay the same!

Are they 2026? Or 2016? Or 2006? Procurement Trends? Part I

Tom Mills recently posted a Top 10 Procurement Trends in 2026 post on LinkedIn that made me ask Really? Basically, I’ve been reading, and writing, about the majority of the “trends” for two decades. As per my recent 34-part series on you don’t need to read another state of procurement report for five years!, nothing has really changed in the last five years. In fact, not much has changed in the last ten, if not twenty, years. All that ever changes is the tech-du-jour, which particular risk is the most prominent, which particular process is the most recommended, and whether the trend is in-sourcing solutions, out-sourcing solutions, or hybrid models.

To make this oh-so-clear, we’re going to review Tom’s list and provide some colour commentary!

1️⃣ The CPO as Enterprise Architect

Back in the first major age of responsible sourcing in the early 2000s, the message was that the CPO had to be an enterprise architect to be responsible. To make this abundantly clear, SI did a 12-part series on the “Responsible Sourcing Supplier Workbook” released by the John Lewis Partnership which was the best example of how Procurement could architect a responsible enterprise!

2️⃣ Procurement as Business Storyteller

I remember going to Ariba Live a decade ago, and they opened with the SAP Storyteller. The reason – their solution (which never fully integrated Procuri that they had bought almost a decade prior) was going on 15 years old (while Coupa was still revolutionizing its platform and telling its own tall tales and BravoSolution was acquiring like mad [just before it became Jaggaer]) and there was less and less reason to buy Ariba’s outdated tech … until they told the whole story of what was possible when Ariba was fully integrated in the SAP ecosystem (and what could be possible — forget reality, just believe and buy).

3️⃣ Strategic Supplier Partnerships over Transactional Buying

State-of-Flux (SoF) was founded 24 years ago because strategic supplier partnerships were the key to success! Aravo (US) and SoF (UK) were the first to recognize this and this message has been consistent for decades, coming into the forefront whenever significant supply disruptions occur due to natural, or man-made, disasters. This goes back to the 80s when the recession, plant fires, and the lingering after-effects of the 70s steel crisis led to part shortages and cost hikes that could (only) be mitigated with strategic supplier partnerships. This situation reared its ugly head again as the web, and SaaS, exploded, we had new semiconductor (and RAM) shortages due to demand (and plant fires), multiple man-made and natural disasters had global consequences (9/11 attacks, Indian Ocean Tsunami, Hurricane Katrina, etc.), and market losses surged (dot com bust, 2008 financial crisis), leading to the rise of SXM software as a key category in Procurement in the early 2000s.

4️⃣ Outcome-Based Procurement

That’s the whole point of GPOs. Outcomes is only the price model du jour because the AI vendors couldn’t sell their solutions using a SaaS model with true cloud computing costs being passed on to them by their hosting (and AI) providers! So they have to convince you to buy into their “outcome”-based model. (And that’s why, now, outcomes is a dirty word.)

5️⃣ Strategic Supplier Risk and Resilience Orchestration

Aravo was founded in 2000 to do this. I remember writing about them back in 2007, and Google was one of their early adopters.

To be continued …

Fastest Freeway to Financial Failure? Gen-AI!

Not joking here.

First of all, AI is getting more expensive for coding.

Input-output token pairs, which used to cost pennies per M tokens, are approaching $100/M for high-end models.

An average enterprise app starts at 100,000 lines. It will require 2M output tokens for initial output. It will take at least 5 iterations to get code good enough for the devs to even begin to work with, or 10M tokens. Then you will have to test and debug, figure another 5 iterations, or 20M tokens. But this doesn’t include the context history or coding samples required to produce a baseline, integrate a security framework, or account for multiple service-based deployments. This will consume an additional 10X to 30X the token count, and you will require 40M to 80M tokens to produce the app along with an experienced team of senior developers who will have to shore, as only 20% of AI-generated code survives unscathed. And then comes the testing, debugging, and QA. This could double the token requirement again.

For coding, which requires about 20 tokens per line, it would, in theory, only require 10,000 tokens to produce 5,000 lines of code, which is the net-new production code you’d expect from a senior developer every year, but given that it will require at least 5 iterations to get something to start with, and then all the updates to get it to testing and then all the testing and debugging, that’s at least 50M tokens as per above — with prices expected to rise (and possibly double) by the time you’re done (at the current rapid rate of token cost increase), or $10,000 to $20,000. Not bad in theory, as a senior Dev costs you 10X to 20X that on the low end, but …

As we said before, only 20% of AI code ends up being usable, so you still need a team of devs to review it and fix the major bugs/issues. With 80K lines needing correction, and a top dev only producing 5,000 lines of net new production code a year, you would still need 16 devs. That’s still expensive. You might realize that you only need to fix the critical issues to get your MVP out the door, and cut the team in half because you can stagger the reviews and fixes to issues. And while you think you saved the cost of 12 devs …

As time goes on, you realize there are fundamental flaws in the code. The security framework it chose was an old framework off of an abandoned Github code branch that used a lot of methods and procedures that were already marked for deprecation in the next framework release, which hit as soon as you released your code. They all have to be redone. The “multilingual” support is clumsy and requires the manual production of very carefully crafted fixed format text files. The workflow is rigid and not malleable. You wanted it AI friendly, but it doesn’t properly support MCP. And so on.

Then, like so many enterprise app startups are finding, you can’t scale the MVP into enterprise quality, have to scrap it, and rewrite if from scratch. Which means the 10K to 20K in LLM cost and the 800K to 1600K + in minimal dev support cost to get the MVP up and running in a production environment was all wasted — most of your seed money went up in smoke, and you have to start from scratch.

Second, its performance is much worse for trying to correct/update existing code where it has to ensure all unit, functional, user journey, workflow, and integration tests still work. This is evidenced by the fact that many companies, like Uber are now blowing through their annual AI budgets in a quarter. Engineers trying to rely heavy on AI are already spending 2,000 a month! Backtracking the math, it’s easy to see that the amount of project code, documentation, and online (GitHub) samples it has to ingest and compute to create an output, that might not even be 20% acceptable on the first few passes, is astronomical!

Plus, as we’ve explained before, when a dev has to correct up to 80% of the code, you’re losing on the efficiency improvement if a dev is spending 20% of their salary to get you that 20% increase in code lines which, as we’ve also explained before, is still of a worse quality than if that senior dev had wrote it by hand, that’s not a savings. That’s, at best, net 0.

However, this isn’t taking into account that it will likely have to be refactored or written out in very short order. You won’t get the median 2.5 to 3 year lifespan for a small app or 5 to 7 years for an enterprise framework, you’ll get 0.5 to 1 year — which means you’ll write and re-write each line of code three times as often with the use of AI. Or, in other words, you’ll inadvertently spend three times as much on that code! And your customers won’t pay 3 times as much for an app just because you spent three times what you need to, so bankruptcy will be just around the corner!

Third, it is getting infinitely more expensive for any document processing with a legal ramification.

Judges are now fed up with AI hallucinations and slop. Include AI hallucinations, and you’re getting fined at a minimum, and probably sanctioned.

Even worse, if it takes out a risk mitigation clause or creates an unforeseen risk you didn’t catch, a failure could cost you (hundreds) of millions of dollars that you would have otherwise been protected against if an experienced lawyer had written the contract for you.

Fourth, it’s making us physically AND mentally sick.

The cognitive atrophy is becoming well documented. People aren’t remembering what they wrote even an hour later when they use Gen-AI. They are being lulled into a false sense of security and accepting its outputs, even when those outputs are false and dangerous to their health (and tells them to effectively commit suicide). (But go ahead, eat that poisonous mushroom. The one rock a day it told you to eat will protect you, right?) Average decline in mental acuity and performance after regular use is 17% (which effectively equates to a loss of 17 IQ points. In comparison, it took us almost 120 years since the Victorian age [before we had industrial revolution technology to make our lives easier or media to dumb us into submission] to lose 14 IQ points). It’s making our society mentally sick!

Moreover, given how much energy and water a modern data centre consumes annually (100MW for a hyperscalar site or an amount of energy that would power at least 10,000 greedy American homes for a year) as well as how much water it consumes for cooling (100M+ G, assuming it recycles efficiently, or easily 200M+ G if it doesn’t, which would meet all the water needs of at least 5,000 of those homes per year, if not all 10,000), when energy and fresh water is becoming in scarce supply in first world countries, we’re jeopardizing the well being of 10,000 people for every unneeded AI data centre that we build. Given that there are now about 11,500 data centers consuming about 2% of planetary energy and likely between 0.1% to 1% of available fresh/drinking water, that’s a lot of energy and water being wasted to produce cr@p code and poor documents that can often be produced better by interns*. Especially when, in energy or water stressed areas, these data centers take systems to the breaking point and risk our health due to lack of necessary heating, cooling, bathing, and/or drinking water.

But, even worse, since this energy often comes from grids powered by dirty coal and oil, and the water extracted from desalination plants also require energy from those same grids powered by dirty coal and oil, they are polluting the environment to a significantly measurable degree as they account for somewhere between 0.5% and 1.0% of global CO2 emissions. With the global slowdown in shipping thanks to all the conflicts in the Red Sea and the Strait of Hormuz as well as the lack of water (due to less rainfall) in the Panama Canal, and the rampant increase in Data Center construction, data centers will soon account for more CO2 production than global (unregulated) shipping, which is the dirtiest industry on the planet. That’s NOT good for our health!

* There’s a reason Builder.ai was successful in its efforts to pass off human-written code as AI for over 7 years. Human produced code actually works! Even hastily written shoddy code works better than AI generated code by orders of magnitude!

The Mythical AI ROI!

A few companies claimed ROI from AI. (About 6% if you believe McKinsey or 5% if you believe MIT.)

And by few, we mean a few. One in twenty (1 / 20) is not a lot. And that’s just some ROI, not amazing ROI. Not necessarily enough to justify the elimination of even a single human (that you had hoped to replace), as that human is still generating more ROI than the BS AI you were sold (and making decisions at a much higher success rate).

There’s only one way to get true AI ROI.

1. Stop believing in Artificial Intelligence, realize all the vendors claiming it are only offering Artificial Idiocy, and that the best you can get is Augmented Intelligence.

Repeat

2. Identify a major problem that is hurting.

3. Use your Human Intelligence (HI) to map the current, and required, workflows end-to-end.

4. Identify all the manual steps that could be automated with the right data.

5. Do the hard work of identifying where all the data is, implementing a data orchestration platform to collect it all, and make it forward deployed everywhere it is needed for task automation.

6. Automate each step with the appropriate (A)RPA tool.

7. Implement a workflow orchestration platform to connect all of the steps together to the extent possible which ensures everything that can be automated with the automation and orchestration tools is once the intelligent human provides the right inputs and makes the right decisions.

8. Analyze where humans are still involved and where human inputs and/or decisions can be further automated through the integration of additional (external) data feeds and encoding of the (business) logic the human always uses to make the decision.

9. Analyze what’s left and determine where “AI”, even with a poor accuracy rate and hallucinations, could be helpful to an intelligent human making decisions and acquire small, focussed, specialized model licenses only for those steps.

10. Ensure Augmented Intelligence, connected to your forward deployed data, is available everywhere Human Intelligence (HI) requires it to make a decision.

until all major problems solved.

One by one. Put the effort in once, do it right, and with modern tech, you’ll never have to do it again.

You only win with AI when you’ve first centralized, validated, and forward deployed your data; implemented deterministic (adaptive) robotic process automation everywhere you can, and identified precise use cases where custom solutions actually provide a benefit (and not just a fairy-tale promise).