Why Do End-to-End Process Reengineering Projects Fail? —— Three Structural Reasons and Four Pre-Project Thresholds

A manufacturing company's quote-to-cash cycle is 42 days, compared to the industry benchmark of 18 days. To address this, they initiated a Business Process Reengineering (BPR) project: 20 people from eight departments worked for six months, revising 137 pages of process documents and introducing three new mechanisms—process owners, process KPIs, and process audits. On the project's acceptance day, the cycle was measured at 39 days. The following year, they hired external consultants to make another round of changes, reducing the cycle to 38 days.

After two years, two rounds, and several million dollars, the cycle only improved by 4 days. This is not a matter of poor execution—the project team worked hard, held dozens of meetings, and produced documents even more neatly than the consulting firm's templates. The problem lies in three structural design issues that were not addressed before the project began.

Conclusion first: The failure of end-to-end process reengineering is often not due to "insufficient changes," but rather to three structural misjudgments—drawing the boundary within departments, not adjusting the evaluation, and lacking a process owner. Any of these issues, if left unaddressed, will result in a faster rebound, the more resources are invested. Below, we will break down the three reasons and provide a table of thresholds that must be cleared before the project starts.

1. First, Recognize What Failure Looks Like: Three Measurable Signals

Before discussing the reasons, it's important to confirm whether your project is already in the failure zone. The failure of process reengineering is not "the project being canceled," but rather "the project being accepted on schedule, bonuses distributed, and then nothing changes." Here are three signals:

• Cycle Time Stagnation. Six months after reengineering, the end-to-end cycle time improvement is less than 10%. The passing line is 20%, and the healthy range is 30% to 50%.
• Fewer Steps, Same Number of People. Approval nodes are reduced by 30%, but the number of people and overtime hours in each department remain unchanged. This indicates that the reduced steps are only on paper, and the workload remains the same.
• Elastic Band Effect. Within 12 months after acceptance, the actual practices revert to the original state by more than 60%. The documents are still there, but people no longer follow them.

Among these three signals, the third is the most critical. It indicates that the process was never truly implemented, but merely obscured by the project team's reports.

2. Reason One: Boundaries Drawn Within Departments, End-to-End Becomes "Departmental End-to-End"

True end-to-end processes are defined by deliverables: starting from when the customer places a demand (or an order is placed) and ending when the customer signs off on payment (or the material is used by the downstream production line). However, most so-called "process reengineering" projects define their start and end points by organizational structure—because the project is initiated by a specific department, the budget is allocated to that department, and the boundaries are naturally drawn at the department's doorstep.

A typical example: a "procurement process reengineering" project is reduced to "simplifying internal approvals within the procurement department." Approvals are reduced from seven levels to three, and purchase orders are placed two days faster. However, the supplier's delivery delay, incoming quality control (IQC) nonconformities, and payment disputes—all of which constitute the bulk of the cycle time—are left outside the scope.

To judge whether the boundaries are drawn large enough, consider three metrics:

• Number of departments involved ≥ 3
• Number of KPIs affected ≥ 2 (i.e., the success or failure of the process requires at least two departments' indicators to improve simultaneously)
• Number of system switches ≥ 1

If fewer than two of these metrics are met, it can be concluded that the project is not end-to-end but merely a departmental process optimization. The benefits of departmental optimization are limited, typically only 1/5 of those from an end-to-end reengineering.

Another practical method is to draw the process flow diagram and check if the downstream or customer role is included. If the entire diagram consists of internal positions and does not show the "customer sign-off" step, the boundary is too narrow.

3. Reason Two: Process Changed, Evaluation and Authority Not Adjusted

Process defines "who does what when," while evaluation defines "what benefits I get from doing it." As long as these two are not aligned, people will follow the evaluation, and the process documents will become mere decorations—this is not a matter of employee non-cooperation but a rational choice.

A real-life counterexample: a company changed order modifications to "one-time entry, network-wide sharing," eliminating four transmission steps and theoretically reducing the response time from three days to four hours. However, the sales department's evaluation still included "timely order placement," and modification orders were counted in this metric. As a result, salespeople simply stopped modifying orders in the system and instead called the production department directly. System statistics showed a 70% reduction in modification orders, making it appear that the process was well-executed; in reality, the modifications continued, just moved from the system to phone calls, making the response time even less predictable.

This is the most hidden failure of process reengineering: the data looks better, but the business does not improve.

The criteria can be quantified: for every approval step canceled in the reengineering plan, there should be a corresponding departmental KPI canceled or adjusted. If the ratio of canceled steps to adjusted KPIs is less than 1:0.8, the changes are insufficient. This ratio can be calculated during the plan review, without waiting for the implementation.

Another passing line: within three months after reengineering, the "bypass rate" (the proportion of business completed through phone calls, emails, or paper forms) should be reduced to below 10%. If the bypass rate does not decrease, it indicates that the evaluation is still driving the old practices.

4. Reason Three: No Process Owner, Project Team Dissolution Leads to Rebound

Process reengineering is typically driven by project teams. These teams have goals, budgets, and weekly meetings, which enable them to drive changes. However, the day the project team is dissolved is also the day the process starts to revert—because the end-to-end cycle is not included in anyone's performance metrics.

Department managers' KPIs focus on departmental output, cost, and delivery time, with no one responsible for the total "quote-to-cash" cycle. Once the project team, which serves as a temporary arbitrator for cross-departmental coordination, is disbanded, the practices revert to departmental negotiations.

The criteria are straightforward: is the end-to-end cycle included in a specific position's performance metrics, and is its weight at least 15%? The name of the position, whether it is called "process owner" or not, is less important than whether the person has at least two of the following powers:

• Decision-making authority to change process nodes (no need to report to a committee every time)
• Influence over cross-departmental resource allocation (affecting others' production schedules and manpower)
• Veto power over the quality of upstream deliverables (ability to reject nonconforming inputs)

Giving a title without the corresponding authority will quickly reduce the process owner to a mere progress chaser, and by the third month, no one will answer their calls.

5. Four Pre-Project Thresholds

Combining the three reasons above with a commonly overlooked prerequisite, we can create a table to be reviewed at the project initiation meeting. All four thresholds must be cleared before the project starts. If any one is not met, address it first—do not bypass it with a "fix as we go" approach.

The fourth threshold deserves a special mention. Many "reengineering" projects should actually be "standardization" projects: if the same process varies by more than three steps across different factories or product lines, and these variations are not due to customer requirements, then it is a standardization issue, not a design issue. Standardize the practices first, then redesign—reversing this order will result in a mismatch of data when the new design is implemented, leading to the creation of another Excel sheet at headquarters. This pitfall has been detailed in Process Standardization Must Precede System Implementation (16.1.2), with the same logic.

6. If You Must Proceed, Follow This Order

1. Define Deliverables and Draw Boundaries. From customer demand to customer sign-off, mark the number of departments involved and the number of KPIs affected on the diagram.
2. Observe the Real Process, Not the Process Documents. Reconstruct the actual path from system logs. The real process often differs from the documented process by 30% to 50%. For methods, see How Far Off Is the Process Flow from the Real Process? (16.1.1).
3. Identify Breakpoints and Measure Handovers. Statistically determine the proportion of handover waiting time in the total cycle. Below 30% is healthy; over 50% indicates the problem lies in departmental interfaces, not in the steps themselves—optimizing job actions at this point is futile. These breakpoints are categorized by location in Seven Breakpoints in the Order-to-Delivery Process (16.2.1).
4. Pair Step Deletions with Evaluation Adjustments. For each approval step deleted, simultaneously cancel or adjust a departmental KPI. See the three-step method for reducing steps in Why Do Approval Flows Keep Getting Longer? (16.1.2). Do not delete steps that cannot be paired; they will grow back.
5. Appoint an Owner and Include the End-to-End Cycle in Their Performance Metrics. The weight should be at least 15%, and the owner should have at least two real powers. Without this step, the first four steps will only be temporary states during the project period.

As for which steps should be automated by robots and which should not be touched, that is the next step in this chain. See Three Types of Nodes Suitable for RPA Automation and Four Types That Must Not Be Automated (16.1.4). The order cannot be reversed: implementing automation without a smooth process is equivalent to solidifying chaos.

In a Nutshell

The success or failure of end-to-end process reengineering is largely determined before the project starts—boundaries must span three departments, evaluations must align with process changes, and the cycle must be included in an individual's performance metrics. If any of these three elements are missing, the result will be a more aesthetically pleasing process diagram. The criteria are simple: the number of departments involved should be at least three, the ratio of canceled steps to adjusted KPIs should be at least 1:0.8, and the owner's performance weight should be at least 15%. If all three criteria are met, then discuss the investment; if not, clarify the boundaries and evaluations first, which is much cheaper than hiring consultants.

This article belongs to the "Digitalization and AI Zone · Process Digitalization" section, targeting operations and process managers, and does not involve quality management system clauses.

Knowledge code: 16.1.3 Version: v20261031 Author: QTank