A monitoring system that stands alone becomes a separate reporting activity nobody uses. The integrations decide whether it is operational.
The warehouse management system
Task events in, as the primary source.
Findings out, where they change configuration: wave timing, slotting, task sequencing.
The loop matters. An analysis that recommends a slotting change and a system that implements slotting should be connected, or the recommendation stays in a report.
Maintenance
Telematics into the maintenance system, so service intervals follow actual usage.
Fault codes routed to whoever acts on them.
Downtime back into the availability analysis, which explains equipment gaps.
Without this join the utilisation analysis has a hole where every unexplained absence sits.
Safety management
Detected events and near-miss reports in one place, which is where the ratio between them becomes visible.
Incident investigation drawing on the operational data, with scoped access.
Risk assessments referencing the measurements, which is what makes them evidence-based rather than periodic paperwork.
Ownership by whoever owns safety, not by the analytics function.
Labour and rota
Demand curve out, shift shape in.
Aggregate only, at team and shift level, which is where the identity policy is enforced technically rather than by convention.
Peak planning, with training lead time included.
Finance and commercial
Cost per order line, from the elapsed time decomposition.
The cost of exceptions, which supports the prevention case.
Peak cost, which supports the commercial conversation about cut-offs and lead times.
This join is what turns operational findings into decisions above the facility, and it is usually missing.
The identity boundary in the architecture
Decide at ingestion, which is the only place it can be enforced.
Two streams: an aggregate stream feeding all routine reporting and retained long, and an individual stream retained briefly with access under a defined trigger.
Routine reporting draws only from the aggregate stream, technically, so drift is not possible by accident.
Access to the individual stream logged and reviewed.
What integration prevents
A second version of the truth disagreeing with the operational system.
Findings that die in reports because nothing connects them to the system that would implement them.
Individual data leaking into routine reporting, which is the most common drift and is prevented by architecture rather than by policy.
Analysis that cannot explain a gap because the maintenance or absence data was never joined.
The order
Management system first, because it is the primary source.
Safety second, because it is cheap and the obligation is clearest.
Maintenance third.
Labour fourth, with the identity boundary designed in.
Finance last, and it is the one that makes the programme's value legible outside the facility.
Closing the loop into configuration
An analysis that recommends a change and a system that implements it should be connected.
Slotting findings into the slotting configuration.
Wave timing findings into the wave schedule.
Task sequencing findings into the routing rules.
Otherwise the recommendation stays in a report, which is the most common way findings die.
Automate where the change is routine — re-slotting the top movers quarterly — and keep human review for anything structural.
Where the identity boundary lives
It is an architecture decision, not a policy one, and it belongs at ingestion.
Strip the identifier as data enters the aggregate stream.
Route the individual records to a separate store with its own access control and its own retention.
Point all routine reporting at the aggregate store, technically.
Any tool that can reach both will eventually be used to join them, which is why the separation must be at the storage layer rather than in a query filter.
Test it: attempt to produce an individual report from the reporting tool and confirm you cannot.