Twenty-eight years of technological advancement have not moved the failure rate. That is not an accident.
McKinsey’s Growth, Marketing & Sales practice posted something this week that is worth reading closely — not for the headline, but for the line at the foot of the graphic:
AI creates the greatest value when it changes how decisions are made — not just how work gets done.
That is the correct distinction, and most of the field is still working on the second half of it. Their argument is that customer signals, pricing, market changes, experimentation and sales activity can now feed commercial decisions continuously, in real time, rather than through periodic analysis of historical information.
They are right that this is now possible.
I want to take the premise seriously, because I have some history with it.
The question, and who asked it
In April 2008, a member put a question to me that I have never stopped thinking about. Almost ten years earlier, Bill Gates had published Business @ The Speed of Thought, drawing an analogy between an organization’s IT infrastructure and a living being’s nervous system. The member’s question was blunt: does your enterprise actually have a digital nervous system? Can you receive important information in real time and adapt — or are you constrained in your ability to adapt by the very systems meant to help you?
He suspected the answer would mostly be no. He was right.
My answer at the time distinguished two ways of building software. Equation-based models — the traditional approach, and the one every major vendor had invested in — quantify and therefore confine multiple strands: the operating attributes of diverse stakeholders, compressed into a single definable static process. Agent-based models do the opposite. They start by understanding those attributes as they actually are, then link seemingly disparate ones through advanced algorithms to produce a real-world outcome on a real-time basis.
I also noted why the industry was stuck. Vendors with a substantial investment in equation-based architecture were bridging the synchronization gap with Service-Oriented Architectures, and Larry Ellison was on record admitting that the best that approach could achieve was near real time. Near real time is not what a dynamic enterprise requires.
That was 2008. The post is still there, dated, with the vendor names in it.
It was not theoretical
Ten years before that answer, I built one.
In 1998, a defence maintenance operation was achieving next-day parts delivery 51 percent of the time against a 90 percent contractual requirement. The work ran on advanced self-learning algorithms operating in real time — on a model that did not stop at the enterprise boundary. It extended to every agent touching the outcome: service technicians, buyers, suppliers, couriers, customs brokers, finance.
That reach mattered, because the condition determining the result was not inside procurement. Technicians were measured on call response, so they cleared calls first and submitted parts orders afterward, producing a four o’clock batch of urgent demand. Buyers cleared the batch by pushing work to small US suppliers with no cross-border experience, against delivery dates those suppliers had never confirmed. Each supplier used a separate courier, multiplying customs risk. And in finance, purchase orders captured part cost while courier charges arrived separately on invoices — so the contractual markup, calculated on part cost alone, was quietly losing money on transactions the program booked as revenue.
Five domains. Every individual measure accurate. Nothing in the system connecting them.
Delivery moved from 51 percent to 97.3 percent within three months, and held there for seven years.
What made that possible was not the sophistication of the algorithms. It was a contract in trouble, and a client willing to let the trace leave procurement and keep going — into the service department’s incentive structure, across the border, and into finance.
The technology was the easy part. It always is. The algorithms were pointed at a system that had first been made real. Point the same algorithms at the declared process and you get a faster version of 51 percent.
The evidence nobody wants to look at
Twenty-eight years later, the capability is not in question. What took custom work in 1998 is now a commercial product. McKinsey describes it accurately: the signals can be read continuously, the feedback embedded in the workflow, the decision adapted in real time.
Here is the part that should stop us.
Across that entire period — client-server, ERP, the internet, SOA, cloud, SaaS, analytics, and now AI — the proportion of initiatives that fail to achieve their expected results has not meaningfully moved. Every era delivered a genuine and substantial increase in capability. The outcome stayed where it was.
A constraint that survives every change to a variable is not caused by that variable.
That is not a rhetorical point. It is the whole argument. If technology were the limiting condition, six technological revolutions would have shown up in the results. They did not.
This is what Invariant Physics™ describes: the conditions that determine whether an implementation succeeds do not change when the technology changes. They were the same in 1998 as they are now, which is why the same failure keeps arriving wearing different clothes.
So the question I would put to McKinsey’s audience is not whether the capability is real. It is.
Are we any more ready for it than we were in 1998?
Not more capable. More ready. Those are different things, and the gap between them is where implementations have been failing for twenty-eight years.
Continuous is not the same as open
Look at the McKinsey diagram again. Six signal sources arranged around a hub: customer signals, pricing, sales activity, experimentation, learning, market changes. Every one of them identified in advance. Beautifully composed.
It is a portrait.
The claim is that the portrait now refreshes continuously instead of quarterly, which is a real advance. But a portrait that refreshes every second is still a portrait of what someone decided to include. Nothing arriving from outside the frame appears in it, however fast it updates.
On 8 April 2008 — three days after the digital nervous system exchange — I published a post titled Similarity Heuristics, Iterative Methodologies and the Emergence of the Modern Supply Chain, drawn from a paper written in 2005. It is about exactly this problem.
The argument there was that the reliability of a declared value degrades over time — not because the value was wrong when it was set, but because the conditions move and the declaration does not. And that the subject and attributes in a supply practice are in a state of constant motion and change. The remedy I named was strand commonality, and the word I used for it, in parentheses, was camcorder:
To effectively capture the dynamic elements within this kind of environment, a different methodology such as strand commonality (re camcorder) must be employed to ensure that an accurate picture is captured on an ongoing basis, thereby bridging or synchronizing the chasms between multiple transactional streams.
A camcorder keeps recording when something walks into the frame that nobody put there. That is what has to be captured, and it is not what a faster still picture captures.
In 1998, no signal set built around procurement would have contained the four o’clock condition, because the condition lived in the service department’s incentive structure. A faster procurement dashboard would have shown a faster picture of the wrong system.
This is the distinction I wrote about in The Map You Design and the Map You Trace. A designed map begins with what people believe the system contains. A traced map begins with evidence of failure and follows the operating reality wherever it goes — including out of the department, out of the process, and out of the technology.
Speed is an amplifier. It does not care what it is amplifying.
Two different systems. The map on the left is the line to a destination — every arrow points at the goal, and it contains only what someone thought to design in. The map on the right is a search that starts from failure and leaves the frame four times.
Feedback is not loopback
This is the test, and it is not a technology question.
Feedback improves a decision against the existing model. The signal comes in, the recommendation adjusts, the model stays as it was. Every system in the McKinsey diagram does this well.
Loopback allows new outcome evidence to challenge the model itself — to reopen what counts as a signal, where the boundary sits, and whether the relationship driving the result was ever represented at all.
The moment that separates them is when the outcome diverges from the recommendation.
If that divergence tunes the next action, the organization has feedback. If it can reopen the assumptions, the organization has loopback. Most have the first and believe they have the second, because both look like learning from the outside.
A framework that can only be confirmed is not being governed. It is being maintained.
The constraint never moved
It was never in the technology. It has always been in four places that no amount of compute reaches, and it was in exactly those four places in 1998:
Who is allowed to say the signal set is wrong. If reopening the frame is above the pay grade of everyone who can see the problem, the frame does not get reopened.
What happens to the person who says it. Surfacing a gap creates work, delays a project, and invites questions from people who expected a decision. Quietly resolving it gets you a completed task and a grateful project manager. Multiply that across a team and a few months, and you have a system that looks rigorous on a foundation nobody has examined.
Whether outcome evidence outranks the model. When the result contradicts the recommendation, which one is treated as the error? In most organizations the answer is the result — it becomes an exception, an outlier, a data quality issue.
Whether anyone owns the space between functions. The four o’clock condition belonged to no one. Service was hitting its numbers. Procurement was processing what it received. Finance was reconciling cleanly. The loss existed only in the relationships between them, and no function was accountable for a relationship.
That last one is the hardest, because it cannot be solved by assigning it to a function. It is the reason the finding took a trace rather than a report.
The honest answer
Yes — business at the speed of thought is finally possible. McKinsey is right about that, and the graphic is right that this changes how decisions are made rather than merely how work gets done.
And no, I do not think most organizations are more ready for it than they were in 1998. They are enormously more capable and no more willing to be contradicted by their own outcomes.
That is what the flat failure rate has been telling us for twenty-eight years. The technology changed six times. The operating physics did not change once.
Which means the risk has changed shape, even though the constraint has not. In 1998, a badly framed system failed slowly enough that someone eventually noticed. A continuously learning commercial engine built on an unexamined frame does not fail slowly. It gets very good, very quickly, at learning the wrong thing.
The question is no longer whether your enterprise has a digital nervous system.
It is whether your organization can survive being told, by its own outcomes, that the nervous system is wired to the wrong places.
-30-
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
Jon W. Hansen, FCIPS — Procurement Insights | Hansen Models™
If the readiness question is the one you are sitting with, I am running a free 30-minute lab on the smaller version of it: how to select, work with and progressively engage AI models so the output gets more accurate rather than just more polished. It is a working session, not a presentation — you make the calls before you see what I did.
Friday, 25 September, 9:30 AM ET, and again Wednesday, 30 September, at 1:00 PM ET. Everyone who attends gets a copy of Thinking With the Machine.
Register: https://www.linkedin.com/events/7504567838724997120/
Related
Business at the Speed of Thought Is Finally Possible. Are We Any More Ready for It Than We Were in 1998?
Posted on September 14, 2026
0
Twenty-eight years of technological advancement have not moved the failure rate. That is not an accident.
McKinsey’s Growth, Marketing & Sales practice posted something this week that is worth reading closely — not for the headline, but for the line at the foot of the graphic:
That is the correct distinction, and most of the field is still working on the second half of it. Their argument is that customer signals, pricing, market changes, experimentation and sales activity can now feed commercial decisions continuously, in real time, rather than through periodic analysis of historical information.
They are right that this is now possible.
I want to take the premise seriously, because I have some history with it.
The question, and who asked it
In April 2008, a member put a question to me that I have never stopped thinking about. Almost ten years earlier, Bill Gates had published Business @ The Speed of Thought, drawing an analogy between an organization’s IT infrastructure and a living being’s nervous system. The member’s question was blunt: does your enterprise actually have a digital nervous system? Can you receive important information in real time and adapt — or are you constrained in your ability to adapt by the very systems meant to help you?
He suspected the answer would mostly be no. He was right.
My answer at the time distinguished two ways of building software. Equation-based models — the traditional approach, and the one every major vendor had invested in — quantify and therefore confine multiple strands: the operating attributes of diverse stakeholders, compressed into a single definable static process. Agent-based models do the opposite. They start by understanding those attributes as they actually are, then link seemingly disparate ones through advanced algorithms to produce a real-world outcome on a real-time basis.
I also noted why the industry was stuck. Vendors with a substantial investment in equation-based architecture were bridging the synchronization gap with Service-Oriented Architectures, and Larry Ellison was on record admitting that the best that approach could achieve was near real time. Near real time is not what a dynamic enterprise requires.
That was 2008. The post is still there, dated, with the vendor names in it.
It was not theoretical
Ten years before that answer, I built one.
In 1998, a defence maintenance operation was achieving next-day parts delivery 51 percent of the time against a 90 percent contractual requirement. The work ran on advanced self-learning algorithms operating in real time — on a model that did not stop at the enterprise boundary. It extended to every agent touching the outcome: service technicians, buyers, suppliers, couriers, customs brokers, finance.
That reach mattered, because the condition determining the result was not inside procurement. Technicians were measured on call response, so they cleared calls first and submitted parts orders afterward, producing a four o’clock batch of urgent demand. Buyers cleared the batch by pushing work to small US suppliers with no cross-border experience, against delivery dates those suppliers had never confirmed. Each supplier used a separate courier, multiplying customs risk. And in finance, purchase orders captured part cost while courier charges arrived separately on invoices — so the contractual markup, calculated on part cost alone, was quietly losing money on transactions the program booked as revenue.
Five domains. Every individual measure accurate. Nothing in the system connecting them.
Delivery moved from 51 percent to 97.3 percent within three months, and held there for seven years.
What made that possible was not the sophistication of the algorithms. It was a contract in trouble, and a client willing to let the trace leave procurement and keep going — into the service department’s incentive structure, across the border, and into finance.
The technology was the easy part. It always is. The algorithms were pointed at a system that had first been made real. Point the same algorithms at the declared process and you get a faster version of 51 percent.
The evidence nobody wants to look at
Twenty-eight years later, the capability is not in question. What took custom work in 1998 is now a commercial product. McKinsey describes it accurately: the signals can be read continuously, the feedback embedded in the workflow, the decision adapted in real time.
Here is the part that should stop us.
Across that entire period — client-server, ERP, the internet, SOA, cloud, SaaS, analytics, and now AI — the proportion of initiatives that fail to achieve their expected results has not meaningfully moved. Every era delivered a genuine and substantial increase in capability. The outcome stayed where it was.
A constraint that survives every change to a variable is not caused by that variable.
That is not a rhetorical point. It is the whole argument. If technology were the limiting condition, six technological revolutions would have shown up in the results. They did not.
This is what Invariant Physics™ describes: the conditions that determine whether an implementation succeeds do not change when the technology changes. They were the same in 1998 as they are now, which is why the same failure keeps arriving wearing different clothes.
So the question I would put to McKinsey’s audience is not whether the capability is real. It is.
Are we any more ready for it than we were in 1998?
Not more capable. More ready. Those are different things, and the gap between them is where implementations have been failing for twenty-eight years.
Continuous is not the same as open
Look at the McKinsey diagram again. Six signal sources arranged around a hub: customer signals, pricing, sales activity, experimentation, learning, market changes. Every one of them identified in advance. Beautifully composed.
It is a portrait.
The claim is that the portrait now refreshes continuously instead of quarterly, which is a real advance. But a portrait that refreshes every second is still a portrait of what someone decided to include. Nothing arriving from outside the frame appears in it, however fast it updates.
On 8 April 2008 — three days after the digital nervous system exchange — I published a post titled Similarity Heuristics, Iterative Methodologies and the Emergence of the Modern Supply Chain, drawn from a paper written in 2005. It is about exactly this problem.
The argument there was that the reliability of a declared value degrades over time — not because the value was wrong when it was set, but because the conditions move and the declaration does not. And that the subject and attributes in a supply practice are in a state of constant motion and change. The remedy I named was strand commonality, and the word I used for it, in parentheses, was camcorder:
A camcorder keeps recording when something walks into the frame that nobody put there. That is what has to be captured, and it is not what a faster still picture captures.
In 1998, no signal set built around procurement would have contained the four o’clock condition, because the condition lived in the service department’s incentive structure. A faster procurement dashboard would have shown a faster picture of the wrong system.
This is the distinction I wrote about in The Map You Design and the Map You Trace. A designed map begins with what people believe the system contains. A traced map begins with evidence of failure and follows the operating reality wherever it goes — including out of the department, out of the process, and out of the technology.
Speed is an amplifier. It does not care what it is amplifying.
Two different systems. The map on the left is the line to a destination — every arrow points at the goal, and it contains only what someone thought to design in. The map on the right is a search that starts from failure and leaves the frame four times.
Feedback is not loopback
This is the test, and it is not a technology question.
Feedback improves a decision against the existing model. The signal comes in, the recommendation adjusts, the model stays as it was. Every system in the McKinsey diagram does this well.
Loopback allows new outcome evidence to challenge the model itself — to reopen what counts as a signal, where the boundary sits, and whether the relationship driving the result was ever represented at all.
The moment that separates them is when the outcome diverges from the recommendation.
If that divergence tunes the next action, the organization has feedback. If it can reopen the assumptions, the organization has loopback. Most have the first and believe they have the second, because both look like learning from the outside.
A framework that can only be confirmed is not being governed. It is being maintained.
The constraint never moved
It was never in the technology. It has always been in four places that no amount of compute reaches, and it was in exactly those four places in 1998:
Who is allowed to say the signal set is wrong. If reopening the frame is above the pay grade of everyone who can see the problem, the frame does not get reopened.
What happens to the person who says it. Surfacing a gap creates work, delays a project, and invites questions from people who expected a decision. Quietly resolving it gets you a completed task and a grateful project manager. Multiply that across a team and a few months, and you have a system that looks rigorous on a foundation nobody has examined.
Whether outcome evidence outranks the model. When the result contradicts the recommendation, which one is treated as the error? In most organizations the answer is the result — it becomes an exception, an outlier, a data quality issue.
Whether anyone owns the space between functions. The four o’clock condition belonged to no one. Service was hitting its numbers. Procurement was processing what it received. Finance was reconciling cleanly. The loss existed only in the relationships between them, and no function was accountable for a relationship.
That last one is the hardest, because it cannot be solved by assigning it to a function. It is the reason the finding took a trace rather than a report.
The honest answer
Yes — business at the speed of thought is finally possible. McKinsey is right about that, and the graphic is right that this changes how decisions are made rather than merely how work gets done.
And no, I do not think most organizations are more ready for it than they were in 1998. They are enormously more capable and no more willing to be contradicted by their own outcomes.
That is what the flat failure rate has been telling us for twenty-eight years. The technology changed six times. The operating physics did not change once.
Which means the risk has changed shape, even though the constraint has not. In 1998, a badly framed system failed slowly enough that someone eventually noticed. A continuously learning commercial engine built on an unexamined frame does not fail slowly. It gets very good, very quickly, at learning the wrong thing.
The question is no longer whether your enterprise has a digital nervous system.
It is whether your organization can survive being told, by its own outcomes, that the nervous system is wired to the wrong places.
-30-
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
Jon W. Hansen, FCIPS — Procurement Insights | Hansen Models™
If the readiness question is the one you are sitting with, I am running a free 30-minute lab on the smaller version of it: how to select, work with and progressively engage AI models so the output gets more accurate rather than just more polished. It is a working session, not a presentation — you make the calls before you see what I did.
Friday, 25 September, 9:30 AM ET, and again Wednesday, 30 September, at 1:00 PM ET. Everyone who attends gets a copy of Thinking With the Machine.
Register: https://www.linkedin.com/events/7504567838724997120/
Share this:
Like this:
Related