AI automation for supply operations and the ERP

Watch a supply planner for an hour and count the screens. The ERP in one window, supplier emails in another, a spreadsheet of late orders in a third, and a chat thread with the warehouse on the phone. Most of the day goes on exceptions: a confirmation that never arrived, a delivery date that moved, an invoice that does not match the purchase order.

That exception work is where AI automation pays first in operations. It is also where projects most often stall, because the data the AI needs lives in the ERP, and nobody wants to touch the ERP.

Where AI earns its place

The useful jobs are specific and close to the paperwork:

Reading supplier documents (order confirmations, shipping notices, invoices) and matching them to the purchase order and goods receipt in the ERP.
Spotting exceptions early, such as a confirmed date that is later than the date the customer was promised.
Drafting the follow-up to the supplier, with the order number and the dates, for a buyer to check and send.
Answering "where is my order?" for sales or customer service from live ERP data, with the source shown.
Summarizing the week's demand signals for planners, with the numbers behind each point.

In each case a person stays in charge of the decision. The AI does the reading, matching and drafting that used to fill the morning, and the planner or buyer approves what matters.

Keep the ERP as the system of record

The ERP holds the orders, stock, costs and accounts your finance team relies on. Modifying it to add AI features is expensive, slows down every upgrade, and puts month-end close at risk.

ERP vendors increasingly say the same. SAP, for example, recommends keeping the core clean and building extensions side by side on a separate platform that talks to the ERP through its interfaces. Whatever ERP you run, the principle carries over: the automation lives beside the ERP and reads and writes through its APIs.

Three layers, each with one job

A setup that holds up over time usually has three layers.

The front end is where people work: a console for planners and buyers, a portal where suppliers confirm dates and upload documents, and a phone app for the warehouse. Each shows only what that person needs to act on.

The middle layer connects everything. An API gateway checks who is asking. An orchestrator runs each workflow step by step. An event bus passes news between systems, such as "goods received" or "confirmation late". A model router sends each AI task to the right model. Adapters translate between your systems and the ERP.

The back end holds the records: the ERP itself, the warehouse and transport systems, and supplier data.

Here is how one illustrative request moves through it. A supplier uploads a confirmation to the portal. The orchestrator asks the AI to read it and compare it with the purchase order. The confirmed date is four days late, so an event goes on the bus. The planner's console shows the exception with the affected customer orders, and a drafted reply to the supplier waits for approval. Once approved, an adapter updates the expected date in the ERP. Nobody retyped anything. We show the same pattern for a field-service company on our web apps and automation page.

Move one workflow at a time

Replacing or rebuilding everything at once is the riskiest way to modernize operations. Martin Fowler's Strangler Fig describes the alternative many teams use: build new pieces alongside the old system, move behavior over gradually, and let value arrive with each step.

For supply operations that means picking one workflow, such as supplier confirmations, and running the automation side by side with the manual process for a few weeks. Compare the results every day. Move to the next workflow once the team trusts the first one.

The people part decides the result

Buyers and planners have built their own workarounds over years, and they know where the data is wrong. Bring them in before anything is built. Ask which exceptions take the most time and which ones they would never hand to software.

Then plan the change as carefully as the integration: training by role, someone on hand in the first weeks, a visible list of fixes, and an adoption number reviewed every week. We wrote about this in more detail in change management after go-live.

The goal is a team that runs, adjusts and extends the automation itself. That includes adding new rules, tuning thresholds and taking on the next workflow without waiting for outside help.

Where to start

For two weeks, ask your planners and buyers to tally every exception they handle, by type. The biggest pile with a clear cost attached is your first workflow. If you want help sizing it or building it, see our web apps and automation and management consulting work.