Category Archives: Decision Optimization

“The Suite Was Supposed to Settle Everything.”

This is a requested response to Paul Marty’s inquiry: Is Source-to-Pay Dying.

We’ve heard the “one app to rule them all myth” since the late 60s when IBM said the MRP would control the operations and no other app would be needed. This was rekindled in the mid 80s when Oracle said the ERP would control the organization and no other app would be needed. Then in the late 90s when the web would provide a common interface to everything. Then the late noughts / early tens when the Suite would solve everything. It’s the myth that keeps on giving.

The reality is that any new monolith application model only solves all the problems that came before, not the problems you have now, and not the problems that are coming.

That doesn’t mean suites don’t have value, or that suites won’t provide more value than any other alternative, just that it’s not a panacea. Determining whether it provides more or less value requires understanding the true total value realized (taking all costs and benefits into account) compared to the true total value of the alternatives, many of which are unproven.

“Is The Economic Value Moving Somewhere Else?”

First off, let us note that, fundamentally, the new AI orchestration craze is no different, as it ultimately depends on a protocol that can bind everything together. This isn’t new either. Remember CORBA? Probably not, as most of you probably don’t even know what it is. Look it up. At the dawn of the dot com era, it was going to solve everything. It made all the same promises MCP is making now.

The reality is that the fundamental truths of technology have not changed.

> If it sounds too good to be true, it is.

> Technology can’t advance any faster than discovery (either mathematical computing theory or practical scientific discoveries that allow for new engineering that can build better machines to support better models), and that has, and will, always be slow. How many hundreds of thousands (or millions of years) has it taken us to compute a theoretical warp bubble, and how many decades/centuries more before we can achieve it? (We’ve went from conjecture with the introduction of Star Trek 60 years ago to theoretical possibility 5 years ago … but now we need to create the energy source, the materials that could withstand it, etc. etc. etc.)

> … businesses not only need to make money every year, but are punished by the capitalistic economy if they don’t; so even if all they have is the same old sh!t, they still need to sell it, and the best way to do that is to slap a new coat of paint on the old Mustang and tell you it’s a brand new model (even though the engine hasn’t changed in almost a decade)

This doesn’t mean that AI orchestration doesn’t provide value, just that it’s not the ultimate answer and that you have to truly understand it’s true cost vs its true benefits and, where autonomy is granted, true risks before you can make a decision.

“What if the employee does not need to enter the procurement system at all?”

That doesn’t change the fact you still need a procurement system.

Just because an intake layer can work across applications, and just because an AI agent can complete a routine workflow without ever displaying the myriad of screens suite vendors spent years (if not decades) refining, that doesn’t mean that the core functions go away. Either those have to be part of the intake/orchestration system (in which case it’s really a suite with a new kind of interface) or you still need the underlying best-of-breed / suite systems, which are only accessed through their APIs.

In the latter case, the true economic value remains in the best-of-breed/core systems … and the only value of the intake/orchestration/AI agent is the cost of user time reduction (i.e. 5 FT AP agents to manually process all the invoices vs 1 FT AP agent to manually deal with the exceptions). So if the cost of the software is greater than the manpower saved, it’s negative value.

This assumes that the agent is deterministic and will do all processing according to user defined rules and in user defined bounds. If you are using LLM-powered agents and giving them autonomy, there is no guarantee they will follow all rules and stay without bounds — autonomy means that they can decide only 10K over their approval limit is ok because it appears to be a known supplier, onboard an uncertified supplier, issue a new PO to a supplier who is late on other critical deliveries, etc. which can result in significant losses.

Which brings us to the most important question:

“ONE INTERFACE > MANY SYSTEMS > WHO DECIDES?”

This is a key question for multiple reasons:

1) You can’t cost / benefit a system without knowing.

As above, if the decision is ultimately human, you can accurately cost the system and determine it’s fixed (workforce reduction) benefit as well as it’s expected benefits from (weighted) average results and track true benefits over time.

But if the decision is ultimately the system, you can’t truly estimate the benefits as you don’t know what it will do, how many mistakes it will make, and what the cost to clean them up will be — and if it uses LLM technology, you can’t even cost the system as you don’t know how the token/compute cost is going to increase over time as you don’t know the token growth that will be required or how soon you’re going to have to pay true compute costs (the big AI companies can’t keep losing $4 for every $1 of revenue, and with today’s energy and water costs, the true compute cost is about 5X what most of the players are charging … and this will only increase over time.)

2) You can’t quality control without absolutely knowing who decides what, what the range of options are, where, and how to encode the checks.

Which means that:

“THE CENTRAL QUESTION … IS WHO OWNS THE REASONING THAT DETERMINES WHAT PROCUREMENT SHOULD DO”

Especially when the answer to:

“Are Twenty Agents Really Twenty Opinions?”

is NO!

I know Jon W. Hansen might disagree with me here, since he uses multiple systems to arrive at his (starting) algorithmic analysis of the marketplace regularly, but agents reason off of the data they are given.

When you interconnect them, they share “data” and “reasoning” continuously. Also, even though they are ultimately sophisticated probabilistic models no human can fully understand, the core is similar to deep multi-level feedback neural networks. This means that common “data” and “reasoning” increases the weighting on that “data” and “reasoning”, increases similar output, which increases similar input to the minority models, which causes that “data” and “reasoning” to become more heavily weighted in them. Or, in simple terms, a majority of agents will bully the minority of agents into their viewpoint until there is one opinion, not twenty.

Even if all 20 agents start out different, as they share “data” and “reasoning”, there will be some commonality, and as the “data” and “reasoning” flows back and forth, the weighting of the commonality will increase until it snowballs into a majority, given enough exchanges (over time).

While some “experts” will try to tell you this all but certainly guarantees you will get the best results once the agents agree, that is ONLY true if the common “data” and “reasoning” is accurate. Some agents will have bad / fake / hallucinated (wrong) data and others will share faulty “reasoning” because they don’t actually reason. (They predict arguments … think of them as a super powerful fancy version of next word suggestion on your iPhone, except they are predicting answers to questions and sometimes even the steps involved to get there!)

While individual agents sometimes work well if they have enough raw question/answer input/output previous step/next step data top work from (and that’s how they create mathematical “proofs” — they can scan millions of research papers and proofs, build up all the associations as input/output pairs, and then see if there is a way to chain them all together from a question to an answer where the output of one step in one paper is the required input of a step in a paper in another paper, possibly published in an unrelated journal in an unrelated discipline), they sometimes don’t work very well at all!

They’ll tell you to eat one rock a day. Or that strawberry only has 2 rs. Or, because they don’t understand reality, when asked, they will tell you that “the woodchuck could carry 57,600 pounds of wood in a day” when asked “How much wood could a woodchuck chuck if the woodchuck was 10 lbs?” (I didn’t make this up, DeepSeek did!) (And, even worse, it gave some extremely ridiculous “reasoning” to back it up which might fool someone who didn’t think twice because the logic was pretty good, while the data it worked on was ridiculous [and obviously hallucinated]. I should also point out that this was a result “I” totally expected because there shouldn’t be much “data” on “how much wood a wouldchuck could chuck if a woodchuck could chuck wood” on the internet [which is it’s training data], because we all know a woodchuck can’t chuck wood but the AI doesn’t know that.)

Thus, whether you use one agent or twenty, you will get one opinion, and one result, which could be a total hallucination if none of the systems had enough correct “data” and examples to “reason” on.

Given that, as Paul Martyn points out, the best decisions are made when there is

  1. A diversity of experiences and information to draw on
  2. Independent thought by the participants (that can provide truly different views to the ultimate decision owner)
  3. Decentralization of knowledge for risk mitigation

and that today’s AI, which is NOT intelligent, cannot be trusted to always make the best decision as

  1. all agent systems have access to the same data on your network and the web
  2. agents cannot think, only produce “outputs” based on different weightings of “inputs”
  3. agents with minority data/reasoning can, and will, have at least their reasoning, if not their data, overwritten by the majority

This brings us to the following conclusions:

1. Traditional Suite and BoB solutions ARE still needed, even with orchestration and agents (especially since the later should be restricted to either fully deterministic processes or processes where the cost to fix/clean up after an occasional bad decision by software is less than the cost of having a team of people do that process manually)

2. The New Hotness Hype will always take sales away from established players, as the lazy and greedy look for that panacea solution that does not, and cannot exist … but when those solutions fail to achieve the result, some of those sales will return (as the only other option will be to build the missing parts into the acquired system, and why waste money trying to extend a system that’s fundamentally broken?)

3. “The Market is Not Dying”, as Paul Martyn states, but it is shifting. Suites will become the transaction engines and systems of record in organizations that experiment with new interfaces, orchestration, and AI agents. Hybrid suites, which embed orchestration and intake, will take over in organizations that want modern connectivity and interface but want to limit the number of vendors they need to deal with. And traditional suites will gain traction in highly regulated industries and governments where everything has to be 100% predictable and in-line with thousands (if not millions) of pages of policy regulations!

As Jason Busch likes to say, “many things can be true at once” and as long as those things are not mutually exclusive, they will be in the market.

(P.S. Thanks for taking up my day with no warning, Paul!)

Operations Research Lessons are Timeless … Especially in the Age of AI

Twenty years ago we published a piece focussed on Mark Daskin’s Everyday Lessons from Operations Research that he delivered at INFORMS 2006. They are just as relevant today, if not more so, in the age of AI (Hype).

  1. Service and Performance Gets Worse as Utilization and Variability Increase
    This is true in so many ways. Dumb users asking stupid questions with poorly formed prompts that don’t match the training prompts flooding the internet with poor and hallucinatory answers that are fed into the next AI model in the collective race to the bottom. Response times decreasing as the models need to get bigger to process ever more mediocre data and, hopefully, create better responses (even though that won’t happen). Costs going through the roof as a result of the constant need for more computing power.
  2. … But Variability is necessary.
    Because every request is fundamentally different, even if phrased the same as the lack of standardization, and training on that standardization, ensures every user has a different intent with their request.
  3. Expect the unexpected in today’s world.
    Most responses will be okay, some will be bad, a good number will be completely hallucinatory, and every now and again the hallucination will provide a revolution insight — which will go unnoticed because most users now lack the cognitive power, and possibly the intelligence, to even detect a hallucination in the first place due to the mass cognitive atrophy Gen-AI is, provably, inducing.
  4. If it is too good to be true, it probably is not.
    But yet we continue to believe the lies, damn lies, and hallucinatory hype spewed by the purveyors and pushers of Gen-AI and the garbage it spits out.
  5. Life is full of errors.
    And Gen-AI multiplies those errors tenfold to ten-thousandfold!
  6. A good decision can result in a bad outcome.
    Even when the AI gets it right on the data, the data is always backward looking, not forward looking, and the right decision based on a past trend can still be wrong if a key variable or assumption just changed and the data does not yet reflect that. So even when the AI actually gets it right, it can still be wrong!
  7. If you are not using all you have, don’t pay for additional quantity.
    If you only have a small amount of data to train the model on, don’t pay for the largest model available — not only will it not help your case, it will hurt as there won’t be enough data to “train” the model even to reasonable levels of accuracy (relative to what the model is theoretically capable of). Always go with the smallest model that will theoretically meet your needs — and, moreover, if you have multiple distinct needs, multiple distinct models will perform much better than trying to create one big mega model.
  8. You can never do better by adding a constraint.
    Never, ever, ever. Whatever you are trying to minimize will increase. Constraints restrict options and that will always result in increased cost, increased risk, etc.
  9. Keep it Simple
    The best AI, especially in the age of Gen-AI, is no AI. More specifically, don’t use AI where AI is not needed. Deterministic automation, when properly applied, has worked well for decades and now, in an age where we can encode adaptive workflows, suggest exception resolutions, have the rules automatically update when a resolution is accepted or created, and improve over time.
  10. Think about problem formulation.
    The formulation dictates the potential solutions … and the better you define a problem, and a stepwise algorithm to resolve that problem, the less need you will actually have for (Gen-) AI.
  11. Look for compromise solutions.
    If a problem ends up being defined particularly constrained or complicated when multiple parties get involved, work together to simplify the constraints or complexity where it truly isn’t needed. There’s a big difference between preference and requirement, and understanding that allows for the creation of good comprise models and solutions.
  12. Data is not information.
    It never has been, and never will be. Moreover, data pulled out of an LLM might not even be accurate, so the chance of it producing usable information is even less. Always remember that.

The Great Thing About Optimization: You Can Cost Constraints and Solve for Them!

The Sourcing Optimization Grand Master Paul Martyn, as part of his ongoing Sourcing Excellence, published two great posts on how The Most Important Constraint Is Often Left Unspoken and The Real Problem Is Usually Context.

In Part 16, Paul notes that:

Sometimes the most important part of the decision never gets discussed directly.
Nobody says: “We don’t trust ourselves to manage the transition.”
Nobody says: “If this fails, I own the fallout.”
Nobody says: “We’d rather pay more than explain a disruption.”

But they poison the model by insisting on:

Extra incumbent weighting.
Requirements that narrow the field.
Timelines that make supplier change almost impossible.
Risk language that quietly points one direction.

Which ensures that the “optimal” solution is one that keeps the incumbent, even though it’s far from the optimal solution.

Then, in Part 17, Paul notes that context is the harder problem. That while the sourcing team can model price, lead times, freight, capacity, payment terms, supplier performance, etc., the data doesn’t capture:

  • a plant manager [who] still remembers a shutdown tied to a supplier change
  • marketing does not want packaging changes during a seasonal launch
  • finance is suddenly focused on working capital
  • operations is protecting uptime
  • an incumbent relationship [that] carries more internal support than anyone says out loud

And this is what leads to the insistence of constraints and inflated switching costs in the model that mathematically ensures the “optimal” solution is the one where nothing changes, even though the CFO can clearly see that costs are 5% above market averages with no real explanation as to why the organization has to pay that much to minimize risk, ensure supply, yada, yada, yada.

But here’s the thing, if the real issues are surfaced BEFORE the event begins (and the model built):

  • Even though the plant manager is scared of a shutdown, the probability can be computed and the cost can be quantified — as the cost per hour/day/week is known
  • The cost of extending the current contract just through the launch can be quantified and the cost of keeping the supplier for the whole contract term vs. just the launch and then switching to a new supplier can be computed
  • Up front vs. over-time costs can be modelled and the cost of solutions that require more investment up-front vs. later can be compared and contrasted
  • The on-time expectancy per supplier and carrier can be modelled and accounted for
  • The true cost of the incumbent preference can be modelled

The great thing about strategic sourcing decision optimization with what-if scenario support is that all costs and constraints, if properly expressed, can be modelled and the true cost of a preferred, vs. market, scenario computed. If the cost difference is inconsequential, then you go with what the people want. If it’s significant, then some real discussions need to happen and some real decisions need to be made.

Sourcing and Procurement Are NOT The Same

And they are definitely NOT interchangeable, as per a recent article by Paul Martyn (the Sourcing Optimization Grand Master) on LinkedIn.

As per his article,

  • sourcing is strategic
  • procurement is transactional

And this is why they are not only not the same, as per Paul’s article, but not interchangeable.

In the age of AI (Hype), this is distinction becomes doubly important!

As technology advances rapidly, humans become less and less important in Procurement as rapid advances in automation allow more and more of the tactical process to be completely automated (as ARPA allows exceptions to be learned and future manual intervention requirements to be eliminated) but more and more important in sourcing as Gen-AI repeatedly proves just how Astonishingly Inept modern Artificial Idiocy is.

Many will argue that sourcing is tactical because modern software can assemble RFXs from existing specs, automatically select suppliers from your SXM and/or ERP, automatically distribute them, automatically validate the returned RFXs, eliminate vendors who don’t meet absolute requirements, analyze the responses against market data for validity, build and execute multi-objective models, and recommend and award. And while that certainly sounds like sourcing, it’s not. It is sourcing execution. The tactical part that has to be done to support the strategic, but NOT the strategic.

The strategic is creating the specs, identifying the real organizational requirements, determining the requirements for supplier inclusion, validating the suppliers, determining the proper (multi-round) event type, validating the generated RFXs, analyzing the responses for hidden risks and traps and idiosyncrasies, defining the right trade-off models, selecting and modifying the right award scenario, overseeing the negotiation, etc. Every part of the process that requires an actual decision with Human Intelligence.

This is because, as Paul points out, a dumb machine doesn’t understand:

  • lowest cost vs resilience
  • incumbent vs challenger
  • standardization vs innovation
  • savings vs service
  • global leverage vs local agility

Or any other trade-off that can’t be completely quantified and captured in fail-safe rules.

Systems can, and should, support all tactical bit-pushing — especially since we were promised they would do so over 40 years ago when the big push was made for every person and business to adopt them — but, like IBM said in 1979, a computer should never (EVER) make a decision. And that most definitely includes Sourcing decisions!

AI CANNOT TELL YOU WHAT TO DO!

And I’m so glad I’m not the only one saying it!

The (Strategic Sourcing Decision Optimization [SSDO]) Grand Master himself Paul Martyn recently wrote a great post on LinkedIn that made this exceptionally clear and how the real problem is knowing what to do.

Paul starts off with three critical statements:

  1. AI can tell you what’s happening
  2. AI can’t tell you what to do
  3. In sourcing (procurement) the hard part isn’t visibility, it’s choice.

More specifically, it’s making a decision when every decision has tradeoffs, constraints, and (sometimes dire) consequences.

Unless you have an operating model to make those decisions, powered by technology that can actually help you adhere to the constraints, make the tradeoffs, and understand the consequences, the best case with AI is you get overwhelmed with the complexity of what’s happening.

So if you want to be buried in data and complexity and pretend you know what you are doing, there are dozens of BS AI players ready to help you.

But if you want the ability to make good decision, understand tradeoffs, restrict your inquiries to scenarios that adhere to constraints, and model the potential consequences when things go wrong, you need decision optimization with multi-objective capability. That’s Coupa (Trade Extensions). Or Jaggaer (Bravo Solution). Or Keelvar (just Keelvar). Not some BS AI startup offering nothing more than a clod or chat, j’ai pété LLM wrapper.

And if you want to know how to build the right operating model backed up by the right multi-objective optimization model(s) (and save millions while reducing risk and increasing quality), you contact Paul Martyn. He’s saved Billions. (Whereas in 94% of companies, AI has effectively saved 0.)

Now for those who don’t know, not only am I one of the last original (independent) analysts standing in our space (20 years doing SI next month), but I am likely the last original strategic sourcing decision optimization model builder left standing too. (Mindflow [acquired by Emptoris], 2000. First multi-line item model. Before CombineNet [acquired by SciQuest, renamed Jaggaer]. Before Emptoris [acquired by IBM and sunset]. Before all of them. Twelve years before Keelvar. First model to do more: Trade Extensions, acquired by Coupa.)

So unless Thomas Sandholm or Arne Andersson want to come out of retirement and recommend someone better — it’s Paul Martyn. No one still active in our space goes as far back or has worked with as many platforms as he has. (And I helped a PM/Consultant who worked at 2 different optimization providers get hired at 3 others over the past 20 years, and even that doesn’t match Paul’s resume!)