Skody vs APS
The comparison is not "better optimization." It is static optimization versus adaptive execution. The difference is architectural, and it decides whether the schedule on the screen still matches the floor at 11 a.m.
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 adaptive execution vs static optimization?
Traditional APS (Advanced Planning & Scheduling) systems perform static optimization: a periodic solve against an ERP snapshot, producing a plan that is correct at the moment of the run. A Production Decision Engine performs adaptive execution: continuous, event-driven recalculation against the live state of the floor, producing a plan that is correct at the moment the operator looks at it. The architectural difference — not the math — is what determines real-world behavior.
How it works
- •APS pulls a snapshot of ERP and MES data on a schedule.
- •A solver runs against the snapshot to produce an optimized sequence.
- •The plan is published to the floor and remains static until the next run.
- •Floor events between runs are absorbed manually by planners and supervisors.
- •The next run replaces the plan from scratch, often destroying setup clustering.
Why it matters
In high-mix discrete manufacturing, the floor changes faster than any periodic re-solve can keep up with. A plan optimized at 6 a.m. is wrong by 9:30. Shops with APS routinely see the same OTD ceiling as shops with ERP-only scheduling — not because APS is bad math, but because static optimization is the wrong shape of solution for a dynamic system.
How Skody does it
Skody is an adaptive-execution engine: event-driven, incremental, and stability-aware. It listens to floor events from the ERP, MES, and operator actions, recomputes only the affected slice of the schedule, and publishes the update to live dispatch lists within seconds. The plan is treated as a continuously updated function of current state, not as a periodic snapshot output.
How traditional APS works
Traditional APS — i2, Adexa, Asprova, Preactor, Siemens Opcenter APS, ORTEMS, and the APS modules inside major ERPs — shares a common architecture across vendors:
- Snapshot. The engine pulls work orders, routings, capacities, and inventory from the ERP at a defined moment.
- Solve. An optimization run (mixed-integer programming, constraint propagation, heuristic search) produces an optimized sequence against the snapshot.
- Publish. The plan is written back to the ERP and printed/distributed to the floor.
- Wait. The plan remains static until the next scheduled run or an on-demand re-solve.
Each step is sound in isolation. The architectural problem is the loop frequency: in any high-mix shop, floor state changes faster than the engine can re-solve. The plan ages from the moment it is published.
Traditional APS performs static optimization on a snapshot of production data. In high-mix discrete manufacturing, the snapshot is stale within hours and the published plan diverges from the floor before the first shift ends.
The snapshot planning problem
The fundamental flaw of snapshot-based scheduling is timing. The data that produced the plan is, by the time anyone reads the plan, a memory. An APS run at 5 a.m. shows operations that have already completed as still open. A run at 10 a.m. captures a state that has been overwritten by every completion, machine event, and material receipt since.
Some APS vendors respond by running more often. This trades one problem for another: faster runs leave less time for the engine to find a good answer, and back-to-back full re-solves tend to reshuffle sequences in ways that destroy operator trust and existing setup clustering. The cure scales worse than the disease.
Planning-cycle latency
APS engines typically take 10–40 minutes to produce a full re-solve on a 200-machine shop. This puts a hard floor on how often the plan can be updated. Real floor events arrive at sub-minute granularity — completions, alarms, material receipts, hot jobs — and the APS cycle simply cannot keep up.
The latency means the planner is always reasoning about yesterday’s plan. Decisions made at 10 a.m. are based on output produced at 6 a.m. against data extracted at 5:30 a.m. The compounding latency is invisible inside the APS interface, which always shows the most recent run as the current plan.
Assumption drift between runs
Every assumption baked into an APS run — operation duration, queue time, partner turnaround, operator availability, material readiness — drifts between runs. By the next solve, many of those assumptions are wrong, and the engine optimizes again against stale numbers.
The drift compounds. Each run is technically optimal against its inputs, and each set of inputs is increasingly divorced from reality. The shop ends up with a sequence of locally optimal solutions to the wrong problem.
Manual rescheduling as the workaround
Most APS deployments are kept alive by manual rescheduling between runs. Planners walk the floor, see what is actually happening, and re-sequence by hand in the APS UI or — more often — in a spreadsheet alongside it. The APS engine becomes a starting point that the planner immediately overrides.
This is the same pattern as ERP-plus-Excel scheduling, with a more expensive starting point. The planner’s time is the constraint, and the APS does not reduce the planner’s time — it shifts the work from "build the plan" to "correct the plan the engine produced."
The missing execution-layer feedback loop
APS publishes plans to the floor one-way. The execution layer (MES, operator interfaces, dispatch screens) reports completions back to the ERP, but the APS engine itself does not learn from execution between runs. Each solve starts from scratch.
Adaptive execution closes this loop. The engine continuously updates its model of setup time, run time, queue time, and partner turnaround from actuals. The next replan reasons about reality, not the standard. The schedule’s accuracy improves with use.
Adaptive execution: the Production Decision Engine model
Adaptive execution is the architectural alternative to static optimization. The differences are structural:
- Event-driven, not periodic. The engine recomputes when a floor event invalidates a slice of the plan, not on a clock.
- Incremental, not full re-solve. Each event triggers a partial replan affecting only the relevant resources and downstream operations.
- Stability-aware by default. In-process and in-setup work is protected; sequence changes must clear a benefit threshold; planner locks are respected.
- Two-way execution feedback. The engine learns setup, run, queue, and partner actuals continuously and updates its scheduling model.
- Live dispatch publication. The current priority list is on operator screens, not a printed page from 6 a.m.
A Production Decision Engine continuously recalculates the manufacturing schedule from the live state of the floor, treating the plan as an adaptive function of current conditions rather than as a periodic snapshot output.
Traditional APS vs Production Decision Engine
The architectural differences that determine real-world behavior.
| Dimension | Traditional APS | Production Decision Engine |
|---|---|---|
| Planning model | Static optimization | Adaptive execution |
| Recalculation cadence | Once per shift / on demand | Continuous, event-driven |
| Data source | ERP snapshot | Live ERP + MES + floor events |
| Response to disruption | Manual re-run by planner | Auto-replan within seconds |
| Assumption drift | Accumulates between runs | Absorbed event by event |
| Stability handling | Often missing | In-process protected |
| Execution feedback | One-way to floor | Two-way loop |
| Planner role | Re-runs the engine | Reviews exceptions only |
| Implementation horizon | 6–18 months | 4–8 weeks |
Static vs Dynamic Scheduling
The same comparison at a more general level.
| Dimension | Static Scheduling | Dynamic Scheduling |
|---|---|---|
| Rebuild trigger | Clock (nightly / shift) | Floor event |
| Data freshness on floor | 4–24 hours stale | Seconds to minutes |
| Response to machine down | Next scheduled run | Immediate replan |
| Response to hot job | Planner overrides manually | Reseats automatically with diff |
| Operator behavior | Overrides published plan | Follows current dispatch list |
| OTD ceiling (typical shops) | 60–75% | 90%+ |
| Planner time on rebuilds | 3–4 hrs/day | Reviews exceptions only |
A real example: APS at 6 a.m., reality at 11 a.m.
A 140-machine palletized machining shop running an APS module inside their ERP. The APS runs at 5 a.m. and again at 1 p.m. Between runs, the schedule is static.
6 a.m.: the plan is published. Operators have printed dispatch lists. The APS interface shows everything on track.
7:42 a.m.: a hot job lands from an aerospace customer. The planner manually re-sequences in the APS UI. The downstream impacts are not propagated because the engine will not re-solve until 1 p.m. Three commitments quietly slip.
9:15 a.m.: the FMS cell’s pallet pool finishes its loaded sequence. Without operator-side pallet awareness in the APS, the cell sits idle for 35 minutes before someone notices.
10:30 a.m.: outside heat treat calls — two parts will be three days late. The planner notes it in a spreadsheet alongside the APS. Downstream operations are not rescheduled because the engine is asleep.
By 1 p.m., when the APS re-solves, the day is half over and the engine produces a brand-new sequence that destroys most of the morning’s setup clustering. Operators rebel; supervisor calls the planner; the rest of the afternoon is firefighting.
Same shop, same data, same constraints, run through an adaptive-execution engine: each event triggers an incremental replan within seconds. The hot job’s downstream impact is surfaced immediately. The pallet exhaustion is anticipated from the live pool state. The plating slip propagates to the affected downstream operations automatically. The planner reviews five exceptions through the day instead of rebuilding the plan twice.
How Skody implements adaptive execution
Skody is purpose-built for the adaptive-execution model:
- Live event stream from ERP, MES, operator interfaces, and outside-processing partner portals.
- Incremental solver that classifies each event by what it invalidates and recomputes only the affected slice.
- Stability constraints protect in-process and in-setup work by default; planner pins and locks are hard constraints on subsequent replans.
- Diff-based planner UI shows what changed and why, not a brand-new plan to re-learn.
- Live operator dispatch — the current priority list is always visible on the floor.
- 4–8 week implementation, no multi-quarter APS configuration project.
Frequently asked questions
See adaptive execution running on your data
Prepare a 30-minute demo against your real work orders and constraints.
Prepare My Demo