Keep the source record behind every OEE percentage.

In this guide

Check the denominator before trusting an OEE score

Overall equipment effectiveness combines availability, performance and quality. The result is useful only when the underlying definitions are consistent. A percentage without its production window, ideal cycle time and count rules is difficult to compare and easy to misinterpret.

AI-generated editorial illustration; not a customer photograph or product screenshot.

PreventiveHQ records production runs and their inputs. It does not independently observe a machine or validate the ideal cycle time. Manual entries need the same discipline as a spreadsheet, even when the software calculates the result correctly.

Worked example: one production run

Consider an illustrative run with 480 planned minutes, 60 downtime minutes, 600 total units, 570 good units and an ideal cycle time of 0.6 minutes per unit.

The same result can be checked as fully productive time divided by planned time: 570 × 0.6 ÷ 480 = 71.25%. This is a calculation example, not a customer result or a performance target.

Do not average percentages without their weights

Suppose one short run has a high score and a much longer run has a lower score. Their simple arithmetic average gives the short run too much influence. Keep the planned time and productive-time contribution for each run, and examine the aggregated inputs. For mixed products, retain the correct ideal cycle time for each product/run rather than applying one line-wide number after the fact.

Use the OEE calculator guide to work through the definitions. Agree how planned stops, changeovers, rework and scrap are classified before comparing shifts. Changing a classification can move a score without changing the machine's actual performance.

Test impossible and ambiguous entries

Try a zero planned duration, downtime greater than planned time, good count greater than total count and an implausible cycle-time unit. The software should reject impossible relationships. Plausible but incorrect entries still need operator review: 0.6 seconds and 0.6 minutes are both numbers, but differ by a factor of sixty.

Ask the shift reviewer to reconcile one record with the source sheet or counter. Preserve who entered the run and why a correction was made. A low score can identify a question to investigate; it does not establish the root cause of a loss.

Connect the production question to maintenance evidence

If downtime rises, inspect the related equipment and work history before concluding that maintenance caused the change. Material shortages, operating practices and product changes can affect production too. Use a consistent time window when comparing run records with repair evidence.

Choose PreventiveHQ when a structured, manually recorded production view alongside maintenance work fits the pilot. If automatic PLC ingestion, high-frequency event capture or MES integration is mandatory, require a demonstrated connector for your equipment. Those capabilities do not follow automatically from an OEE dashboard.

Decide which production question the score should answer

An OEE score describes productive performance within a defined planned-production window. It becomes useful when the team can explain the inputs and connect the result to a practical question. A supervisor may want to understand why a run produced fewer good units than expected. Maintenance may need to investigate recurring equipment-related stoppages. Neither question is answered by the percentage alone.

Begin with one line, one product and a clearly defined run. Write down the intended production period, the source of counts and who reviews the record. A small consistent sample is a better starting point than a plant-wide dashboard assembled from incompatible definitions.

Vorne's calculation reference describes OEE through availability, performance and quality, and shows the equivalent productive-time calculation. Use that framework as a reference, then make your own input definitions explicit. The examples below are original arithmetic illustrations for evaluating a software workflow, not customer results or recommended performance targets.

Make the time units explicit at data entry

A cycle time of 0.6 minutes is thirty-six seconds. Entering 0.6 into a field labelled seconds produces a result sixty times smaller than intended. Both entries are numeric, so ordinary validation may not identify the mistake as impossible.

AI-generated editorial illustration; not a customer photograph or product screenshot.

PreventiveHQ's production entry uses planned and running time in minutes and ideal cycle time in seconds. For the worked example earlier in this guide, enter 480 planned minutes, 420 running minutes and 36 ideal cycle seconds. Keep total and good units as counts. Write those units in the source worksheet so the person entering the run does not need to infer them.

Check the physical meaning of the cycle definition too. If a machine produces several pieces per machine cycle, decide how the ideal time is expressed per counted unit. The count and ideal-cycle basis must match. A change in the number of pieces produced per cycle can otherwise make the reported performance move without any corresponding change in the equipment's operation.

Include a deliberately mis-scaled example in the pilot. The reviewer should notice an implausible result and trace it back to the source definition. A software calculation can be correct while the input interpretation is wrong, so the acceptance test must include the human review process.

Define the planned-production window before reviewing losses

The denominator determines the question the score answers. Planned production time should be defined consistently with the intended analysis. If one shift excludes a category of time while another includes it, their scores may not be comparable even when both are calculated correctly.

Write down how the organization handles time when production was not intended, planned stops within a production window and unplanned interruptions. The appropriate classification should follow the measurement policy the team adopts. Do not change it after looking at a disappointing result merely to improve the score.

For an illustrative review, take one production window and reconstruct its time from the source record. Confirm that the reported running time does not exceed planned time and that the categories are understood by the operator and reviewer. Where a source record is incomplete, preserve that limitation rather than filling the gap with a convenient assumption.

A low availability factor can reflect several operational causes. Maintenance-related equipment failure is one possibility, but material shortages or other process conditions can also interrupt intended production. The score should trigger investigation of the underlying evidence, not automatically assign responsibility to maintenance.

Use ideal cycle time as a controlled reference

Ideal cycle time is a reference input, not simply the average speed observed during a difficult run. If the reference is changed casually to match actual performance, the performance factor loses much of its meaning. Identify who owns the reference and which product or operating setup it applies to.

For mixed products, preserve the appropriate reference for each run. A single line can make products with different cycle requirements. Applying one cycle time to every product can distort both individual results and aggregate interpretation. Record the relevant product or run identity clearly enough for a reviewer to verify the reference used.

PreventiveHQ flags performance above 100% rather than silently forcing it to a maximum of 100. Such a result can indicate an incorrect reference, units, count or time input that needs review. It is not automatically proof that the machine achieved an extraordinary improvement. Investigate the basis before using the number in a performance claim.

Use the pilot to test a plausible run, a clearly mis-scaled cycle value and a changed product. Ask a second person to explain the reference behind each result. A dashboard that hides the input basis makes it difficult to distinguish a real operational change from a data-definition problem.

Keep total count and good count on the same basis

Quality uses the relationship between good and total units in the defined run. The counts need a shared boundary and interpretation. If total count comes from one point in the process and good count from a different period or product batch, the ratio may be misleading.

AI-generated editorial illustration; not a customer photograph or product screenshot.

Agree how the organization classifies rejects, rework and items awaiting a decision. The software should not invent that quality policy. Keep the source of the accepted counts identifiable and establish who reviews corrections. A change in classification can move the factor without changing the physical output of the run.

For an illustrative record, total output of 400 units and accepted good output of 380 gives a 95% quality factor. If twenty units are still awaiting inspection, do not automatically describe all of them as either good or rejected without applying the chosen policy. Record the final accepted input and its basis through the team's process.

Test impossible relationships as well. Good count greater than total count should be rejected. A production count with zero running time also needs validation. These checks protect arithmetic consistency, but they do not prove that a plausible count matches the actual source evidence.

Aggregate runs using their productive contribution

A simple average of individual percentages gives every run equal influence, regardless of its length. That can make a short demonstration run disproportionately important in a daily or weekly result. Preserve the underlying time and count inputs so the aggregate can be reviewed.

AI-generated editorial illustration; not a customer photograph or product screenshot.

Consider two original illustrative runs:

The simple average of 75% and 62.5% is 68.75%. But the combined fully productive time is 195 minutes across 300 planned minutes, giving 65%. The longer run correctly contributes more to the combined result. This example illustrates why the underlying denominator matters.

PreventiveHQ's aggregate OEE uses the sum of ideal-cycle seconds multiplied by good units, divided by total planned seconds for the included non-voided runs. It does not simply average the displayed run percentages. Keep the filter population and the per-run cycle references clear when reviewing the total.

An aggregate can still hide important differences. Review the component runs and their factors before concluding that the line improved. A higher combined score may reflect a different product mix or the exclusion of a problematic record. The total is a useful entry point for investigation, not a replacement for it.

Distinguish an absent factor from a perfect factor

Some input combinations do not support every ratio. If no units were produced, a quality ratio based on good divided by total cannot be interpreted in the same way as a normal production run. If running time is zero, performance cannot be calculated as productive time divided by running time.

PreventiveHQ represents those undefined factors separately rather than pretending they are perfect scores. The overall productive-time result can still indicate that no fully productive output was recorded in the planned window. A reviewer should understand the difference between zero productive output and a ratio that cannot be meaningfully computed from the available denominator.

Use a zero-output example in the trial. Inspect how the interface presents it and ask the reviewer to explain what can and cannot be concluded. Do not fill missing or undefined factors with 100% merely to keep a dashboard visually complete.

This test is especially useful when comparing products. A polished chart can conceal how a system handles edge cases. The acceptance question is whether the displayed result preserves the meaning of the underlying record when ordinary assumptions do not hold.

Reconcile manual entries with the source before scaling

Manual production records can be a practical starting point, but they still need ownership and review. Decide who enters the run, who confirms its source and how corrections are handled. A new interface does not automatically improve the quality of an inconsistent paper or spreadsheet process.

AI-generated editorial illustration; not a customer photograph or product screenshot.

Select a small number of runs and compare the saved values with the source sheets or counters. Review units, planned time, running time and counts separately. If a record is wrong, investigate whether the cause was transcription, definition or an incomplete source. The remedy differs for each.

Avoid entering a long historical period simply to populate charts before the definitions have been tested. A small reconciliation can expose a sixtyfold cycle-unit error before it affects hundreds of rows. Keep the source recoverable and record the basis of any cleanup decisions.

PreventiveHQ preserves production run records and supports the applicable correction/voiding process. Review how an excluded run affects the aggregate. Removing a record should have a reason; it should not become a way to improve a score without acknowledging the change in the included population.

Connect production losses to maintenance evidence carefully

When a production result suggests a loss, inspect the relevant equipment and work history in the same observation window. A maintenance record can help explain a repair or recurring symptom, while the production record describes output and time. The relationship should be investigated rather than assumed.

For an illustrative case, a run has lower availability on the same day as an equipment repair. Confirm when the interruption occurred, what the maintenance record says and whether other operational conditions contributed. Matching dates alone do not establish that every lost minute was caused by the repaired component.

Likewise, a lower performance factor can have causes beyond equipment condition. Product characteristics, operating methods and source-data errors may matter. Use the factor to choose a question, then gather evidence through the appropriate production and maintenance processes.

The work-order guide explains how to preserve findings, actions and verification. Complete closeouts make later production investigations more useful, but they should not be turned into causal claims without enough supporting evidence.

Compare manual analytics with automatic machine collection

An OEE dashboard and an industrial data-acquisition system are different capabilities. A manual run-entry workflow can help a small team establish definitions and review production alongside maintenance. A plant requiring high-frequency machine states, automatic reason classification or MES integration needs additional demonstrated capabilities.

List the actual equipment and source requirements. Identify the PLC, controller or other data source, required signal, sampling approach and expected integration behavior. A generic claim of connectivity does not establish that the proposed system can collect and interpret your line's data correctly.

PreventiveHQ's current production workflow is based on recorded runs. It does not claim native PLC ingestion or a complete MES. If automatic collection is mandatory, make that a separate acceptance criterion rather than assuming it follows from the presence of an OEE calculation.

A manual pilot can still be useful before automation. It can reveal inconsistent definitions and identify the inputs that an eventual integration must provide. The value is the reviewed measurement process and its records, not a promise that manual entry will satisfy every future industrial requirement.

Run an OEE software acceptance test with known answers

Prepare a small set of original examples whose arithmetic can be independently checked. Include the normal run shown above, a zero-output run, a run with an implausible cycle unit and two unequal-duration runs for aggregation. Use the same examples when comparing products.

Check both the input form and the saved result. Confirm that the interface makes the units clear, rejects impossible relationships and preserves enough source context for another person to review the record. Then filter the run population and inspect how the aggregate changes.

Keep the arithmetic check separate from the operational decision. Correct calculation establishes that the software implements the defined inputs consistently. It does not establish that the source data is accurate or that a proposed maintenance action will improve production.

A practical first-month measurement rollout

Choose one line and a manageable product scope. Agree on planned time, cycle reference and count definitions with production and maintenance. Record a small sample, reconcile it and revise unclear instructions before expanding the population.

AI-generated editorial illustration; not a customer photograph or product screenshot.

During the next review cycle, inspect results with the people who supplied the inputs. Ask them to explain unusual values and trace one low result to the source evidence. Distinguish a data problem from an operational investigation. Both are useful findings, but they need different follow-up actions.

At the end of the pilot, decide whether the workflow produces interpretable records and whether the remaining manual effort is acceptable. Compare the current plans and any required external systems. Do not require a short evaluation to demonstrate a dramatic productivity improvement; first establish that the measurement can be trusted.

Start with the OEE explanation and calculator and a trial workspace. Use the known-answer examples to test the product, then use your own reviewed production data to decide whether it fits the operation.