Multi-Site Production Monitoring and OEE Reporting

Build the hierarchy around the real production organisation

Identify companies, factories, departments, lines and equipment using stable identities. The reporting hierarchy should reflect who owns the operating decision and which physical boundary supplies each count. A line that changes its constraint or routing may need a revised interpretation without losing its historical identity.

Record the product and configuration relationships used at each site. Different plants can use different names for the same product family or the same name for different pack sizes. Establish an approved mapping before combining quantities. A group dashboard should make those relationships easier to inspect rather than hide them behind a common label.

Agree the local measurement before the group metric

For each selected machine or line, identify the actual count, state and time sources. Verify existing controller fields or suitable retrofit observations against independent records. A received signal becomes useful production evidence only after its physical meaning, unit and boundary are established.

Document the treatment of rework, rejects, multiple parts per cycle and manual entries. The local production and quality owners should approve those definitions. A central template can provide consistent fields while preserving the actual source and accepted method used by each factory.

Keep calendars and rate references traceable

Agree planned production time, exclusions, shift boundaries and correction permissions. Factories may work different hours without making the comparison invalid, provided the included minutes and purpose are explicit. Preserve schedule revisions so the report can explain whether a percentage changed because production improved or because the denominator was edited.

Store ideal-cycle or rate references by product and configuration with their source and effective version. Tooling, active cavities and count units can affect interpretation. Mixed-product periods should retain compatible segments before aggregation rather than rely on an unexplained average rate.

Present comparable and non-comparable views clearly

The group may need a time-weighted result, site-level improvement trends and a product-family view. These answer different questions. The multi-site OEE comparison guide explains why a mean of percentages can differ from a combined productive-time ratio.

A management view should retain the contributions behind its headline figure. Show planned time, productive contribution, product mix and qualified periods where relevant. The reporting owner should determine which comparisons are appropriate for allocation, local improvement or executive review, rather than force every factory into one ranking.

Demonstrate permissions before adding every factory

Define the roles that may view local production, compare sites, correct events and change master data. A local supervisor may need detailed records for one factory while a group reviewer needs approved summaries across several. Test those permissions using the actual proposed account structure.

Confirm the data model and licensing arrangement in the project proposal. Multi-site reporting can involve separate interfaces, onboarding effort and recurring services at each location. The scope should identify those items and demonstrate the required access behaviour before the rollout assumes that every factory is included under one unchanged arrangement.

Preserve local context in the group exception process

A low result may reflect a real operating loss, an incomplete quality record or a mapping problem. Keep those categories distinguishable. The central team should be able to ask a specific local question using the relevant period, source and evidence, rather than assign a generic performance label.

Record who reviews disputed counts or reasons and how an authorised correction appears in the group report. Retain original and revised values with the effective rule. A site should not need to overwrite history to explain an event that was classified incorrectly during the shift.

Pilot the differences that will matter during rollout

Choose a first factory with accessible source records and named reviewers. Use it to verify identities, calculations and exports. Then select a second site that exercises a meaningful difference, such as another controller family, product mix or shift pattern. This tests the portability of the model rather than only repeating the easiest installation.

Retain the additional work required at the second site. A successful first factory does not establish every interface or reporting interpretation elsewhere. The rollout checklist should identify reusable configuration, local verification tasks and exceptions that require engineering or reporting review.

Keep ownership clear after commissioning

Assign responsibility for product references, calendar changes, source interfaces and user access. Group governance should define the shared meaning while local teams retain responsibility for the evidence they supply. The accepted model needs a route for resolving conflicts without allowing either central or local edits to become invisible.

Send the factory list, line hierarchy, sample reports, product definitions and available interfaces for scoping. Identify the central reporting owner and the local production, quality and engineering participants. The first deliverable should be a reproducible comparison with a clear account of which sites and conditions it covers.

Agree how a factory joins and leaves the comparison

Create an onboarding record containing the first valid reporting date, accepted equipment population and known exclusions. A newly connected site should not appear historically complete before its sources were verified. If a line is moved, retired or temporarily unavailable, preserve the effective boundary and the treatment of its contribution to group totals.

Test a sample export for both a local supervisor and the group reviewer. Confirm that each can identify the source period, product reference and current review status. The customer should also be able to explain why one site is excluded from a selected comparison. These checks turn the permission model and calculation definitions into a usable management process, rather than leaving them as configuration notes understood only by the project team.

Plan installation, continuity and operating handover

The installation proposal should identify the field equipment, available interfaces, local power, mounting conditions and communication path for the accepted point list. Suitable LoRaWAN points with 4G backhaul are selected against the actual site survey and reporting requirement. The local team supplies access and the relevant specialist participation for the physical work and reference checks.

Before commissioning, agree what evidence each test should produce. Include point identity, unit conversion, an appropriate independent comparison and the handling of unavailable observations. Where the supplied architecture retains records during an interruption, verify recovery with original acquisition times. A recovered historical record and a live notification are separate functions in the acceptance schedule.

Handover includes installed photographs, the accepted configuration, operating instructions, an export demonstration and a list of open actions with owners. Assign routine instrument checks, user administration, communication service and the replacement process. A later change to equipment, operating conditions or reporting rules should have an effective date and a review of the affected acceptance evidence.

Compare the complete quoted scope

Request separate lines for equipment, configuration, installation, specialist verification and recurring services. Identify work supplied by the customer or an existing contractor, together with the access and information needed to complete it. The quotation should make the proposed result and each dependency understandable before procurement.

Use current quotations for the selected equipment and actual site arrangement. The project estimate should account for practical maintenance and replacement as well as first installation. Agree the initial acceptance boundary and the evidence required before extending the same configuration to additional assets or locations.

Connect the decision to the project

Use Oee management, Why production dashboards fail, Manufacturing to place this task within the wider installation. Bring a recent operating record and identify the decision that the proposed measurement should support. A focused discussion should establish the first boundary, the responsible site participants and the evidence needed before expanding the scope.

Agree who maintains the point register and who can change interpretation rules. Preserve the previous version when a device, product, reporting period or responsibility changes. During handover, demonstrate an export that another authorised person can reconcile without relying on the dashboard operator to explain missing fields.

Discuss the scope with addanode using the actual site information, available interfaces and proposed acceptance record.

Sources and method

The Vorne calculation guide provides OEE calculation background. The proposed hierarchy, rollout and access tests are project scope; exact interfaces, licences and service arrangements are confirmed against the customer’s factories.

Frequently asked questions