Production Planning & Scheduling: Start with MRP, Grow into Finite Scheduling

Ask a shop owner what their scheduling system is and you will usually get one of two answers. The first is a spreadsheet, or a whiteboard, or the memory of one very experienced scheduler who knows what has to run next and in what order. The second is an ERP module that technically exists, was configured once during implementation, and is now quietly ignored because nobody trusts the dates it produces. Both answers point at the same underlying problem: production planning is the hardest thing an ERP does, and most systems either oversimplify it into uselessness or overcomplicate it into abandonment.

The conventional advice is to pick a lane. Buy simple planning software if you are small, and accept that the dates are approximate. Buy a dedicated advanced scheduling package if you are serious, and accept the cost, the implementation, and the integration work required to bolt it onto whatever ERP you already own. Neither option is satisfying, and the reason is structural: the industry has treated planning depth as a product tier rather than as a setting you turn up when you are ready.

CyntrixOne takes a different approach. Planning is one system with three levels of control, and you choose how far up you go. What matters most is what happens when you decide to move: the configuration you have already done carries forward. Stepping up a level is a change in how the engine treats capacity, not a new implementation.

Why Scheduling Is Where ERP Implementations Go to Die

Every other module in an ERP records something that already happened. An invoice reflects a sale. A receipt reflects material that arrived. Inventory reflects what is physically on the shelf. These are all descriptions of reality, and if the data is entered correctly, the module is correct.

Scheduling is different in kind. A schedule is a claim about the future — an assertion that this operation will run on this machine at this hour, and that the order will therefore ship on this date. It is the only part of the system that has to be predictive rather than descriptive, and it is the only part whose accuracy depends on modeling the physical constraints of the shop: how many machines there are, how many hours they run, who is qualified to operate them, how long setup takes, and what has to finish before the next thing can start.

This is why scheduling modules get abandoned. If the model of the shop is wrong or incomplete, the dates are wrong, and a schedule nobody believes is worse than no schedule at all — it actively erodes trust in the entire system. And because the setup burden is front-loaded, most implementations either skip it, or attempt it all at once, fail, and never return.

A schedule nobody believes is worse than no schedule at all. It does not just fail to help — it teaches the floor to ignore the system.

The way out is to stop treating the setup as all-or-nothing. If a shop can get real value from a light configuration, then deepen that configuration incrementally as the payoff justifies the effort, the abandonment problem largely disappears. That is the logic behind the three levels.

Level One: MRP — Plan What to Make and What to Buy

Material requirements planning is the oldest idea in production software and still the most underrated. It answers the two questions that cause the most expensive mistakes in a job shop: what do I need to buy, and when do I need to start. It does this by exploding your bills of material against your due dates and subtracting what you already have, then working backward through lead times to produce start dates and purchase recommendations.

The deliberate simplification at this level is capacity. MRP assumes you have unlimited machine hours and unlimited people, which is obviously false — but the assumption is what makes the setup so light. You do not have to model shifts, individual machines, operator skills, or setup times to get started. You need routings at the work-center level, lead times, and accurate inventory. For a shop whose real constraint is material arriving on time rather than machines being full, this is frequently enough to run on.

What you get is a plan that is directionally right and immediately useful: purchase orders raised early enough, jobs released in a sensible sequence, and a clear warning when a promised date is not achievable given lead times. What you do not get is a promise you can stake a customer relationship on, because the plan does not yet know whether the floor has the hours available.

Level Two: APS Infinite — See Your Real Load

The step from MRP to infinite APS is a change in resolution. Instead of planning against a work center — a department, effectively — the engine assigns each operation to the actual machine that will run it and the actual person who will run it, in the correct routing sequence, timed against when material is genuinely available.

The word infinite refers specifically to capacity. The engine now knows how much load you are putting on each resource, and it shows you, but it will not stop you from overloading anything. If a machine has forty hours available next week and the plan puts sixty hours on it, you will see sixty hours against forty — clearly, resource by resource — and the decision about what to do belongs to you.

This turns out to be exactly what a lot of shops want, and it is a genuinely useful place to stop. An experienced scheduler who can see the true load on every machine will make good decisions about overtime, sequence, and outsourcing. What they could never do before was see the load accurately in the first place. Infinite mode gives them the visibility without the engine overriding their judgment, and it is also the natural proving ground for your data — if your routings or setup times are wrong, the load chart makes it obvious quickly.

Level Three: APS Finite — A Schedule You Can Run

Finite scheduling is where planning software stops describing your shop and starts producing an executable plan. The engine now refuses to schedule work past the hours a resource actually has. Sixty hours of demand against forty hours of capacity does not produce an impossible schedule — it produces a queue, and the work that does not fit moves to when it genuinely can run.

The consequence is the single most valuable output in production software: a date you can defend. When an order cannot make its requested date, the engine does not silently show it as late and leave you to discover the problem when the customer calls. It calculates the soonest date the order can actually be delivered given real capacity, and it tells you. That is a fundamentally different conversation to have with a customer — not an apology after the fact, but an honest number before you commit.

Quoting and scheduling run off the same finite capacity, so the date you promise is the date the floor can keep. Most systems quote from a formula and schedule from reality — then wonder why the two never agree.

This last point deserves emphasis, because it is where most implementations leak credibility. In a lot of ERPs, quoted lead times come from a static rule — a standard number of days, or a planner's estimate — while the shop schedule is calculated separately from actual load. The two are structurally guaranteed to disagree, which is why sales promises dates the floor cannot hit. When the quote engine and the schedule share the same finite capacity model, that gap closes by construction.

What the Finite Engine Actually Handles

Cure time and operation overlap are worth calling out, because they are frequently missing and their absence quietly ruins schedules. If a part has to sit for four hours after coating, a scheduler that does not model that will promise a date that is physically impossible. And if a thousand-piece run has to fully complete before the next operation can begin, when in practice the second operation could start after the first hundred pieces, the schedule will invent weeks of delay that do not exist.

At a Glance

The Ladder Is One-Way and Lossless

The reason this structure matters is not that three options are better than one. It is that moving between them does not cost you anything you have already built. Every level consumes the same underlying data — the same routings, the same bills of material, the same resource definitions — and each higher level simply adds detail and changes how capacity is treated.

Starting with MRP does not mean building a throwaway configuration you will later replace. The routings you enter at the work-center level remain valid when you assign specific machines. The lead times you establish stay meaningful. Moving from infinite to finite does not require re-entering anything at all — it requires that you have defined the shifts and capacities for your resources, and then it changes the engine's behavior from permissive to enforcing.

The setup you have already done always carries forward. Stepping up is a change in how capacity is treated, not a new implementation.

This is what the traditional tiered market could not offer. When simple planning and advanced scheduling are different products — often from different vendors, on different data models — outgrowing the first one means a migration. When they are levels of the same engine, outgrowing the first one means changing a setting and doing the incremental setup that the next level requires.

Which Level Should You Start At?

The honest answer depends on what actually constrains your shop, and it is worth being clear-eyed about this rather than defaulting to the most powerful option.

• If your jobs are paced by material arriving rather than machines being full, start at MRP. Finite scheduling solves a problem you may not have, and the setup effort will not pay for itself.
• If you suspect you are overloaded but cannot prove where, start at infinite APS. The load view frequently reveals that the bottleneck is not where everyone assumed it was.
• If you are regularly quoting dates you miss, or turning down work because you genuinely cannot tell whether you have room for it, finite is the level that pays for itself fastest.
• If your data quality is uncertain — routings that were entered years ago and never verified — begin at infinite regardless of your eventual target. Finite scheduling built on wrong setup times produces confident, precise, wrong answers.

That last point is the one most often learned the hard way. Finite scheduling is unforgiving of bad data in a way that MRP is not, because it is making hard commitments rather than rough suggestions. Using infinite mode as a data-validation stage is not a detour — it is the shortest path to a finite schedule you can actually trust.

The Bottom Line

Production planning has been sold as a binary for decades: simple enough to implement but too vague to run on, or powerful enough to run on but too expensive and disruptive to reach. The binary was never a property of the problem. It was a property of how the software was packaged and priced.

Start where your shop actually is. Get value from a light configuration in weeks rather than quarters. Deepen it when the payoff justifies the effort, and know that nothing you set up along the way gets thrown out. That is planning that starts simple and ends up running your shop.