AI-Powered Production Planning: When APS Systems Hit Their Limits

Walk into the planning office of a typical German mid-sized manufacturer on a Monday morning and you will see the same scene. A senior planner, 18 browser tabs, a wall-sized Excel sheet, three phone calls on hold, and a printed SAP PP/DS plan that was already obsolete by 09:15. The APS ran the nightly batch. A supplier is three days late. A machine is down. A customer wants their order pulled forward. The plan has to be rebuilt, manually, in the next hour.

This is the gap no APS vendor likes to talk about. SAP PP, APO, IBP, Asprova, DELMIA Ortems, wayRTS, Inform Felios - they all solve the static planning problem beautifully. What they cannot do is react to reality at the speed reality moves. 43 percent of German machinery companies now use AI or machine learning in some form¹⁵, but almost none of them use it where the pain actually is: the daily scheduling grind. Meanwhile SAP APO mainstream maintenance ends on 31 December 2027⁷, the IBP migration path has real functional gaps⁵, and Gartner forecasts that supply chain management software spending on agentic AI will hit 53 billion US dollars by 2030³.

This guide is for the production manager, COO, IT lead, or supply chain director at a German mid-sized manufacturer who already has an APS and does not want to rip it out. It covers exactly where classical APS breaks, what an AI planning layer actually does, how it connects to SAP and non-SAP stacks, and how to pilot it in 90 days with the planner still in charge.

Where Classical APS Falls Short

APS systems were designed in the 1990s and 2000s for a world of stable demand, long planning horizons, and batch re-planning. The world changed. Most APS did not. Here is where the cracks show up in mid-sized German plants.

• Batch re-planning cycles are too slow - Typical APS runs plan once or twice a day in a nightly or lunch-break batch. Between runs, the shop floor relies on the planner, a spreadsheet, and tribal knowledge. When a tool breaks at 11:00 and the next run is at 22:00, the entire production is ad-hoc for 11 hours.
• Multi-constraint optimisation is rigid - Most APS solvers handle capacity and material constraints well, but they struggle when you add energy peaks, operator qualifications, tool life, and quality tolerances all at once. The planner ends up overriding the solver with manual heuristics that nobody documents.
• What-if analysis is painful - Running a scenario in SAP APO or IBP typically means cloning a planning version, re-running the heuristic, and comparing reports. That takes hours. The planner does it once, not ten times. Real scenario discipline rarely happens.
• Planner heuristics are not codified - Every plant has three to five senior planners who know which orders always run on machine 4, why customer X never goes after customer Y, and which changeover sequences are painless. When those planners retire, the knowledge walks out the door. APS does not capture it.
• Disruption response is manual - A supplier delay, a customer pull-in, a tool breakage - the APS does not know it happened until someone updates a transaction. The planner finds out from email, phone, or a shop-floor walk, then manually reshuffles the plan.
• Integration with MES and shop-floor reality is weak - The APS plan assumes everything runs to standard cycle times. The MES knows about actual speeds, actual downtime, actual yields. The two worlds often do not talk, so the APS plan drifts from reality within hours.

This creates the classical Mittelstand situation: a seven-figure APS investment that the planner still has to supplement with Excel every single day. The answer is not a better APS. The answer is a reasoning layer above it.

What an AI Planning Layer Actually Does

The term “AI planning” is used for too many different things. Let us be precise. An AI planning layer is a software tier that sits between your APS and your planners. It reads data from SAP, MES, and connected sources, runs reasoning and optimisation externally, and writes recommendations back as proposed plans, scenario comparisons, or planner alerts.

It is not a replacement for your APS. It is not a chatbot. It is not an RPA script. It is a dedicated reasoning engine that takes what the APS already does and adds three capabilities the APS never had: continuous re-planning, rich scenario analysis, and contextual reasoning.

The three core capabilities

What the layer actually looks like in production

• Monday 07:30 - The AI layer pulls the overnight SAP PP/DS plan, open POs from purchasing, MES status from the last shift, and this morning’s email from the main steel supplier announcing a two-day delay.
• Monday 07:45 - The layer runs five sequenced options: keep the original plan, pull in customer B, swap to alternative material, split batch, delay shipment. Each option is ranked by on-time delivery, changeover cost, and OEE impact.
• Monday 08:00 - The planner opens the dashboard, sees the five ranked options, and accepts option 3. Accept triggers a write-back to SAP as a proposed planning run.
• Monday 08:05 - The planner converts the proposal to a firmed plan in SAP. The shop floor never notices anything was wrong. The supplier delay gets absorbed.
• Over weeks and months - The layer learns that this planner always prefers lower changeover cost over marginal on-time improvements. Future rankings adjust accordingly.

The AI layer approach is less ambitious and more pragmatic. It does not promise to fix everything. It promises to fix the daily reality the planner lives in, without touching the systems of record. That is why it works in the Mittelstand, where APS replacement programmes tend to stall.

6 Use Cases That Deliver ROI

Not every planning problem is worth automating. Six use cases consistently deliver measurable ROI in the Mittelstand. They are ordered by typical payback speed.

1. Sequence Optimisation Across Machines and Campaigns

The daily re-sequencing problem - which order runs first, which sequence minimises changeovers, which combination hits on-time delivery - is where planners spend most of their time. The AI layer solves it continuously.

• Multi-objective sequencing - On-time delivery, total changeover time, WIP cost, and energy peak are weighted simultaneously
• Learns planner preferences - The planner’s accept/reject history teaches the layer which trade-offs matter
• Handles thousands of orders - Classical APS heuristics degrade with scale; optimisation layers built for AI scale linearly
• Typical result - 15 to 25 percent shorter lead times and 5 to 10 percentage points higher OEE within 12 months¹⁸
• Real example - One automotive parts manufacturer implemented an AI-driven scheduling system with real-time shop-floor data and achieved 25 percent more on-time deliveries¹⁸

2. Changeover and Setup Time Reduction

Changeovers are where small optimisations compound. In discrete and batch manufacturing, the difference between a well-sequenced day and a badly-sequenced day is often 20 to 30 percent of effective machine time.

• Changeover matrix learning - The layer ingests historical setup times and builds a data-driven matrix that is always more accurate than the one in SAP master data
• SMED-aware sequencing - Product families, tool families, and colour-lot sequences are grouped automatically
• Tool availability integration - Tool wear and tool location constrain sequencing to avoid hidden setup time
• Typical result - 10 to 20 percent reduction in total setup time, directly flowing to OEE
• Why APS misses this - Classical APS uses static changeover matrices that get set up once and never updated

3. What-If Scenario Planning

Every mid-sized plant faces a constant stream of what-if questions. What happens if we take the rush order? What happens if the supplier is late? What happens if we pull in customer B? Classical APS can answer these - slowly. An AI planning layer answers ten in parallel, in minutes.

• Supplier disruption - What if raw material arrives two days late? The layer runs the plan with the constraint and shows the knock-on effect
• Capacity change - What happens if we add an evening shift on machine 3? Shows the throughput, cost, and labour impact
• Demand spike - What if customer X orders 40 percent more? Shows which other customers get delayed and by how much
• New product introduction - What is the impact of ramping new SKU Y over the next six weeks? Shows the trade-off against current production
• Typical result - Planners move from 1 scenario per decision to 5 to 10, with commercial decisions backed by numbers instead of gut

4. Bottleneck Detection and Capacity Forecasting

Bottlenecks are obvious in retrospect. The value is seeing them early. An AI planning layer continuously looks at the plan, the order book, and capacity forecasts, and flags where the bottleneck will appear two, four, or eight weeks out.

• Rolling bottleneck projection - The layer projects capacity utilisation week by week across every work centre
• Hidden constraint detection - Tool availability, skilled operator availability, and quality-inspection capacity are flagged alongside machine capacity
• Proactive recommendations - The layer suggests which orders to pull in, which to delay, or which products to offload to a subcontractor
• Typical result - 10 to 20 percentage points higher on-time delivery, because the bottleneck is addressed before it becomes a crisis
• Real example - A Fortune 500 manufacturer reduced unplanned downtime by 45 percent through AI-driven predictive capacity management¹⁹

5. Disruption Response (Supplier Delay, Machine Stoppage)

Disruptions are the category where APS is weakest and AI planning is strongest. The APS knows about a disruption only after someone updates a transaction. The AI layer can ingest unstructured sources - supplier emails, MES alerts, logistics updates - and react in minutes, not hours.

• Supplier email ingestion - Supplier delay notifications are parsed automatically and matched to open POs
• MES event streaming - Machine breakdown events trigger immediate re-sequencing proposals
• Alternative sourcing suggestions - The layer proposes substitute materials or suppliers where master data allows
• Express freight trade-off - Cost of express freight versus cost of late delivery is quantified automatically
• Typical result - Response time from disruption to adjusted plan drops from 4 to 8 hours to 20 to 40 minutes

6. Customer Prioritisation and Order Reshuffling

Customer A is a strategic account with a 60-day forecast. Customer B is a one-off order that pays a premium. Customer C is in penalty territory if we are late. Every day, planners reshuffle to balance these. The AI layer makes the trade-offs explicit and documented.

• Customer tier logic - Strategic, preferred, and transactional tiers are encoded with different slack tolerances
• Penalty-aware sequencing - Late-delivery penalties become a quantified constraint, not a mental note
• Margin-aware trade-offs - Orders with higher margin get sequenced preference when capacity is tight
• Commercial and operations alignment - Sales sees the same trade-off view the planner sees - arguments about priority end
• Typical result - 5 to 10 percentage points higher strategic-customer on-time delivery without harming overall plant performance

SAP and Non-SAP Architecture

The architecture question is the one that blocks most AI planning projects in the Mittelstand. IT wants to know exactly where the layer sits, what it reads, what it writes, and how it is secured. Here is the pattern that works.

SAP PP, APO, and IBP: the connection pattern

The AI layer connects to SAP through standard interfaces - no middleware, no custom ABAP beyond what you already have. The specifics differ by SAP stack.

• SAP PP on S/4HANA - Read via OData APIs, CDS views, or the Public Cloud APIs. Planned orders, production orders, BOMs, routings, and work centres are all exposed. Write-back is via standard BAPIs or the Production Planning API for scheduling moves.
• SAP APO (PP/DS and SNP) - Read from the liveCache via standard BAPIs or OData. Planning versions and optimiser output are accessible. Write-back proposes changes in a dedicated planning version; the planner promotes them. Note: SAP APO mainstream maintenance ends 31 December 2027⁷, so AI layer investment should be portable.
• SAP IBP - Read and write via the IBP REST APIs for Supply Planning, Response Planning, and Demand Planning. IBP’s native AI/ML is limited and often requires a data scientist to set up⁵. An external AI layer closes that gap without waiting for SAP to build it.
• SAP PP/DS in S/4HANA - The successor to APO PP/DS, with APIs that are more accessible than legacy APO. The AI layer reads PP/DS optimiser output and proposes adjustments via the S/4HANA APIs.
• Security model - The AI layer uses a dedicated service user with read access to planning data. Write-back uses a separate user with authorisation limited to specific planning versions and order types. Every action is logged in SAP’s standard audit trail.

Non-SAP APS: Asprova, DELMIA Ortems, wayRTS, Inform Felios

A large share of Mittelstand manufacturers run non-SAP APS, usually alongside SAP ERP or an industry-specific ERP. The integration pattern is the same - read data, run optimisation, write recommendations.

• Asprova - Japanese APS used at over 2900 manufacturing sites globally. Exposes a COM interface and Excel-based data import/export that the AI layer can read and write through. Strong in discrete manufacturing with complex routings.
• DELMIA Ortems - Dassault Systemes APS with finite capacity scheduling and constraint management. Integrates through the 3DEXPERIENCE platform or standard database access. Widely used in automotive, aerospace, and industrial equipment.
• wayRTS - German APS popular in mid-sized manufacturing. Standard relational database access makes integration straightforward. The AI layer reads the plan, runs optimisation, and proposes updates via wayRTS’s scripting interface.
• Inform Felios - German-developed AI-based optimisation software for production planning with a strong Mittelstand user base. Already AI-enabled at its core, but even Felios installations benefit from a layer that handles continuous re-planning and scenario analysis¹⁵.
• Blue Yonder - Named a Leader in the 2026 Gartner Magic Quadrant for Supply Chain Planning Solutions: Discrete Industries⁴. Blue Yonder is investing heavily in agentic AI and autonomous planning; the AI layer adds organisation-specific logic on top of the platform.

The end-to-end data flow

1. Source systems - SAP, APS, MES, supplier portal, email, IoT sensor streams push data to a staging layer
2. Data layer - Raw data is cleaned, joined with master data, and exposed to the AI layer through a semantic model
3. AI layer - Optimisation, scenario analysis, and reasoning run here. Outputs are ranked recommendations with trade-off metrics
4. Planner interface - Recommendations appear in a side-by-side view alongside the current plan. Planner accepts, adjusts, or rejects
5. Write-back - Accepted recommendations are written to SAP or APS as proposed planning versions the planner confirms
6. Audit and learning - Every action is logged. Accept/reject decisions feed back into the learning loop for the next run

The 90-Day Pilot Playbook

The biggest mistake in AI planning projects is starting with write-back. Start with read-only. The planner compares AI recommendations against their own plans for a few weeks. If the value is visible, you move to write-back. If not, you walk away with minimal sunk cost.

Phase 1: Read-Only Digital Twin (Weeks 1-4)

1. Week 1: Process and data access - Interview two to three senior planners. Document how they actually plan, including the workarounds. Identify the exact data needed from SAP or APS. Get read access through standard service users.
2. Week 2: Connection and data model - Build the read connection to your APS. Pull planned orders, routings, BOMs, open POs, and MES status into a staging area. Validate data quality against what the planners see on screen.
3. Week 3: First optimisation model - Build the first version of the sequence optimiser and scenario engine. Run it on last week’s data. Compare the AI plan against the plan that was actually run. Identify obvious wins and obvious misses.
4. Week 4: Side-by-side dashboard - Build the planner view that shows current plan versus AI recommendation with trade-off metrics. Hand it to the senior planner. No write-back yet. Pure observation.

Phase 2: Shadow Running (Weeks 5-10)

5. Week 5-6: Daily comparison - Every day, the planner reviews the AI recommendation before their normal planning run. They accept or reject each recommendation as an opinion, but still run their own plan. The accept/reject data trains the layer.
6. Week 7-8: What-if scenarios - Enable scenario analysis. Planners run 5 to 10 scenarios per strategic decision. Commercial and operations start using the same scenario view for joint decisions.
7. Week 9: Disruption response - Add supplier email parsing and MES event streaming. The layer now generates proposals in response to disruptions, not just at planning cycle time.
8. Week 10: Go/no-go review - Pull the numbers. What percentage of AI recommendations would the planner have accepted? What measurable KPI change would it have made? Decide on write-back phase.

Phase 3: Write-Back and Expand (Weeks 11-14)

11. Week 11: First write-back - AI proposals write to a dedicated planning version in SAP or APS. The planner reviews, adjusts, and promotes to firmed plan. Nothing bypasses the planner.
12. Week 12: Full dual-run - Every planning cycle produces both the classical APS plan and the AI-proposed plan. Planner picks which to execute. KPIs track both.
13. Week 13: Scale to second use case - If sequence optimisation is live, add changeover reduction or bottleneck detection. The data and integration infrastructure are already in place.
14. Week 14: Steady state and measurement - KPIs are tracked monthly against baseline. Planner feedback drives ongoing refinement. Plan for next plant or next use case.

Human-in-the-Loop Design

The single most common objection to AI planning is “we cannot let a machine run the plant.” Correct. And no serious AI planning layer does. Human-in-the-loop is not a concession to risk - it is the entire design pattern.

How the planner stays in control

• Every recommendation is a proposal - The AI layer never writes directly to the live plan. It writes to a proposed planning version that the planner explicitly promotes
• Trade-off metrics are always visible - Every recommendation shows on-time delivery, changeover cost, WIP impact, and OEE projection. The planner judges the trade-offs
• Reasoning is explained - The layer explains why it proposes a sequence (“pulls customer B forward to use the same tool family as customer A, saving 90 minutes of changeover”)
• The planner can adjust and re-run - “Lock this order sequence, re-optimise the rest” is a standard planner operation, not a special feature
• Accept/reject is training signal - The layer learns planner preferences over weeks and months. Rejections are not failures - they are how the system gets sharper
• All actions are logged - Every proposal, every acceptance, every adjustment is in the audit trail. Essential for EU AI Act Article 14 compliance²³

Levels of autonomy that work in the Mittelstand

Most Mittelstand manufacturers settle at Level 1 with pockets of Level 2 for well-defined routines. Level 3 is rarely the right answer - not because the technology cannot handle it, but because the organisation does not want it and does not need it. Level 1 is already where most of the ROI lives.

Works Council, GDPR, and EU AI Act

Production planning AI in Germany runs into three regulatory frameworks: the works council (Betriebsrat), GDPR, and the EU AI Act. The good news is that production planning is on the cleaner side of all three - but there are specific things you have to get right.

Works council alignment

• Production planning itself is not co-determined - The classical scheduling of machines and orders is operational, not a personnel matter
• Shift planning influence triggers co-determination - If the AI layer recommends shift patterns or overtime, the works council must be involved under BetrVG Section 87
• Performance monitoring triggers co-determination - If the layer tracks individual planner performance (accept rates, cycle times), involve the works council early
• The BV (Betriebsvereinbarung) - Most Mittelstand manufacturers already have a framework works agreement that covers digital tools. An AI planning layer usually fits within it with a minor amendment
• Transparency is the winning posture - Show the works council exactly what the layer does, what data it uses, and what decisions it influences. Adversarial positioning fails; collaborative positioning succeeds

GDPR considerations

• Production planning data is usually not personal - Orders, routings, BOMs, capacity, and changeovers are operational data, not personal data
• Personal data edge cases - Operator qualifications, shift schedules, or performance metrics are personal data and need lawful basis, typically legitimate interest or Article 88 collective agreement
• Service user access - The AI layer uses service users, not personal user credentials. Clean separation simplifies the data protection impact assessment
• Data residency - For German manufacturers, prefer EU data residency for the AI layer. The EU-based sovereign cloud stack is maturing fast
• Retention - Log retention for AI decisions should match the existing SAP audit retention - typically 10 years for tax-relevant data, less for purely operational

EU AI Act classification

• Production planning falls into minimal risk - It is not in any of the high-risk annexes of the EU AI Act
• Article 4 AI literacy - Everyone who uses the system must be trained on what it does and what it does not do²⁵. Small, repeatable training programme, not a compliance burden
• Article 14 human oversight - Human-in-the-loop design satisfies this by construction²³. Every proposal is reviewed before execution
• Full applicability 2 August 2026 - AI literacy and oversight are already in force. High-risk rules (not applicable here) take full effect on that date²⁴
• Documentation - Keep a short document describing the system, its purpose, its data, and its oversight mechanism. Five pages is enough

How Superkind Fits

Superkind builds custom AI layers for production planning and operations. The approach is the same one that works for the Mittelstand in every other domain: read-only first, planner-led, use-case scoped, no rip-and-replace.

• Connects to your existing APS - SAP PP, APO, IBP, Asprova, DELMIA, wayRTS, Felios, Blue Yonder, or custom. No migration required. The layer reads what is there.
• Process-first discovery - We talk to the planners who actually plan, map how re-planning happens today, and identify where AI changes the economics before writing a line of code
• Read-only digital twin first - Weeks 1 to 4 produce a shadow view of AI recommendations next to your current plan. Proven value before any write-back
• Planner-led design - Every recommendation is a proposal. Planners keep authority. Level 1 human-in-the-loop is the default. Level 2 only where the planner asks for it
• Outcome-based pricing - We price per use case with measurable KPIs defined up front. No seat licences. No multi-year lock-in
• Multi-plant scale pattern - First plant in 10 to 14 weeks. Second plant is usually 40 to 60 percent of that effort. Data and architecture compound
• Survives APS migration - The layer is portable across SAP APO, IBP, and S/4HANA PP/DS. If you move from APO to IBP in 2027, the layer moves with you
• EU data residency by default - The AI layer can run in EU regions with European LLM providers where sovereignty matters. DSGVO, EU AI Act, and works council engagement are part of the standard scope

Decision Framework: Is Your Plant Ready?

Not every mid-sized plant needs an AI planning layer right now. Here is a framework to decide.

Frequently Asked Questions

Henri Jung

Co-founder of Superkind, where he helps SMEs and enterprises deploy custom AI agents that actually fit how their teams work. Henri is passionate about closing the gap between what AI can do and the value it creates in real companies. Before Superkind, he spent years working with mid-sized manufacturers on digital transformation and saw first-hand how many APS projects stall in the gap between the system and the planner. He believes the Mittelstand has everything it needs to lead in AI-powered operations - it just needs the right layer on top of what it already has.