Your ERP is not the only problem: finding the handoffs that create rework

When an order requires four spreadsheets, two email threads, and a phone call to someone who “knows how the system works,” the ERP becomes an easy target.

Sometimes the ERP deserves the blame. It may be poorly configured, unsupported, or genuinely unable to handle the business. But the worst rework often happens between functions, where no single system owns the whole process.

Replacing software without examining those handoffs can preserve the same confusion in a newer, more expensive form.

Follow one transaction

Start with a real order, job, return, or service request. Choose one that was difficult but not so unusual that everyone dismisses it as an exception.

Walk it from the first customer request through delivery and invoicing. Use the records people actually touched. Do not begin with a standard operating procedure or a consultant’s process diagram. Those describe the intended path. You need the path the work took.

At each handoff, ask:

• What information did the receiving person need?
• What arrived late, incomplete, or in the wrong form?
• What did someone retype, interpret, or verify?
• How did the sender know the next person was ready?
• Where did the transaction wait?

The goal is not to catch mistakes. It is to find where the process expects one person to compensate for missing rules, unreliable data, or a system boundary.

Look for the second record

Rework leaves evidence. A planner keeps a local schedule because system dates cannot be trusted. Customer service maintains a pricing sheet because approved terms are hard to find. Production writes changes on a traveler after the ERP order is released. Finance keeps a reconciliation workbook to explain what the operational system cannot.

These secondary records are not automatically bad. A focused spreadsheet can be the simplest tool for a local decision. The warning sign is that the second record becomes authoritative while the official system still drives downstream work.

Ask which record people trust when the two disagree. Then ask why. The answer is often more useful than a feature comparison.

Identify ownership gaps

Many handoff problems are management problems expressed through data.

Who owns the promise date after sales enters an order? Who approves a new item definition? Who decides whether a customer change requires a new revision? Who closes a completed service job? If the answer is “it depends,” document what it depends on.

Software can route an approval. It cannot decide which manager is accountable or settle a policy the leadership team has avoided. Those decisions need to be made before configuration begins.

Ownership also includes maintenance. A field may be correct at go-live and unreliable six months later because no one reviews how it is created. Define who can change shared data, what evidence is required, and how errors are corrected.

Measure friction in operating terms

People rarely record “handoff failure” in a system. Use measures close to the work:

• orders placed on hold for missing information
• jobs released and then changed
• invoices delayed by unresolved completion or pricing questions
• manual entries made in more than one system
• exceptions that require a supervisor to interpret policy

You do not need a perfect baseline to begin. Sample a useful period and review the exceptions with the people doing the work. Their explanations will separate recurring design problems from unusual customer needs.

Be wary of counting every touch as waste. Some checks are important controls. A quality review or credit approval may intentionally slow a transaction. The question is whether the check has a clear purpose, reliable input, and accountable owner.

Decide what kind of problem you found

Handoff problems tend to require different responses.

A policy problem needs a business decision. A data problem needs ownership and validation. A configuration problem may need changes to fields, workflow, or permissions. An integration problem needs a reliable exchange and a plan for failures. A capability problem may justify a new module or system.

Do not force every finding into the ERP. A shipping carrier integration, customer portal, or simple work queue may solve a boundary problem without replacing the core platform. Conversely, do not keep adding workarounds when the ERP cannot support a process central to the company’s direction.

Test a better handoff before automating it

Choose one repeated source of rework and redesign it with the people on both sides. Define the minimum complete input, the acceptance rule, and the response when information is missing. Run the revised handoff manually for a few weeks if necessary.

This exposes policy questions while changes are cheap. It also shows whether the problem was the screen or the agreement between teams.

Once the handoff works, decide what technology should enforce or simplify it. Automation is useful when the rule is understood. Automating an unsettled process produces faster confusion.

When replacement is still the answer

Process work should not become an excuse to protect an inadequate system. Replacement may be warranted when the ERP is unsupported, creates unacceptable security or availability risk, cannot represent essential transactions, or blocks a business model the company has chosen.

Even then, the handoff review is not wasted. It supplies real requirements, identifies data owners, and shows where implementation will require operating change. Those are some of the hardest parts of an ERP program.

Before approving a replacement, leadership should be able to name which sources of rework the new design will remove and which will remain management responsibilities. If the business case depends on people suddenly entering perfect data or following undefined rules, it is not ready.

The next time someone says, “the ERP made us do it,” follow one transaction across the departmental lines. The system may be at fault. Just as often, it is faithfully exposing a handoff nobody owns.

EdgePoint sometimes helps teams conduct this kind of cross-functional review before a major system decision. It can also be done internally, provided the discussion stays close to real work and avoids turning into a search for blame.