Production Scheduling Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the constraint model get scoped too small?

Because the constraints that are easy to describe are the ones that get written down. Work centres, calendars, routings and due dates all sit in the enterprise resource planning (ERP) system, so they turn up in requirements naturally. The constraints that actually determine the sequence do not sit anywhere. They sit with the senior planner.

She knows the four hundred ton press cannot take tool 118 until maintenance replaces the platen. She knows running line 3 light to dark saves twenty five minutes of purge per colour change. She knows two operators are certified on the five axis cell and one of them is on nights this week. None of that has a field in a routing record, so none of it appears in a specification written from the ERP outward.

The result is a first release that schedules against infinite tooling, unlimited certified labour and sequence independent setups, which is a more expensive version of what the ERP already does. The floor notices in the first week.

The fix is to extract the rules before the architecture is fixed, in structured workshops rather than an interview. Build the sequence dependent changeover matrix, the machine and tooling compatibility table and the operator certification records as data the engine reads, with expiry dates on certifications. Then log every override the planner makes during the parallel run with a reason, because the overrides surface the rules nobody thought to mention. Expect the rule set to grow by a third during the build. Plan the budget for that rather than treating it as scope creep.

What goes wrong with routing and standard time data?

Scheduling exposes data quality that a system of record tolerates happily. An ERP will hold a routing with a standard time of two hours that has actually run in four for the last three years, and nothing complains, because the ERP is not trying to fit that operation into a shift. A finite capacity engine is, and it will produce a plan that is wrong by a factor of two on that work centre and correct everywhere else, which is the hardest kind of wrong to diagnose.

The common defects are consistent across manufacturers. Standard times set at launch and never revised. Alternate operations that exist on paper for machines long since sold. Routings that skip an operation the floor always performs. Setup times buried inside run times so the engine cannot separate them, which makes changeover optimisation impossible. Work centre calendars that do not reflect the actual shift pattern, particularly around weekend and holiday coverage.

Do not attempt to clean everything. Rank work centres by load, take the top ones, and compare standard times to actual recorded run times from the last twelve months. Where the gap is consistent, correct the standard. Where it is erratic, that work centre needs data capture before it needs scheduling, and saying so early protects the project.

Then keep it honest after launch. Feed actuals back and report drift between standard and observed by work centre, monthly, to a named owner. Run time learning is often sold as a machine learning feature. In practice a simple drift report that somebody acts on delivers most of the value in the first year.

Why does ERP writeback break after launch?

Reading work orders is a week of work. Writing confirmed dates back safely is a subsystem, and the difference is where projects lose their schedules.

The breakages are all about change. A work order quantity is revised after it was scheduled and dispatched. An operation is added to a routing mid job. An order is cancelled after the dispatch list printed. A date is written back, then the ERP recalculates from material requirements planning overnight and overwrites it. Two planners touch the same order in the same minute. Each of these is ordinary in a plant and each needs a defined behaviour, not a retry.

What survives is an explicit contract per field. Decide which system is authoritative for the promise date, the quantity, the routing and the operation status, write it down, and enforce it in the integration rather than in a habit. Make writeback idempotent so a repeat does not double post. Queue failed writebacks visibly with an owner rather than logging them, because a silent writeback failure means customer service is quoting from stale dates and nobody knows for days.

Ask any developer directly how they handle an order cancelled after dispatch, and how a failed writeback surfaces. Vague answers here turn into a weekly reconciliation meeting that never ends.

What happens when traceability and audit obligations are not covered?

They get retrofitted, badly, three weeks before a certification audit. If you hold AS9100 or serve customers with equivalent obligations, the auditor's question is always who moved the job and why, and a scheduling system with mutable history cannot answer it.

The failure is subtle because the system looks compliant. Schedules exist, dispatch lists were printed, work orders were completed. What is missing is the record of the decisions. Which sequence was published on Tuesday morning, who overrode it at nine fifteen, what reason they gave, which orders slipped as a result and who authorised the overtime that covered them. Rebuilding that from application logs after the fact is not evidence, and an experienced auditor knows the difference.

Design it in from day one, because it is cheap at the start and expensive later. Immutable schedule versions with a publish event. Every override stored with the user, the timestamp and a reason code. Traceability from work order to operator to work centre, which you frequently need anyway for a customer escape investigation. A read only view an auditor can be handed rather than a report somebody assembles.

If you serve medical device or regulated customers, get the applicability question answered properly rather than assumed. A developer who applies pharmaceutical style electronic record controls everywhere will waste your budget, and one who misses them where they apply will cost you a contract. Both mistakes are common.

Should you build custom or configure what you already own?

Configure first, genuinely. If you run one site, under roughly fifty open work orders, a standard job shop flow and no constraint an advanced planning and scheduling vendor would blink at, the scheduling module inside the ERP you already pay for is the right answer, and the honest recommendation is to exhaust it before buying anything.

Next, buy. PlanetTogether and Siemens Opcenter APS are real products and they solve real scheduling problems. If your constraint set is conventional and the vendor model fits without heavy customisation, buying is faster and cheaper than any build. The warning sign is not the licence price, it is the customisation quote. When your sequencing rules keep coming back as paid customisation and the implementation estimate climbs toward what owning a system outright would cost, you are buying a partial fit at a full price.

Build when the spreadsheet has a bus factor of one, when you run more than one site and there is no single load view, when promise dates are set by asking a planner who is guessing, or when the way you sequence and promise is part of why customers choose you. If scheduling is a commodity in your niche, buy the commodity and spend the money on machine reliability.

How do hidden costs get into the quote?

• Constraint count. A changeover matrix is cheap. Tooling contention across cells, certified labour pools and batching furnaces are each their own model, and they are rarely enumerated in a first estimate.
• ERP writeback. Frequently quoted alongside the read as one integration. It is a separate subsystem with its own failure handling.
• Solver depth. A good rules based heuristic ships in weeks. Mathematical optimisation adds months and is often unnecessary. Ask which is being quoted and why.
• Shop floor data capture. Live status is what keeps the schedule honest. Tablets, mounts, network coverage in a metal building and the operator training week are real costs and usually somebody else's budget.
• Data cleaning. Standard times and routings for the loaded work centres. Priced as discovery, delivered as weeks.
• The parallel run. Two to four weeks of the senior planner doing the job twice. That is the most expensive person in the project and their time is rarely in the plan.

What separates a build that works from one that fails here?

The builds that work make the senior planner the design authority from week one, not a stakeholder consulted at the review. She decides what the board looks like and which moves need to be fast, because adoption in this category fails on workflow friction rather than on scheduling mathematics. If a drag and drop override takes more clicks than editing a cell, the spreadsheet wins and no amount of solver quality rescues it.

They treat a breakdown as an event rather than a data entry task. The work centre flags down from a machine signal, the manufacturing execution system or a button on the operator tablet, the engine proposes a repaired schedule in minutes, and the planner compares scenarios side by side: authorise overtime, outsource the milling operation, or slip three low margin orders to protect the two carrying penalties. The customer impact list comes out sorted by exposure, so the first call goes to the account that matters.

They earn the promise date. A capable to promise endpoint the quote screen can call, returning the earliest realistic ship date given current load plus what it costs to jump the queue, is the feature that changes commercial behaviour. Rush work starts carrying a rush fee instead of an apology.

And they retire the spreadsheet deliberately. Parallel run for at least two full schedule cycles, daily comparison of system output against the planner's sheet, differences investigated rather than explained away, and the planner signs acceptance. Anyone who proposes a cutover without that is selling you an installation, not a working system.

Settle ownership before contract. Full assignment of the code on payment, the repository in your control from the first sprint, and documented deployment. At Digital Heroes the client owns it from the first commit. Your constraint model is years of knowledge about your own floor, and it should not sit anywhere you cannot take it.