This is the first in an ongoing series on Operations Research and Decision Intelligence (OR/DI). This piece names the problem, why growing investment in data and analytics hasn't translated into proportionally better operating decisions, and then clears up the confusion that comes up as soon as OR/DI is on the table: how it relates to AI, and specifically to large language models (LLMs). Later parts build on both halves: showing how OR/DI fits into a data platform, how it connects an enterprise across time horizons, and what applying it looks like in practice.
Every large organization today has more data, cheaper compute, and more analytics than it did five years ago. Forecasting models are common. Dashboards are everywhere. AI pilots are running in most functions. And yet, the everyday experience inside these organizations tells a different story: forecasts exist, but decision quality barely moves. Dashboards exist, but people still find bottlenecks by hand, days after the fact. AI gets deployed, but supply chains keep breaking, schedules keep slipping, and budgets keep getting reallocated by instinct rather than by calculation.
The natural conclusion is that the organization needs more data, a better model, or a newer AI tool. That conclusion is usually wrong. The gap isn't a shortage of analytics. It's that analytics and decision-making are being treated as the same activity, when they answer fundamentally different questions.
Most organizations have a long-standing habit, reasonable in its origin but misleading in its consequence, of labeling any report, dashboard, or forecast as “decision support.” It is accurate in the loosest sense: a chart does support a human who is about to make a decision, the same way a weather report supports someone deciding whether to bring an umbrella. But the label quietly implies more than it delivers. It suggests the hard part, weighing options against real constraints and picking the best one, has already been handled, when in fact it has been left entirely to a person, informally, without any tool checking whether their choice is actually the best one available.
This habit is not a minor semantic issue. It is why so much analytics investment plateaus: teams keep building better dashboards and more accurate forecasts, genuinely believing they are getting closer to better decisions, when they are actually just producing better-quality inputs to a decision step nobody has built.
A demand forecast is analytics. A purchasing plan that says exactly how much of each of 500 SKUs to order, from which supplier, to minimize stockouts and holding cost within a fixed budget, is a decision. The forecast can be perfect and the business can still make a bad purchasing call, because nothing translated the forecast into an action under real-world limits.
This gap persists not because of a lack of ambition. It's a lack of the right discipline in the toolkit. Operations Research (OR) is a decades-proven, rigorously mathematical field built specifically to close it: a family of methods engineered to find the provably best action under real constraints, not just a plausible-looking one. It sits within the broader field of Decision Intelligence (DI), the umbrella that also includes data science, predictive AI, and generative AI, as the piece that decides rather than describes or predicts.
Until recently, OR was expensive, slow, and required specialist teams most companies couldn't justify. That has changed: compute is cheaper, data volumes are far larger, and open platforms have matured enough that adding a decision layer on top of existing analytics is now a realistic, incremental step, not a multi-year research project.
That relationship between OR/DI and AI, and specifically large language models, is the natural next question, and it's where most of the confusion starts.
Because LLMs are the most visible AI technology today, organizations tend to fall into one of two mistaken positions. The first folds OR/DI into the general “AI trend,” treating an optimization model and a chatbot as points on the same spectrum, just at different levels of sophistication. The second treats OR/DI as a legacy discipline made obsolete by generative AI, something from “before AI got good.” Both are wrong, and both come from the same root cause: judging every technology by how well it writes or talks, which is the one thing LLMs are built to optimize for and OR was never trying to do.
An LLM is a technology for generating plausible content: text, code, images, summaries. It answers the question “what looks like a correct answer?”, and it answers that question exceptionally well wherever correctness is ultimately judged by a human reading the output. OR answers a fundamentally different question: “which decision is mathematically best, given these constraints and this objective?” It returns a provable, measurable answer, not a persuasive-sounding one.
Concretely: ask an LLM to write a maintenance schedule for 60 assets across 4 crews with parts and regulatory constraints, and it will produce something that reads like a schedule: plausible, well-formatted, confident. It has no mechanism to guarantee the schedule is feasible, let alone optimal, because feasibility and optimality were never what it was trained to produce. An OR model given the same inputs will not always produce fluent prose about the schedule, but it will guarantee the schedule respects every stated constraint and is the best (or provably near-best) among all feasible options.
In every one of these patterns, the division of labor stays intact: language and content generation on one side, constrained optimization and provable decisions on the other. The value comes from combining them deliberately, not from expecting one to quietly absorb the other's job.
Getting this distinction right changes how organizations invest. Betting entirely on LLMs to “handle decisions” produces confident-sounding recommendations with no guarantee they respect real-world constraints, a risk that grows, not shrinks, as those recommendations get automated further downstream. Dismissing OR as outdated next to LLMs skips the one technology purpose-built to make a decision provably correct, and leaves that job to human judgment or to a tool that was never designed for it.
The next article in this series moves from concept to architecture: how a decisioning layer built on OR/DI fits into a data platform an organization already has, as an incremental, evolutionary addition, not a rebuild, working alongside BI, ML, and LLM/GenAI as one more composable capability.
