AI applied to production planning: from historical data to the real order

At 7:15 on a Monday morning, the planner at a garment factory in the Vale do Ave opens the ERP and sees 23 production orders for the week. Twelve are missing raw materials. Three clash on the same sewing line. The deadline for the German client is Friday. No algorithm warned him the previous Friday — when there was still time to act.

The thesis of this article is uncomfortable: the problem is not the lack of AI. It is that most Portuguese industrial factories are trying to implement AI on top of data that was never collected with enough rigour to feed a model. Solving that first — before choosing any platform — is what separates the projects that work from those that end up in a PowerPoint presentation. The rest is architectural detail.

The problem is not a lack of data — it is a lack of real execution data

Most factories have data. They have records of orders, cycle times, line stoppages, returns, supplier history. What they do not have is a mechanism that synthesises that data into planning decisions before the shift begins — and, more importantly, they have plan data where they needed real execution data.

According to INE, in 2025 only 9.4% of small Portuguese companies (10-49 employees) used artificial intelligence technologies — and even among medium-sized ones (50-249 employees), adoption did not reach 18.2%. Portuguese manufacturing industry, mostly made up of SMEs, is still at the stage where the ERP records the past but does not project the future.

An ERP without AI is a minute book. It records what happened. AI is what turns that record into instruction for tomorrow. But only if the record is true.

The conceptual leap this article develops is this: AI applied to WIP and planning does not replace the planner. It removes the most thankless part of the job — the manual reconciliation of variables that the human brain cannot process simultaneously at industrial speed. But it demands, in return, that the input data be real execution data — not the theoretical values someone entered into the ERP in 2018 and never updated again.

What has changed to make this relevant now

Structured data in sufficient volume

For years, the argument against AI in planning was simple: "we don't have enough data". Today, any factory with two years of active ERP has a history of orders, setup times, scrap rates per reference, real supplier lead times and machine availability. That volume — even imperfect — is already enough to train capacity forecasting and conflict detection models. What is still missing, in most cases, is not quantity: it is quality. Specifically, the distinction between what the plan said and what the line actually did.

Pre-trained models accessible via API

There is no need to build a model from scratch. ML platforms such as Azure Machine Learning, AWS SageMaker or Google Vertex AI provide time-series and combinatorial optimisation models that connect to the ERP via API. The cost of infrastructure has fallen dramatically. What remains expensive is the integration and the quality of the data — not the model itself. A vendor who presents the model as the main investment is inverting the priorities.

Regulatory pressure and pressure from international clients

Brands such as Inditex, Decathlon or Mango increasingly require batch traceability and documented compliance with deadlines. The EU Strategy for Sustainable and Circular Textiles adds compliance pressure that forces production decisions to be recorded and justified. AI-assisted planning produces an auditable decision trail — something that manual planning in Excel never managed, however competent the planner was.

Regulation (EU) 2024/1689 — AI Act in force

The AI Act has been in force since August 2024, with the prohibitions applicable from February 2025 and the rules on general-purpose models from August 2025. AI systems that influence production decisions with an impact on workers may be classified as limited risk or high risk, depending on the autonomy of the system. Any implementation of AI in planning must be assessed within this framework before going into production — not after the system is already running in autonomous mode.

The real technical options: four distinct architectures

1. Demand forecasting integrated into the ERP

The most common model. The ERP analyses sales history, seasonality and the order book and generates a requirements forecast that feeds the MRP. AI here is a time-series module — ARIMA, Prophet, LSTM — that replaces the linear forecast of the classic MRP.

It works well when the product mix is stable, the history is at least 18-24 months long, and demand has an identifiable seasonal pattern. It fails when there are many new references per collection (footwear, clothing), when the client is a single international buyer with erratic behaviour, or when the order book is firm and the statistical forecast is simply redundant — because the future is already confirmed in the system.

2. Order sequencing optimisation

Given a set of confirmed orders, the AI determines the optimal production sequence, minimising setup times, resource conflicts and delays. It is the classic job-shop scheduling problem — NP-hard in theory, solvable with heuristics (genetic algorithms, simulated annealing, reinforcement learning) for horizons of 5-10 days.

This is the module with the quickest return in factories with multiple lines and long setups. A textile factory with dyeing can significantly reduce the number of colour purges per week with intelligent sequencing — without changing a single production process. The gain is pure: fewer purges, less waste of water and chemicals, fewer unplanned stoppages. Any production manager in the Vale do Ave gets the argument in 30 seconds.

3. Anomaly detection and preventive alerts

Anomaly detection models monitor IIoT data in real time — machine sensors, piece counters, process temperatures — and compare it with historical patterns. When the deviation exceeds a threshold, it generates an alert before the stoppage happens. It is not classic predictive maintenance: it is simpler and more immediate. It detects that line 3 is producing 12% below the expected rate at 9am, when the plan assumed 100% capacity. The planner receives the alert and redistributes the load before the end of the shift — still within the same day, when the decision still has value.

4. Autonomous planning with closed-loop feedback

The most advanced level. The system generates production orders, monitors execution in real time via KORA Productivity, compares with the plan, adjusts automatically and regenerates orders for the next shift. The planner validates — does not build. It requires deep integration between ERP, MES and shop-floor sensors. For most Portuguese industrial SMEs, this level is a medium-term aspiration, not a starting point. Anyone who presents it as the first phase is selling the wrong project.

Comparison of architectures: trade-offs by dimension

Decision matrix: which architecture to choose

Trade-offs that no vendor mentions in the presentation

The problem of capacity data quality

Any sequencing model assumes that the ERP has reliable capacity data: cycle time per operation, machine availability, number of qualified operators per shift. In practice, this data is often outdated or simply absent. A factory that has never recorded operation times in the ERP cannot implement AI sequencing in 8 weeks — it first needs 3-6 months of data collection via KORA Productivity or equivalent. This is the most common mistake we see in projects that start with the model and not with the data.

There is an even subtler detail that the manuals do not mention: the cycle times in the ERP were often entered by the process engineer during the factory's start-up phase, based on theoretical standard times. Then nobody updated them when the machine aged, when the operator changed, or when the reference became more complex. The AI model will learn those theoretical times as if they were real — and will generate systematically optimistic orders. The factory fails to deliver, the planner blames the AI, and the project dies. Not through any fault of the algorithm, but through a data fault that existed before the project began.

The Felgueiras footwear paradox

A footwear factory in Felgueiras with a collection of 900 references, three axes of variation (colour, size, last) and two presentation moments per year — men's footwear buyers in August, women's in February — has a demand profile that defeats any classic time-series model. There is no stable seasonality: there are peaks of samples, then silence, then an explosion of confirmed orders in windows of 3-4 weeks.

For this profile, the most useful AI is not demand forecasting. It is the sequencing of confirmed orders with capacity constraints and material batch traceability. The model reads the firm order book and optimises the sequence — it does not try to guess the future. And grouping by last family — sequencing all the references that share the same mould before changing — is the most immediate and least exploited gain in this cluster.

In footwear, forecasting demand with AI is the wrong problem. Sequencing 400 confirmed orders in 3 weeks with 12 assembly lines and 6 sole suppliers — that is the right problem.

Operational resistance: the production manager as a risk variable

The biggest implementation risk is not technical. It is the production manager who has spent 20 years sequencing orders in his head and who sees the system as a threat to his authority. If the system generates a sequence he considers wrong — even if it is mathematically optimal — and there is no documented and respected override mechanism, the project fails through silent abandonment. There is no closing meeting. The system simply stops being opened.

Always configure a suggestion mode with manual override. The system proposes, the planner validates or adjusts, and the system learns from the adjustment. Without this cycle, adoption collapses within weeks. And document each override with a reason — not to control the planner, but because those reasons are the most valuable training data the model will receive.

What works in practice: three sector patterns

Pattern 1 — Start with sequencing, not with forecasting

In factories with a firm order book above 70% of weekly capacity, demand forecasting has little marginal value — the future is already confirmed in the system. What generates immediate return is optimising the sequence of orders that already exist. A textile finishing factory in the Vale do Ave can, for example, reduce the number of colour changes per week by 30-40% with intelligent sequencing, without changing a single production process. The gain is pure: fewer purges, less waste of water and chemicals, fewer unplanned stoppages. And it is a gain the production manager can see and measure on the same day.

Pattern 2 — Integrate deviation alerts before integrating forecasting

Before implementing demand forecasting, implement real-time deviation detection. A system that alerts when the line is producing 15% below the planned rate at 10am has immediate and measurable value: the planner acts while still within the shift. This pattern is compatible with any ERP that has integration with IIoT or with production recording terminals — and it prepares the data for more complex models in the future, because it starts accumulating real execution data with timestamps and context.

Pattern 3 — Feed the model with real execution data, not plan data

The subtlest mistake, and the most frequent: training the AI model with plan data instead of real execution data. The plan says the sewing operation takes 4 minutes. The real execution, recorded in KORA Productivity, shows 5.3 minutes on average, with a standard deviation of 1.2 minutes. A model trained on the plan will generate systematically optimistic orders. A model trained on real execution will generate orders the factory can meet. This distinction — plan vs. execution — is the difference between an AI project that works and one that is abandoned after three months with the wrong conclusion that "AI doesn't work for our sector".

How to measure success after implementation

First-level metrics (operational)

• On-time delivery rate (OTD): the percentage of orders delivered on the date confirmed to the client. Establish the baseline before AI, measure monthly afterwards.
• Number of capacity conflicts detected by the system vs. detected manually: the system should detect more, earlier.
• Average weekly sequencing time by the planner: it should decrease. If it does not decrease, the system is not being used — and that is information, not technical failure.
• Manual override rate of the system's suggestions: above 60% indicates that the model is not calibrated or that the operational resistance has not been resolved.

Second-level metrics (financial and quality)

The variation in average weekly WIP is the most direct financial indicator: more efficient planning reduces work in progress, which frees up working capital. The cost of setups per week — measurable in hours of stoppage and consumption of cleaning or purging materials — is the second. The third, and the most ignored, is the scrap rate per order correlated with the sequence generated by the system: if certain sequences produce more scrap, the model needs to incorporate that constraint.

Adoption metrics (the ones projects ignore and should not)

• The percentage of planners who use the system daily without IT intervention.
• The number of support requests related to the AI module per month: this should decrease after the first 60 days.
• The production team's satisfaction with the quality of the generated orders: a direct question, asked monthly, is worth more than any KPI dashboard.

The implementation procedure: from historical data to the first real order

1. Audit the quality of the capacity data in the ERP. Check whether the work centres have real cycle times recorded, machine availability per shift and qualified operators associated. If these fields are empty or have theoretical values, start collecting real data before moving on to the model. Plan 3-6 months for this phase — not 3-6 weeks.
2. Define the planning horizon and granularity. Daily planning per shift? Weekly per line? The AI needs to know what it is optimising. Horizons that are too long with fine granularity generate unstable models. Start with a 5-working-day horizon and half-shift granularity.
3. Extract and clean the real execution history. A minimum of 12 months of completed order data with real start and end times per operation. Eliminate outliers with a known cause — breakdown stoppages, mass absences, Christmas weeks. This step takes longer than expected: plan for 4-6 weeks, not 4-6 days.
4. Train the model in a test environment with historical data. Run the model over the last 3 months of history and compare the orders the model would have generated with the orders that were actually executed. Measure the deviation. If the average deviation is above 20%, the model needs more data or parameter adjustment before going into production.
5. Launch in suggestion mode with mandatory override for 60 days. The system generates the sequence, the planner validates or adjusts, and each adjustment is recorded with a reason. This period is one of mutual learning: the model learns from the overrides, and the planner learns to trust the model where it is consistently correct.
6. Evaluate and decide on partial autonomy. After 60 days, analyse the override rate. If it is below 25% and the overrides concentrate on specific situations — priority client, one-off breakdown, unforeseen absence — configure exception rules and pass those situations to manual management. The rest can run in autonomous mode with daily validation.

Integration with the ERP and regulatory compliance

The ERP as the source of truth — and its limits

The MULTI ERP and QAD Adaptive ERP are the platforms where order, capacity and material data reside. Planning AI does not replace the ERP — it consumes its data and returns optimised orders that the ERP executes. The integration must be bidirectional: the model reads from the ERP, writes to the ERP, and the ERP records the execution that feeds the model in the next cycle.

Any integration that goes through manual export to Excel and manual import back is an antipattern. It does not scale, it is not auditable, and it fails precisely when the pressure is greatest — at the end of the month, when the delivery deadline tightens and the planner no longer has time to feed files.

SAF-T and decision traceability

Ordinance 195/2020 requires the monthly submission of the invoicing SAF-T. There is a less obvious consequence for AI-assisted planning: the automatically generated production orders have to be traceable back to the decision that originated them. If the tax authority (AT) or an auditor questions why an order was created with a particular date, the answer "the system generated it" is not enough. The system has to record the input parameters — order book, available capacity, material constraints — that justify each order. Most market solutions do not produce this decision trail by default. Check before signing the contract, not after the system is in production. Also read SAF-T in industrial production: extraction errors the ERP does not warn you about to understand where production data fails before reaching the AT.

AI Act: risk classification for planning systems

An AI system that generates production orders and influences operators' workload may be classified as limited risk under Regulation (EU) 2024/1689. It is not high risk — but it requires transparency: users have to know they are interacting with an AI system. Configure the interface so that the origin of the suggestion is always visible. This is not an aesthetic requirement — it is a regulatory obligation that has been in force since February 2025.

The AI Act does not prohibit AI in industrial planning. It requires those who use it to know that they are using it. It seems obvious. It is not — especially when the system is integrated into an ERP the operator has used for ten years without thinking about it.

Sector context: where planning AI has the greatest impact in Portugal

Textiles and clothing — Vale do Ave and surroundings

In the textile sector, production planning is complicated by three simultaneous factors: extensive subcontracting (part of the production leaves the factory and comes back as a semi-finished product), variability in raw material quality (yarn lots with variation in count or colour) and deadline pressure from international brands that do not accept delays. Sequencing AI with subcontracting constraints — which includes the subcontractors' real lead times in the model, not the nominal lead times in the contract — is the module with the greatest return in this cluster.

In the clothing sector, the critical variable is labour: operators with different levels of qualification per operation, variable absenteeism, and high turnover in certain roles. A model that does not include the real availability of qualified operators will generate orders the shop floor cannot execute. Integrating data from pplPortal — attendance, skills per operation — into the planning model is a non-obvious but decisive configuration. It is also the configuration that most frequently falls outside the project's initial scope for being "too complex", and which then explains 40% of execution deviations.

Footwear — Felgueiras and Guimarães

In the footwear sector, the central problem is SKU complexity. A collection

Frequently asked questions

What does AI actually solve in production planning?

AI does not replace the planner, but it removes the manual reconciliation of variables that the human brain cannot process simultaneously at industrial speed. It transforms historical data into instructions for the next day, allowing the planner to focus on strategic decisions instead of repetitive calculations.

Why do many AI projects in Portuguese factories fail?

Because they try to implement AI on top of data that was never collected with enough rigour. The problem is not a lack of data — it is a lack of real execution data. Most factories have theoretical records in the ERP, but no mechanisms that synthesise that data into planning decisions before the shift begins.

What is the difference between plan data and real execution data?

Plan data is theoretical values entered into the ERP and rarely updated — for example, cycle times from 2018 that no longer reflect reality. Real execution data is what the line actually did: effective times, stoppages, scrap, machine availability. AI only works well with real execution data.

Which AI module has the quickest return in factories?

Order sequencing optimisation. It determines the optimal production sequence, minimising setup times and resource conflicts. In textile factories with dyeing, for example, it significantly reduces the number of colour purges per week — less waste of water, chemicals and unplanned stoppages.

Is it necessary to build an AI model from scratch?

No. Platforms such as Azure Machine Learning, AWS SageMaker or Google Vertex AI provide pre-trained time-series and optimisation models that connect to the ERP via API. The cost of infrastructure has fallen dramatically. The main investment lies in the integration and quality of the data, not in the model.

How does the Portuguese AI Act affect the implementation of AI in planning?

Regulation (EU) 2024/1689 has been in force since August 2024. AI systems that influence production decisions with an impact on workers may be classified as limited risk or high risk. Any implementation must be assessed within this framework before going into production, not after it is in autonomous mode.

Can a traditional ERP without AI do effective planning?

An ERP without AI is a minute book — it records what happened. It does not project the future. AI transforms that record into instruction for tomorrow. Without AI, planning remains dependent on linear forecasts and the manual reconciliation of variables that the human brain cannot process simultaneously.

Sources

• Instituto Nacional de Estatística (INE) — Statistics on the adoption of artificial intelligence technologies in Portuguese companies (2025)
• Regulation (EU) 2024/1689 — AI Act (Artificial Intelligence Act), in force since August 2024
• European Commission — EU Strategy for Sustainable and Circular Textiles
• ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system
• ENISA (European Union Agency for Cybersecurity) — Guidelines on AI Cybersecurity and Safety