What Is a Production Decision Engine?
ERPs record transactions. MES tracks execution. APS produces periodic plans. None of them continuously decide what should happen next on the floor. The Production Decision Engine is the layer that does.
Built with real job shops
Developed alongside discrete manufacturers running 20–200 machines — CNC, fabrication, mixed operations, including Boeing-tier suppliers.
Co-designed with planners
Every concept on this page was pressure-tested against live planners, schedulers, and shop-floor supervisors — not derived from generic SaaS playbooks.
Validated on the floor
Pallet pools, setup clustering, lights-out runs, outside processing, hot jobs — modeled from real machinist workflows, not theory.
What is Production Decision Engine?
A Production Decision Engine is a software system that continuously decides what should happen next on a manufacturing floor, based on the live state of machines, labor, material, tooling, and outside processing. It reads from the ERP (which records transactions) and the MES (which tracks execution), runs finite-capacity scheduling against the current state, and publishes a live, continuously updated dispatch sequence to operators, supervisors, and planners. It is the decision layer the existing manufacturing software stack was not designed to be.
How it works
- •Reads live state from ERP, MES, operator interfaces, and outside-processing partner portals.
- •Runs finite-capacity, constraint-aware scheduling continuously, not periodically.
- •Recomputes only the affected slice of the schedule on each floor event.
- •Publishes the current priority sequence to live dispatch screens and planner exception views.
- •Learns setup, run, queue, and partner actuals and feeds them back into the model.
Why it matters
Discrete manufacturers have invested heavily in ERP, MES, and sometimes APS — and most still cannot answer the basic operational question: given everything that is true on the floor right now, what should this operator run next? The gap is structural. ERPs were not built to decide; MES tracks after the fact; APS optimizes on snapshots. The Production Decision Engine names and fills the gap.
How Skody does it
Skody is a Production Decision Engine purpose-built for discrete manufacturers running 20–200 machines. It connects to existing ERP and MES systems, models machines, labor, tooling, pallets, and outside processing as first-class constraints, and continuously publishes the current best decision to the floor. Implementation runs 4–8 weeks; OTD lift is typically visible in 30–60 days.
ERP records, MES tracks, APS optimizes — none of them decide
Every layer of the conventional manufacturing software stack was designed for a different question. None of them was designed for the operational question that matters most.
- ERP answers: what did we buy, what did we sell, what is in inventory, what work orders are open? These are transaction questions. ERPs are excellent at transactions. They are not scheduling systems, and scheduling modules bolted onto transaction systems inherit the transaction-first architecture.
- MES answers: what is happening on the floor right now, what just completed, what is the cycle time on this machine? These are execution-tracking questions. MES is excellent at tracking execution. It does not decide what should happen next.
- APS answers: given a snapshot of demand and capacity, what is the optimal sequence? This is a periodic optimization question. APS is excellent at periodic optimization. It is not continuous and not event-driven, so by the time the floor reads the output, the snapshot is already stale.
- Dashboards and BI answer: what happened? They are explanatory, not decisional.
- Planners answer: given everything I know that is not in the system, what should happen next? They are the de facto decision engine in most shops. The cost is paid in their time — 3–4 hours per day of manual re-sequencing.
ERP records transactions. MES tracks execution. APS optimizes plans on snapshots. None of them continuously decides what should happen next on the floor — that gap is the role of a Production Decision Engine.
The decision layer factories have been missing
The Production Decision Engine is not an ERP feature, an MES feature, or a better APS. It is a different architectural layer: the layer that takes the live state recorded by ERP and MES, applies finite-capacity and stability logic, and continuously produces the operational answer to the question "what should the floor do next?"
Adding this layer to the stack is not a configuration choice or a vendor upgrade. It is a structural addition that closes the gap between transaction systems and execution-tracking systems. The function exists in every shop — it is performed today by planners with spreadsheets. The Production Decision Engine is the software embodiment of that function.
The operational loop: Sense → Decide → Publish → Learn
A Production Decision Engine runs a continuous loop. Each cycle is small; the engine performs hundreds per day.
- Sense. Read state changes from ERP, MES, operator interfaces, partner portals, and machine controls. Each event is timestamped and classified by what it invalidates.
- Decide. Recompute the affected slice of the schedule using finite-capacity and stability logic. Honor planner pins, locks, and priority overrides.
- Publish. Push the updated priority sequence to live operator dispatch screens, supervisor dashboards, and the planner exception view. Show a diff with the cause attached, not a brand-new plan.
- Learn. Capture actuals — setup time, run time, queue time, partner turnaround — and update the scheduling model so the next decision reasons about reality.
The loop is the structural difference between a Production Decision Engine and an APS. APS performs a single Sense-Decide-Publish cycle on a schedule. A Production Decision Engine performs the cycle continuously, with learning closing the loop back to the next decision.
The decision hierarchy
Not every decision belongs in the engine. A useful Production Decision Engine respects a hierarchy:
- Strategic (quarterly): capacity expansion, new equipment, shift policy. Humans, not the engine.
- Tactical (weekly): customer commitments, outside-processing partner selection, campaign planning. Humans, informed by engine output.
- Operational (daily): release decisions, hot-job acceptance, capacity trade-offs. Humans, with the engine surfacing the trade-off explicitly.
- Execution (continuous): sequencing, dispatching, resequencing on floor events. The engine, with planner pins and locks respected.
The engine’s job is execution-level decisions. The planner’s job is operational-and-above decisions. Most scheduling failures come from forcing one role to do the other’s work.
Why factories become unstable without a decision engine
Without a continuous decision layer, the gap between plan and reality is closed manually — by planners, supervisors, and operators making local decisions with partial information. Each local decision is rational; the aggregate is chaotic.
The supervisor expedites a hot job. The planner notices and re-sequences in Excel. Operators see the change verbally and re-prioritize. Material people pull stock for the new priority. Outside processing gets a panicked call. Two of these actions conflict because no one had the full picture. By end of shift, three downstream operations are starved and two customer commitments are quietly broken.
Factories become unstable not because planners are bad at deciding, but because the floor produces decisions faster than any human can coordinate them. A Production Decision Engine absorbs the routine so humans can focus on the exceptions.
Why execution diverges from plans
The most reliable indicator that the decision layer is missing: the schedule looks fine in the system and broken on the floor. The ERP reports on-plan execution. The MES shows completions arriving. The dispatch list was printed at 6 a.m. And yet operators are running by gut, supervisors are expediting verbally, and the planner is in Excel.
Execution diverges from the plan because the plan is a memory and execution is happening now. Without a continuous decision engine, the gap is closed by people, in their heads, with imperfect information. The gap is invisible to the systems that should see it.
Why adaptive coordination matters
A modern discrete-manufacturing floor is a continuously interacting system: machines, operators, tools, fixtures, materials, and partners all changing state independently and constantly. Coordinating them requires a system that updates as fast as the state changes.
That is the function of adaptive coordination — and it is the function a Production Decision Engine performs. The engine does not optimize once. It coordinates continuously. The output is not "the plan" but "the current best decision given everything that is true right now."
Modern manufacturing floors are dynamic systems. Plans drift. Schedulers adapt manually. A Production Decision Engine continuously recalculates from live production conditions so the floor and the system see the same reality.
ERP vs MES vs APS vs Production Decision Engine
Which system answers which question — and where the gap is.
| Question | ERP | MES | APS | Production Decision Engine |
|---|---|---|---|---|
| What did we buy and sell? | Yes | No | No | No |
| What is happening on the floor right now? | No | Yes | No | Yes |
| What was supposed to happen this shift? | Snapshot plan | No | Yes | Yes |
| What should happen next given live state? | No | No | In next batch | Continuously |
| Which job should this operator run next? | Printed list | Shows queue | Stale by mid-shift | Live dispatch |
| Why did the plan change? | No | No | No | Named cause per replan |
| What will OTD be on Friday? | No | No | Plan-side only | Yes |
How Skody implements the Production Decision Engine
Skody is a Production Decision Engine built specifically for discrete manufacturers running 20–200 machines. It connects to existing ERP and MES systems and adds the continuous decision layer:
- Reads from NetSuite, Epicor, JobBOSS, Global Shop, E2, ProShop, Made2Manage, Sage, Acumatica, and other discrete-manufacturing ERPs.
- Models machines, labor and certifications, tooling, fixtures, pallets, outside-processing partners, and sequence-dependent setup as first-class constraints.
- Runs finite-capacity, event-driven, incremental scheduling with stability defaults.
- Publishes live dispatch lists to operator screens, supervisor dashboards, and planner exception views.
- Learns from actuals continuously and updates the scheduling model.
- Implements in 4–8 weeks, with measurable OTD lift typically visible in 30–60 days.
Frequently asked questions
See the Production Decision Engine running on your data
Prepare a 30-minute demo against your real work orders, routings, and constraints.
Prepare My Demo