Manufacturing, industrial, and maintenance software
Manufacturing Execution Software Requirements Checklist
A practical requirements framework for manufacturers replacing paper travelers, spreadsheets, disconnected terminals, and fragile production interfaces with controlled execution software.
Published by Kennedy Gichobi · Expert-reviewed by Kennedy Gichobi · Published · 3327 words
Define the production outcome and system boundary
Manufacturing execution software may coordinate production orders, dispatch work, instructions, materials, labor, equipment, quality, genealogy, downtime, exceptions, and performance between enterprise planning and plant-floor control. The appropriate boundary differs across discrete assembly, batch, process, packaging, fabrication, job-shop, and mixed operations. Begin with the product, process, site, operating model, and failure the organization needs to reduce.
Map work from demand and released order through material staging, setup, execution, inspection, movement, completion, reconciliation, and shipment or downstream use. Include shortages, substitutions, rework, split lots, partial completions, failed tests, machine unavailable, wrong revision, operator change, late data, network loss, label failure, and an order cancelled after work begins. Observe actual shifts rather than documenting only the intended standard route.
Choose measurable outcomes such as preventing obsolete instructions, improving work-in-process visibility, reducing transcription, finding quality issues earlier, preserving lot or serial genealogy, shortening changeover, or reconciling production with inventory. A collection of touchscreen forms is not manufacturing control unless records have defined authority, version, evidence, exception behavior, and downstream meaning.
Model the physical and organizational hierarchy
Represent enterprise, site, area, line, cell, work center, work unit, equipment, location, storage location, production capability, and calendar explicitly where the operation needs them. Keep the physical asset, logical work center, and accounting or planning identifier distinct. One machine may support several operations; one work center may contain several assets; and reporting structures may change without moving equipment.
Use stable internal identifiers and preserve external identifiers from ERP, maintenance, quality, automation, and warehouse systems. Names and codes change during reorganizations and equipment replacement. Effective dates and historical relationships allow an old production record to retain the hierarchy, responsible organization, and asset context that existed when work occurred.
ISA-95 provides models and terminology for enterprise-control integration and organizes information exchanged between manufacturing operations and enterprise functions. Use the relevant concepts as a shared language, not as permission to copy every object into a small application. Name the exact ISA-95 parts and editions required by a contract or integration; the series contains several parts with different scopes.
Separate product definitions from production records
Model product, material, bill of material, route or recipe, operation, step, specification, parameter, instruction, tooling requirement, quality characteristic, and packaging requirement as versioned definitions. A production order should reference the approved versions released for execution. Changing the current master definition must not rewrite what an earlier order required.
Define effective dates, sites, product variants, alternate routes, approved substitutions, revision compatibility, and release authority. Separate engineering approval, planning release, and shop-floor availability. An engineer may approve a new drawing before material, tooling, training, software, or customer authorization is ready for production.
Preserve a production snapshot or immutable references sufficient to reconstruct the work. If an external lifecycle-management or ERP system owns definitions, agree on version identifiers, effectivity, transfer completeness, and behavior when dependent content is missing. “Use the latest revision” is unsafe when the software cannot prove what latest meant at the time of dispatch.
Control production orders and dispatch
A production order should identify product and revision, quantity, unit, site, route, priority, planned dates, material requirements, customer or project context where permitted, external identifiers, and current release state. Distinguish planned, released, dispatched, started, held, partially completed, completed, closed, cancelled, and reopened according to approved operations.
Define who may release, reprioritize, split, merge, reschedule, hold, cancel, or close an order. Preserve reasons and affected quantities. A planning-system update received after production starts should create a controlled exception rather than silently replacing the route or due date.
Dispatch should consider authorized work centers, material readiness, tooling, equipment state, skills, quality holds, dependencies, and approved sequencing rules. Show supervisors why an order is blocked. Avoid opaque optimization that rearranges work without explainable constraints, a usable override, and evidence of the resulting commitment.
Record resources and capability separately
Personnel, equipment, tools, materials, and process segments contribute different capabilities. Define which resource types an operation requires, their qualification or status, quantity, and approved alternatives. Do not overload availability, capability, assignment, and actual consumption into one field.
Capability can vary by site, asset configuration, product, tolerance, certification, maintenance state, tooling, and time. An asset existing in the equipment list does not mean it is ready or qualified for every job. Preserve the capability and rule version used when work was assigned.
For scarce tools, fixtures, gauges, and shared equipment, define reservation, checkout, calibration or inspection status, location, return, and exception behavior. The system should block or warn according to approved risk, but it must also give authorized operators a governed path for urgent decisions instead of encouraging work outside the application.
Design material staging and consumption
Define material identifier, revision or grade, lot or batch, serial where applicable, quantity, unit, status, location, ownership, expiration, and quality disposition. Keep planned requirement, staged quantity, issued quantity, consumed quantity, returned quantity, produced quantity, and scrapped quantity distinct.
Support scanning and manual fallback with validation. Confirm item, lot, status, quantity, unit conversion, order, operation, and permitted substitution. A barcode scan proves the encoded identifier was read; it does not prove the physical contents, condition, quantity, or correct use without the surrounding process.
Handle partial containers, commingling where permitted, yield variation, backflush, by-products, co-products, substitutions, returned material, and inventory corrections. Reconcile transactions with the warehouse or ERP source of truth. A retry must not consume the same lot twice or create inventory because the production record was replayed.
Preserve lot, batch, and serial genealogy
Genealogy connects incoming lots or serials, intermediate output, process events, equipment, people, and finished goods according to the traceability need. Define the required granularity. Container-level history may be adequate for one product, while another requires unit-level component relationships and measured parameters.
Record transformation, aggregation, disaggregation, packing, unpacking, rework, split, merge, consumption, production, and transfer events. Preserve event time, recording time, location, business step, disposition, actor or source, and related identifiers. Late or corrected events need an explicit relationship to the original history.
Test backward and forward trace queries across partial consumption, reused containers, rework, outsourced operations, relabeling, and multiple sites. Measure completeness and response time with realistic volume. A graph that draws a plausible path is not sufficient; reconcile quantities and identify unexplained gaps.
Deliver controlled work instructions
Instructions may include text, drawings, images, video, parameters, safety references, tools, checkpoints, and data-entry requirements. Define authoring ownership, review, approval, effectivity, translation, publication, withdrawal, and acknowledgment. Keep the instruction version and any referenced file revisions frozen for the production record.
Display only the approved content for the product, operation, site, equipment, and order context. Warn clearly when an instruction becomes superseded while a job is active and route the case through an approved transition policy. Do not assume every active unit can change to a new method mid-operation.
Design for plant conditions: gloves, noise, glare, distance, shared terminals, scanning, limited screen space, and interrupted attention. Provide keyboard or alternative input where relevant, large targets, status beyond color, readable zoom, and a safe way to report unclear instructions. Acknowledgment does not prove comprehension or competent training.
Capture execution events without rewriting history
Record operation start, pause, resume, hold, completion, quantity, unit, resource assignment, material events, parameters, checks, exceptions, and comments with event and receipt times. Separate machine-generated, operator-entered, imported, and calculated data. Preserve provenance. Show the source and freshness when operators rely on an event to make the next production decision.
Define how work transfers between people, shifts, assets, and locations. Avoid shared accounts that erase responsibility. When a supervisor records an event on behalf of another person, preserve both the performer and recorder with an approved reason.
Corrections should append or supersede through a controlled event, not edit consequential history silently. Record original value, replacement, reason, authority, and impact on downstream inventory, quality, genealogy, and reports. Reconcile every correction that has already been exported.
Validate process data in context
For each captured parameter, define unit, data type, expected source, resolution, range, target, tolerance, sampling rule, equipment or operation context, and required behavior. Keep the measured value, normalized value, validation result, and specification version distinct.
Do not discard out-of-range values because they look like sensor errors. Record the observation and route validation or investigation. Conversely, a value inside tolerance does not prove the correct sensor, unit, product, time, or sample. Context and provenance matter.
Handle device clocks, delayed events, repeated messages, unit conversion, calibration status, sensor replacement, communication loss, and data bursts. Define whether the manufacturing application is a historian, consumes summarized values, or only records selected evidence. Unbounded high-frequency collection can overwhelm a transactional system without improving decisions.
Build quality checks into the route
Define inspection plan, characteristic, method, sample, frequency, specification, instrument requirement, result, disposition, reviewer, and evidence. Tie each check to the product, operation, material, equipment, and approved definition version. Distinguish planned inspection from an executed inspection and a final quality decision.
Support pass, fail, conditional, invalid, retest, and not-applicable according to policy. A retest must not erase the first failure. Preserve samples, readings, attachments, comments, instrument, calibration context, and who made each disposition. Make pending and invalid results visibly different from approved acceptance.
Route holds and release consistently. Prevent downstream completion, packing, or shipment when approved policy requires a stop, while supporting authorized containment and investigation. A quality manager’s override should identify scope, reason, evidence, expiration, and affected genealogy rather than simply turning a red indicator green.
Manage nonconformance, deviation, and rework
Separate defect observation, nonconformance record, containment, investigation, disposition, deviation authorization, corrective action, rework instruction, verification, and closure. The exact terminology depends on the organization and applicable quality system, but early detection should not be confused with final cause or liability.
Record affected order, product, quantity, serial or lot, operation, material, equipment, specification, evidence, and containment scope. Link related records without merging independent issues. Define who can classify, disposition, authorize use-as-is, scrap, return, rework, or expand containment.
Rework needs an approved route and genealogy. Preserve removed and added material, repeated operations, new measurements, labor, equipment, and final verification. Do not force rework through the original route in a way that makes the first pass look successful.
Coordinate equipment state and downtime
Define production states and reason hierarchies that match the actual operation. Running, idle, blocked, starved, setup, planned stop, unplanned stop, maintenance, and unknown may be useful, but each site needs agreed definitions and boundaries. Separate observed equipment state from the business reason assigned by a person or rule.
Capture start and end, source, asset, order or operation context, reason, comments, and correction. Prevent overlapping or impossible intervals according to the model. Provide a fast operator workflow for unknown reason followed by accountable classification rather than forcing a guess during urgent recovery.
Machine signals may suggest state changes but require interpretation. A motor running does not always mean productive work, and no signal does not prove downtime. Document mapping, debounce, thresholds, planned-state context, failure behavior, and reconciliation with production evidence.
Integrate maintenance without duplicating the CMMS
Name the source of truth for assets, maintenance plans, work orders, condition, spare parts, calibration, and repair history. Manufacturing execution may request maintenance, show status, and block assignment while a maintenance system owns the detailed work. Avoid two systems independently closing the same event.
Define triggers from operator reports, downtime, counters, condition measurements, failed checks, and schedules. Preserve the source event and transfer status. A predictive score should create an explainable recommendation or governed work request, not stop equipment autonomously unless qualified people have designed and approved that control.
Reconcile asset availability and return-to-service. Require the necessary maintenance, quality, safety, or production authorization for the operation. Test partial integration failure: the maintenance order is created but its identifier is not returned, the network drops after completion, or an asset is released in one system and held in another.
Define performance measures before building dashboards
Metrics such as throughput, yield, scrap, cycle time, schedule attainment, changeover, downtime, work in process, and overall equipment effectiveness require precise definitions. State numerator, denominator, time boundary, included states, source, unit, timezone, product mix treatment, and owner. Preserve the definition version.
Do not use a universal OEE formula without agreeing on planned production time, ideal rate, good count, rework, startup loss, overlapping downtime, and data completeness. Comparative rankings can encourage hiding stops or misclassifying scrap. Provide drill-down to the events and exclusions that produced a result.
Show freshness, missing data, estimated values, corrections, and unreconciled interfaces. Separate operational signals from financial or regulatory reporting. A near-real-time board can support a shift conversation, while an official month-end measure may require reviewed and closed data.
Support people, skills, and shift handover
Define roles, qualifications, certifications, authorization, site, operation, product, equipment, effective dates, and training evidence needed for assignment. A general job title is not enough when capability depends on a current process or equipment qualification. Record the rule and evidence used when the system permits or blocks an assignment.
Protect sensitive personnel information. Supervisors may need to know whether a person is authorized without viewing private training, medical, or employment details. Define the owning HR or learning system, freshness, fallback during an outage, and process for an urgent correction.
Shift handover should capture active orders, holds, shortages, quality issues, equipment state, maintenance, pending decisions, and accountable follow-up. Preserve both structured status and concise context. Copy-forward must require confirmation so yesterday’s problem does not become today’s unquestioned record.
Control labels, documents, and identifiers
Define label type, template version, data source, printer, quantity, authorization, verification, reprint, void, and reconciliation. A reprint can create duplicate physical identifiers, so distinguish replacing a damaged label from producing an additional valid copy. Require an accountable reason when the workflow changes the expected label count.
Keep human-readable and encoded data consistent. Validate product, revision, lot, serial, quantity, date, destination, and required standard identifiers before printing. Preserve the generated payload and template version. Printer success does not prove the correct label was applied to the correct item.
For certificates, travelers, packing records, and other generated documents, freeze the data snapshot, template, approver, and issued file. Avoid public download links. Correct through a controlled replacement that retains the superseded record and notifies the necessary downstream parties.
Plan external traceability exchanges precisely
Traceability beyond the plant may require sharing events with suppliers, customers, logistics providers, marketplaces, or regulators under approved agreements. Define identifiers, event vocabulary, visibility, ownership, correction, retention, and commercial confidentiality before designing an API. Separate internal evidence from the information each external party is authorized to receive.
GS1’s EPCIS and Core Business Vocabulary provide a common event-data language for supply-chain visibility and traceability. EPCIS 2.0 supports information about what occurred, when, where, why, and how across events. Using the standard does not decide the organization’s identifiers, business steps, permissions, partner agreements, or data quality.
Name the exact EPCIS version and profile, required event types, master data, capture and query behavior, subscriptions, authentication, error handling, and conformance expectations. Test representative aggregation, transformation, shipping, receiving, correction, and sensor-related cases. A syntactically valid event can still describe the wrong physical history.
Integrate ERP, planning, warehouse, and quality systems
Inventory product lifecycle, ERP, advanced planning, warehouse, laboratory, quality, maintenance, identity, timekeeping, and data-platform interfaces. For each exchange, define source of truth, identifiers, version, direction, timing, authentication, mapping, units, status, idempotency, retry, reconciliation, and operator ownership.
Production orders, material masters, inventory transactions, completions, scrap, labor, and quality dispositions often cross system boundaries. Model each as a business transaction with an immutable request and traceable response. Prevent a message replay from producing duplicate inventory or labor.
Build exception queues for unknown identifiers, closed periods, invalid units, unavailable lots, changed revisions, rejected quantities, and provider outages. Reconcile intended versus accepted transactions and downstream balances. ISA-95 can help teams discuss enterprise and manufacturing information boundaries, but the actual contract must define fields and behavior.
Keep manufacturing software separate from safety control
Decide whether the application observes, instructs people, coordinates work, sends approved parameters, or directly controls equipment. These are materially different risk boundaries. A general web application should not become an unreviewed safety or real-time control system because an API endpoint is available.
Safety instrumented functions, machine protection, emergency stops, interlocks, and deterministic controls require qualified engineering, applicable standards, validated designs, and organizational authority. Manufacturing execution should show relevant state and preserve evidence without bypassing protective layers or encouraging unsafe recovery.
Define command allowlists, direction, approval, range validation, sequence, timeout, acknowledgment, independent safeguards, and safe failure for any permitted control exchange. Test stale orders, duplicate commands, delayed acknowledgments, wrong asset mapping, communication loss, and application compromise with the responsible automation and safety teams.
Design for edge operation and unreliable connectivity
Identify which plant tasks must continue when cloud, site network, identity, ERP, or a provider is unavailable. Define local access, cached orders and instructions, expiration, data capture, queueing, printing, time, conflict, resynchronization, and operator communication. Degraded operation must be deliberately bounded.
Use idempotent events and durable local queues. Show whether a scan, completion, measurement, or label request is accepted, pending, failed, or reconciled. Preserve local work until the trusted service confirms it, while preventing offline action after an order, qualification, or instruction becomes invalid.
Test device restart, power loss, low storage, clock drift, prolonged isolation, certificate expiration, duplicated messages, changed order priority, revised instructions, and two terminals editing the same unit. Recovery should explain conflicts to an authorized operator rather than silently choosing the newest timestamp.
Protect OT reliability and security
Manufacturing applications bridge enterprise information and operations, which can expand pathways into operational technology. Inventory assets, data flows, trust zones, remote access, accounts, protocols, dependencies, and safety or production consequences. Coordinate security changes with plant reliability and automation owners.
NIST SP 800-82 Revision 3 provides guidance for securing operational technology while considering its performance, reliability, and safety requirements. Apply a risk-based architecture appropriate to the site rather than copying an IT control that disrupts deterministic or legacy operations. Segment networks, limit pathways, use controlled remote access, monitor appropriately, and plan recovery.
Use separate environments, managed secrets, least privilege, reviewed deployment, dependency and artifact controls, secure configuration, backups, restoration tests, vulnerability handling, and incident procedures. NIST’s Secure Software Development Framework offers practices for the application lifecycle; OT guidance addresses the operational context the application may touch.
Migrate and reconcile before cutover
Profile product definitions, revisions, routes, material masters, equipment, locations, open orders, inventory, work in process, genealogy, quality holds, qualifications, instructions, labels, integrations, and historical records. Identify duplicates, invalid units, obsolete codes, broken relationships, and undocumented local spreadsheets.
Choose what must migrate as active transactional data, what can remain in a read-only archive, and what requires correction before launch. Rehearse conversion and reconcile counts, quantities, balances, statuses, versions, relationships, and representative genealogy. Do not load ambiguous work in process and hope operators repair it during production.
Plan phased site, line, product, or process rollout with a defined rollback and coexistence period. Avoid dual entry without reconciliation ownership. Verify reports, interfaces, labels, scanners, terminals, edge behavior, permissions, backups, and support readiness under realistic shift volume.
Use this checklist before approving manufacturing software
Confirm that the proposal defines the production boundary; models hierarchy and resources; versions product definitions and instructions; controls orders and dispatch; reconciles material; preserves genealogy; records execution without rewriting history; validates process data; governs quality and rework; coordinates downtime and maintenance; defines metrics; respects skills and privacy; controls labels; specifies traceability standards; reconciles enterprise interfaces; separates coordination from safety control; works during outages; protects OT; enforces authority; migrates safely; and preserves ownership.
Then rehearse a difficult shift: an ERP update arrives after an order starts, a substituted material has a different unit, a scanner repeats consumption offline, an instruction is superseded, one measurement is out of range, a machine signal incorrectly shows running, maintenance holds the asset, a label is reprinted, a unit enters rework, the completion posting times out, and the network reconnects out of order. A strong design explains version, authority, evidence, safety boundary, retry, conflict, reconciliation, and operator action at every point.
Share your manufacturing type, sites, products, routes, materials, order flow, quality rules, genealogy, equipment, downtime, maintenance, labels, ERP and automation interfaces, connectivity, production volume, security boundary, and current failures through the project questionnaire so discovery can define an appropriate manufacturing execution architecture.
Authoritative references
Related software planning guides
- Maintenance Management Software Requirements Checklist
- Manufacturing Production Tracking Implementation Roadmap
- Manufacturing Production Tracking Software Cost Guide