By 1993, our logistics firm's IT department had earned a certain reputation. The Mylex episode had made believers out of sceptics, Windows NT was rolling out across German sites, and small Access applications were appearing on desktops like wildflowers. People had started to trust that the IT team could actually move things forward.
Meanwhile, in a quieter part of the building, another problem had been festering for months: parcels were disappearing.
Not in dramatic quantities — just enough to be expensive, and just frequently enough to be infuriating. Insurance claims were filed. The support department investigated but did not find a pattern.
The losses were written off, and the problem continued. Nobody looked into the raw data. The entire operational backbone of the business — an Informix system on SCO Unix for accounting and payroll, an AS/400 for logistics and parcel operations — was generating data on every single scan, every single movement, and every single handoff in the network. Somewhere in that data, the answer was waiting.
The Wrong Tool for the Right Question
My introduction to the problem came sideways, through a different task entirely. I was asked to fix a slow laptop for a colleague in the operations analysis team. Turned out he was trying to find pattern in the logistics operations data to solve the disappearing parcel mystery.
He showed me what he was working on: enormous Excel spreadsheets, tens of thousands of rows, macros that ran for minutes and sometimes simply gave up. He suspected he needed more RAM.
My boss looked at what he was trying to do and said something that has stayed with me ever since: the problem isn't the hardware. It's the wrong tool.
Excel had a hard ceiling of 65,000 rows. My colleague needed to work with half a million records. No amount of RAM was going to fix that. What he needed was a database.
First, we looked into Oracle. The licence costs and the required specialist training made it a non-starter. A little later, my boss came back into my office and put two boxes and a stack of books on my desk: Sybase/Microsoft SQL Server 4.2, and everything published about MS Access data programming. "Here. Figure it out".
Learning to Ask the Data a Question
The task was genuinely fascinating to think about.
We had CSV exports from the scan software: every barcode that identified a parcel, every scan code that recorded its status and location as it moved through the network. Import that data. Write queries. Find the parcels that entered the system and never came out the other side — the ones with an open end, no final delivery scan, no return record.
What made it interesting were nuances in the intersection of statistics and business:
- what sequence of scan codes represented a legitimate delay?
- what sequence was statistically anomalous?
- Which depot, which operator, which route appeared in the data when high-value items went quiet?
The answer to the theft problem wasn't in any one record. It was in the shape of the data that fraud left behind in thousands of individually innocent-looking data points.
My colleague was sceptical. He'd been running Excel for months and finding nothing. As a first test, he gave me a specific challenge: a one-month window during which seven high-value parcels — Sony and JVC video recorders and CD players — had gone missing at a known location. Could I find them?
He expected it to take half an hour. The query returned in seconds. The little MS Access status bar barely had time to flicker. He looked at me. I looked at the screen. We both understood that this was it.
Building the Pipeline
Over the following weeks, we built something properly useful.
Nightly batch jobs pulled scan data from depots across the network. The Access database ingested it automatically and ran a suite of queries: parcels entering the system, parcels leaving it, the difference between the two. Most discrepancies resolved themselves within a few days — legitimate delays, rescans, routing corrections. The ones that didn't resolve were the ones worth watching.
My colleague would study the outputs, identify the anomalies that matched our evolving profile of genuine loss, and then do something refreshingly direct: get in his car and drive to the depot to look.
Sometimes he actually found the lost parcel — mislabelled, misrouted, sitting in a corner, and often that was the end of it. But occasionally he didn't, and these cases kept pointing in the same direction.
The Barn
When we ran the full query against the largest depot in the network, the statistical pattern was unambiguous. So, we went to the police.
The investigation led to a barn belonging to a family member of one of the drivers. Inside: furniture, fridges, television sets — and our missing parcels. It was a larger operation than we had suspected, with tentacles well beyond our network.
The forensics system had done its job.
The Outcome Nobody Expected
Here is something that was unexpected...
We had plans. I wanted to migrate the Access system onto a proper SQL Server architecture — client-server, automated ingestion, robust and scalable. A continuous fraud monitoring platform. The kind of thing that could run quietly in the background, flagging anomalies every morning before the first shift.
We never built it, because we didn't need to.
Word spread through the depots — not the accurate version, but a better one. Staff began to believe that the barcode scan software itself was detecting theft automatically and that anyone stealing would be caught. The fear of a system that didn't even exist yet, turned out to be more effective than the system we were going to build.
Losses dropped. The problem went away.
What This Has to Do With Everything That Came After
The tool we built was modest by any later standard: a desktop database, some carefully written queries, a nightly CSV import. But the thinking behind it was the same thinking that underpins every serious data-driven system I've worked with since — including the AI workflows we build today.
The data already contained the answer. It had contained it for months while the problem was being investigated by people looking in the wrong places. What changed wasn't the data. What changed was having a structured way to ask it the right questions.
That's still the work. The databases are faster, the queries are more sophisticated, and the patterns we're now able to detect are far more subtle. But the fundamental insight is unchanged: before you can find the signal, you have to decide what question you're actually asking.
Get that right, and the answer tends to come back faster than you expect.
What I Kept
I left the firm years ago.
What stayed with me from this story was the realisation that the best solution we deployed was one that existed only as a rumour. As an engineer, you want to build the real thing — the machine that flags the anomaly before the first shift clocks in, the one that's actually true — and the lesson I couldn't shake was that sometimes it doesn't need to be true so much as it needs to be believed.