This week I came across a paper that details the story of Lufthansa CityLine — a regional airline and subsidiary of the Lufthansa Group, operating commuter services across Europe on behalf of its parent, with roughly 300 flights per day to 85 destinations and 8 million passengers annually. The paper follows the airline's decision to introduce process mining into its ground operations and maintenance, and what it found when it finally looked at the data.
The airline had process owners with decades of operational experience. It had internal reporting systems and regular performance reviews. It had, by every conventional measure, a functioning understanding of how it operated. And yet, when the actual execution data was surfaced for the first time, the picture it revealed had almost no resemblance to the one the organization believed was true.
That gap — between how an organization thinks it operates and how it actually does — is not a Lufthansa problem. It is the central underexamined risk in every enterprise transformation project. And it is the reason so many ERP migrations, despite their scale and cost, produce so little competitive change.
The Layer That Gets Lost
In 2006, Gartner introduced the Pace-Layered Application Strategy as a framework for managing enterprise software portfolios. The model divides an organization's applications into three layers, each governed at a different rate of change.
The System of Record is the foundational layer — the ERP, the core HR platform, the general ledger. It changes slowly, for good reason. Governance requirements, regulatory obligations, and the risks associated with master data mean that stability is a feature, not a limitation.
The System of Innovation is the opposite end. Experimental, short-lifecycle applications built to test new ideas or respond to emerging market conditions. These move fast and are expected to fail often.
Between them sits the System of Differentiation — and this is the layer that most transformation projects handle poorly. These are the processes that encode how a specific organization operates differently from its competitors. They evolve at a moderate pace, adapting over time to specific customer requirements, regional realities, or operational capabilities built through years of accumulated practice.
The framework's practical implication is straightforward: not everything should be standardized, and not everything should change at the same speed. The System of Record benefits from standardization. The System of Differentiation, by definition, should not be standardized away — because the differentiation is the point.
Although almost all EA architects and business consultants are aware of this framework, most transformation projects ignore this distinction in practice.
The Lift and Shift Trap
Enterprise migrations have a structural bias toward the System of Record. Project scope is defined around data migration, module configuration, and go-live readiness. Success is measured in system uptime and cutover completion. The processes running inside the new system receive considerably less scrutiny than the system itself.
The result is what practitioners commonly refer to as lift and shift: organizational processes, with all their embedded inefficiencies and unexamined workarounds, are transferred from the old system to the new one. The infrastructure is modern. The operational reality is not. The organization has paid for transformation and received an upgrade. In some cases, that upgrade may even make things worse.
In December 2013, the Wall Street Journal reported that Avon Products spent four years and over $125 million building a global SAP-based order management system. By the company's own account, the technology functioned as designed. The pilot deployment in Canada was technically successful. What it disrupted was something the project had not adequately analyzed: the daily working reality of Avon's six million independent sales representatives.
Avon's competitive model is built on direct selling — personal relationships, in-home demonstrations, and representative autonomy. The order management process was not a back-office administrative function. It was the primary interface between the company and its sales force, composed of independent entrepreneurs for whom friction in daily processes translated directly into a decision to leave. Representatives left in significant numbers. Active representative counts dropped sharply across the Canadian market. The global rollout was cancelled.
Avon's CEO was precise in her characterization of what had occurred: "the pilot technology platform worked well... the degree of impact of change in the daily processes to the Representative was significant."
The system worked. The transformation failed because the project had treated a System of Differentiation — the representative experience and the direct selling process built around it — as a System of Record problem to be standardized and migrated. $125 million was written off. This was not a technology failure. It was a failure of process classification.
Not All Non-Standard Processes Are Differentiation
The inverse error is equally consequential, and the Nestlé USA case from the same period illustrates this.
In the late 1990s, Nestlé USA operated as a collection of largely independent brands. Each division made its own procurement decisions. The company was paying 29 different prices for vanilla from the same vendor. It maintained nine separate general ledgers and 28 distinct points of customer entry. Every factory managed its own vendor master, making volume estimation across the organization effectively impossible.
These were non-standard processes. But they were not Systems of Differentiation. They were fragmented Systems of Record — process dysfunction that had accumulated under a decentralized organizational model and been allowed to persist because no one had visibility across the full portfolio. The right decision was to standardize them, and the 325 million in savings by 2002, primarily through supply chain rationalization.
The analytical challenge that transformation projects must resolve is precisely this distinction. Non-standard does not mean differentiated. Some process variation represents competitive capability deliberately built over time. Other variation represents organizational entropy — inefficiency that has never been examined because no one had the tools to examine it. Treating the former as the latter destroys value. Treating the latter as the former wastes it.
The Nestlé case is also notable for what came after. Decades later, having learned what process invisibility costs, Nestlé has built process intelligence as a core organizational capability. As Rouven Morato, President and CRO of SAP Signavio, LeanIX, and WalkMe at SAP SE, noted in one of the episodes of the "Transformation Every Day" podcast: "Nestlé is a great example. They have now built all of their business processes — I think more than two million process steps — into Signavio. So they know exactly how the processes in their company are working. They also use process mining to get the data behind it... They have LeanIX for their entire architecture... if they want to sunset a system they know exactly which processes are affected, which process owners they need to talk to... connecting all of it brings them into a stage where they can apply any transformation extremely quickly."
The company that in 2000 could not reconcile nine general ledgers now has two million process steps mapped, full architecture visibility, and process mining running as a continuous operational function. The distance between those two states is not a technology story. It is a story about what organizations can do once they can see themselves clearly.
Why Workshops Are Not Enough
The standard method for process discovery in transformation projects is the workshop. Consultants and enterprise architects gather process owners, map workflows, document the current state, and produce a process inventory that forms the basis for migration decisions.
The limitation of this approach is not methodological. It is epistemological. Process owners describe processes as they were designed, as they are meant to work, as they are officially documented. What they do not — and often cannot — describe are the years of accumulated adaptations: the workarounds built around system limitations, the informal handoffs that developed because the official process was too slow, the regional variations that emerged to serve specific customer requirements. These are not failures. In many cases they represent genuine organizational learning. But they are invisible in a workshop setting because they exist in practice, not in documentation.
The gap between the designed process and the executed process is precisely where the System of Differentiation lives. It is where organizations have, often without deliberate intention, built capabilities that distinguish them from competitors running the same standard software. And it cannot be recovered through interviews, facilitated sessions, or process owner memory.
Process Data as Diagnostic Infrastructure
Business process management and process mining tools — among them SAP Signavio and Celonis — do not solve business problems directly. What they provide is visibility into actual process execution: the event logs generated by enterprise systems, reconstructed into process flows that reflect what happened, not what was intended.
Two cases illustrate what this visibility produces in practice across different industries and process domains.
At Lufthansa CityLine, the focus was ground operations and maintenance — processes that were understood in the conventional sense: documented, owned, and reviewed regularly. The process mining analysis produced a different picture. The most frequently express-delivered spare parts were coffee machine components — a scheduling and inventory problem that had been invisible because no one had connected delivery frequency to underlying maintenance patterns. Repair tools existed in a single set requiring transfer between hubs; the timing of these transfers was generating maintenance delays that no one had identified as a root cause of punctuality failures. Introducing a five-minute buffer into the flight schedule eliminated delay propagation across the entire operational day. By the end of 2019, Lufthansa CityLine had reduced total delay by 300,000 minutes year-over-year, improved on-time performance by approximately eight percent, and contributed to Lufthansa Group's rise from 18th to 15th in the OAG global punctuality ranking.
At Neste, the world's largest producer of renewable diesel and sustainable aviation fuel, the problem was in the Order-to-Cash process. As Nazia Kanwal, Intelligent Business Process Lead at Neste, described the situation prior to implementation: "The order-to-cash process is such a complex operation. When we were searching for process improvements, it was like trying to find a needle in a haystack. We had no real-time visibility into the end-to-end business process, and we had no KPIs to monitor the effectiveness of the process." Using Celonis, the team identified the specific factors driving invoicing lead times, established cross-divisional KPIs, and built a continuous monitoring cycle. Within six months, average invoicing lead time fell from 9.4 days to 4.2 days, producing an estimated €55 million monthly improvement in cash flow.
In both cases, the organizations were not failing. They were large, operationally sophisticated enterprises with experienced teams. The constraint was not competence. It was visibility. Neither the delays at Lufthansa nor the invoicing bottleneck at Neste were recoverable through workshops or process owner interviews. They required data.
What the Diagnostic Is Actually Looking For
The Pace-Layered model provides the analytical frame. Process intelligence tools provide the empirical input. The question that connects them is one that most transformation projects do not ask with sufficient rigor: which of our processes constitute a genuine System of Differentiation? or in other words, WHY are we the best at what we do?
The answer cannot be assumed. It cannot be derived from organizational charts or system documentation. It requires understanding how processes actually execute — where they deviate from design, where variations cluster, where operational adaptations have accumulated over time. Some of those variations are inefficiencies to be eliminated. Others are capabilities to be protected and, where possible, deliberately extended.
The distinction matters because the consequences of misclassification run in both directions. Treating a System of Differentiation as a System of Record — standardizing it in the name of simplification — removes the capability that justified the cost of the migration, as Avon's experience demonstrates. Treating a System of Record process as a System of Differentiation — preserving customizations that serve no strategic purpose — drives up implementation cost, maintenance complexity, and technical debt, as Nestlé's early experience illustrates.
Getting the classification right is not a technology problem. It is an analytical one. And it must be resolved before the migration begins, not after go-live reveals what was lost.
Conclusion
The question that opens most transformation projects is: what are we migrating? It is the wrong starting point.
The question that should precede it is: what actually makes this organization different from its competitors, and where does that difference live in our processes?
That answer is not in a consultant's template. It is not in a process owner's recollection. It is in the execution data — in the gap between how the organization designed its processes and how those processes actually run. Closing that gap, understanding it, and making deliberate decisions about what to preserve and what to standardize is what separates a transformation from an upgrade.
A newer system running unexamined processes is not progress. It is a more expensive version of the same problem.
References
- Böhm et al., "Process Mining at Lufthansa CityLine: The Path to Process Excellence," Journal of Information Technology Teaching Cases, 2021.
- Celonis customer case study, Neste, 2021.
- Kanaracus, C., "Avon Halts Work on Big SAP Implementation," Computerworld, December 2013.
- Fargreatco, B., "ERP Implementation's Failure Cases," Medium, October 2019.
- Morato, R., "Transformation is a Capability, Not a Project," Transformation Every Day, Episode 30, March 2025.