What Activity Monitoring Actually Is

Warehouse and industrial monitoring is bought as one capability and turns out to be three, with different purposes, different data, and very different obligations attached.

The three things

Process measurement. How long each stage takes, where work queues, how much travel a task requires, where errors originate. The subject is the flow, not any individual.

Asset and equipment telemetry. Where forklifts and handling equipment are, how they are used, when they need maintenance, whether they are idle.

Worker monitoring. Measurement attributed to a named person: their rate, their idle time, their location through a shift.

They use overlapping sensors and they are not the same activity. The first two are operational engineering. The third is workplace surveillance, with legal obligations and a real cost in trust, and it is covered separately and honestly in these notes.

Why the distinction matters immediately

The justification differs. Finding a bottleneck needs no individual attribution. Ranking pickers by rate does.

The obligations differ. Aggregated process data raises few issues; individual monitoring engages employment and data protection law in most jurisdictions.

The failure modes differ. Process measurement fails by measuring the wrong thing. Worker monitoring fails by damaging the cooperation the operation depends on.

Most of the value is in the first two, and most of the controversy is in the third. Deployments that conflate them get the controversy without needing it.

What a facility already generates

Before any new sensor, most operations already hold more data than they use.

Scan events from barcode and RFID, timestamped, at every handling point.

Warehouse management system transactions: task issued, accepted, completed.

Equipment telematics, where fleets are modern.

Access control and gate records.

Order and despatch data, which brackets everything else.

Building systems: doors, temperature, lighting.

The first project in most facilities is joining what exists, not installing something new.

What monitoring is for

Finding where work waits. Queueing time typically exceeds working time by a wide margin, and it is invisible without timestamps.

Finding travel that need not happen, which is usually the largest single loss in a picking operation.

Finding equipment sitting idle while people wait for it.

Finding where errors originate, which is rarely where they are detected.

Understanding demand variation, so staffing matches it.

Safety, which is a distinct purpose and the one with the clearest justification.

What it is not for

Setting individual rate targets without understanding what drives variation, which is the practice most associated with injury and turnover.

Discipline as the primary output. A monitoring system whose main product is disciplinary evidence will be resisted, gamed and eventually defeated.

Replacing supervision with a dashboard.

Proving a decision already made, which is what most poorly-scoped deployments are actually for.

The framing that keeps it useful

Measure the process, not the person.

Almost every operational question — where the bottleneck is, why Tuesday is worse, whether the new layout helped — is answerable from aggregated data with no individual attribution at all.

Where individual data is genuinely needed, say why, tell people, and limit the purpose. That is the subject of its own section, and getting it wrong costs more than the measurement is worth.

The first week

Four things that establish where a facility stands, before any purchase.

Extract a week of task events with timestamps and locations.

Compute the elapsed time decomposition for a unit of work: waiting, travel, handling, checking, rework.

Compare the proportions against what everyone assumed. Handling is almost always a smaller share than expected.

Show it to the people on the floor and ask whether it matches what they see.

No hardware, no licence, no consultation required, because none of it involves individual measurement — and it usually redirects the whole project.

Who owns it

Programmes stall where ownership is ambiguous, and the three plausible owners each distort it.

Technology treats it as a data platform and under-weights the operational decisions every finding requires.

Operations treats it as reporting and under-invests in data quality.

Health and safety treats it as compliance and misses the flow analysis entirely.

The workable arrangement is one owner inside operations, with a standing relationship to safety and a data engineering resource, plus worker representation in the design.

What fails is a shared responsibility with no named person, which is how most first attempts are structured and why they end as a dashboard.