Why ERP falls short for procurement in manufacturing
Most manufacturing companies have their procurement process automated on paper. There is an ERP with an MRP module, there are purchase orders, there are supplier records. But in practice, planners and buyers still run spreadsheets alongside the system. They export an MRP run, manually check what is missing, adjust quantities based on knowledge that exists nowhere in the system, and follow up confirmations by email because the system does not catch the deviation. This is not a user error. It is a structural gap in what standard ERP workflows can handle the moment production reality deviates even slightly from the textbook.
Breaking point 1: translating production requirements into purchase orders
MRP calculates requirements based on the bill of materials, stock levels, and planned production orders. Up to that point, things run smoothly. The problem lies in the translation to a concrete purchase order. Lead times vary by supplier and by moment, minimum order quantities differ from what MRP calculates, and sometimes the buyer wants to split an order across two suppliers for security. Standard MRP supports one replenishment strategy per item. The exceptions, and in manufacturing there are always exceptions, land in the buyer's inbox. The buyer decides, re-enters data manually, and the risk of errors is immediately built in. An AI Worker that reads MRP output, consults supplier history, and prepares a draft order for one-click approval removes the manual work without taking control away from the buyer.
Breaking point 2: matching supplier confirmations to purchase orders
The supplier confirms the order, but with a different delivery week, a different quantity, or split into two partial deliveries. In theory, the buyer records the deviation in the ERP so the planner is informed. In practice, it rarely works that way. The confirmation arrives by email or PDF, the buyer processes it manually when time allows, and the planner continues working with the original date. This does not cost minutes but hours per week, multiplied across all open orders. Three-way matching, where the purchase order, confirmation, and goods receipt are automatically compared and deviations are flagged immediately, is the type of automation that makes a difference here. Not as a replacement for the buyer, but as a filter that only puts genuine exceptions on the desk.
Breaking point 3: pushing changes through to production planning
When a supplier delivers two weeks later than expected, this has consequences for the production order, capacity planning, and potentially the commitment to the customer. In most companies, the planner only finds out when the buyer forwards the email, when the planner asks for an update, or when the material simply does not appear on the shop floor. The link between procurement status and production planning is the weakest link in the chain. An automated workflow that triggers a signal to planning with every confirmed deviation, and prepares a rescheduling proposal when a threshold is crossed, is technically feasible. But standard ERP does not do this automatically: it requires either custom development on the existing system or an AI Worker that connects the two worlds.
When to choose an AI Worker and when to rebuild?
If the ERP is functionally adequate but the three breaking points above account for most of the manual work, an AI Worker is the logical first step. It reads emails and PDF confirmations, compares them with open purchase orders in the ERP, and queues deviations for the buyer to approve. The connection to the planning module can follow as a second step. If the ERP itself is the bottleneck, because the data model is incorrect, bills of materials are unreliable, or workflows structurally conflict with how the factory operates, an AI Worker will not solve the problem. In that case, the foundation needs to be addressed first. Making that distinction is the first thing to establish before investing in tooling.