Manufacturing Software Development

Engineering teams building manufacturing execution systems, production management platforms, or industrial IoT applications face a set of tightly coupled problems: production order lifecycle management across multiple work centres, machine telemetry at high sample rates, quality inspection data that must be statistically defensible, and inventory transactions that trace every component from receipt to finished good. Scrums.com builds dedicated teams for your manufacturing software domain: engineers who design MES architecture, OEE monitoring pipelines, SPC workflows, and MRP integration. Every architecture decision is made to serve software companies and operators running plant floors, not the end consumer.

Production Order Management and MES Architecture

The production order is the central record in any MES. A production_orders table holds planned quantity, produced quantity, work centre assignment, scheduled and actual start and end timestamps, and current status. State transitions follow a strict machine: PLANNED / RELEASED / IN_PROGRESS / COMPLETED | CANCELLED. Every transition writes to a production_events append-only log with operator ID, machine ID, quantity produced, and scrap quantity at each step. This log is the source of truth for OEE calculations, labour costing, and quality traceability.

Bill of materials is versioned: a bom_header record carries product_id, version number, effective_from, and effective_to dates. Components are child rows in bom_components with quantity per assembly, unit of measure, and sequence. When a production order is released, BOM explosion calculates gross material requirements; net requirements subtract on-hand stock and open purchase orders. Routing is similarly versioned: routing_steps define sequence, work centre, setup time, and cycle time for each operation. Work centre capacity is configured in shifts with available hours, enabling finite capacity scheduling against the production schedule.

Production events feed a daily_production_summary materialised view refreshed per shift: units produced, scrap count, downtime minutes, and variance against schedule. Supervisors consume this view; the underlying append-only events remain unchanged. Shop floor terminals submit events via a lightweight REST API (barcode scan, quantity entry, or OPC-UA machine signal), all serialised through the same event ingestion path.

Machine Monitoring, OEE, and Predictive Maintenance

Machine telemetry arrives as a continuous stream. A machine_telemetry table is append-only with time-series partitioning (TimescaleDB or PostgreSQL BRIN index on timestamp): machine_id, timestamp, metric_type, value, and unit. OPC-UA is the standard protocol for PLC and SCADA data acquisition; MQTT handles lighter IoT sensors. A stream processor (Kafka Streams or Flink) consumes the telemetry topic and derives machine status transitions, writing to a machine_events append-only log. Machine current status (IDLE, RUNNING, FAULT, MAINTENANCE) is the latest record in that log, never a mutable column.

OEE (Overall Equipment Effectiveness) is Availability x Performance x Quality. Availability derives from planned production time minus downtime events in machine_events. Performance is actual output rate against ideal cycle time from routing configuration. Quality is (produced minus scrapped) divided by produced from the production_events log. These three components project into an oee_by_shift materialised view. No intermediate aggregates are stored; the calculation runs from the append-only source tables so historical OEE can always be recomputed from raw events.

Predictive maintenance uses a rolling anomaly detection algorithm (Z-score or CUSUM) over the telemetry stream. When a metric exceeds a configured threshold, an anomaly_alert is written with machine ID, metric type, severity, and detected timestamp. The maintenance module converts confirmed anomalies into maintenance_work_orders. A maintenance_schedule table supports multiple trigger types: CALENDAR (fixed interval), HOURS (operating hours counter), CYCLE_COUNT (from production_events), and ANOMALY (triggered by alert). Spare parts consumed per maintenance event are recorded in parts_consumption as append-only rows for stock reconciliation.

Manufacturing execution systems like these are built and delivered by dedicated engineering teams through our mobile app development service.

Quality Management and Non-Conformance Workflow

Inspection plans are defined per product and operation: an inspection_plan record references product, operation, inspection type (INCOMING, IN_PROCESS, FINAL), and a list of characteristics each with upper control limit (UCL), lower control limit (LCL), and target value. Inspection results are append-only rows in inspection_results: measured value, PASS/FAIL/BORDERLINE status, inspector ID, and timestamp. No result is ever overwritten: resubmissions create new rows referencing the original inspection event.

Statistical Process Control (SPC) charts (Xbar-R or Xbar-S) are computed from inspection_results by a background job evaluating Western Electric rules for out-of-control signals. A signal writes to spc_alerts with the violated rule, affected characteristic, and production order context. Depending on alert severity, the production order can be automatically paused pending disposition, preventing continued production of non-conforming goods without requiring manual intervention at every alert.

Non-conformance reports (NCRs) capture defect type from a typed enum, quantity affected, root cause, and disposition (REWORK, SCRAP, USE_AS_IS, RETURN_TO_VENDOR). CAPA (Corrective and Preventive Action) records link to NCRs with owner assignment, due date, completion evidence URL, and an effectiveness review date. A quality_kpis materialised view surfaces first-pass yield, defect rate by product, scrap cost, and supplier quality score: all derived from append-only source tables with no manual data entry required at the dashboard layer.

Inventory Management, MRP Logic, and ERP Integration

Inventory is append-only by design. A inventory_transactions table records every movement: RECEIPT, ISSUE, RETURN, ADJUSTMENT, TRANSFER, each with item ID, quantity, unit cost, reference document ID (production order, purchase order, or NCR), warehouse ID, and location ID. On-hand balance is a materialised view derived from this ledger, never a mutable counter. Historical stock positions can be reconstructed at any point in time, and stock discrepancies are investigated through the transaction log rather than overwriting a balance field.

Lot and serial number traceability links component receipts through production orders to finished goods and outbound shipments. A forward trace query (given a component lot, find all finished goods) and a backward trace query (given a finished good, find all input lots) are materialised as indexed views for recall and audit use cases. MRP logic runs as a scheduled job: BOM explosion of open production orders produces gross requirements, net requirements subtract on-hand and open purchase orders, and planned orders are written to a mrp_planned_orders table for planner review before release.

ERP integration publishes domain events to Kafka or as outbound webhooks: production_order.completed, ncr.created, inventory.consumed. Inbound flows (sales orders, purchase order receipts, item master updates) arrive via REST or EDI adapters. An integration_log records every inbound and outbound message with status and retry count. WMS connectors receive pick-pack-ship confirmations as inventory transactions; the WMS never writes directly to the on-hand balance view.