The richest and cheapest data source in most facilities is already installed, and it is treated as an operational tool rather than a measurement instrument.
What to extract
Task lifecycle events: created, released, assigned, accepted, started, completed, cancelled. Each with a timestamp.
Location references at every step.
Item, quantity and unit of measure.
Order and wave references, which link tasks into customer-visible outcomes.
Exception and short-pick records.
Inventory adjustments, with reason codes.
Wave and release timing, which drives everything downstream and is frequently the hidden cause of congestion.
The extraction
Prefer a read replica or an export to querying the live system, which nobody will permit at the volume analysis requires.
Incremental extraction by timestamp, not full reloads.
Retain raw events. Aggregates cannot be un-aggregated when the question changes, and it will.
Include cancelled and failed tasks, which are where the exception analysis lives and which reporting extracts routinely omit.
Agree the identity policy here, because the operator field is present in almost every table.
The joins
To scan events, on task and item.
To telematics, on equipment and time.
To order data, on order reference.
To rota data, on shift, which is needed for aggregate analysis by shift and is the same field that would enable individual attribution — so handle deliberately.
To environmental data, on time and zone.
Wave and release timing
The most under-examined lever available.
Work is released in waves, frequently on a schedule set years ago.
Release patterns create congestion: a large wave floods the floor, everyone starts at the same locations, and the aisles jam.
Plot work in progress against release times. The relationship is usually visible immediately.
Smaller, more frequent releases shorten cycle time and reduce congestion at no cost.
This is one of the few interventions that is free, fast and reliably effective, and it is available from data every facility already holds.
What the system does not record
Time between task completion and the next task acceptance, unless configured to.
Anything happening away from the device.
Why a task was cancelled, beyond a reason code that is usually one of three options.
Physical searching, which appears as a long task.
Interruptions.
These gaps are the case for additional sensing, and they should be stated specifically before anything is purchased.
Examining the wave schedule
The highest-return configuration change available in most facilities.
Plot work in progress against release times over two weeks.
Look for the flood: a large release followed by congestion and a queue that takes hours to clear.
Ask when the schedule was set and by whom. The answer is usually years ago, for conditions that no longer apply.
Halve one wave and double the frequency, as a trial.
Measure cycle time and congestion, both of which usually improve immediately at no cost.
Configuration that improves the data
Available without any new system and usually more valuable than a sensor.
Enable event logging that is off by default.
Timestamp task acceptance separately from task start, which reveals waiting that is otherwise invisible.
Require the scan at the location rather than accepting it anywhere.
Add reason codes that distinguish what needs distinguishing, agreed with the people who select them.
Retain cancelled and failed tasks in the extract, which is where the exception analysis lives.