Ask an operations director what their throughput was last Tuesday and you’ll usually get one of two answers. Either “I’ll have to pull that together,” or a number that turns out to disagree with a different number from a different system.
This isn’t a reporting problem. It’s a structural one, and it’s worth being precise about why.
The data exists. It just doesn’t agree.
A mid-sized operation typically runs on somewhere between five and fifteen systems. A rostering tool. A time and attendance system. Something for assets or vehicles. A maintenance log. A handful of spreadsheets that quietly became load-bearing. Increasingly, a scanner or sensor feed producing events nobody has ever queried.
Each of these is fine on its own. The trouble starts when you try to answer a question that crosses two of them.
Say you want to know whether a particular shift pattern causes overruns. Shifts live in the rostering system. Overruns live in the operational log. To connect them you need to know that employee 4471 in one system is T-4471 in the other, that one records local time and the other UTC, and that “shift end” means scheduled end in one place and actual clock-out in the other.
Nobody wrote that down. It lives in the head of the person who does the monthly report, and they do it by hand, and it takes them a day and a half.
That is the real cost of siloed operational data. Not storage, not licences — the fact that every cross-system question needs a human translator.
Why the usual fix underdelivers
The instinctive move is to build a data warehouse: pipe everything into one database, point a BI tool at it, done.
You should do this. It just doesn’t finish the job, for a reason that catches a lot of teams out.
A warehouse consolidates storage. It doesn’t consolidate meaning.
After the pipelines are built, you have all eleven systems’ tables in one place — and you still need to know that emp_id and staff_ref are the same person, that duration_min excludes breaks in one source and includes them in another, and that three different tables have a column called status with three unrelated sets of values.
So you’ve moved the translation problem, not solved it. It used to live in a person; now it lives in a growing pile of transformation logic that one engineer understands. When a source system changes a field, something downstream breaks quietly, and you find out when a number looks wrong three weeks later.
What a semantic layer actually is
The missing piece is a layer that carries meaning alongside the data.
Concretely: instead of a table with a column called dur_2, you have a defined concept — task duration — that knows it’s measured in minutes, that it excludes breaks, that it comes from these two sources reconciled this way, and that it belongs to a task, which belongs to a person and a location.
Once that exists, several things get easier at once.
In practice
- One definition per metric, version-controlled alongside the model.
- Joins and grain declared once, not rediscovered in every query.
- Plain-language questions resolve against known terms, not guessed columns.
Questions stop requiring a translator. “Show me task durations by shift pattern” resolves without anyone remembering which system holds what.
Source changes stop breaking things silently. The mapping is declared in one place rather than scattered through queries.
And — the part most people underestimate — a language model becomes genuinely useful. This is worth dwelling on, because it’s where a lot of “AI for operations” projects quietly fail.
Why this matters for anything conversational
Point a language model at raw operational tables and it will confidently produce wrong answers. Not because the model is bad, but because it has no way of knowing that status = 3 means “cancelled by supervisor” or that one table double-counts rows created by a legacy sync.
It has no access to the meaning, so it guesses. And a plausible-sounding wrong number in an operational context is worse than no answer at all.
Give the same model a semantic layer, and its job changes completely. It no longer has to infer what a column means — it looks up a defined concept and its relationships. “How many tasks ran over yesterday” becomes a lookup against a known definition of ran over, not an improvisation.
This is the difference between a chatbot that can query your database and a system you’d let a supervisor rely on mid-shift.
The order that works
If you’re starting from eleven systems and a monthly spreadsheet, the sequence matters more than the tooling.
1. Pick the questions first. Not “what data do we have” but “what do we repeatedly need to know and can’t answer quickly?” Three or four questions is enough. They tell you which sources actually matter, and they stop you from building a beautiful warehouse nobody queries.
2. Bring in only the sources those questions need. Resist completeness. A pipeline you don’t use still costs maintenance every time the source changes.
3. Define the concepts before you build the dashboards. This is the step everyone skips. Agreeing what task duration means, in writing, across departments, is unglamorous and occasionally contentious — and it’s the thing that makes everything after it work.
4. Keep it current automatically. A dataset refreshed by someone remembering to run something is a dataset that will be stale exactly when it matters.
5. Then put an interface on it. Dashboards, natural-language querying, or both. Do this last. An interface over undefined data just distributes confusion faster.
Where OptiControl fits
This is the layer we built OptiControl to be. It connects operational systems into a single database per customer, holds the definitions that make the data mean something, and keeps it current with scheduled jobs rather than manual refreshes.
It sits underneath everything else we do, and that’s deliberate. Optimization is only as good as its inputs — a scheduling engine given inconsistent duration data will produce a confident, well-reasoned, wrong plan. Getting the data layer right isn’t preparation for the interesting work. It’s what makes the interesting work possible.
Optimum Intelligence builds optimization systems for real-world operations — ground handling, distribution, and facilities. If your operational data is spread across systems that don’t agree with each other, we’re happy to talk.