APS vs MRP: when your ERP is no longer enough

The symptom you see every Monday

Monday morning planning meeting. On the table: the printout of what the ERP suggests, a handful of spreadsheets, a few handwritten notes. Someone decides what goes into production. On Wednesday an important customer moves a delivery date; on Thursday another order becomes urgent. Monday's plan no longer describes Wednesday's factory.

This is not a people problem. It is a tool problem.

What the MRP inside your ERP does

MRP is the part of the ERP that works out what to buy and what to make. It starts from orders and forecasts, breaks products down into their components, and proposes the purchase and production orders required.

It does all of this assuming that resources are always available: it never looks at how many hours the machines and the people actually have.

It is logic that came out of the 1970s, when batches were large, the product range was narrow, and the time lost changing a machine over counted for little next to the time spent making the part. It still works in a great many situations, but it has one precise limit: it does not tell you whether the plan can actually be carried out.

What an APS does

An APS plans against real capacity. It does not only say what to make: it says when, on which machine, in what order. It takes into account:

• the hours genuinely available on each machine and in each department;
• the time lost changing tooling, colour or format when moving from one job to the next;
• the components and part-finished goods actually in stock;
• commercial priorities and the delivery commitments made to customers;
• the people available and the skills required, where that makes a difference.

The result is not a list that is only valid on Monday. It is a plan that can be rebuilt whenever something changes, instead of waiting for next week's meeting.

The signs that you need an APS

This is not a matter of principle: you decide it by looking at what happens on the shop floor. The moment arrives when two or more of these signs appear together.

1. Promised dates are unreliable. Sales phones the planner to ask whether a date can be promised, and the planner answers from experience. That is an answer the system should already be giving them, and it does not have one.
2. Material sitting on the floor keeps growing, but deliveries do not improve. More work is released than the factory can absorb, on the assumption that having everything ready speeds things up. It is the classic symptom of planning that ignores capacity.
3. A large share of what enters production enters as a rush job. When going outside the plan is the rule rather than the exception, nobody is planning: everyone is handling emergencies.
4. Changing the order of jobs is expensive. Tooling changes, colour changes, format changes: MRP does not see them, an APS does.
5. Machines look busy almost all the time, yet something is always late. The average hides the problem: the slowest machine — the bottleneck, the one that sets the pace for the whole factory — is saturated even when the department as a whole looks quiet.

What changes in day-to-day work

How much you improve depends on where you start, and the starting point is measured on your own data before anything begins: without it, any percentage is just a word. What does change, for certain, is the way the work is done, and it shows within the first few months.

• Delivery dates stop being one person's estimate. When sales calls to ask whether a date can be promised, the planner answers with what the plan says — built on what the factory can genuinely produce — instead of from experience.
• Less work enters the factory at a time. How long an order takes to cross production depends mostly on how many other orders are in there at the same time: the plan exists to let in only as many as the factory can carry.
• The order of jobs accounts for changeovers. Similar jobs are grouped together, so less time is lost resetting machines and the same machine produces more within the same shift.
• The bottleneck becomes visible. You stop reasoning about average utilisation and start seeing which resource is genuinely limiting deliveries — which is also the only one worth investing in.
• Rebuilding the plan becomes something you do when you need to. When a rush order changes the picture, the plan is recalculated instead of being patched by hand until the next meeting.

None of this comes from the software. It comes from the fact that, for the first time, the people who plan have a tool that matches the real factory.

What is rarely mentioned

An APS is not something you simply install. Three things separate a project that enters daily use from one that is quietly abandoned after acceptance testing.

• The quality of the underlying data. Wrong bills of materials, processing times estimated by eye for a whole department, machine capacities stated but never verified: an APS makes visible the errors that used to stay hidden, and spreads them across the whole plan. That is why the first phase of our projects is always checking the existing data, and the cost of that phase is set in the quote before we start.
• The connection to the systems already in place. The ERP, the system that collects data from the machines, the one that runs the warehouse. Without knowing where each order really stands, an APS plans on stale data.
• Adoption by the people who plan. If the planner keeps correcting the system's proposals by hand because they trust their own experience more, the plan and the factory will never speak the same language. That takes support during real work.

When you do not need an APS

In fairness: if you make a small number of different products, in large batches, with negligible changeovers, for customers who accept generous lead times, the MRP in your ERP is enough. Investing in an APS in that situation is the opposite mistake, and you find out when the tool sits unused.

The question to ask

In a given week, how many planning decisions are made on the phone or in front of a spreadsheet?

If the answer is "a lot", the problem is not how hard people are trying. It is that they do not have a tool that matches the reality they manage.

And once they do, they stop chasing emergencies and start deciding in advance.