Most operations have a lot of data about what they meant to do.
The rostering system holds who was supposed to work. The planning tool holds which tasks were supposed to happen and when. The ERP holds what was supposed to be delivered, to whom, by which route. It’s tidy, it’s complete, it goes back years, and every reporting project starts there because it’s the data that’s easy to get at.
It’s also a record of intentions. It describes a series of days that didn’t quite happen.
The data about what actually happened is usually thinner, messier, and held in places nobody has connected — a scanner log, a timestamp from a reader, a photo, a driver’s app. And it’s worth more than all of the above, for a reason that takes a moment to see.
The gap is the only honest number you have
If you only have plan data, you can report on the plan. How many tasks were scheduled, how many people were rostered, what the theoretical utilisation was.
Every one of those numbers describes a document.
The moment you also have execution data, a different class of question opens up. Not “how many tasks did we schedule” but “how many started when we said they would.” Not “what’s the standard time for this task” but “what does it actually take, and under which conditions does it take longer.”
Plan against actual is the only measurement in your operation that isn’t self-referential. Everything else is the plan grading its own homework.
And it’s the input that makes everything downstream better. A scheduling system given real durations produces feasible plans. Given standard times from a manual written in 2011, it produces confident, well-reasoned, wrong ones. The solver isn’t the weak link. The duration estimate is — which is half of why good optimizers still produce shifts that fall apart.
Three things you can only get from execution data
Durations that reflect reality. Covered above, and it’s the one with the clearest financial return. A plan built on wrong durations is wrong in both directions all day, and no amount of optimizer sophistication fixes an input problem.
Evidence. Under the new EU ground handling rules, and in any insurance or contractual dispute, the useful record is the one that says a specific task was performed at a specific time by a specific person. Planning data says it was supposed to be. Those are not the same claim and only one of them survives a question.
Live divergence. This is the one people underestimate. If you know what was supposed to happen and you know what’s happening, you can see them separating while there’s still time to act. Without execution data you find out at the end of the shift, when the only available action is writing it down.
Why almost nobody collects it
Three reasons, and they’re all reasonable.
It feels like overhead. Someone has to scan something, press something, confirm something, and that’s seconds taken from a person who is already busy. The benefit is invisible for months and the cost is immediate and personal.
It needs hardware in the field, which means procurement, mounting, charging, breakage, and a rollout. Nobody enjoys that project.
And there’s no obvious payoff on day one. A month of execution data tells you very little. Six months tells you a great deal. The gap between those two is where most of these initiatives quietly die.
The objection worth taking seriously
There’s a fourth reason, and it’s the one that actually kills projects: people think you’re measuring them.
Sometimes they’re right, because sometimes that’s what the buyer wanted. And I’d argue that’s both a bad idea and a self-defeating one.
If execution data is used to evaluate individuals, you get gamed data. People scan at convenient moments rather than accurate ones. Tasks get marked complete before they’re complete because the shift is ending. The numbers stay clean and stop being true, and you’ve spent real money to make your inputs worse than the standard times you were trying to replace.
Use it to measure the plan instead, and the incentive inverts. When a task consistently takes thirty-two minutes and the plan says twenty, the honest scan is the one that makes the crew’s life better — because it’s what eventually gets the plan changed. Now the person holding the scanner has a reason to be accurate.
That’s not a soft point about culture. It’s a data quality argument. You will get better numbers from a system people trust, and the way you make it trustworthy is by being specific, publicly, about what it’s used for and what it isn’t. Say it out loud at the start, and then don’t break it.
Start narrow
The instinct is to instrument everything, which is how you end up with a two-year rollout and no results.
Better: pick the handful of tasks where the duration estimate matters most. Usually those are the ones on the critical path — the task that, when it runs long, makes something else late. In ground handling that’s a short list and everyone knows what’s on it. In distribution it’s usually the drop itself rather than the driving.
Instrument those. Leave everything else alone. You’ll have useful data in weeks rather than years, and you’ll find out whether the whole idea works before committing to it.
Then let it accumulate before you draw conclusions. The first month of execution data mostly tells you about your capture process, not your operation. The interesting patterns — that a particular stand is reliably slow, that Fridays run differently, that one crew’s times are tighter because they’ve solved something nobody wrote down — need months to show up.
The order that works
Measure before you optimize. This is slightly against my own commercial interest and I’ll say it anyway.
If you don’t know what your operation actually does, an optimizer is an expensive way to formalise your assumptions. Six months of honest execution data will tell you whether there’s enough variance and enough waste to be worth optimizing, and it’ll tell you where. Sometimes the answer is that your durations are fine and your problem is somewhere else entirely — and that’s a cheap thing to find out before a procurement process rather than after one.
It also means that when you do buy a scheduling system, you arrive with the one asset that makes it work immediately instead of after a year of tuning.
The planning data was never the valuable part. It’s a record of what you decided. The scanner log is a record of what’s true, and truth is the thing you can’t get anywhere else. Where it goes once you have it — and why one place with shared definitions matters — is the semantic layer argument.
Optimum Intelligence builds OptiScan for field data capture and OptiControl for holding operational data in one place with the definitions that make it mean something. If you’re planning against numbers nobody has checked in years, we’re happy to talk.