SAPUse Case

SAP PP/MRP + AI agents

AI Agents for SAP Production Planning, MRP, and Exception Triage

Short answer

A planner running SAP MRP typically opens MD04 to a wall of exception messages with no ranking beyond the default sort order. An AI agent grounded on the same MRP data can group and prioritize those exceptions, explain a predictive MRP shortage in plain language, and draft the planned-order or purchase-requisition action for the planner to approve, without ever changing an order on its own.

ERP
SAP S/4HANA, SAP ECC 6.0
Industries
Manufacturing, Automotive, Electronics, Industrial Equipment
Written for
Supply Chain Director

Every SAP shop running MRP has the same daily ritual: a planner opens MD04, scrolls a stock/requirements list full of exception messages, reschedule-in, reschedule-out, missing parts, excess coverage, and decides in their head which ones actually matter today. That triage is real expertise, built up over years of knowing which exception codes are noise for this plant and which ones predict a line-down event next week. It does not scale past the handful of senior planners who have it.

Predictive MRP was supposed to help by simulating shortages before they become firm exceptions, but a simulative shortage message is not self-explanatory. A planner still has to dig into why the simulation flagged it, which consumes the same demand or supply element, before deciding whether to act early or wait. Most planners we talk to say pMRP tells them something is wrong without telling them why, which limits how much they trust it.

As a Supply Chain Director, the cost of this shows up in two places: planners spending their time on manual triage instead of the judgment calls that actually need a human, and exceptions that get missed because there were simply too many to work through before the next MRP run overwrote the list. Neither problem is solved by running MRP more often or adding more exception messages.

This page describes a narrower, more concrete fix: an AI agent that reads the same MD04/MD05 exception data, PLAF planned orders, and pMRP simulative results your planners already look at, ranks and explains them in plain language, and drafts the specific action, convert this planned order, expedite this PO, adjust this safety stock, for a planner to approve. It does not run MRP differently or replace the planner's judgment. It removes the manual reading and typing between the exception appearing and the decision getting made.

What usually gets in the way

The problems we hear most from supply chain director teams running SAP S/4HANA.

MD04 exception volume outpaces planner capacity

A mid-size plant can generate hundreds of exception messages across a single MRP run, and the standard MD04 view offers no ranking beyond material and plant, so planners default to working the list top to bottom or relying on memory for what usually matters.

Exception codes require tribal knowledge to interpret

Knowing that exception code 05 (reschedule to earlier date) matters more for a bottleneck work center than for a low-runner part is not written down anywhere in SAP. It lives in the head of whoever has been planning that material family the longest.

Planned order conversion and firming is manual and repetitive

Reviewing a batch of PLAF planned orders, checking capacity and material availability, and converting the right ones to production orders is a mechanical task planners do by hand every day, one order at a time.

Predictive MRP output is hard to trust without an explanation

A simulative shortage in the Monitor Predictive MRP app tells you a demand element is at risk, not why, so planners often ignore pMRP signals until they become firm exceptions anyway, which defeats the point of running it predictively.

Supplier expedite requests are written from scratch every time

When a purchase requisition or PO is at risk of missing a required date, someone has to look up the vendor, the PO history, and the required date, then write an expedite email, a task that adds no judgment beyond what SAP already knows.

Where AI earns its place in SAP S/4HANA

Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.

MD04 exception triage and prioritization

Each morning, the agent reads the current MD04/MD05 exception messages for a planner's material scope, groups them by likely business impact (customer order at risk, bottleneck work center, low-runner part), and presents a ranked list with a one-line rationale for each.

Touches: MD04 stock/requirements list, MD05 MRP list, exception message codes, MRP controller assignment

Outcome: Cuts the time a planner spends scanning the raw exception list before deciding what to work on first, without changing which exceptions exist.

Planned order review and conversion drafting

The agent reviews the current batch of planned orders against capacity and material availability, and drafts a recommended list of which to convert to production orders now versus hold, for the planner's sign-off.

Touches: Planned orders (table PLAF), capacity leveling data (CM01/CM07), material availability

Outcome: Turns a one-by-one manual review into a single batch decision the planner confirms, typically in a fraction of the original time.

Predictive MRP shortage explanation

When the Monitor Predictive MRP app flags a simulative shortage, the agent explains in plain language which demand and supply elements are driving it and how confident that projection is given recent consumption patterns.

Touches: Predictive MRP simulative materials, demand and supply elements, consumption history

Outcome: Gives planners a reason to act on a pMRP signal before it becomes a firm exception, closing the gap between prediction and trust.

Supplier expedite drafting

For purchase requisitions or orders at risk of missing a required date, the agent drafts an expedite email referencing the specific PO, line, quantity, and required date, for the buyer to send.

Touches: Purchase requisitions (ME51N), purchase orders, vendor master, required delivery dates

Outcome: Removes the manual lookup-and-write step from an expedite request that a buyer would otherwise start from a blank email.

Capacity overload summary for the production meeting

Before the daily or weekly production meeting, the agent summarizes which work centers are overloaded, by how much, and which orders are contributing, in plain language rather than a raw capacity leveling screen.

Touches: Capacity planning table (CM01/CM07), work center master, order operations

Outcome: Replaces a manually prepared capacity slide with a grounded summary the production planner edits rather than builds from the raw data.

BOM and routing exception flagging before the MRP run

The agent flags materials where a recent BOM or routing change looks inconsistent, a missing component, an unusually long lead time, before the next MRP run propagates the issue into dozens of downstream shortages.

Touches: Material BOM (CS03), routing (CA03), recent engineering change records

Outcome: Catches a class of shortages at the source rather than after MRP has already generated exceptions across every affected order.

Safety stock and reorder point review

Using recent consumption history against current MRP1-MRP4 settings, the agent suggests specific safety stock or reorder point adjustments with the reasoning shown, for the planner to approve and apply through the normal material master change.

Touches: Material master MRP views (MRP1-MRP4), consumption history, MRP controller

Outcome: Turns an occasional, ad hoc safety stock review into a routine, data-backed suggestion the planner acts on or dismisses.

Reference architecture

The agent sits alongside SAP, reading MRP, capacity, and material master data through standard connectors, and never runs MRP itself or changes a planned order without a planner's explicit action. Five layers keep that boundary clear and auditable.

  1. 1

    ERP connectors

    Read access to MD04/MD05 exception data, PLAF planned orders, and capacity leveling tables via OData services and CDS views on S/4HANA, or RFC/BAPI reads on ECC 6.0, through a scoped service user.

  2. 2

    Data and semantic layer

    Exception codes, capacity terms, and material groupings are mapped to the language your planners actually use, so a question about which orders are at risk this week resolves to the right combination of exception codes and dates.

  3. 3

    Model serving

    An open-weight model served with vLLM or Ollama on your own GPUs or in a private cloud tenant, sized to the query volume of a planning team rather than an enterprise-wide deployment.

  4. 4

    Retrieval and agents

    Multi-step agent workflows for triage, conversion drafting, and expedite drafting, each producing a proposed action and its supporting data rather than executing anything directly.

  5. 5

    Governance and audit

    Every recommendation is logged with the data it was based on. Converting a planned order, changing a safety stock value, or sending an expedite email always requires the planner or buyer to take the action themselves in SAP.

Integration notes for your ERP team

  • MD04/MD05 exception data and PLAF planned orders are read via CDS views or RFC/BAPI calls, refreshed on a schedule that matches your MRP run cadence rather than polling continuously.
  • Predictive MRP simulative data is read from the same tables the Monitor Predictive MRP Fiori app uses, so the agent's explanation matches what a planner sees in that app.
  • Capacity leveling reads from CM01/CM07-equivalent tables; work center master data is cached and refreshed less frequently since it changes rarely.
  • Converting a planned order, changing a safety stock value, or updating an MRP controller assignment all require the planner to execute the change in SAP directly; the agent never calls a write BAPI on its own.
  • The same architecture supports ECC 6.0 via RFC/BAPI where S/4HANA-specific OData services are not available.
  • Multi-plant deployments scope the connector per plant and MRP area, so a single instance can serve several plants without mixing their planning data.
  • Custom Z-tables used for plant-specific exception logic can be incorporated into the semantic layer during discovery, they are common in mature SAP PP implementations and worth surfacing early.

Deployment options

Air-gapped on-prem

Plants supplying defense or regulated programs where MRP data itself is sensitive, or any site with a strict no-outbound-internet policy for production systems.

Model and connector run entirely inside the plant network, with the same no-external-call guarantee as the rest of this surface.

Private or sovereign cloud

Multi-plant operations without GPU capacity at every site, or where centralizing the AI layer for several SAP instances is more practical than deploying per site.

A dedicated tenant serving multiple plants' MRP data, still isolated from public model APIs, with per-plant authorization scoping preserved.

Hybrid

Organizations piloting at one plant before deciding on a standard deployment pattern.

Start on-prem at a single site to prove the connector and exception taxonomy, then move to a shared private cloud instance once the pattern is validated across plants.

Compliance and data control

How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.

Data residency and sovereignty

You choose where the model and data live, on-prem or a private cloud region you control, so MRP and cost data never crosses a border you have not approved, relevant for multinational operations with regional data rules.

SAP authorization concept

The AI layer's service account is scoped the same way a planner's SAP role would be, plant by plant and MRP controller by MRP controller, so it never surfaces data a given user could not already see in MD04.

ITAR / EAR (where the plant supplies defense programs)

For plants with export-controlled work mixed into the same SAP instance, the connector can exclude ITAR-flagged materials and orders from the AI layer's scope entirely, or the whole deployment can run air-gapped as described above.

Change and audit logging

Because no action is taken automatically, the existing SAP change document trail for planned order conversions, safety stock changes, and PO updates remains the system of record; the AI layer adds a log of what it recommended and why, alongside it.

How an engagement runs

Phase 1 . 2-3 weeks

Discovery

  • -Exception taxonomy workshop with senior planners to capture the judgment that currently lives in their heads
  • -SAP PP/MRP data and authorization review for the target plant or MRP area
  • -Prioritized use case list, typically triage first, conversion drafting and expedite drafting next
  • -Deployment sizing against available GPU capacity

Phase 2 . 6-8 weeks

Pilot

  • -Exception triage and ranking live for one MRP area or planner group
  • -Accuracy validation against the same planners' own judgment on a sample of historical exceptions
  • -Predictive MRP explanation feature tested against a set of known past shortages
  • -Go/no-go review with measured time saved per planner per week

Phase 3 . 8-10 weeks

Production

  • -Rollout across the full planning team for the pilot plant
  • -Conversion drafting and expedite drafting added with planner approval workflows
  • -Integration into the existing daily/weekly production meeting reporting

Phase 4 . Ongoing

Scale

  • -Extension to additional plants and MRP areas
  • -Safety stock review and BOM/routing exception flagging added as later-phase use cases
  • -Periodic re-tuning as exception taxonomy and plant priorities evolve

Questions to ask any vendor, including us

A short list that separates real SAP S/4HANA AI work from a chatbot demo.

  1. How does the system rank exceptions, and can our senior planners review and adjust that ranking logic directly?
  2. Does the agent ever convert a planned order, change a safety stock value, or send a supplier email without a person approving it first?
  3. How is accuracy validated, against what set of historical exceptions, and by whom?
  4. Can the system explain a predictive MRP shortage in terms our planners already understand, not just flag it?
  5. How does the deployment handle multiple plants or MRP areas on the same SAP instance without mixing data across them?
  6. What happens to the recommendation log if a planner disagrees with the agent, is that disagreement captured anywhere?
  7. Can this run entirely on our own infrastructure with no external network dependency?
  8. What is the actual time-saved measurement from the pilot, not a projected estimate?

Frequently asked questions

Will this change how SAP runs MRP?

No. MRP runs exactly as it does today. The agent reads the exceptions and planned orders MRP already produces and helps a planner triage and act on them faster. It does not change MRP logic, live cache settings, or scheduling.

Can it convert planned orders automatically?

By default, no. It drafts a recommended batch of conversions with its reasoning, and a planner reviews and executes the actual conversion in SAP. Automatic conversion can be scoped in later for low-risk, high-confidence cases if your team wants that, but it is never the starting point.

How does it handle predictive MRP differently from standard MRP exceptions?

It reads the same simulative shortage data the Monitor Predictive MRP app surfaces and adds a plain-language explanation of which demand and supply elements are driving the projected shortage, so a planner can judge whether to act early rather than wait for it to become a firm exception.

Does this require a separate MRP run or extra system load on SAP?

No, it reads existing MRP output on a schedule matched to your normal MRP run cadence rather than triggering additional runs or continuous polling, so the load on your SAP system is minimal.

How accurate is the exception ranking compared to a senior planner's judgment?

Accuracy is validated during the pilot against your own planners' historical decisions on a sample of past exceptions, not against a generic benchmark, since what counts as a priority exception varies by plant and material family.

Can this work across multiple plants on one SAP instance?

Yes, the connector is scoped per plant and MRP area using the same authorization boundaries SAP already enforces, so a multi-plant instance can be served without one plant's planners seeing another's data.

What is the realistic first outcome from a pilot?

Most pilots target a measurable reduction in the time planners spend manually scanning and prioritizing the MD04 exception list each day, since that is the highest-volume, most repetitive part of the job and the easiest to validate against a before-and-after time measurement.

Related guides

Talk it through with an engineer who knows SAP S/4HANA

Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.