Why ERP Schedules Fail
Your ERP is excellent at what it was built for. Production scheduling is not what it was built for. Seven structural reasons every ERP-based schedule collapses on the floor — and the fix that does not require replacing the system.
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 ERP scheduling failure?
ERP scheduling fails in discrete manufacturing for a structural reason: ERPs were built as transaction systems, not as live floor schedulers. They assume infinite capacity, run on snapshots, ignore labor and tooling, treat outside processing as a fixed offset, and cannot respond to floor events between runs. The schedule on the screen and the work on the floor diverge by mid-morning, and the divergence is invisible to the system.
How it works
- •The ERP issues work orders against MRP demand and infinite capacity.
- •The scheduling run is a periodic batch over a static snapshot of data.
- •Operations are slotted by earliest-need date, not by what the floor can actually run.
- •No event between runs updates the plan; the dispatch list ages immediately.
- •Operators compensate by ignoring the system, and the ERP keeps reporting on-plan.
Why it matters
Discrete manufacturers running on ERP scheduling typically report 60–75% OTD with planners spending 3–4 hours per day rebuilding sequences in Excel. The root cause is not the planner, the operator, or the data — it is that the planning model assumed a world that does not match the factory. Replacing the ERP does not fix this. Adding a live scheduling engine on top of it does.
How Skody does it
Skody is the live scheduling engine that sits on top of the ERP. It reads work orders, routings, and constraints from the ERP and writes completions back, so the financial system is untouched. The schedule itself runs against the live floor with finite capacity, labor, tooling, pallets, and outside processing all modeled — and replans within seconds of floor events.
Infinite capacity is the default assumption
The most common ERP scheduling mode assumes any work center can absorb any amount of work. The 5-axis cell is treated as an unbounded queue. If a planner releases 80 hours of work to a 40-hour machine, the ERP accepts the release. The infeasibility is silently transferred to the floor.
APS modules add finite capacity, but most run periodically on a snapshot, which means the floor sees an overloaded plan between runs and operators resequence by gut.
Scheduling runs on a snapshot, not on live state
ERP scheduling is, in almost every system, a batch over yesterday's transactions. Nightly MRP, on-demand reschedule, shift-boundary run — the variants differ but the architecture is identical: take a snapshot, run the solver, publish the plan. The plan is, by definition, a memory of state at the moment of the run.
On a normal day in a 100-machine shop, the floor generates dozens of state changes per hour. None of them update the plan. By 9:30 a.m., the published schedule no longer represents the floor.
No model for labor, tooling, or fixtures
Most ERP scheduling modules consider machines and (sometimes) labor hours, in aggregate. They do not model individual operator certifications, shared tools, special fixtures, calibrated gauges, or sub-plates. A machine without an operator who can run it is still scheduled. A spindle without the required tool holder is still scheduled.
On the floor, these missing constraints are the actual binding constraints. Up to half of the daily disruption in a typical shop comes from the labor and tooling resources the scheduling system never knew existed.
Outside processing modeled as a fixed offset
Heat treat, plating, anodize, painting, NDT — most ERPs treat outside processing as a fixed lead-time offset. "Heat treat: 5 days." The actual partner has a queue, a workload, holidays, capacity bottlenecks, and slip patterns. When the 5-day quote becomes 9 days, the receiving operation cannot start, downstream queues empty, and the schedule is wrong for everything that depended on the return.
A scheduler without a real outside-processing model is running on hope. In shops with heavy outside processing, this is routinely the largest single cause of OTD miss.
No event response: the plan is frozen until the next run
A machine goes down at 8:15 a.m. The published schedule still has six operations queued for that machine through end of shift. The ERP does not react. Operators reroute by hand. By the time the nightly MRP run produces a new schedule, the day is over and the damage is done.
The lack of event response is the difference between a scheduling system that helps and one that gets in the way. Without it, every disruption — and there are dozens per day — is handled outside the system, undermining trust in the plan.
Setup time stored as a single number
The ERP stores one setup time per operation. Reality: the setup time depends on what ran before. A stainless job after a similar stainless job: 15 minutes. The same job after aluminum: 90 minutes. The ERP plan never knows which case it is in, so it averages, and the average is wrong on every shift.
The cumulative drift across a day of mis-estimated setups is enough to invalidate every downstream operation on the machine. The schedule looks accurate; the floor finishes two operations short by end of shift.
Queue time treated as a constant
Queue time accounts for 70–90% of total lead time. ERPs typically store it as a fixed standard ("4 hours between operations"). When work piles up in front of a bottleneck, actual queue time is 16 hours, not 4. Every downstream operation's promised start is wrong, and the error compounds for every routing step.
The visible symptoms in a typical shop
- OTD has been stuck between 60% and 75% for years.
- The planner spends 3–4 hours per day in Excel or on a whiteboard.
- Supervisors expedite hot jobs verbally; the system catches up after.
- Operators routinely override the printed dispatch list.
- Quoted lead times are 20–40% shorter than actual lead times.
- Customers learn about ship slippage from a phone call, not a system report.
- "The plan looks fine in the system but is broken on the floor."
- Friday afternoons are firefights even when Monday looked clean.
None of these are problems with the planner or the operator. They are predictable outputs of a scheduling architecture that does not match the factory.
This is not a vendor problem — it is an architecture problem
Every major mid-market ERP has the same scheduling limits. That is not coincidence. ERPs were designed as transaction systems — to log, to invoice, to issue, to receive. The scheduling module, in every system we have audited, is a secondary feature built around the transaction model.
Switching from one ERP to another to fix scheduling is one of the most expensive ways to not solve a scheduling problem. The result is two years of disruption, several million dollars, and the same scheduling architecture under a new name.
ERP vs Traditional APS vs Skody
The three scheduling architectures and what each can actually do.
| Capability | ERP Scheduling | Traditional APS | Skody |
|---|---|---|---|
| Schedule source | Static work order list | Daily ERP snapshot | Live floor state |
| Capacity model | Infinite (assumed) | Finite (periodic) | Finite + labor + tooling + pallets |
| Replan frequency | Manual / MRP run | Once per shift | Continuous (event-driven) |
| Handles unplanned downtime | No | In next batch | Replan in seconds |
| Models outside processing | Manual offsets | Yes | Dynamic with partner calendars |
| Sequence-dependent setup | No | Configured | Yes |
| Pallet & lights-out aware | No | No | Yes |
| Live operator dispatch list | Static print | Daily print | Live, updates per replan |
| Implementation horizon | Already deployed | 6–18 months | 4–8 weeks |
The Capacity Model Under Each Architecture
Most ERPs default to infinite; finite is the structural fix.
| Behavior | Infinite Capacity | Finite Capacity |
|---|---|---|
| Treats machines as | Unlimited hours | Real shift calendars |
| Bottleneck overload | Silently accepted | Flagged as at-risk |
| Promise dates | Optimistic, often missed | Tied to real capacity |
| Where the math runs | In the planner's head | In the scheduling engine |
| What operators see | 16 hours of work in 8 | A feasible sequence |
| Visibility into overload | No | Yes |
| Used in quoting | Lead times become fiction | Quote against real capacity |
How to fix scheduling without replacing your ERP
Keep the ERP. Add a purpose-built scheduling engine on top that reads work orders, routings, and constraints from the ERP, runs a live finite-capacity model with labor, tooling, pallets, and outside processing, and writes completions back. The financial system stays untouched.
Typical implementation is 4–8 weeks. The data already exists in the ERP — the missing piece is the live scheduling model on top of it. Most shops see measurable OTD lift (60–75% → 90%+) within 30–60 days of go-live.
That is the role Skody plays: the Production Decision Engine that lives next to the ERP, not instead of it.
Frequently asked questions
See a live scheduler running next to your ERP
Prepare a 30-minute demo against your work orders, routings, and constraints — no ERP replacement required.
Prepare My Demo