Before You Redesign Your ERP Workflow, Run This 30-Day Test

"The proposal fixes the ERP. I'm not sure the ERP is what's broken."

The operations director at a growing distributor has a redesign proposal on her desk. New status fields, more notifications, a reworked approval flow. The goal is to stop her team from spending mornings checking supplier portals, reconciling delivery dates and answering "where's my order?"

The proposal is reasonable. It's also bigger than it looks. A new order workflow touches approval rules, permissions, integrations, reports and every team downstream: purchasing, finance, inventory, customer service. A targeted fix turns into a cross-department project before the first meeting ends.

Before she signs, she wants to know one thing: how much of the problem will this actually fix?

You can answer that in about 30 days, before you commit to anything. Here's how.

Week 1: Audit where the delays actually start

Pull 10 to 20 orders from the last two months that were late, escalated or needed a lot of chasing. For each one, trace back to the first moment it went off track, and sort that moment into one of four buckets:

1. Inside an ERP transaction. The system was slow, missing a field, or forced extra steps.
2. Between systems. The information existed, but in email, a portal or a spreadsheet the ERP didn't see.
3. Waiting on a person. Someone inside the company had what was needed but didn't know it was their turn.
4. Waiting on someone outside. A supplier or customer was late, and nobody noticed in time.

Count the buckets. An ERP redesign can mostly fix bucket 1. If buckets 2 to 4 make up most of your list, the redesign is aimed at the smaller part of the problem.

(Why so much of the work lands outside the ERP is a longer story. We covered it in Your ERP Wasn't Designed for Your Workflow.)

Week 2: Sort the redesign wish list

Take every item in the proposal and put it in one of three groups:

• Configuration. A setting, a field, a report, a permission. Cheap, low-risk, stays upgradable. Usually just do it.
• Customization. New code or a custom flow inside the ERP. Expensive to build, and more expensive to keep through every upgrade. Only worth it with a clear, measured payoff.
• Coordination. Anything that depends on information arriving from outside the ERP: a supplier date in an email, a customer change on a call, a handoff between people. These don't belong inside the ERP, because the ERP will never see the input.

Most proposals end up with a short list of easy configuration wins, a few real customizations, and a surprising number of coordination items dressed up as ERP features.

Weeks 3 to 6: Pilot one coordination gap

Pick the coordination gap that showed up most in your audit. For most distributors, it's supplier updates that never reach the customer commitment.

Before you change anything, take a baseline for two weeks:

• Time spent chasing. Hours a week your team spends checking portals, inboxes and spreadsheets for status.
• Time to know. How long between a supplier slip and someone on your team knowing about it.
• Late surprises. How many customers learned about a delay before you told them.

Then run the pilot. Connect the supplier updates to the orders they affect, flag the orders at risk, and give the team one shared view of what needs action. Keep the ERP exactly as it is.

Measure the same three numbers again. Now you have real data on how much of the pain was coordination, and how much an ERP change still has to solve.

This is the kind of pilot LevelOneAI runs: one workflow, on top of the systems you already have, with a person approving anything that changes the record. If you want the full case for fixing coordination before buying more ERP, see You Might Not Need a Bigger ERP Yet.

Five questions for your ERP partner before you sign

Whatever the pilot shows, ask these before approving the redesign:

1. What else does this change touch? Get the full list of rules, integrations, reports and teams affected.
2. What happens at the next upgrade? Which parts are configuration, and which are custom code someone has to maintain?
3. Who owns it after go-live? Name the person who fixes it when it breaks.
4. How does it handle exceptions? Walk through three real exceptions from your audit, not the standard order.
5. How will we measure success? Use the same baseline numbers from your pilot, so you can compare.

What the distributor found

In our composite example, the audit told a clear story. Order entry and transactions worked fine. Most delays started with supplier updates arriving by email and portal, and nobody tying them to customer dates.

The wish list shrank to a few configuration changes, done in a week. The customizations were put on hold. The coordination items moved to the pilot instead, where they could be measured.

If the numbers had shown the ERP itself was the bottleneck, the redesign would have gone ahead, with a tighter scope and a clear target. Either way, the decision was based on where the work actually breaks.

Try this week

• Pull five late orders from last month and sort the first delay in each into the four buckets above.
• Open your redesign proposal and mark every item as configuration, customization or coordination.
• Write down your current numbers for time spent chasing, time to know and late surprises. You'll want a baseline whatever you decide.

Talk to LevelOneAI about running a pilot