Why the workaround outlives every technology era, and the question to ask your AI platform before it joins the list
By Jon W. Hansen, FCIPS · Procurement Insights
In 2007, I was asking whether a new joint product from SAP and Microsoft would finally bring enterprise work to where people actually did their work. This week on LinkedIn, I found myself asking the same question about SAP’s AI platform.
Nineteen years apart. A different technology era. The same question, almost word for word.
That is what Invariant Physics™ describes. The names of the technologies change. The variable that decides the outcome does not. And the way to find that variable, in any era, is Hansen Strand Commonality™.
How the question came up again
Julia Danyal posted a list of eight AI governance platforms for companies to evaluate in 2027. Her closing point was the one that mattered most: many of the AI systems inside a company are unknown to its board, and unapproved AI is part of the company’s governance risk.
I agreed, and added that you can’t govern what you don’t know exists. Every platform on her list governs AI once it is in the inventory. The unknown systems are a different kind of finding. And shadow AI isn’t new. It is the latest version of a pattern that has run through every technology era: Excel models in the 1990s, then personal devices, then unsanctioned cloud apps, and now personal AI accounts. Each time, the official system didn’t fit how the work was actually done, people routed around it, and governance arrived afterward treating the workaround as the problem.
And the workaround starts at the top. In a March 2026 survey of 2,001 employees in the US and the UK, 65% of senior decision-makers said they use AI tools their organization has not approved. That is more than twice the rate of the people they manage, at 31%. At C-suite level, the figure was 73% (TrustedTech, survey conducted by Censuswide). The people who set the approved route are among the first to go around it.
Christian Haser then made a fair point: SAP’s Business AI Platform was missing from the picture. In his words, it consists of “the middleware Integration Suite, the data layer Business Data Cloud, and the builder suite around Business Technology Platform.”
2005 to 2007. SAP and Microsoft announced a joint product, code-named Mendocino, in 2005 and renamed it Duet in 2006. The premise was to let people reach SAP data and processes from inside Outlook and the other Office tools they already used every day. The problem it set out to solve was plain: people found the enterprise system hard to work in, so they did their real work somewhere else.
2026. SAP’s AI platform brings integration, a data layer and tools for building agents together, so that data and approvals can reach people where the work happens. The problem it sets out to solve is the same: people route around the official system to get the work done.
The question asked of Duet was: will people stop working around the system?
The question to ask of the AI platform is: will people stop working around the system?
Same question. Different technology.
Why the question keeps coming back
If integration had settled this question in 2006, nobody would be asking it in 2026. It keeps coming back because each era answers it with technology: a better connector, a smarter platform, and now an agent. Meanwhile, the reason people left the official workflow in the first place goes untraced.
That reason is rarely the software. It is usually one of three things:
A clock. The approved route takes longer than the work allows.
An incentive. People are measured on something the approved route gets in the way of.
An approval. The person who has to say yes isn’t there when the work needs it.
I saw all three in 1998 on a defense maintenance contract that was running at 51% next-day delivery against a contractual requirement of 90%. The technicians held their part orders until late afternoon, because they were measured on call volume and stopping to order a part interrupted a service call. Procurement processed every order it received by the end of the day. But the orders arrived after the courier cutoffs, so next-day delivery was impossible no matter how fast procurement worked. A faster procurement system would have been a better answer to the wrong question. The answer came from tracing back from the missed deliveries to where the strands crossed.
A workaround is not the problem to be governed away. It is evidence. It marks the place where the approved route doesn’t serve the work, and that is where tracing back should start.
The workaround is a strand nobody put on the map
Hansen Strand Commonality™ starts from a simple observation: an operation is not a set of separate departments. It is a set of strands, each running continuously, each crossing the others. Service, buyers, finance, suppliers, couriers. And alongside them, the strands that never appear on the documented process map: the incentives people are measured on, the shadow systems they keep, and the workarounds they rely on. These seemingly disparate strands share related attributes, and together they decide the outcome, even when nobody has declared them related.
A workaround is one of those undocumented strands. It exists because something on another strand, a clock, an incentive or an approval, made the approved route unworkable. You cannot see why by looking at the workaround alone, and you cannot see it by looking at the platform. You see it where the strands cross.
This is not a method we worked out in response to AI. I first noticed the pattern in 1983, programming in dBASE II, when improving one line of code stopped another from working. I formulated it as a theory and a practice on the 1998 defense contract above, and it is built into ARA™ RAM 2025™ today. Every technology era since has handed it the same question.
Illustrative. AI operating system layers as published by McKinsey, 13 October 2026. Hansen is not affiliated with McKinsey.
The graphic shows how this works. On the left is the operation as it actually runs, with the incentives, shadow systems and workarounds that never appear on the documented map. Tracing back from an outcome that fell short shows which strands crossed and where. That validated picture of how the work really happens is what should feed the platform on the right, whatever the platform is: McKinsey’s AI operating system in the illustration, SAP’s AI platform in this post, or whichever comes next. A platform is only as good as the picture of the operation it is built on.
The test
So here is the test I would put to any platform, from any provider, in any era. It is not the one most organizations use.
The usual test asks the platform three questions. Can people get the data they need? Can they get the approvals they need? Can they finish the work in time? A vendor will answer yes to all three, and in a demo every answer will be true. The data is integrated, the approvals are automated, and each step is faster.
But each of those answers is true inside its own silo. In 1998, procurement could truthfully have said it processed every order by the end of the day. The technicians could truthfully have said they were maximizing service calls. The couriers kept to their cutoff times. Every group passed its own test, and next-day delivery still ran at 51%. The failure was not inside any group. It was in how the groups combined.
That is the aperture problem. The usual test looks along one strand at a time, so it measures siloed interests and misses collective impact. Hansen Strand Commonality™ widens the aperture to every strand at once, including the ones nobody documented. The workaround lives in the collective impact. It also lives outside the process map the platform will be configured from: in the unapproved AI tools, the spreadsheets and the side channels, including the ones used by the people at the top.
So the test has to start from the workaround, not from the platform:
Find the workaround. Pick one task your people already do outside the approved route. Look at the unapproved tools and the spreadsheets as well as the process steps, and look at every level of the organization, not only the front line.
Ask why it exists, in every group it touches. Who relies on it? What are they measured on? What clock are they working against? Who has to say yes, and when are they available? Each answer will make sense on its own, the way the technicians’ reasons did.
Trace where those reasons cross. A workaround exists where several groups’ reasonable choices combine into an outcome none of them intended. That crossing is the real requirement, and it rarely appears on any one group’s map. Finding it is what Hansen Strand Commonality™ does.
Then ask the platform one question: does it change that crossing, or does it only make each silo faster?
If it changes the crossing, people come back to the approved route on their own, because the reason they left is gone. If it only makes each silo faster, the workaround survives, often in a new tool, and in a few years someone will be asking the same question of the next technology.
No platform answers this question by itself, SAP’s included. The answer is in the operation, not the technology. That is why the question has to be asked first, of how the work actually runs, before any platform is judged by what it can do.
Same platform, opposite outcomes
I asked Christian where he had seen this work well in an SAP environment. He answered with a case: a video of NVIDIA’s SAP implementation, and the line, “If Nvidia can do it with SAP, everybody can do it.”
It is a good case. But a success story answers the question with technology again: it worked there, so the platform must be the reason. The record says otherwise.
Ontario’s Education Collaborative Marketplace (OECM) and Virginia’s eVA program both ran on Ariba. OECM had modeled its program on eVA’s. OECM’s implementation failed. Virginia’s succeeded. The Virginia team was clear about why: Ariba did what it was supposed to do, and they would have succeeded with another platform.
Then Virginia showed it. It later moved eVA from Ariba to Ivalua, and the program kept operating at scale. In fiscal year 2025, eVA recorded $13.3 billion in purchase-order spend across 763,040 transactions (eVA FY25 Entity Spend Report, Commonwealth of Virginia).
So the same platform produced opposite outcomes, and the same program succeeded on two different platforms. If the outcome changes when the platform stays the same, and stays the same when the platform changes, the platform is not the variable that decides it.
Expertise in the platform isn’t the variable either. In my white paper on SAP implementations, I documented Hewlett-Packard struggling with its own SAP rollout while it was selling SAP integration expertise to its clients.
NVIDIA’s case shows what worked at NVIDIA. A case study can show what’s possible. It rarely tells you how likely another organization is to succeed, because no two organizations are the same, even when they look alike from the outside. Their strands are different, and so are the places where those strands cross. The work of implementation has to start with how the client actually operates in the real world. That has held across every technology era in the record, as set out in Let’s Stop Crediting Technology for Success, and Blaming Technology for Failure (June 2026).
That is the workaround question again, from the other side. A platform doesn’t end a workaround. Understanding why people needed one does.
The question that stays
Invariant Physics™ is a claim that can be disproved. If a technology era ever answers this question by itself, the record will have to say so. It hasn’t happened yet.
So before your organization adopts its next platform, AI or otherwise: which task are your people already doing around the system, and which strands crossed to put it there?
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
Same Question, Different Technology: Will SAP AI End the Workaround?
Posted on November 15, 2026
0
Why the workaround outlives every technology era, and the question to ask your AI platform before it joins the list
By Jon W. Hansen, FCIPS · Procurement Insights
In 2007, I was asking whether a new joint product from SAP and Microsoft would finally bring enterprise work to where people actually did their work. This week on LinkedIn, I found myself asking the same question about SAP’s AI platform.
Nineteen years apart. A different technology era. The same question, almost word for word.
That is what Invariant Physics™ describes. The names of the technologies change. The variable that decides the outcome does not. And the way to find that variable, in any era, is Hansen Strand Commonality™.
How the question came up again
Julia Danyal posted a list of eight AI governance platforms for companies to evaluate in 2027. Her closing point was the one that mattered most: many of the AI systems inside a company are unknown to its board, and unapproved AI is part of the company’s governance risk.
I agreed, and added that you can’t govern what you don’t know exists. Every platform on her list governs AI once it is in the inventory. The unknown systems are a different kind of finding. And shadow AI isn’t new. It is the latest version of a pattern that has run through every technology era: Excel models in the 1990s, then personal devices, then unsanctioned cloud apps, and now personal AI accounts. Each time, the official system didn’t fit how the work was actually done, people routed around it, and governance arrived afterward treating the workaround as the problem.
And the workaround starts at the top. In a March 2026 survey of 2,001 employees in the US and the UK, 65% of senior decision-makers said they use AI tools their organization has not approved. That is more than twice the rate of the people they manage, at 31%. At C-suite level, the figure was 73% (TrustedTech, survey conducted by Censuswide). The people who set the approved route are among the first to go around it.
Christian Haser then made a fair point: SAP’s Business AI Platform was missing from the picture. In his words, it consists of “the middleware Integration Suite, the data layer Business Data Cloud, and the builder suite around Business Technology Platform.”
His point took me back to Mendocino and Duet, which I wrote about in 2007.
The same question, nineteen years apart
2005 to 2007. SAP and Microsoft announced a joint product, code-named Mendocino, in 2005 and renamed it Duet in 2006. The premise was to let people reach SAP data and processes from inside Outlook and the other Office tools they already used every day. The problem it set out to solve was plain: people found the enterprise system hard to work in, so they did their real work somewhere else.
2026. SAP’s AI platform brings integration, a data layer and tools for building agents together, so that data and approvals can reach people where the work happens. The problem it sets out to solve is the same: people route around the official system to get the work done.
The question asked of Duet was: will people stop working around the system?
The question to ask of the AI platform is: will people stop working around the system?
Same question. Different technology.
Why the question keeps coming back
If integration had settled this question in 2006, nobody would be asking it in 2026. It keeps coming back because each era answers it with technology: a better connector, a smarter platform, and now an agent. Meanwhile, the reason people left the official workflow in the first place goes untraced.
That reason is rarely the software. It is usually one of three things:
I saw all three in 1998 on a defense maintenance contract that was running at 51% next-day delivery against a contractual requirement of 90%. The technicians held their part orders until late afternoon, because they were measured on call volume and stopping to order a part interrupted a service call. Procurement processed every order it received by the end of the day. But the orders arrived after the courier cutoffs, so next-day delivery was impossible no matter how fast procurement worked. A faster procurement system would have been a better answer to the wrong question. The answer came from tracing back from the missed deliveries to where the strands crossed.
A workaround is not the problem to be governed away. It is evidence. It marks the place where the approved route doesn’t serve the work, and that is where tracing back should start.
The workaround is a strand nobody put on the map
Hansen Strand Commonality™ starts from a simple observation: an operation is not a set of separate departments. It is a set of strands, each running continuously, each crossing the others. Service, buyers, finance, suppliers, couriers. And alongside them, the strands that never appear on the documented process map: the incentives people are measured on, the shadow systems they keep, and the workarounds they rely on. These seemingly disparate strands share related attributes, and together they decide the outcome, even when nobody has declared them related.
A workaround is one of those undocumented strands. It exists because something on another strand, a clock, an incentive or an approval, made the approved route unworkable. You cannot see why by looking at the workaround alone, and you cannot see it by looking at the platform. You see it where the strands cross.
This is not a method we worked out in response to AI. I first noticed the pattern in 1983, programming in dBASE II, when improving one line of code stopped another from working. I formulated it as a theory and a practice on the 1998 defense contract above, and it is built into ARA™ RAM 2025™ today. Every technology era since has handed it the same question.
Illustrative. AI operating system layers as published by McKinsey, 13 October 2026. Hansen is not affiliated with McKinsey.
The graphic shows how this works. On the left is the operation as it actually runs, with the incentives, shadow systems and workarounds that never appear on the documented map. Tracing back from an outcome that fell short shows which strands crossed and where. That validated picture of how the work really happens is what should feed the platform on the right, whatever the platform is: McKinsey’s AI operating system in the illustration, SAP’s AI platform in this post, or whichever comes next. A platform is only as good as the picture of the operation it is built on.
The test
So here is the test I would put to any platform, from any provider, in any era. It is not the one most organizations use.
The usual test asks the platform three questions. Can people get the data they need? Can they get the approvals they need? Can they finish the work in time? A vendor will answer yes to all three, and in a demo every answer will be true. The data is integrated, the approvals are automated, and each step is faster.
But each of those answers is true inside its own silo. In 1998, procurement could truthfully have said it processed every order by the end of the day. The technicians could truthfully have said they were maximizing service calls. The couriers kept to their cutoff times. Every group passed its own test, and next-day delivery still ran at 51%. The failure was not inside any group. It was in how the groups combined.
That is the aperture problem. The usual test looks along one strand at a time, so it measures siloed interests and misses collective impact. Hansen Strand Commonality™ widens the aperture to every strand at once, including the ones nobody documented. The workaround lives in the collective impact. It also lives outside the process map the platform will be configured from: in the unapproved AI tools, the spreadsheets and the side channels, including the ones used by the people at the top.
So the test has to start from the workaround, not from the platform:
Then ask the platform one question: does it change that crossing, or does it only make each silo faster?
If it changes the crossing, people come back to the approved route on their own, because the reason they left is gone. If it only makes each silo faster, the workaround survives, often in a new tool, and in a few years someone will be asking the same question of the next technology.
No platform answers this question by itself, SAP’s included. The answer is in the operation, not the technology. That is why the question has to be asked first, of how the work actually runs, before any platform is judged by what it can do.
Same platform, opposite outcomes
I asked Christian where he had seen this work well in an SAP environment. He answered with a case: a video of NVIDIA’s SAP implementation, and the line, “If Nvidia can do it with SAP, everybody can do it.”
It is a good case. But a success story answers the question with technology again: it worked there, so the platform must be the reason. The record says otherwise.
Ontario’s Education Collaborative Marketplace (OECM) and Virginia’s eVA program both ran on Ariba. OECM had modeled its program on eVA’s. OECM’s implementation failed. Virginia’s succeeded. The Virginia team was clear about why: Ariba did what it was supposed to do, and they would have succeeded with another platform.
Then Virginia showed it. It later moved eVA from Ariba to Ivalua, and the program kept operating at scale. In fiscal year 2025, eVA recorded $13.3 billion in purchase-order spend across 763,040 transactions (eVA FY25 Entity Spend Report, Commonwealth of Virginia).
So the same platform produced opposite outcomes, and the same program succeeded on two different platforms. If the outcome changes when the platform stays the same, and stays the same when the platform changes, the platform is not the variable that decides it.
Expertise in the platform isn’t the variable either. In my white paper on SAP implementations, I documented Hewlett-Packard struggling with its own SAP rollout while it was selling SAP integration expertise to its clients.
NVIDIA’s case shows what worked at NVIDIA. A case study can show what’s possible. It rarely tells you how likely another organization is to succeed, because no two organizations are the same, even when they look alike from the outside. Their strands are different, and so are the places where those strands cross. The work of implementation has to start with how the client actually operates in the real world. That has held across every technology era in the record, as set out in Let’s Stop Crediting Technology for Success, and Blaming Technology for Failure (June 2026).
That is the workaround question again, from the other side. A platform doesn’t end a workaround. Understanding why people needed one does.
The question that stays
Invariant Physics™ is a claim that can be disproved. If a technology era ever answers this question by itself, the record will have to say so. It hasn’t happened yet.
So before your organization adopts its next platform, AI or otherwise: which task are your people already doing around the system, and which strands crossed to put it there?
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
-30-
Share this:
Like this:
Related