OEE & Production Performance Software Procurement Guide

Define the KPI model before buying software

• Document how availability, performance and quality will be calculated for each line or asset, including planned time, ideal cycle rate, good-count logic, scrap and rework treatment, changeovers and excluded states.
• Keep KPI definitions consistent across shifts, lines and sites before comparing dashboards. A software platform should implement an agreed measurement model rather than silently redefine plant performance.
• Use ISO 22400-2:2014 as the current published manufacturing-operations KPI reference where applicable. ISO shows a second edition in draft development, so verify the revision status during future procurement reviews.

Validate machine-state and downtime data capture

• Test real production states: running, stopped, starved, blocked, setup, planned stop, fault, speed loss and short or micro-stop events. Define minimum event duration and time synchronization requirements.
• Compare automatic machine-state capture with operator-entered reason codes. Require a controlled downtime taxonomy and a workflow for unknown or unclassified stops rather than forcing inaccurate cause selection.
• For existing PLC, SCADA or server data, verify supported protocols, read-only options, tag mapping, buffering during network loss and the effect of software or gateway failure on production equipment.

Connect performance, quality and manufacturing context

• Confirm how good count, scrap, rework, product or SKU, work order, shift, line, crew and changeover context are associated with machine events so OEE changes can be explained rather than merely displayed.
• Evaluate ERP, MRP, MES, historian, maintenance and quality-system integrations using representative production data and exception cases. Define which system owns each master-data field.
• Require export or API access to raw events and calculated KPIs so the plant can independently audit calculations and avoid unnecessary data lock-in.

Pilot with measurable acceptance criteria

• Run a limited pilot on a representative line and compare software-recorded states, counts and losses with an independently checked reference period before scaling plant-wide.
• Define acceptance tolerances for event timestamps, production counts, reason-code completeness, KPI calculations, report latency and system availability. Treat claimed savings as hypotheses until validated on the plant's own baseline.
• Compare total lifecycle cost including sensors or gateways, installation, licenses, connectivity, implementation, integration, training, administration, support and expansion to additional lines or sites.

Cybersecurity and operational resilience

• Prefer architectures that minimize write access to production controllers when monitoring does not require it. Document network zones, credentials, remote access, patching, logging and vendor-support paths.
• Verify local buffering or recovery behaviour when cloud, gateway or network connectivity is interrupted, and ensure monitoring failure cannot stop the manufacturing process unless explicitly designed and risk-assessed.
• Apply proportionate cybersecurity governance to production data and connected gateways; commercial partner status must never replace security, safety or controls-engineering review.

Professional references

These references establish the standards, technical framework or authoritative engineering context used for this page. Vendor commercial terms are not used as engineering evidence.

• ISO 22400-2:2014 Automation systems and integration — KPIs for manufacturing operations management — Current published ISO Part 2 defines manufacturing-operations KPIs and their formulas, elements, time behaviour and characteristics. ISO lists Edition 2 as a draft under development, so this guide uses the published 2014 edition as the normative reference.
• OPC Foundation — OPC UA — Industry interoperability framework relevant when production-performance software reads machine states, counts and process information through OPC UA.
• NIST Cybersecurity Framework — Risk-management framework for cybersecurity governance, identity, protection, detection, response and recovery controls relevant to connected manufacturing systems.

Commercial independence

PROFENG may display a separately disclosed approved partner after the engineering content. Partner status never changes formulas, conversion factors, procurement criteria, technical references or calculation results. Pending and unapproved programs remain hidden.