flowchart LR
A[Business Requirements] --> B[Business Problem]
B --> C[Collect & Clean Data]
C --> D[Explore Data]
D --> E[Build & Evaluate Models]
E --> F[Deploy]
F --> G{Used by Business?}
Part 3 of 4 · Thinking in Systems
THINKING IN SYSTEMS WITH AI
Why Data Science and AI have not delivered the value businesses expected, and why it is not an IT problem
AI
data science
systems thinking
business
Why Data Science and AI have not delivered the value businesses expected, and why it is not an IT problem
This article is written for the CXOs and business heads who decide where Data Science sits in their organization and who owns what it delivers. It is also for the Heads of Data Science who make it worth it. My argument is simple AI is not an IT project. It is a business loop, and it works only when business and Data Science learn from each other.
I have divided this article into three parts, followed by my learnings. The first part looks at the gap between Data Science and business, from both sides. The second part asks whether Data Science is used as a functional tool or as a steering wheel, using a simple banking example. The third part looks at AI through the lens of systems thinking, and how the right roles, oversight and governance keep this loop healthy as AI becomes more autonomous.
I want to thank the many people who helped me think through these ideas, including the early leaders who shaped my thinking and perspectives. I am inspired by the work of Donella Meadows and her book Thinking in Systems, and by the recent book AI Oversight by Dr. Elena Alikachkina, Dr. Shama Patel and Bernhard Brouwer, which helped me think about the role of AI in systems thinking. I would also like to thank Ashok Vasudevan and Ireena Vittal for their thoughtful comments and feedback on this article.
1. Data Science/AI Process Flow
When I started my career in Data Science in 2013, all I knew was linear regression and logistic regression. However, I was excited to learn about the power of data and how it can help organizations make better decisions. Over the years, I have seen Data Science and AI evolve and become an integral part of the business decision-making process.
In the early days, most leaders recruited Data Scientists from the perspective of value creation and business impact. However, as I changed jobs and moved across different organizations and countries, I was always flabbergasted to see how Data Science became more of a technical function, mostly part of IT, with little interest in learning about the business and how its work fits into the value chain of the organization.
Many organizations followed this trend. They set up Data Science as a vertical within the IT department and started recruiting Data Scientists for their technical skills rather than for business impact. Over time, this reinforced itself: technical hires built technical teams, and the business side drifted further away.
1.1. How Data Science thinks about its role
Data Scientists come with a perspective of solving a problem using data and algorithms. They love the latest and greatest algorithms, and they rub their hands with excitement when they get to use them.
The linear flow of Data Science is: understand the problem, collect the data, clean the data, explore the data, build models, evaluate models and deploy models. In practice, the very first step, understand the problem, is the one that gets compressed or skipped. It is the least technical step, and so it gets the least attention.
As the years progressed, this flow got divided into more roles: Data Engineers, Data Analysts, Machine Learning Engineers and AI Engineers. However, the focus is still on the technical aspects of the work and not on the business impact.
1.2. How Business thinks about Data Science
Business leaders think about Data Science as a function that can help them make better decisions. But in practice, most businesses delegate to Data Science rather than participate with it. A request goes in, a model comes out, and the business judges the result without ever being part of how it was shaped. Expectations swing between two extremes: either Data Science is expected to work magic, or it is not trusted at all.
What is needed is a knowledge corridor between Data Science and business, a two-way path where each side learns enough about the other. Data Scientists need orientation towards its priorities, its processes and the metrics it is judged on. Management, in turn, needs enough understanding of Data Science, data visualization and the capabilities and limitations of the tools to frame expectations intelligently. The goal is for business leaders to participate in the use case, not simply hand it over.
Walking this corridor also means Data Scientists must learn to communicate the “so what?” Business leaders may not want to follow the quantitative complexity behind an analysis, but they do need to understand the implication, the decision and the value. Technical sophistication should enable the insight, not become a barrier to it. This is also a recruitment gap, because most Data Scientists are hired for their technical skills, and very few are hired, or trained, to walk this corridor.
For a few use cases, teams were able to demonstrate business impact and deploy models into production. But the reality is that the majority of models never make it to production, by most industry estimates. This is not only a technical problem to fix with MLOps or DevOps. It is equally a business problem, to be fixed with the right recruitment, the right oversight and the right governance.
Slowly, over the years, business leaders absorbed the idea that Data Science is a technical function. They built processes around it to validate the outcome of Data Science work and to assess how well it fits into the larger process of the organization. This is a wonderful step, but…
1.3. What are we missing in the process flow
…the missing piece is the feedback from the business back to Data Science. The feedback loop is missing in the process flow. Without it, there is no way to understand the business impact of the work or to assess how well it fits into the larger process of the organization.
Where there was understanding on both sides, business and Data Science, the feedback loop worked. Models were deployed in production and kept improving, even without a mature MLOps or DevOps process, because the feedback loop itself demanded refined models. The business demands from Data Science, and in turn Data Science demands feedback from the business, to improve the models and ultimately add value.
In Donella Meadows’ language, this is a reinforcing loop: feedback leads to better models, better models build trust, trust brings more use cases, and more use cases bring more feedback. When the loop is missing, the system does not just stay still. It stalls, and models quietly sit on the shelf.
flowchart LR A[Business Need] --> B[Data Science Builds Model] B --> C[Embedded in Business Process] C --> D[Business Outcome] D -. "feedback (often missing)" .-> B D -- "trust & new use cases" --> A C -. "no feedback" .-> X((Model Stalls))
2. Data Science in the Value Chain
My hypothesis is that an organization can use Data Science in two very different ways. It can use it as a functional tool, which delivers a model when asked and steps away. Or it can use it as a steering wheel, which helps the business decide where to go, and keeps correcting the direction as the road changes. The technology is the same in both cases. The value is not.
Let us test this with a simple example. Assume there is a brick-and-mortar bank. The bank sees that its staff is working overtime, and it feels that it needs either to open more branches or to create an online banking platform. Decision making is the responsibility of the management, and assume they decide to build an online banking platform.
Since the management does not have the technical expertise to build the platform, they hire a Head of IT. The Head of IT hires a team of software engineers, who build the platform and deploy it to production. From here on, the management monitors the usage of the platform and makes decisions based on the usage data. The responsibility of IT is to build and run the platform. The responsibility of the management is to decide.
flowchart LR A[Staff Overtime] --> B[Management Decision:<br/>Online Banking] B --> C[IT Builds Platform] C --> D[Platform Live] D --> E[Usage Data] E --> B
Now, assume the management wants to move more customers to the online platform. The question for the management is: is this a technical problem or a business problem? Since this is a straightforward business problem, they usually hire a Head of Online Banking. The Head of Online Banking realizes that customers first need to be aware of the platform. So, with a limited budget, the team runs a marketing campaign, and soon customers start using the online platform.
Later, the management notices that the percentage of customers using the online platform has become stagnant, and they are unable to understand why. The marketing campaigns show a positive uplift during the campaign period, but once the campaign ends, usage goes down again. Now the management learns that Data Science can help them understand customer behavior and create personalized marketing campaigns to increase usage.
Let us consider two scenarios: a Data Science team within IT, and a separate Head of Data Science reporting to the management.
In the first scenario, Data Science is a functional tool. The Data Science team within IT builds models to understand customer behavior and create personalized campaigns. The Online Banking team is responsible for the outcome of the campaigns and for explaining the results to the management. Depending on the outcome, the Online Banking team continues or stops the campaigns. The Data Science team’s job ends when the model is delivered. The feedback exists, but it stops at the Online Banking team and never reaches the model.
flowchart LR
subgraph BIZ["Business"]
M[Management] --> PT[Online Banking Team]
end
subgraph ITD["IT Department"]
DS[Data Science]
end
PT -- "request" --> DS
DS -- "model" --> C[Campaign]
C --> O[(Outcome)]
O --> PT
O -. "feedback never reaches DS" .-x DS
style ITD fill:#fdecea,stroke:#c0392b
In the second scenario, Data Science becomes the steering wheel. The Data Science team is responsible not only for building the models, but is also co-responsible for the outcome of the campaigns and for explaining the results to the management. They collaborate with the Online Banking team to make sure the campaigns are effective and that usage keeps increasing. This creates a feedback loop between the Data Science team, the Online Banking team and the management, which keeps improving the campaigns and the usage of the platform.
flowchart LR
subgraph BIZ["Business"]
M[Management] --> PT[Online Banking Team]
M --> DS[Data Science]
PT <-- "co-own outcome" --> DS
end
DS -- "model" --> C[Campaign]
C --> O[(Outcome)]
O --> PT
O -- "feedback" --> DS
DS -- "so what?" --> M
style BIZ fill:#e8f5e9,stroke:#27ae60
This collaboration will further increase the business understanding of the Data Science team, and they no longer see the problem as just predictive modelling but as a business problem of changing customer behavior. They start asking different questions. Why do customers go back to the branch once the campaign ends? Is it trust, habit, or something missing in the platform itself? These questions go beyond marketing. They feed back into how the platform is designed and even how the branches serve customers. This is the point where Data Science stops being a support function and starts becoming part of the value chain.
Clarification: A Head of IT would rightly say that their systems also add business value. If a customer is not able to complete a transaction, the bank loses the customer’s trust. If an insurance company’s systems delay a submission, it loses the opportunity. Both are true. But in both cases, the technology is meeting an expectation. It is not extracting a new opportunity. When these systems fail, it is a failure of service. When they work, the customer simply gets what they expected. This is protecting value, not creating value.
This does not mean IT never creates value. Launching the online banking platform itself relieved the branches and opened a new channel. And Data Science can also protect value, for example by detecting fraud. So the real difference is two questions: does the work protect value or create it, and does it execute once or learn over time?
quadrantChart x-axis Protects Value --> Creates Value y-axis Executes --> Learns quadrant-1 Compounding Value quadrant-2 Smarter Protection quadrant-3 Keep the Lights On quadrant-4 New Capability Transaction Uptime: [0.2, 0.2] Policy Submission: [0.3, 0.3] Online Platform Launch: [0.75, 0.25] Fraud Detection: [0.25, 0.75] Personalized Campaigns: [0.8, 0.8]
Most of IT lives in the bottom half, and it should, because stability is its job. Data Science earns its place in the top right only when the feedback loop closes, like our second scenario. That is where value does not just arrive once. It compounds.
2.1. Seeing Adoption as a Stock and Flow
Let us come back to our online banking adoption, and look at it through the simple stock and flow lens of Donella Meadows. The stock here is the number of active online banking customers. The bank wants this stock to grow, because every customer who moves online reduces branch load, reduces staff overtime and ultimately reduces opex. The stock fills through an inflow, branch customers adopting online banking, and drains through an outflow, customers drifting back to the branch.
flowchart LR
B[Branch Customers] --> IN{{Adoption}}
IN --> ST[("Active Online<br/>Customers")]
ST --> OUT{{Drop-off}}
OUT --> R[Back to Branch]
Now, the Data Science team builds a customer segmentation model to target the right customers and improve the inflow. Similarly, there is a retention model that tries to reduce the outflow. Both models have the same intention, which is to grow the stock. But each model optimizes its own flow in isolation. The segmentation model does not know who is leaving, and the retention model does not know who was brought in and why.
flowchart LR
subgraph INF["Inflow team"]
direction TB
SEG[Segmentation Model] -.-> IN{{Adoption}}
end
ST[("Active Online<br/>Customers")]
subgraph OUTF["Outflow team"]
direction TB
RET[Retention Model] -.-> OUT{{Drop-off}}
end
B[Branch Customers] --> IN --> ST --> OUT --> R[Back to Branch]
style INF fill:#eef6f5,stroke:#0b6e6e,color:#0f1b2d
style OUTF fill:#fbede5,stroke:#b4410b,color:#0f1b2d
Now, assume the stock is still improving, but more slowly than expected. Meadows reminds us that stocks change slowly by nature, because they only move through flows and with delays. So slow growth is not failure by itself; it is a signal to look at the structure. This is where the outflow needs to talk back to the inflow. Which type of customers are moving away? Is the segmentation model bringing in the wrong customers? Is the UI confusing a particular group? The answers bring in other teams, such as UI experience, and they also improve the existing models that were not capturing the right segments.
flowchart LR
B[Branch Customers] --> IN{{Adoption}}
IN --> ST[("Active Online<br/>Customers")]
ST --> OUT{{Drop-off}}
OUT --> R[Back to Branch]
SEG[Segmentation Model] -. "increases" .-> IN
RET[Retention Model] -. "reduces" .-> OUT
OUT -- "who leaves & why" --> SEG
OUT -- "who leaves & why" --> RET
OUT -- "pain points" --> UX[UI Experience Team]
UX -. "improves" .-> IN
This feedback unlocks value in three places at once: better models, a better UI experience, and ultimately a deeper understanding of the customer. None of this value came from a new algorithm. It came from connecting the flows.
When the Data Science team is embedded in this feedback loop by design, value is not created just once. It compounds. Every cycle teaches the bank something new about its customers, and that learning goes into the next cycle. In Meadows’ language, this is a reinforcing loop. It works like a simple cycle of Design, Deploy, Measure and Learn, running continuously around the inflow and the outflow.
flowchart LR
subgraph Loop["Learning Loop (Reinforcing)"]
D1[Design] --> D2[Deploy] --> D3[Measure] --> D4[Learn] --> D1
end
B[Branch Customers] --> IN{{Adoption}}
IN --> ST[("Active Online<br/>Customers")]
ST --> OUT{{Drop-off}}
OUT --> R[Back to Branch]
D2 -- "models & UI changes" --> IN
D2 -- "retention actions" --> OUT
ST -- outcomes --> D3
This is the difference between Data Science as a support function and Data Science as part of the value chain. In the first, a model is delivered and the job is done. In the second, the model is only the first turn of the loop.
3. AI Through the Lens of Systems Thinking
We have seen an introduction to feedback loops in the previous section. Now let us understand a few more concepts of systems thinking, and how value gets generated, or lost, inside these loops.
Let me give a broad understanding of how systems work, inspired by Donella Meadows’ book Thinking in Systems. Assume our body is a large system. It has multiple organs, and each organ is a system by itself, made of cells that are systems by themselves. No single organ is “the body,” yet together they keep us alive. Meadows points to a few properties that make such systems work well.
Resilience. When we feel hot, we sweat. When we feel cold, we shiver. These are balancing loops that keep the body stable despite changes outside. A resilient system is not one that never gets disturbed. It is one that has enough loops to recover.
Self-organization. The body does not just maintain itself. It learns and adapts. Muscles grow stronger with exercise, and the immune system remembers an infection it has seen before. The system builds new structure from its own experience.
Hierarchy. Cells serve organs, and organs serve the body. Each level has its own job, but every level exists to serve the level above it. Hierarchy works when the subsystems serve the whole.
Suboptimization. This is what happens when a subsystem’s goal dominates the goal of the whole. A cell that grows only for itself, ignoring the body, is a cancer. The cell is “succeeding” at its own goal while the body fails.
flowchart TB BODY["Body<br/>Goal: Stay Alive & Healthy"] BODY --- H[Heart] & L[Lungs] & B[Brain] & I[Immune System] H --- C1((Cells)) L --- C2((Cells)) I --- C3((Cells)) T["Temperature Change"] -->|sense| B B -->|sweat / shiver| BODY BODY -. "balancing loop" .-> T
Now replace the body with an organization. Functions are the organs and teams are the cells. The organization’s goal, in our bank example, is growing active online customers and reducing opex.
But not every organ plays the same role. Some give the body structure and stability: the skeleton holds it up, and the blood vessels carry what is needed to every organ. They are built once, they must not fail, and when they work well we never notice them. This is IT. It gives the organization resilience.
Other organs give the body the ability to learn. The nervous system senses, decides and adapts, and it gets better with every experience. This is AI. When it is in the loop, it gives the organization self-organization.
Both are essential. But nobody would build a nervous system the way they build a skeleton.
And suboptimization is exactly what we saw in our silos: the segmentation model optimizing the inflow, the retention model optimizing the outflow, marketing optimizing campaign clicks, IT optimizing uptime. Each team succeeds at its own goal, while the stock grows slower than it should.
flowchart TB ORG["Bank<br/>Goal: Grow Active<br/>Online Customers"] ORG --- MK["Marketing<br/>Goal: Campaign Clicks"] ORG --- IT["IT<br/>Goal: Uptime"] ORG --- DS["Data Science<br/>Goal: Model Accuracy"] ORG --- OP["Branch Operations<br/>Goal: Footfall"] MK -. "suboptimization" .-x ORG DS -. "suboptimization" .-x ORG
3.1. How AI feeds the value chain and helps in systems thinking
The first step is a realization: AI is part of the business process, not a technical function sitting beside it. Once we see that, the role of AI in the organization looks very much like the nervous system in the body.
The nervous system senses what is happening, interprets it, decides and acts, and then senses again to see what changed. It connects organs that would otherwise work in isolation. AI can play the same role in an organization. Data is the senses. Models interpret and decide. Business processes act. Outcomes are sensed again as new data.
flowchart LR S["Sense<br/>Data from every flow"] --> I["Interpret<br/>Models & AI"] I --> D["Decide<br/>Recommendation<br/>or Action"] D --> A["Act<br/>Inside the<br/>Business Process"] A --> O[(Business Outcome)] O -- "feedback" --> S
This is where AI helps systems thinking itself. A human in one team sees one flow. AI can see across all the flows at once. It can show that customers who drop off were brought in by a particular campaign, that a UI change slowed adoption for one segment, or that a delay in one team is draining value in another. Meadows says one of the most powerful leverage points in any system is the structure of information flows: who knows what, and when. AI, when embedded in the loop, changes exactly that. It carries the outflow’s story back to the inflow.
3.2. Why AI is different from Traditional IT
This is where most organizations go wrong. They see code, servers and deployments, and conclude that AI is an IT project. It looks like one from the outside. But it behaves completely differently once it goes live.
An IT system is deterministic. Give it the same input and it gives the same output, today and five years from now. It is built to a specification, tested against it, and when it works, the project is done. Success means “delivered on time and it does not break.”
An AI system is probabilistic. It gives its best guess, and that guess is only as good as the world it learned from. And the world keeps changing: customers change, markets change, operations change, and the model quietly drifts. There is no specification to test against. The only test is the business outcome. So an AI system is never “done.” Deployment is not the finish line. It is the first turn of the loop.
flowchart LR
subgraph IT["Traditional IT Project"]
direction LR
R[Requirements] --> B[Build] --> T[Test] --> D[Deploy] --> M[Maintain]
M --> E((Project Closed))
end
subgraph AI["AI System"]
direction LR
P[Business Problem] --> MD[Model] --> DP[Deploy] --> OC[Outcome]
OC -- "feedback" --> MD
OC -- "new questions" --> P
W[Changing World] -. "drift" .-> MD
end
When AI is run as an IT project, it gets IT’s success measures. The project closes at deployment, the team moves to the next request, and no one owns the outcome. Nobody is watching whether the model is still right. This is exactly our first scenario from Part 2, where the feedback stopped at the Online Banking team and never reached the model. It is not about employing MLOps, but about employing the right engagement model and governance.
So the problem is not where AI sits on the org chart. It is the mindset it is managed with. Run it like a skeleton, built once and maintained, and its value decays. Run it like a nervous system, always sensing and always learning, and its value compounds.
3.3. Why it is more important now
Now, a few of these loops can be increasingly automated using Agentic AI, which can act directly on behalf of a person. Until now, AI mostly advised. A model gave a score, and a human read it and decided. The human was a natural pause in the loop. They were slow, but they were also a check. Agents act. In our bank, an agent can nudge each customer at the right moment, answer queries inside the app, offer a retention incentive and learn from every response, all without waiting for a human.
In systems terms, this removes the delays, and the loops spin much faster. When the loop is designed well, value compounds faster than ever. But Meadows reminds us that a reinforcing loop amplifies whatever it is fed. And an agent pursues its goal literally. Give a nudge agent the goal of “more logins,” and it may message customers so often that they get annoyed and go back to the branch. The agent succeeds at its goal while the outflow increases. That is suboptimization, now at machine speed.
flowchart LR
subgraph Before["AI Advises"]
direction LR
M1[Model] --> H1[Human Decides] --> A1[Action] --> O1[Outcome]
O1 -. "slow feedback" .-> M1
end
subgraph Now["AI Acts (Agentic)"]
direction LR
AG[Agent] --> A2[Action] --> O2[Outcome]
O2 -- "fast feedback" --> AG
end
Before ==> Now
So the question is no longer whether AI adds value. It does. The question is: when the human pause is removed, what replaces it? The body has balancing loops for everything that can grow out of control. An organization running agents needs them too, and they have to be designed on purpose.
And this is why the IT-project mindset becomes dangerous with agents. An IT project that goes live and is never revisited is just a stale system. An agent that goes live and is never revisited keeps acting, every day, on a goal that nobody is checking anymore.
3.4. AI Oversight and Governance
When the natural human check is removed from the loop, oversight becomes the new balancing loop. It does not slow the system down for its own sake. It keeps the agent’s goal aligned with the organization’s goal, so that the subsystem serves the whole. But who designs this balancing loop, and who owns it?
The book AI Oversight by Dr. Elena Alikachkina, Dr. Shama Patel and Bernhard Brouwer answers this clearly. Its starting point is the same as this article’s: AI is not an IT project. It makes the case that AI has to be understood at the board and corporate level, and it emphasizes that this does not require becoming a Data Scientist. A general working knowledge is sufficient, and the book walks through just the concepts that matter at that level. Its conclusion is that AI is a process that must be monitored, governed and audited, especially from the board and C-suite.
The book also describes how to shape the AI agenda with the C-suite, and how roles are evolving: new ones like the CAIO, changing ones like the CIO and CDO, and the shifting responsibilities of other CXOs. It walks through past AI failures to show that we are entering a new era of accountability. In systems terms, this is the answer to the gap we saw in Part 1: someone has to own the loop, and that ownership has to start at the top.
One idea from the book I found especially useful is the DRS AI Readiness Score. It suggests that an organization should pick the type of AI it adopts based on its readiness, rather than jumping straight to the most advanced option. The types range from Descriptive, Basic Predictive and Real-Time Predictive, through Assistive AI, Continuous Learning Loops and Operational AI Platforms, all the way to Agentic AI with goal-driven agents and Multi-Agent Ecosystems.
Seen through the lens of this article, each step up this ladder makes the loop faster and more autonomous, and so it demands stronger oversight and deeper data fluency. This is why the book’s point lands so strongly: oversight without data fluency is theatre. A board that cannot ask the right questions about its AI loops cannot act as their balancing loop.
I have deliberately not disclosed the details of the book here, but I strongly recommend reading it. It is extremely important at this stage, before we scale up AI. Otherwise, AI will stay in pilot mode for a long time, which is the same story we started with in Part 1, where most models never make it to production.
4. My Learnings
When I look back at my career, I always wondered why Data Scientists were not more interested in learning about the business and helping with its continuous improvement. I tried to motivate a few of them to learn. I always thought this was the fundamental problem: Data Scientists were simply not adding value to the business. These books helped me flip that perspective.
Early in my career, an operations manager told me something I never forgot. On the shop floor, if the pay is the same, workers will naturally choose the job that takes the least effort. When I extend this from blue-collar to white-collar work, I realize we are all fundamentally the same. This is not laziness. It is a rational response to how the system is designed. Passion, motivation and purpose matter, and for some people they are enough. But for most of us, who work primarily for a paycheck and stability, we need clarity and direction. Without them, and without a feedback loop that connects our work to its outcome, the system quietly settles into minimal effort.
This is exactly what Donella Meadows teaches: a system’s behavior comes largely from its own structure, not from the individuals inside it. Change the people and keep the structure, and you will get the same behavior. So the Data Scientist who never asks about the business is not the problem. The missing feedback loop is. They were never shown what happened after their model went live.
The fix has to come from both directions: awareness from the bottom up, and education from the top down. Along with this, organizations need the right structure, governance and team composition. One idea is to include process improvement experts, such as Six Sigma practitioners, within the AI team. Their entire discipline is built around understanding the business problem, measuring the outcome and closing the loop. They can help the AI team communicate with the business and comprehend its problems, and they can help design the right feedback loops and governance going forward. Not every loop needs to be, or should be, Agentic AI.
Finally, systems evolve and change over time. Feedback loops are not built once and forgotten. Like our muscles, they grow stronger with use and weaken without it. They need continuous maintenance and monitoring.
That, for me, is the real difference between IT and AI. One is built and maintained. The other has to be exercised.
This article has focused on the why: why Data Science and AI have not delivered the value businesses expected over the last decade. I have outlined a few suggestions along the way, but the next article will focus on the how: where Data Science could sit, how to design the feedback loop, and how to build the knowledge corridor, so that every model can finally answer the business’s question, “so what?” I will draw on books like Thinking in Systems and AI Oversight, and on what I have seen work, and fail, over my career.