When Production Really Needs MES/APS — and When Simpler Rules Are Enough ART-023

Start with the decision production cannot make today, not with the name of a system

When urgent orders multiply, the dispatcher constantly rebuilds the queue, and equipment alternates between overload and waiting, it is easy to compress the problem into one sentence: “we need MES” or “we need APS.”

But that is not yet a diagnosis.

The same picture — downtime, a missed due date, a queue in front of a machine, manual spreadsheets — can arise for fundamentally different reasons. In one shop an order simply does not reach ready-to-cut status: there is no current drawing, no control program prepared in a CAM system, no confirmed material, or no priority. Elsewhere all the data exists but is scattered across ERP, CAM, Excel, and managers’ messages. In another case the morning plan looks good, but after the first disruption no one knows the actual state of the work anymore. And sometimes the problem really is mathematically difficult: many orders compete for several resources at the same time, with different routes, materials, due dates, changeovers, and dependencies, and a human dispatcher cannot physically build a realistic schedule fast enough.

These situations need different tools.

So the useful first question is: which specific production decision is currently made late, blindly, or manually every time?

Not “which software should we buy,” but specifically:

• is the order ready to be released;
• what should run next;
• where the batch actually is;
• which resource is truly available;
• whether the due date is feasible with the current load;
• what must be replanned after a disruption;
• whether releasing this job will create an even larger queue at the next operation.

Once that decision is named, it becomes much easier to determine whether a new system is needed at all.

MES and APS solve different classes of problems, even though modern products can overlap

MES and APS are often mentioned together in manufacturing, but it is useful to separate them by their primary function.

MES — a Manufacturing Execution System. In the ISA-95 model, manufacturing operations belong to Level 3, between ERP-level business planning and direct control of the physical process. In practice, MES-class systems focus on what is actually happening in production: job release and execution, statuses, resources, materials, actual events, quality, traceability, and feedback from the shop floor.

APS — Advanced Planning and Scheduling. Its strength is building and rebuilding a schedule while accounting for resource availability, material availability, priorities, and constraints. Siemens Opcenter Scheduling and SAP PP/DS documentation explicitly describe schedules that consider resource and material availability, finite capacity, and operation sequencing.

This does not mean every product on the market fits neatly into one box. Vendors combine planning, execution, analytics, CAM integrations, and material flow in different ways.

For a buyer, a more useful distinction is:

• if the main uncertainty is what is actually happening on the shop floor and what the real order status is, that is closer to an MES problem;
• if actual data is available but it is difficult to build a realistic work sequence under many constraints, that is closer to an APS problem;
• if neither side works, the business may need execution and planning connected together;
• if the problem sits lower down — a missing drawing, an incorrect route, material that is not ready, or a physically overloaded resource — the software category name solves nothing by itself.

Some problems are cheaper and more reliable to close with a simple rule

Imagine a laser-cutting section where the machine waits because the operator repeatedly has to ask which order should run next. There are relatively few orders, routes are simple, material is known, and one responsible person can review all work.

If the cause is that every manager considers their order urgent, a sophisticated planning algorithm will not create a management rule that does not exist.

It may first be enough to establish:

• one owner of production priority;
• clear conditions under which priority may be changed;
• a “ready-to-cut” status with unambiguous criteria;
• a board or list of ready jobs;
• a recorded reason when a ready order is not started;
• a simple release rule that does not overload the next operation.

That loop can live in the existing ERP, a simple internal tool, or even a disciplined board if the number of interdependencies is still limited.

The key test is: after introducing a simple rule, can the team make the required decision consistently without a manual “investigation” every time?

If yes, buying a large system at this stage may merely digitize disorder instead of removing it.

If the data exists but is constantly re-entered by hand, check point integration first

Another loss class appears when each system works reasonably well on its own, but the exchange between them is unreliable.

A manager creates an order in ERP. A technologist re-enters part of the data into CAM — the system used to prepare control programs. After cutting, the operator reports the status manually. The dispatcher copies it into a separate spreadsheet. The warehouse separately confirms the material. The company then spends time not on planning, but on synchronizing multiple copies of the same reality.

A full MES implementation is not automatically required here.

Sometimes the main effect comes from one specific information bridge:

• sending a production order from ERP into the preparation contour;
• automatically returning execution status;
• using one order identifier across systems;
• synchronizing material data or reservations;
• returning actual time and produced quantity;
• automatically communicating a priority change.

This is why ISA-95 gives explicit attention to information exchange between the business level and manufacturing operations: integration is an engineering problem in its own right.

If removing repeated data entry restores a current picture and the dispatcher can once again manage production, the need for a broader MES may be deferred. If the data is already sufficient but the business still lacks execution control across many operations, that is a different boundary.

MES becomes justified when the problem is the management of actual execution itself

A strong signal in favor of MES does not appear simply because there are many computers or machines on the shop floor. It appears when a manager cannot reliably answer questions about the current state of the production flow.

For example:

• the plan says a batch is at cutting, but in reality it is already waiting for bending;
• one system considers material available while it has not yet been staged at the machine;
• some operations are recorded immediately and others only at the end of the shift;
• the planner does not receive real operation completion and replans from stale status;
• actual downtime and waiting causes do not enter one shared picture;
• the same execution and status logic is needed across several work centers;
• quality or traceability requires the actual route and completed operations, not just the plan.

In these conditions, MES can become the operational layer that connects the production order with actual shop-floor events.

But there is an important boundary: MES does not create correct process engineering automatically. If the route is wrong, standard time is invented, the resource is defined incorrectly, or people do not capture key events, the system receives a bad model of reality.

It may make the error more visible and spread it faster, but it cannot turn incorrect data into correct data.

APS is needed when manual planning runs into constraint complexity, not a lack of discipline

APS makes sense when the production schedule is genuinely a problem with many interdependent constraints.

One laser with a small queue of ready work can often be dispatched with a simple rule. The situation becomes much more complex when planning must account at the same time for:

• several alternative machines with different capabilities;
• different part routes;
• limited material availability;
• resource calendars;
• operation sequence;
• dependencies between cutting, bending, welding, and other stages;
• changeovers and undesirable material switches;
• order priorities and due dates;
• sudden unavailability of one resource;
• the need to assess quickly what a new urgent order will do to the rest of the plan.

This creates a finite-capacity, constraint-aware scheduling problem. Official APS/PP/DS systems model resource and material availability, and detailed scheduling can rearrange operations while respecting constraints and sequence relationships.

That is a different level of problem from “show orders sorted by date.”

A signal in favor of APS is that the team has relatively reliable input data, but every significant change forces the dispatcher to revisit many interconnected decisions manually and they cannot quickly judge which new plan will remain feasible.

Bad input data is not scheduling complexity; it is a separate failure cause

The more sophisticated the planning system, the more it depends on whether the real production system is described accurately enough.

APS can account for resource availability, material, and technological dependencies. But somebody still has to define correctly:

• which operations a part requires;
• which resources can perform them;
• what resource calendars and downtime are real;
• which sequence is mandatory;
• which materials are required;
• where alternative routes exist;
• which durations and changeovers are close enough to reality for decision-making.

If that data is missing or not maintained, an automated schedule can look highly convincing while being impossible to execute.

The same applies to MES: if the same event means different things in different areas, a “70% status” does not become useful simply because it is stored in a central database.

So before a large implementation, verify data readiness and process rules. This step often shows that part of the problem can be removed before a new software contour is purchased.

Software does not add hours to an overloaded physical resource

There is another boundary that should be recognized before automating planning.

If a laser can produce far more parts than one overloaded downstream operation can accept, and that operation is already working within its available calendar, a planning system cannot create additional physical capacity.

It can:

• expose the conflict earlier;
• help avoid releasing excess work-in-process;
• propose a different sequence;
• use an alternative resource if one really exists;
• rebuild due dates faster after a change.

But if no alternative exists, the problem remains physical: a different work organization, additional resource, route change, outsourcing of part of the operation, or another engineering response is required.

That is why a “software first” approach is risky. The system may show very accurately that the queue will grow. That is valuable, but it is not the same as removing the reason the queue grows.

MES and APS do not have to be implemented together

Sometimes a company genuinely needs both contours.

For example, APS calculates a realistic plan across several interconnected resources, but already in the first half of the shift actual execution deviates: one batch is delayed, an operator changes the sequence, material is not staged, a machine stops.

If those actuals do not return to the planning contour, the next schedule is based on yesterday’s reality.

In that case, an MES contour can provide the current execution state, while APS can use updated data for the next resource and sequencing decision.

But the reverse is also true: if the schedule is simple and manageable, MES can be useful without a separate APS. If execution is transparent but scheduling is too complex, the business may first solve the APS-class problem itself.

The architecture should match the loss, not a fashionable “ERP + MES + APS is mandatory” diagram.

Before buying, test your real decision loop, not a demo screen

The best test of a system is not a presentation built on perfect master data.

Take a representative set of real orders and events:

• normal and urgent work;
• several typical routes;
• real resource calendars;
• material availability;
• familiar changeovers;
• at least several kinds of changes that in real life force the dispatcher to rebuild the plan.

Then test whether the system answers your actual production questions.

For MES, these may include:

• can the actual order state be seen without manually collecting information;
• are key statuses interpreted consistently;
• are actual events returned to the systems that need them;
• can technical waiting be distinguished from organizational waiting.

For APS:

• does the system create a feasible schedule on real resources;
• does it respect critical constraints;
• is it clear why an order received a particular due date;
• what happens after a priority change, resource failure, or material delay;
• can the planner work with the result rather than merely look at an optimized picture.

Define the acceptance criterion before the demo: which decision should become less manual, faster, or more accurate — and what observable signs will show that this has happened.

Without that, a system can win the presentation and still fail to change the production day.

A practical decision sequence

Reduced to a short sequence, the logic looks like this.

1. Name the loss. Not “poor planning,” but specifically: the machine waits for CAM preparation, material is not staged, actual status is unknown, priorities conflict, the schedule cannot be rebuilt quickly, or the next operation is overloaded.

2. Identify the owner of the data and the decision. Who confirms readiness? Who changes priority? Where is actual status stored? Which data is canonical?

3. Remove what does not require complex software. Duplicated entry, ambiguous statuses, missing job-release rules, chaotic urgent insertions, and unprepared master data are better fixed before automation.

4. Check what uncertainty remains. If execution is not visible, that is an MES-class problem. If execution is visible but a complex schedule cannot be built, that is an APS-class problem. If physical capacity is missing, it is not a software problem.

5. Test on your own orders. Do not ask a supplier for abstract “optimization.” Give them real routes, resources, materials, due dates, and typical disruptions.

6. Implement exactly the contour that closes the demonstrated loss. A minimum solution that works consistently is often stronger than a large system that no one has yet been able to explain in terms of the problem it is supposed to remove.

When it makes sense to discuss the contour with an engineer