Technology transformation programs often begin with a platform decision: a new ERP system, a modern workflow suite, an AI capability, or an automation platform. However, the value of the technology will remain constrained if the business processes surrounding it are carried forward unchanged.

This is a common transformation problem: business processes are not redesigned to align with new technology capabilities. The organization replaces the underlying platform, yet retains the same approvals, manual handoffs, duplicate data entry, exception paths, and unclear decision rights that developed around the legacy environment.

The result is not a modern operating model. It is an old operating model running on newer technology.

The hidden problem: undocumented legacy processes

In many organizations, essential processes are embedded in legacy systems rather than clearly documented. The system configuration, custom reports, spreadsheets, email chains, and institutional knowledge collectively become the only reliable record of how work is actually completed.

This creates a difficult starting point for an ERP or enterprise-platform transformation. Teams may know the intended process at a high level, but not the many variations that occur in practice:

• Which team owns each handoff?
• Where are data created, amended, or rekeyed?
• Which exceptions are routine rather than rare?
• What approvals add control, and which merely add delay?
• Which workarounds exist because the legacy system cannot support the intended workflow?
• Which integrations, reports, and spreadsheets have become operationally essential?

Without answers to these questions, a transformation program has limited ability to distinguish a process that should be retained from one that should be simplified, automated, retired, or redesigned.

The issue is more consequential than incomplete documentation. It creates and sustains technology debt. Organizations bring legacy complexity into the future, making implementation slower, costlier, and riskier. They may technically go live on a new platform, while employees continue relying on offline trackers, manual reconciliations, and informal coordination to get work done.

New technology can expose old process problems

The rapid adoption of AI makes this challenge more visible, not less.

A recent TechRadar perspective argues that the concern is not simply AI creating a new form of software sprawl. In many cases, the rush to adopt AI is exposing disconnected processes and poorly integrated systems that were already present. Layering another tool onto those conditions can increase complexity rather than remove it. (techradar.com)

This is an important distinction for leaders. The critical question is not, “Where can we apply AI?” It is:

“Where does work currently experience friction, and how should the process change before technology is applied?”

When the answer is unclear, technology can automate low-value activity more quickly. It may help employees produce more outputs, while leaving unnecessary approvals, fragmented ownership, duplicated data, and unclear accountability intact.

The same principle applies to ERP transformation. A new enterprise platform may offer standardized workflows, embedded controls, better data visibility, intelligent automation, and stronger integration capabilities. Yet these capabilities cannot deliver their full value when implementation decisions are based on incomplete knowledge of the current process.

Organizations then face a familiar outcome: customization grows to preserve legacy practices. Standard capabilities are bypassed. Adoption is uneven. Expected benefits become difficult to measure.

Process redesign is returning, but it requires discipline

There is renewed interest in business process redesign as generative and agentic AI expand what organizations can analyze, model, automate, and orchestrate.

A recent perspective in Administrative Sciences frames this as a potential “translated resurgence” of business process reengineering. The original BPR label carries historical baggage, but its underlying question remains highly relevant: How should work be redesigned when technology changes the boundaries of coordination, decision-making, and execution? The article argues that generative AI can improve process discovery, modeling, explanation, simulation, and redesign recommendations, while agentic AI introduces possibilities for more autonomous process execution and adaptation. (mdpi.com)

Technology does not resolve the organizational challenges that made earlier reengineering efforts difficult. Faster process analysis can be valuable, but it does not replace governance, stakeholder involvement, sound decision rights, data quality, or change management.

In fact, AI can magnify these weaknesses if it is introduced without clarity about the process it is intended to improve.

A process that is poorly understood cannot be responsibly automated. A process with unclear accountability cannot be made effective simply by adding an intelligent agent. A process that employees do not trust will not achieve sustained adoption, regardless of the quality of the technology.

Alignment cannot be assumed

Senior leaders often agree that a transformation is necessary. They may also agree on the target platform and the high-level business case.

What they may not agree on is why the organization is changing, what specifically must change, and how the change will be governed.

Harvard Business Review recently described this as the “false alignment trap”: leaders can behave as if they share an understanding of the purpose, scope, and approach to change when meaningful differences remain unresolved. (hbr.org)

For process redesign, these differences often surface in practical decisions:

• Is the objective to standardize across business units or preserve local variation?
• Which process exceptions are genuinely required by customers, regulations, or operations?
• Who can approve a redesigned workflow?
• Are process owners accountable for outcomes after go-live?
• Will the organization change its policies and decision rights to match the new platform?
• How will leaders measure whether manual effort, cycle time, cost, risk, or service quality have actually improved?

If these questions are deferred, teams tend to replicate the familiar process. It feels safer in the moment, especially when a program timeline is under pressure. Yet that choice can reduce the value of the transformation for years.

A practical path: discover, redesign, govern, adopt

Process redesign should begin before major platform configuration decisions are finalized. A focused discovery and documentation program can create the baseline needed to make informed choices.

1. Map the current state as work is actually performed

Document end-to-end processes, including handoffs, systems, roles, inputs, outputs, data flows, process variants, exceptions, controls, reports, and manual workarounds.

This is not an exercise in producing documentation for its own sake. It is a way to make hidden complexity visible and establish a shared factual basis for change.

2. Identify accountable process owners

Every end-to-end process needs a clear owner with authority to make decisions across functions. Functional leaders remain essential, but customer and operational outcomes often depend on work that crosses finance, operations, HR, procurement, sales, and technology.

Without cross-functional ownership, local optimization can undermine the end-to-end process.

3. Redesign for the target capability, not the legacy constraint

Use the documented baseline to ask where the process can be simplified, standardized, automated, or removed.

The target should not be “configure the new platform to reproduce what exists today.” The target should be a process that makes appropriate use of the new platform’s capabilities while reducing unnecessary effort and risk.

This may mean removing redundant approvals, eliminating rekeying, consolidating reports, redesigning data ownership, or replacing manual coordination with integrated workflow.

4. Update governance and the operating model

A redesigned process will not hold if governance continues to reward siloed decisions and exceptions. Organizations should define decision rights, escalation paths, architecture standards, and change-control practices that support the new way of working.

This is especially important as AI and automation are introduced. Governance must establish where autonomous actions are appropriate, where human review is required, how exceptions are handled, and how performance is monitored.

5. Build adoption into the transformation plan

Employees need more than training on a new interface. They need to understand how their work changes, why the new process is preferable, what decisions they can make, and where they can raise concerns.

Stakeholder engagement and change management are therefore not activities to add near go-live. They are part of process redesign from the beginning.

Measure value in reduced friction

The strongest measure of transformation progress is not the number of tools deployed or workflows digitized. It is the amount of friction removed from meaningful work.

Organizations should define measurable outcomes early, such as:

• Reduction in manual touches and duplicate entry
• Fewer process exceptions and workarounds
• Shorter cycle times
• Improved data quality
• Lower cost to serve
• Better control performance and reduced operational risk
• Higher employee adoption and customer satisfaction

Technology provides new capabilities. Process redesign determines whether those capabilities become business value.

For organizations planning an ERP, enterprise-platform, automation, or AI transformation, the message is straightforward: do not move legacy processes into a modern environment without first making them visible, challenging their purpose, and redesigning them for the future.