Any ERPUse Case

MRP exceptions + private AI

AI for MRP Exception Management: From 5,000 Action Messages to the 50 That Matter

Short answer

AI for MRP exception management reads the action messages MRP generates (reschedule in, reschedule out, cancel, expedite), ranks them by actual customer and cost impact, and explains each with its pegging and supplier context. The planner approves and executes in the ERP; the AI prepares the worklist and the reasoning.

ERP
SAP S/4HANA, Infor SyteLine, Infor LN, Epicor Kinetic, Oracle E-Business Suite
Industries
Manufacturing, Aerospace, Electronics
Written for
Production Planner

Run MRP in a mid-sized plant and the output is a flood: thousands of action messages telling planners to move this purchase order in, push that work order out, cancel this surplus supply. Most are small timing adjustments with no customer consequence. A few are urgent, because a component for a shipping order will arrive after the date it is needed. The planner's job is to find those few quickly, and the system gives them the same flat list as everything else.

Each ERP exposes this differently. SAP planners work from MD04 and MD07 and the exception groups in MD06; SyteLine and Infor LN users work from planning detail and action messages by planner code; Epicor Kinetic has the Planning Workbench; Oracle EBS has the Planner Workbench. The common pattern is a list sorted by date or item, not by consequence. Experienced planners know which items matter and which suppliers are unreliable, but that knowledge is in their heads.

An AI layer can supply the missing sort order. By following pegging from the exception to the demand it affects, adding supplier delivery history, and checking for substitutes or alternate sources, it can rank messages by what happens if nothing is done. It can also explain why MRP made a suggestion, which is often the fastest way to find a bad lead time, an outdated safety stock or a bill of materials error.

This page covers how to do that safely: read-only, with deterministic logic for the ranking where possible, explanations a planner can verify, and no direct execution of firm planned orders or purchase changes without an approval.

What usually gets in the way

The problems we hear most from production planner teams running SAP S/4HANA.

Flat lists hide the urgent few

MRP output is sorted by item or date, so the order that will stop a shipping job is buried under cosmetic reschedules.

Nervous MRP creates noise

Small demand changes produce chains of reschedule messages. Planners learn to ignore them, and sometimes ignore the real ones.

Root causes recur

The same wrong lead time or yield produces the same exception every run, and nobody has time to fix the master data.

Supplier reliability is tribal knowledge

Planners know which vendors slip, but the MRP date assumes the promised date is true.

Pegging is slow to trace

Finding which sales order or work order a late component affects takes several screens, so planners expedite the wrong thing.

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.

Impact-ranked exception worklist

Each action message is scored by the earliest affected demand, customer priority, days of slack, value at risk and supplier reliability. The planner sees a ranked list with the reason for each line.

Touches: SAP MD06 exception messages and MD04 pegging, SyteLine planning detail and action messages, LN planning actions, Kinetic Planning Workbench

Outcome: Planners reach the urgent items first, and reschedule noise is batched for later review.

Expedite recommendations with options

For a late component, the agent lists the affected orders, the supplier's recent on-time record, alternate suppliers or substitutes in the item records, and stock elsewhere that could be transferred.

Touches: Purchase order lines, approved vendor list, item substitutions, inter-site stock, supplier receipts

Outcome: Better expedite choices; less chasing of orders that do not affect shipments.

Reschedule batching

Low-impact reschedule messages are grouped by supplier so one communication covers many lines, with a draft supplier message for approval.

Touches: Purchase order schedule lines, supplier contacts, delivery calendar

Outcome: Fewer supplier emails and less planner time on trivial changes.

Cancel and surplus review

Identify supply that MRP suggests canceling, check whether it is committed to a customer, tooling lot size or minimum buy, and flag items where the cancel suggestion is unsafe.

Touches: Open POs, work orders, lot-size rules, minimum order quantities, vendor terms

Outcome: Fewer mistaken cancellations and clearer excess reporting.

Root-cause explanation

For a repeating exception, the agent compares planned lead time, yield and safety stock with actual receipts and completions, then points to the parameter likely at fault.

Touches: Item planning parameters, receipt history, production completions, scrap records

Outcome: Master data fixes that reduce the number of exceptions on the next run.

Shift handover summary

A summary of open critical exceptions, actions taken and promises from suppliers for the next shift or planner.

Touches: Exception status, planner notes, supplier confirmations

Outcome: Less lost context when coverage changes.

Natural-language exception queries

Ask 'which exceptions will make us miss next week's shipments for customer X' and get an answer built from pegging and dates, with the query visible.

Touches: Pegging tables, sales order lines, planned and firm orders

Outcome: Direct answers instead of manual screen navigation.

Reference architecture

A read-only layer pulls MRP output, pegging, supplier history and item parameters. Ranking uses transparent, adjustable scoring; the model explains and drafts. Changes to orders happen in the ERP by a planner.

  1. 1

    MRP output connectors

    Read-only access to action messages, planned and firm orders, pegging and requirements via supported APIs, views or a replica so analysis does not load the production database.

  2. 2

    Supplier and item history store

    Receipt history, promised versus actual dates, and item parameters are assembled into features for ranking.

  3. 3

    Scoring engine

    Deterministic scoring with weights set by the planning manager. The model can describe it but does not invent it.

  4. 4

    Private model serving

    Open-weight model on your GPUs or private cloud for explanations, supplier drafts and question answering.

  5. 5

    Planner approval

    Drafts and recommendations appear as proposals. Executing a reschedule, expedite or cancel is done by the planner in the ERP.

Integration notes for your ERP team

  • Run analysis after each MRP regeneration; store the run timestamp so rankings are reproducible.
  • SAP: read MD06 exceptions and MD04 requirement elements, and use order pegging to find the affected demand; exception group definitions are configurable.
  • SyteLine: planning detail and action messages by planner code, via IDOs or SQL views; firming and releasing stay in the planning workbench.
  • Infor LN: planned actions per planner through ION or BOD messages, or replica reads of the planning tables.
  • Epicor Kinetic and Oracle EBS: use the planning workbench tables or APIs, and keep any write actions behind the standard workbench.
  • Join supplier receipt history by vendor and item to produce on-time and lead-time variance features.
  • Keep the scoring weights in a configuration table so planners can tune them without a code change.

Deployment options

On-premises

Aerospace and defense suppliers with restricted program data

Planning data and supplier history stay inside your network.

Private cloud

Manufacturers on cloud-hosted ERP

Isolated inference with private connectivity to the planning database or API.

Read replica analysis

Sites with heavy MRP runs and sensitive performance

Analysis runs against a replica or extracted snapshot after each MRP run so the live system is not loaded.

Compliance and data control

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

AS9100 and supplier control

The assistant surfaces supplier delivery performance from receipts, which supports your supplier monitoring records. Control over approved sources stays in your system.

ITAR and CUI program data

On-prem deployment keeps part and program data inside the boundary you manage. Responsibility for registration and handling remains with the customer.

SOX (inventory and purchasing controls)

The assistant is read-only. Order changes follow existing approval and audit paths in the ERP.

Customer flow-down requirements

Exception rankings can include customer-specific priority rules agreed in contracts, set by your team.

How an engagement runs

Phase 1 . 1 to 2 weeks

Discovery

  • -MRP run schedule and exception volume baseline
  • -Planner interviews on what matters
  • -Data access plan for pegging and receipts
  • -Scoring factors agreed

Phase 2 . 2 to 4 weeks

Prototype

  • -Ranked list on historical MRP runs
  • -Planner comparison of AI ranking with their own
  • -Root-cause report on the top repeating exceptions

Phase 3 . 4 to 6 weeks

Pilot

  • -Live read-only worklist after each run
  • -Supplier message drafts for approval
  • -Weekly review of missed and false urgent items

Phase 4 . Ongoing

Scale

  • -More planner groups and sites
  • -Master data cleanup program
  • -Weight tuning and ownership handover

Questions to ask any vendor, including us

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

  1. How is the ranking computed, and can planners adjust the weights?
  2. Does analysis run on a replica so MRP performance is not affected?
  3. Can the assistant ever firm or change an order directly?
  4. How are supplier on-time metrics calculated and what history is needed?
  5. How does it handle pegging through multiple BOM levels?
  6. How do we measure whether it reduces missed shipments?
  7. Is our APS tool, if any, a better place for part of this?
  8. What data cleanup should we expect to uncover?

Frequently asked questions

Will this reduce the number of MRP messages?

Not directly. The same messages exist, but they are ranked and grouped so planners handle the important ones first. Over time, root-cause fixes to lead times, safety stock and lot sizes can lower message volume, but that depends on your team acting on the findings.

Can the AI execute reschedules in the ERP?

It can in principle, but we recommend not starting there. Keep the first deployment read-only and have planners execute in the ERP. If you later allow write-back, restrict it to defined low-risk actions with an approval step and a full audit trail.

Is this the same as APS?

No. Advanced planning and scheduling tools make finite-capacity plans. This works on the MRP output you already have and helps the planner decide what to do about it. If your problem is the plan itself, an APS may be what you need.

What data does it need?

MRP action messages, pegging to demand, purchase and work order status, supplier receipt history, and item planning parameters. Most of this exists in the ERP; the challenge is clean receipt and promise-date history.

How is this different from the ERP's exception filters?

Built-in filters group messages by type, planner and date. They do not combine customer priority, supplier reliability, slack and value at risk into one view. If simple filters already give your team an actionable list, you may not need more.

Does it work for engineer-to-order and project-based plants?

Yes, but pegging is more important and more complex there, with project-linked demand and long chains. Allow more time for mapping. Rankings for ETO environments often weigh milestone dates differently, which your team should define.

What is a good first success measure?

Compare, over a few MRP cycles, whether the AI ranking would have surfaced the exceptions that later caused late shipments earlier than the planners did. That is a concrete check and does not depend on opinions.

Related guides

SAP PP/MRP + AI agents

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

AI agents that triage SAP MD04 exceptions, explain predictive MRP shortages, and draft planned-order actions, grounded on your own SAP data, deployed on-prem.

PO follow-up that does not wait on a person

AI Purchase Order Automation: Supplier Follow-Up and Expedite Without a Buyer Chasing Email

AI drafts routine PO confirmation and expedite messages from open ERP order data, with a buyer approving every message and change before it goes out.

Forecasting plus a reason why

AI Demand Forecasting for Manufacturers: Better Numbers and an Explanation Planners Can Trust

AI demand forecasting explains ERP forecast changes in plain language, flags exceptions for planners, and handles short-history SKUs without Excel overrides.

PlanetTogether + private AI

AI for PlanetTogether APS: Explain the Schedule, Compare Scenarios, Reconcile with the ERP

Add private AI to PlanetTogether APS: explain schedule changes, compare scenarios, and reconcile ERP orders with the plan, on-prem and read-only by default.

Ask your ERP anything

Natural Language Query for ERP Data: Ask SAP, Infor, or Oracle a Question in Plain English

See how natural language query over SAP, Infor, Oracle, and NetSuite data works: grounded text-to-SQL, role-based permissions, and a visible audit trail.

Infor SyteLine / CSI + AI

AI for Infor SyteLine and CloudSuite Industrial

Add grounded AI to Infor SyteLine or CloudSuite Industrial: natural-language answers, agents over IDOs and ION, on-prem or CloudSuite deployment.

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.