A customer order is ready to ship, but the warehouse finds fewer units than the system shows. Sales has already confirmed delivery. Procurement is waiting for a supplier update, and the transport team needs a decision before the collection window closes.
The next hour disappears into calls, emails, and spreadsheet checks.
At the next management meeting, someone raises a familiar concern: “Our ERP cannot keep up anymore.”
Perhaps it cannot. But this incident alone does not establish that. The problem could sit in inventory updates, allocation rules, approval delays, or the handoffs between teams. A replacement ERP may inherit those same problems if nobody examines how the exception was handled.
Before committing to replacement, follow what happens when a supply chain transaction goes off plan. That workflow can reveal what the business actually needs to change.
What Is a Supply Chain Exception Workflow?
A supply chain exception is a deviation from an expected operational outcome. A supplier misses a delivery date. A shipment arrives damaged. Stock exists in the system but cannot be located on the warehouse floor.
The exception workflow covers how the business detects that deviation, assesses its impact, assigns responsibility, makes a decision, and confirms resolution.
Consider a short shipment. Recording the missing quantity is only the beginning. Someone must determine which orders are affected, check alternatives, approve a response, and communicate the revised commitment.
For mapping purposes, follow six stages:
- Detection: Where does the issue first become visible?
- Assessment: Which orders, customers, or commitments are affected?
- Ownership: Who takes responsibility for the next action?
- Decision: What options and approvals are available?
- Execution: Who carries out the agreed response?
- Closure: How do teams confirm that records and commitments are updated?
A useful map follows the issue through to closure. Stopping at “alert sent” leaves much of the operational work unexplained.
Start with a Recent Incident
Bring a real exception into the discussion. Choose one that involved several teams and left enough evidence to reconstruct what happened.
A purchase order, stock adjustment, email thread, and shipment record can provide a more useful starting point than a workshop based entirely on how the process is supposed to work.
Ask the people involved to walk through the incident in sequence:
When did the supplier first report the delay? When did procurement see it? How long before customer service understood the impact? Who authorised the additional freight charge?
Keep the original timestamps wherever possible.
This separates time spent doing necessary work from time spent waiting. A five-minute approval may have sat unattended for an entire afternoon. Replacing the screen on which that approval appears will not necessarily resolve the delay.
Include the people who handle these situations every day. They can explain the informal arrangements that process documents miss, such as calling a particular supervisor because the official escalation route rarely gets a response.
Map the Handoffs, Decisions, and Missing Information
Each step should show who acts, what information they need, where they obtain it, and what happens next.
Identify the first reliable signal
An exception may become visible outside the ERP. A warehouse employee discovers damaged goods during picking, or a carrier reports a failed collection through its portal.
Record both when the event occurred and when the responsible team could act on it. The gap between those moments helps identify whether the problem concerns detection, integration, or attention.
Check whether ownership is explicit
“Operations will handle it” is too broad to support a reliable workflow.
Identify the role responsible for assessing the exception and the role authorised to decide. These may be different people. Set out what happens when either is unavailable or the response deadline passes.
Shared visibility is useful, but someone still needs to own the next action.
Capture the information behind the decision
For a stock shortage, an inventory total may be insufficient. The team may also need to know whether units are reserved, awaiting inspection, or available at another location.
Document what people check before acting. Repeatedly gathering the same information from several systems points to a specific integration or data-access requirement.
Define what resolution means
A replacement shipment leaving the warehouse does not automatically close the original issue.
The customer may still need a revised arrival date. Inventory records may require correction. Finance may need to account for additional freight or a credit.
Define closure in operational terms so that the exception does not disappear from one team’s queue while remaining unresolved elsewhere.
Separate ERP Limitations from Workflow Problems
Once the current workflow is visible, classify the causes of delay.
A process problem needs a clear operating decision. An integration problem needs reliable information exchange. A platform limitation may require deeper modernization or replacement.
| What the map reveals | What to investigate |
|---|---|
| Exceptions wait because nobody owns the response | Responsibility and escalation rules |
| Staff repeatedly copy shipment updates between systems | Integration coverage and update failures |
| Teams disagree about available stock | Inventory definitions, data quality, and update timing |
| Routine decisions require several approvals | Approval thresholds and delegated authority |
| A necessary transaction cannot be supported without fragile workarounds | ERP capability and customization constraints |
| Peak activity creates processing delays | Performance, capacity, and system architecture |
Several causes can exist together. An integration fix will have limited value if the receiving team still has no agreed response procedure.
The purpose of this exercise is to make the replacement decision more precise. It may strengthen the case for a new ERP by showing exactly where the existing platform prevents the business from operating effectively.
Test One Improved Workflow Before Expanding the Programme
Choose a recurring exception with a clear business consequence. Inventory discrepancies, supplier delays, and failed collections are practical candidates.
Define the desired response before selecting technology. For a delayed inbound delivery, that might mean procurement confirms the revised arrival, planning identifies affected orders, and customer service receives an approved delivery commitment.
Then test the changes on a manageable scope, such as one warehouse or supplier group.
Track measures that reflect the work:
- Time from detection to assignment.
- Time from assignment to an approved decision.
- Total time to resolution.
- Number of manual handoffs.
- Exceptions reopened after being marked complete.
- Additional freight, rework, or service costs associated with the incident.
Interpret the results carefully. Faster closure is not necessarily an improvement if teams close cases before completing the follow-up work.
The pilot should establish which changes help, which dependencies remain, and what the ERP must support.
Use the Map to Evaluate Replacement Options
If replacement is justified, the exception map becomes a practical evaluation tool.
Give prospective vendors a realistic scenario. Ask them to demonstrate a partial receipt, a stock discrepancy, or a missed collection from discovery through resolution.
Watch how the proposed system identifies affected orders, routes responsibility, records approvals, and updates connected platforms. Ask which steps require configuration, additional products, integrations, or custom development.
This produces more useful requirements than broad requests for “better visibility” or “more automation.” It also gives the implementation team concrete acceptance scenarios.
An ERP investment should support the way the business needs to operate under pressure. Demonstrating a clean purchase-to-payment transaction covers only part of that requirement.
Conclusion
Before approving an ERP replacement, select a recent supply chain exception and trace it across every team involved. Record the delays, missing information, decisions, and unfinished handoffs.
Use that evidence to decide what needs process improvement, what needs integration, and what requires a different platform. This approach to supply chain digital transformation services gives the business a clearer investment brief: the specific operational problems the next system must solve, and a practical way to verify that it does.
