Production Management App Development

Manufacturers building production management and MES platforms need engineering teams who understand shop floor data architecture: work order execution state machines, production scheduling logic, quality inspection workflows, and the material consumption tracking that connects production to inventory. Scrums.com provides dedicated software engineering teams for production management app development, deploying production-ready systems with append-only production event ledgers, configurable quality inspection workflows, shift and operator tracking, and the analytics infrastructure that measures yield, cycle time, and scrap rates.

Work Order Execution and Shop Floor Management

Work orders are the atomic unit of shop floor execution. A work_orders table holds each order with its bom_version_id (the BOM revision active at release), planned_quantity, work_centre_id, planned_start, and planned_end; the BOM version is locked at release so a mid-run BOM update never silently changes what a running work order produces. Status follows a state machine (RELEASED / QUEUED / SETUP / IN_PROGRESS / SUSPENDED / COMPLETED | SCRAPPED) with every transition appended to work_order_events; work orders are never deleted and SCRAPPED is a terminal state with a mandatory scrap_reason code. Operator assignments write to a separate operator_assignments table so an operator can be reassigned without mutating the work order row; assignment history is always traceable. Setup time is captured in setup_events (setup_start_at, setup_end_at, setup_type) and feeds changeover reduction analytics independently of production run time. Work order completions write an immutable work_order_completions row: actual_quantity, good_quantity, scrap_quantity, completed_at, and completed_by. Production runs append one row per production cycle to production_runs: machine_id, operator_id, work_order_id, run_start, run_end, cycle_count, good_count, reject_count: the source record for all yield and rate analytics.

Production Scheduling, Sequencing, and Capacity Planning

Production schedules are frozen per planning horizon and immutable once in FROZEN status: changes follow a schedule_change_requests state machine (REQUESTED / APPROVED | REJECTED), with approved changes writing new schedule_revisions rows that preserve every prior version. Work centre capacity is stored in config: shifts, machines per shift, and configured cycle time per part; adjusting a work centre's capacity requires a config row update, not a code change. Scheduling rules in a scheduling_rules config table control sequencing logic (FIFO | EDD | SHORTEST_PROCESSING_TIME | CUSTOM) and a setup_reduction_matrix (JSONB) that specifies setup times between part families, enabling sequence-dependent scheduling without engineering involvement. Finite scheduling computes capacity load from production_schedule crossed against work_centre_capacity; overloads surface as schedule_conflicts that must be resolved before a schedule can be frozen: silently overbooking a work centre is not possible. The schedule_adherence materialised view computes on-time completion rate, count of late work orders, and average days late from work_order_events versus the frozen production_schedule: always recomputable from source events. Shift plans record planned_start, planned_end, and planned_downtime_minutes per work centre; shift_events captures actual shift boundaries, BREAKDOWN, PLANNED_STOP, and UNPLANNED_STOP: the inputs to availability analytics.

Production management apps like these are built and delivered by dedicated engineering teams through our mobile app development service.

Quality Control, Inspection Workflows, and Non-Conformance Management

Inspection checkpoints are stored as configuration in inspection_checkpoints (part_id, inspection_type, sampling_plan as AQL level and sample_size_formula, characteristic type, specification as JSONB with nominal, upper_tolerance, lower_tolerance); adding a new inspection point requires a config row, not a deployment. Inspection results write to quality_inspections: work_order_id, inspection_checkpoint_id, inspector_id, inspected_at, and result (PASS | FAIL | CONDITIONAL_PASS). Defect events are append-only: defect_type, severity (CRITICAL | MAJOR | MINOR), location_on_part, and disposition (REWORK | SCRAP | USE_AS_IS | RETURN_TO_SUPPLIER); USE_AS_IS disposition requires an engineer_approval_id before it can be recorded. Non-conformance reports follow a state machine (OPEN / UNDER_INVESTIGATION / ROOT_CAUSE_IDENTIFIED / CORRECTIVE_ACTION_PLANNED / CLOSED | VOIDED) and are never deleted; VOIDED is a terminal state that preserves the original record with a void_reason. Corrective actions write to corrective_action_events (ncr_id, action_type, assigned_to, due_date, completed_at); overdue actions surface in analytics without mutating the NCR. First-pass yield and scrap rates are always derived from production_runs and defect_events: no mutable quality counter is maintained.

Material Consumption, MES Integration, and Production Analytics

Material consumption is append-only: each material_consumption_events row records work_order_id, part_id, lot_id, quantity_consumed, consumed_at, and operator_id. Corrections write a negative reversal row followed by a new correct row: no consumption record is ever mutated. Lot tracking maintains lot status via lot_status_events (QUARANTINE | RELEASED | RECALLED | CONSUMED); a supplier recall writes a RECALLED row for the affected lot_id, and the system queries material_consumption_events to identify every work order that consumed that lot and flags the affected finished goods without touching any production records. MES integration via OPC-UA adapter writes machine signals (cycle complete, machine stop, alarm) as machine_events (machine_id, signal_type, occurred_at, payload JSONB), stored in raw form before transformation; idempotency is enforced via ON CONFLICT DO NOTHING on (machine_id, signal_type, occurred_at). Analytics materialised views include first_pass_yield_by_part_by_work_centre, scrap_rate_by_defect_type, cycle_time_by_part_by_machine, schedule_adherence_by_work_centre, and material_variance_by_work_order (planned vs actual consumption): all recomputable and auditable to source events. SPC control chart parameters (UCL, LCL, subgroup_size, Western Electric rules to enforce) live in control_chart_config; a limit change takes effect at next evaluation without a code deployment.

Frequently Asked Questions

How does the system prevent a mid-run BOM update from changing what a running work order produces?

The bom_version_id is locked onto the work order at release time. Even if the BOM is updated during a production run, the work order continues to reference the version active when it was released. Any change to the active BOM affects only subsequently released work orders.

Can non-conformance reports be deleted or modified after creation?

No. NCRs follow an append-only state machine (OPEN / UNDER_INVESTIGATION / ROOT_CAUSE_IDENTIFIED / CORRECTIVE_ACTION_PLANNED / CLOSED | VOIDED). VOIDED is a terminal state for invalid NCRs, but the original record is preserved with the void reason. No NCR row is ever deleted or mutated after creation.

How does lot recall work when a supplier reports a defective material batch?

A recall writes a lot_status_events row with status RECALLED for the affected lot_id. The system queries material_consumption_events to identify every work_order_id that consumed that lot, flags the affected finished goods, and surfaces a recall impact report without touching any production records.

How are SPC control limits changed, and does it require a deployment?

Control chart parameters (UCL, LCL, subgroup_size, and which Western Electric rules to enforce) are stored in control_chart_config. Updating a control limit requires an authorised config row update; spc_signals are then computed against the new limits at next evaluation without a code deployment.

How quickly can a production management platform be deployed?

Scrums.com dedicated engineering teams deliver a working first deployment in 21 days.