Insights

Engaged SCM | Transformation Readiness Series

Gartner predicts that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully achieve their original business case, with much of that shortfall coming from business alignment, governance, stakeholder engagement, and organizational readiness rather than the technology itself. The software is rarely the problem. The organization simply was not ready for it. ERP is the more visible example, but the same pattern holds for WMS, TMS, barcode systems, robotics, and the AI and automation tools now showing up on every modernization map.

The current-state process map becomes the foundation for requirements, solution design, workflow configuration, testing, training, and change management. If that document reflects assumptions instead of operational reality, every decision that follows inherits the same flaw.

‍

Agreement Is Not Alignment

The conference room is full. Representatives from Procurement, Finance, Operations, Accounts Payable, and IT gather around a screen reviewing the current-state Procure-to-Pay process.

Someone asks, "Is this how we work today?" Heads nod around the room. A few minor edits go in, an approval box moves, an exception gets added, and the facilitator updates the diagram.

By the end of the workshop, everyone agrees the process map reflects how work gets done. The team approves the document, hands it to the implementation partner, and treats it as the foundation for the technology project.

Months later, the problems begin.

Approvals do not follow the documented workflow. Business units keep purchasing outside the system. Receiving teams describe exceptions nobody discussed. Accounts Payable finds invoice matching issues no one anticipated. Procurement discovers supplier onboarding differs across business units.

The implementation team has not made a mistake. They built the system based on the information they were given. The organization confused agreement with alignment.

Those two words sound similar, but they are fundamentally different. Agreement happens when people accept the process map in the room. Alignment exists when every function shares the same understanding of how work actually happens across the business.

Part of the reason the two diverge is structural. Enterprise processes do not operate within organizational charts. A Procure-to-Pay process begins long before Procurement gets involved and continues well after an invoice is paid. Decisions made by Operations affect Procurement. Procurement influences Finance. Receiving impacts Accounts Payable. Vendor master data affects everyone.

Finance may believe approvals are standardized because they follow the documented workflow. Operations may rely on expedited purchasing to keep production moving. Receiving teams may have built local practices to handle supplier variability. Accounts Payable may routinely resolve invoice discrepancies through manual work that never appears on a process map.

None of these practices are necessarily wrong. Most evolved to solve legitimate operational challenges. Each team sees its part of the process exceptionally well. Very few people see the entire process from beginning to end. The problem starts when that gap stays invisible.

That is exactly why current-state process mapping earns its place at the start of a transformation. It brings perspectives together that rarely sit in the same conversation. As each function describes its role, the organization starts to see where assumptions differ, responsibilities overlap, and handoffs were never fully understood in the first place.

One of the most valuable outcomes of the exercise is realizing there is not one version of the current state. There are several. Reaching agreement on the current state is only the first step. Transformation requires alignment around the future state, and alignment takes more work than a nodding head in a workshop.

Two Versions of Every Process

Every organization runs on two versions of its processes.

The documented truth lives in process maps, policy manuals, and governance documents. It reflects how the organization believes work happens. The operational truth lives on the warehouse floor, in purchasing departments, at receiving docks, and in the daily decisions employees make to keep the business running. It reflects how work actually happens.

In a well-run organization, those two versions stay close together. In many organizations preparing for a technology transformation, they do not.

Teams build workarounds to solve real operational problems, and those workarounds rarely make it into the documented process. A supervisor bypasses the standard approval process because production cannot wait. A receiving team invents its own method for handling incomplete shipments. None of these decisions come from bad intentions. Most are practical responses to real pressure.

When implementation teams build only from documented truth, they configure a system for a business that doesn't quite exist on the floor. The gap between what's documented and what's actually happening is where transformation risk lives.

The Most Expensive Gaps Are the Ones You Do Not Know Exist

Most process maps tell the story of the normal workflow. Business, however, rarely operates under normal conditions. The greatest implementation risks live in the exceptions: situations that happen often enough to matter but rarely make it into official documentation.

• How are emergency purchases handled when equipment fails at 2 a.m.?

• What happens when a supplier delivers only part of an order?

• Who approves purchases when the designated approver is unavailable?

• Where do mismatched purchase orders and receiving records get resolved?

• Which putaway or cycle-count exceptions get handled off-system when scanners fail?

These situations may represent a small share of total transactions, but they consume a disproportionate amount of time, create the highest operational risk, and generate the greatest frustration across the business.

Because they happen outside the standard process, teams often treat them as one-off events and handle them through emails, phone calls, spreadsheets, or individual experience. These workarounds keep the business moving. They also rarely make it into the process documentation.

When organizations begin a transformation without understanding these exceptions, they build a future-state process around the standard workflow while the realities that keep the operation running stay hidden. The goal is not to eliminate every exception. Exceptions are a normal part of complex operations. The goal is to understand them.

Some exceptions represent legitimate business requirements that belong in the future state. Others reveal process gaps, unclear ownership, or opportunities for automation. Organizations that identify these gaps before implementation gain a real advantage: they design around how the business actually operates, not how it appears on paper.

The cost of missing them shows up in slower purchasing decisions, frustrated suppliers, delayed payments, inconsistent reporting, reduced confidence in system data, and countless hours spent reconciling issues that could have surfaced months earlier.

The most successful transformation programs do not try to eliminate every exception. Instead, they sort which exceptions represent legitimate business requirements, which are symptoms of inconsistent processes, and how each should be managed before the system gets configured. That work is not documentation. It is operational discovery, and it is one of the most valuable investments an organization can make before a major transformation begins.

Technology Standardizes Whatever You Give It

ERP, WMS, TMS and Source-to-Pay platforms do not invent business processes. They operationalize the ones they are given.

Every workflow, approval path, automation rule, and integration gets configured based on decisions made during process design. Incomplete information or inaccurate assumptions get reproduced at scale, faithfully, by the technology.

That is why technology projects sometimes take the blame for problems they did not create. The software performs exactly as it was configured. The business simply was not fully understood before configuration began.

Technology is remarkably good at creating consistency. It is remarkably poor at determining whether the process it is standardizing is the right one. Technology standardizes whatever you give it. It does not validate whether that input was correct in the first place.

Don't Mistake Platform Standards for Best Practices

One question we hear frequently is, "What if we do not have documented processes?"

In most technology projects, the answer is straightforward. The systems integrator brings a library of standard process maps and recommended workflows for the platform selected. After leading ERP and procurement transformation projects at two global consulting firms, we have seen those templates work well in many organizations. They provide an excellent starting point because they reflect how the technology was designed to function.

That does not automatically make them best practice for your business.

Every organization carries different operational realities, governance requirements, risk tolerances, customer commitments, regulatory obligations, and decision-making structures. A process that works well for one organization may create unnecessary complexity or operational risk in another.

Use the templates as a starting point, not the answer. Challenge them. Ask why a workflow exists. Ask whether it supports your operating model. Most importantly, make sure Procurement, Finance, Operations, and the rest of the business are genuinely aligned behind the future-state process. Willingness to accept a template because it came from the implementation partner is not the same thing as alignment.

Good implementation partners expect those conversations. The best ones encourage them.

The Real Value of Process Mapping

The most successful organizations treat process mapping as more than a documentation exercise. They use it to challenge assumptions and build alignment across the business.

The objective is not simply to produce a current-state diagram and move on to system configuration. The real value comes from using the exercise to understand how work flows across the organization and to determine what needs to change before the future state gets designed.

Effective process mapping creates visibility. It identifies where processes create unnecessary effort, where handoffs between functions cause delays, and where responsibilities or decision rights are unclear. It highlights opportunities to simplify workflows, remove manual activities, improve approvals, and target automation where it creates real value.

It also helps leaders understand the operational impact of transformation. A future-state process may reduce manual effort in one area while creating new responsibilities elsewhere. Certain roles may need additional capability and capacity. Approval structures may change. Ownership of data and decisions may shift. Leaders need to understand these impacts before implementation begins, not after.

The most valuable process mapping conversations happen when leaders move past "How does the process work today?" and start asking:

• What changes will this create for the people responsible for executing the work?

• What should this process look like in the future?

• Who should own each decision?

• Where should technology enable the process, and where should business judgment remain?

Answering these questions turns process mapping into a foundation for better decisions. It creates alignment across functions, reduces implementation risk, and helps ensure the future-state process supports the way the organization actually operates. Those conversations often become the first time leaders fully understand how one decision ripples across multiple functions.

The Best Time to Find Gaps Is Before Your Implementation Partner Does

Once configuration begins, assumptions become design decisions. Every misunderstanding gets more expensive to correct. Workshops turn into redesign sessions. Timelines extend. Change requests pile up.

Organizations that experience smoother implementations are not necessarily simpler. They just invest more time discovering operational reality before technology begins to codify it.

The most dangerous document in a technology transformation project is not the one that is incomplete. It is the one everyone believes is accurate when it is not.

Are You Ready for a Technology Transformation?

Many organizations ask whether they are ready to implement new technology. The better question is whether the organization is ready to support one.

Technology readiness is only part of the equation. Operational readiness determines whether the investment delivers long-term value. Before selecting a platform or starting system configuration, leadership teams should be able to answer these questions with confidence:

Organizations that cannot answer these questions with confidence are not facing a technology problem. They are facing a readiness problem. That distinction matters, because implementation partners configure systems. Organizations are responsible for preparing the business to operate within them.

Successful Transformations Start Long Before Configuration

Organizations that get the greatest return from technology investments do not begin with software selection. They begin by understanding how work actually gets done, aligning stakeholders around a common operating model, clarifying ownership, and resolving operational ambiguity before implementation starts.

That work builds a stronger foundation for every decision that follows, from process design and system configuration to testing, training, adoption, and continuous improvement.

At Engaged SCM, successful technology investments start with three things:

• Operational readiness. Understanding the difference between documented truth and operational truth before technology gets introduced.

• Stakeholder alignment. Building a shared understanding of how work should flow across Procurement, Finance, Operations, and the rest of the organization.

• A practical implementation plan. A realistic path from today's operating model to tomorrow's, built without relying on assumptions or undocumented workarounds.

Technology should never be the starting point of transformation. It should be the accelerator of a well-designed operation. Organizations that take the time to understand their business before transforming it are the ones most likely to realize the value they expected from their investment.

The most successful transformations are not built on better software. They are built on a better understanding of how the business actually works.

Where to Start

Operational readiness is not something to assess after the platform is selected. It is the work that makes the selection and implementation succeed.

Our Technology Enablement work is built for exactly this. We help organizations assess technology, process, data, and organizational readiness, define what the business actually needs, and select the right fit, platform-agnostic, across ERP, WMS, TMS, barcode systems, robotics, automation, and AI.

A Technology Readiness Lab gives leadership teams a structured half day to pressure-test current-state assumptions, surface the exceptions that never make it onto a process map, and walk out with a clear decision path instead of another workshop deck.

If your organization is heading into a technology transformation, the best time to find out what your process maps are missing is before your implementation partner does.

About the Author

Brent Willett is Founding Principal of Engaged SCM Inc., a supply chain advisory firm that helps asset-heavy industrial organizations make better operational and technology decisions, then shows up to deliver them.

Brent is a Chartered Professional Accountant with senior advisory experience at Deloitte and EY. He is the former CEO of Supply Chain Canada (Alberta Institute) and currently serves as a strategic advisor to the Alberta Logistics Centre of Excellence.

Connect with Brent on LinkedIn.