Category Archives: Technology

“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!)

Center-Orchestrated Procurement Requires Unique Platforms

In our last few articles, we’ve been writing a lot about the need for center-orchestrated Procurement due to the current global trade environment. As a result of this, a number of policies, processes, and platforms will need to change for a modern global Procurement organization in order for it to be efficient, effective, and even endorsed.

While the core platform requirements don’t change, the unique requirements for the platform are different. When you only have to serve yourself, whatever works for you is good enough. But when you have to serve a diverse base of global users, who have to adhere to a diverse spectrum of global requirement, what works for you is sometimes completely irrelevant.

Then there’s also the fact that center-orchestrated procurement, by definition, requires:

  • orchestration — if the platform can’t orchestrate data streams, workflows, and users, it’s not sufficient
  • common data model — every platform must support the common data model in the central data store to allow for easy data integration and cross organization analytics
  • centralized supplier onboarding — there needs to be a central supplier master and management platform
  • “excellence” — if the platform can’t encode and distribute best practices across the global organization, it’s not the right platform
  • standards — efficiency comes from standardization to the extent possible, if the platform doesn’t support that, it’s no good
  • supply chain awareness — it needs to integrate with the logistics, supply chain, and PLM systems in order to allow for organizational aware sourcing and procurement
  • knowledge management — it should capture all of the knowledge needed to run the orchestrated workflows effectively
  • global risk management — all of the risks must be identified, tracked, mitigated and managed centrally

Breaking this down, you can see that before any sourcing or procurement platform, it needs to support:

  • real orchestration support — it needs a fully defined API that allows all data to be pushed in or pulled out, functions to be executed, and workflows to be configured; it can be a standard REST API or MCP, but it has to be orcehstratable
  • centralized common data model and data federation platform — that can support all sourcing and procurement data collected and generated by all systems with the ability to define the external system mappings as appropriate; this doesn’t mean the organization dumps everything into a lake / warehouse / lakehouse, but builds the foundation for federated data analysis as the best analytics platforms can pull in the data needed on demand when they have a common data model to work off of (pre-defined mappings from the global organizational systems, and a designation as to which system is “master” for any specific piece of data — which means the data model specifies, for each datum, the master system)
  • centralized supplier onboarding — the central supplier master should support global supplier onboarding; if it can’t be localized as needed (language, accessibility, etc.), then it needs to support fine-grained orchestration that will allow a local platform to mimic the global requirements and feed all of the data into the central system
  • excellence — any platform used for centralized operations need to support the creation of specialized workflows for each region, location, and project; moreover, the specialized workflows need to inherit the global requirements while supporting the regional and local overrides with minimal effort; nothing should have to be defined twice and no unnecessary work duplicated
  • standards — the platform needs to support multiple authentication, security, and privacy standards and implementations to meet global requirements; remember, different countries will require different security protocols, login protocols, privacy requirements, government platform integrations, etc. — the global platforms you select must support switching them in and out as needed by the locale
  • supply chain awareness — the platform needs to understand your supply chain data model and be capable of integrating with your supply chain platforms to integrate the required data to make supply chain aware decisions
  • knowledge management — the platforms must capture more than process, they must capture the decision making frameworks used to select and execute the processes and do the required analytics; for the categories, they must cover the strategy; for the suppliers, the soft evaluation criteria based on the objective and subjective rankings; for Procurement process selection — catalog vs. RFQ vs. tail-spend provider — the logic used; etc.
  • global risk management — a solution for identifying, tracking, and monitoring changes in global risk criteria and alerts and pushing out relevant information to the appropriate regions and locations through the tools the end users actually use (using the built-in orchestration capabilities)

In other words, the platform has to be a lot more adaptive, layered, and customizable than most platforms in use today.

If You Can’t Do The Job Without Tech …

Then you can’t do the job with tech.

I’ve said it before and I’ll say it again. If you can’t do the job without tech, then you can’t do the job with tech.

All tech does is automate tasks and workflow processes and allow you to speed them up by a factor of 10 to 1,000,000 plus (depending on the tasks and workflow processes).

It doesn’t make tasks or processes better or worse (unless you Gen-AI, which typically makes it worse) — just faster (unless, of course, you change the process when you implement the tech and make the task or process better or worse).

Now, you’re probably asking why it’s not enough to design the process and simply install the tech. That’s because there’s a difference between designing a process and executing a process. Anyone can design a process at a high level given a highly set of requirements. Not anyone can execute. Among those, even less can execute it effectively.

Only those who can execute it effectively are fit to do the job, regardless of what tech the organization has or does not have. That’s because, if you don’t know how to do the job without tech (and certainly without AI), you don’t understand what the job really is. Business was conducted for thousands of years without modern tech, and computers only became generally available in big business in the 80s and mid-size businesses in the 90s and small businesses in the 2000s. That means everything you do today with modern tech was once done without modern tech (and, 150 years ago, without any tech that we would consider modern at all).

That understanding means you understand the core of the function. You know what has to be done, how, where the time suck is, what can be automated, how, and why. You also know how to verify correct automations has been implemented, and where the results require human interpretation, review, and decisions — and, if necessary, make those interpretations, review, and decisions.

Without that understanding, you can’t properly make use of tech and you definitely can’t make use of AI. Sure some tasks might be 10 to 1,000,000 times slower (and sourcing optimization will be out of the question, just a few bid comparisons), and you shouldn’t do them by hand unless necessary, but the point is you need to be able to — otherwise, you can never judge what the system does. Iin the age of hyper-fast LLM hallucinations, only good human decisions will allow your organization to succeed.

Why Your ProcureTech Initiative Will Fail … Part 1

We’ve written many series on best practice tech identification, tech selection, and tech implementation in the hopes of inverting the odds from an 80%+ chance of failure to an 80%+ chance of success, but given that failures are literally still happening on a daily basis, it seems that most people can’t be bothered to read best practice advice so today we’re going to flip the script and tell you all the reasons you’re going to fail and then you hope you go back and read the best practice advice we’ve freely given you (in series such as Successful Vendor Selection – The Series).

1. You Don’t Understand Your True Needs

You’ve never done a full end-to-end process analysis on your organization, you don’t understand how inefficient your processes are, what processes you actually need, why you need them, and how much better you could be doing. You just know that the KPI metrics you are tracking are not on par with industry averages based on what your overpriced consultants are telling you, that your balance sheet isn’t as good as best in class, and that you need to do something … and that something is get a shiny new tech toy that the overpriced consultants will help you select by telling you who to invite to your RFP. (And you should know all the problems with this — they’ll only recommend the partners they have sycophant partnerships with, get referral and implementation fees from, and who will ensure that they remain your overpriced consultancy of choice.)

2. You Don’t Understand What You Already Have

Once you understand what the correct processes are, why, and where the automation points are, you need to revisit the systems you have to see where they can solve the problems. Chances are you have a number of suites, supply chain platforms, and ERPs with easy to implement plug-in modules that solve a lot of the problems you have without buying any new systems. And even if new systems might do it better, chances are the improvement won’t be worth the extra money, downtime, and change management — which will all cost you dearly. The reality is that if you can get an 80% solution today, with tools your people are already using, that’s much better than a potential 95% years in the future.

3. You Don’t Understand What Your Capabilities Actually Are

By this we don’t mean your process capabilities or technological capabilities, we mean your actual functional capabilities. Your domain knowledge, your ability to execute on that domain knowledge, and your natural efficiency. It’s pointless improving processes to apply more advanced techniques or employing modern technology to speed up processes when you’re not capable of managing those advanced processes or technology. If you employ processes and systems you’re not ready for, they won’t deliver any results while costing you millions of dollars in the system selection and implementation processes.

4. You Don’t Understand How Long It Will Take to Upgrade Your Capabilities

Even if you figure out you need to upgrade your skills and those of your team’s, even if you posses a fair degree of human intelligence, you don’t know how long it will take. It’s not just buying a knowledge dump from a consultancy or giving your team a 5-day crash course, because knowledge that is not applied is not retained. There’s a reason College and University courses give assignments and projects as well as exams — the more you apply, the more you retain. If the imparted knowledge is not applied, it will not be retained. Until your team can start applying, repetitively, the new knowledge in improved processes, they won’t retain it and they won’t advance. The best training will be a day or two a month over months, not a week. And that’s for stage 1. It will take years to get your team from average to mastery. We’ve known for decades that major transformation projects take 5 to 10 years, and that the average journey to best in class for the committed is 8 years. Technology doesn’t change that. The longer you choose to ignore this fact, the longer you will fail.

To be continued in Part 2.