When Digitalization Turns into a Reversal of Digitalization: A Warning from Real-World Experience

The Perfect IT Project—and Its Inglorious End

Once upon a time, there was a custom-built business application that did exactly what it was designed to do: It replaced an error-prone, Excel-based process with a robust, validated software solution. The business department had been working with it successfully for several years. Error rates dropped dramatically, the quality of data submitted to government agencies improved significantly, and employees finally had a tool that made their daily work easier rather than more difficult.

Then came the management initiative.

Under the banner of “Digitization and Consolidation of IT Systems,” the tried-and-true business application was discontinued. The process was dismantled and... [the story ends here for now, because exactly how the process was redesigned remains shrouded in the fog of strategic presentations].

This story is not an isolated case. It repeats itself in German companies and government agencies with alarming regularity. And it reveals a fundamental misunderstanding of what digitalization actually means.

The Irony of IT Consolidation

The irony of this situation is hard to beat: A functioning digital solution is being phased out in the name of digital transformation. A system that eliminated manual, error-prone processes is being sacrificed in favor of a “strategic realignment.”

Let’s take another look at the initial situation:

Before (Excel-based):

• High susceptibility to errors due to manual data entry
• Inconsistent data quality
• Risks associated with regulatory reporting (compliance risks, potential fines)
• Lack of traceability and audit trails
• Reliance on individual employees’ Excel skills
• No systematic validation

Afterward (custom business application):

• Validated, tested software solution
• Built-in plausibility checks and validations
• Reduced error rate
• Traceable processes with an audit trail
• Satisfied business users
• Compliance-compliant data submissions to regulatory authorities

And then (after consolidation):

• ???
  
  

The Three Fatal Fallacies in IT Consolidation

Mistake No. 1: “Fewer Systems = Better IT”

The equation “fewer systems = lower costs and higher efficiency” is deceptively simple—and all too often simply wrong. This line of thinking confuses quantity with quality and overlooks the actual function of IT systems: to optimally support business processes.

A specialized business application doesn’t exist just for the sake of it. It exists because off-the-shelf solutions don’t meet specific requirements. In the case described, the goal was the error-free transmission of critical data to government agencies—a process with zero tolerance for errors.

In practice, consolidation onto a “strategic” standard system often means

cumbersome workarounds for specialized business requirements, export-import-copy workflows between systems, a return to Excel as a “bridge technology” (keyword: shadow IT), or, in the worst case, a return to the original Excel chaos.

Misconception No. 2: “The business units must adapt”

A classic line from IT management: “The new system can’t do it exactly that way, but the processes will just have to adapt.” This statement reveals a fundamental misunderstanding of the role of IT.

IT is not an end in itself. IT is a means to an end. The end is to support business processes, not to hinder them.

If a line-of-business application has reliably supported a critical process for years, then that process is not the problem. The problem arises when management decisions are made out of touch with operational reality.

The question should not be: “How can we force the business units to work with our standard system?” The question must be: “How can we best support the business units in their work—even if that means running specialized solutions?”

Fallacy No. 3: “Total Cost of Ownership is automatically reduced through consolidation”

The TCO calculation for IT consolidations is often overly simplistic. It takes into account:

What’s included in the calculation:

What’s missing from the calculation:

In the case described, there is an additional, particularly critical factor: the risk of erroneous data submissions to government agencies. The custom business application had minimized this risk. What happens if errors reoccur after consolidation?

What Really Happens: The Vicious Cycle of Failed Consolidation

The typical outcome following such a “strategic” decision follows a predictable pattern:

Phase 1 – Euphoria (Months 1–3): Management presents its vision for the consolidated IT landscape. PowerPoint charts show simplified system architectures. Potential savings are quantified. The project gets underway.

Phase 2 – Disillusionment (Months 4–8): The first detailed requirements are documented. It turns out that the new system cannot, after all, do everything the old line-of-business application could. “This will have to do,” they say. Workarounds are developed.

Phase 3 – Crisis (Months 9–15): The system goes live. The business department struggles with the new processes. The error rate rises. The first critical incidents occur in regulatory reporting. Emergency meetings are called. Excel spreadsheets reappear as “temporary workarounds.”

Phase 4 – Shadow IT (Month 16+): The business department develops its own solutions to fill the gaps. Excel once again becomes the primary tool—often without IT governance, without a backup strategy, and without validation. We’ve come full circle: We’re back to the original problem, only now with an expensive off-the-shelf system on top of it.

Phase 5 – Selective Amnesia (Year 3+): No one talks about the original line-of-business application anymore. The new system is “established.” The higher error rates and the additional manual effort have become the “new normal.” The costs of consolidation are spread across various budgets and are no longer visible. The business case is no longer questioned.

The Forgotten Stakeholders: The Users

Amid all the strategic considerations surrounding IT consolidation, one group is systematically overlooked: the people who have to work with the systems every day.

In the case described, the business department had found a solution that had worked well for them for years. This satisfaction was no coincidence:

All of that was undone with the stroke of a pen—not because the system had failed, but because it no longer fit into a management strategy.

The psychological and organizational costs are completely ignored:

Loss of trust in IT decisions.
Demotivation due to forced cutbacks.
Internal resignation (“The people at the top don’t have a clue anyway”).
Resistance to future IT projects.

Better Alternatives: How Consolidation Can Work

IT consolidation isn’t wrong in and of itself. Uncontrolled growth in the system landscape is a real problem. But the solution lies not in blind standardization, but in intelligent differentiation.

Principle 1: Differentiation by Criticality

Not every application is equally important. A sound IT strategy distinguishes between:

Commodity processes (email, Office, basic ERP):

• Standardization makes sense here and saves costs
• Business requirements are minimal
• Best-practice processes are sufficient

Differentiating processes (subject-specific core applications):

• This is where customization creates real added value
• Specialized requirements are high
• Standard solutions result in a loss of quality

Critical compliance processes (such as regulatory filings):

• Here, error-free performance is non-negotiable
• Validation and quality assurance are mandatory
• The costs of flawed processes far exceed any savings on licenses

The business application in the case described clearly falls into the last two categories. Pursuing consolidation for consolidation’s sake in this context is organizational suicide in installments.

Principle 2: Calculate TCO honestly

An honest TCO calculation takes the following into account:

Direct IT costs:

• Licenses and maintenance
• Infrastructure and operations
• Support and administration

Indirect Costs:

• Process Quality and Error Costs
• User Productivity
• Compliance Risks
• Flexibility in Process Changes

Opportunity Costs:

• What could employees do if they didn’t have to struggle with poor systems?
• What innovations are being held back?
• What talent are we losing to the competition?

It often turns out that, when you do the math honestly, the small, specialized application is actually less expensive overall than the “consolidated” solution, despite higher per-user licensing costs.

Principle 3: Make a strategic decision on “Make vs. Buy vs. Configure”

A custom solution doesn’t need to be developed for every process. But at the same time, a standard system may not be the optimal solution for every process either.

Usestandard software (Buy) if:

• The process is not unique
• Best-practice processes are acceptable
• The potential for customization is limited

Configurable platforms (Configure) if:

• There are specific business requirements
• But core processes can be standardized
• Low-code/no-code platforms can bridge the gap here

Custom development (Make) if:

• Highly specific, critical requirements exist
• No standard solution meets the requirements
• The costs of errors are very high (such as with regulatory filings)
• The process generates competitive advantages

The business application described was clearly a case for “Make”—and had proven its worth.

Principle 4: Think from the user’s perspective

Every IT strategy should begin with the question: “How can we best support our users?” Not: “How can we reduce the number of our systems?”

Practical Implementation:

• Involve business units early and seriously
• Test prototypes with real users
• Jointly define acceptance criteria
• Establish a “veto mechanism” for critical functions
• Enable parallel operation until the new solution is truly better

If business units have been satisfied with a solution for years, then the burden of proof should lie with IT to demonstrate that the new solution is at least equivalent—not the other way around.

Lessons for IT Management and Digitalization Initiatives

Lesson 1: Digital Transformation Does Not Mean Standardization

Digitalization means using IT to optimally support processes. Sometimes that means standardization; sometimes it means customization. The trick is to combine the two wisely.

Lesson 2: Consolidation Is Not an End in Itself

Reducing the number of systems is not a success if the remaining systems support business processes less effectively than before.

Lesson 3: Process quality is more important than process standardization

Especially for critical processes such as regulatory reporting, error-free operation is more important than system harmony. A well-functioning “standalone solution” is better than a consolidated, chaotic solution.

Lesson 4: User Feedback Matters

If a business unit has been working satisfactorily with a system for years, that sends a strong signal. It’s risky to jeopardize that satisfaction lightly.

Lesson 5: Honest Measurement of Success

IT consolidation projects should not be evaluated solely based on the number of systems and licensing costs, but also on:

• Process quality (error rates before/after)
• User satisfaction
• Productivity metrics
• Compliance metrics
• Actual TCO over 3–5 years

Conclusion

The story of the discontinued line-of-business application serves as a warning. It shows how well-intentioned digitization and consolidation initiatives can achieve the opposite of what they set out to do.

True digital transformation does not mean cramming all processes into a standard system. It means finding the optimal solution for each process—even if that means running specialized business applications.

IT consolidation is successful when it better supports business processes, not when it simplifies the system landscape. Sometimes, a slightly more complex IT landscape with highly specialized solutions is the price to pay for excellent process quality—a price that is well worth it.

The question every management team should ask itself when undertaking such initiatives is not, “How can we consolidate systems?” The question must be, “How can we best support our business processes—and what IT landscape do we need to do so?”

In the case described, the answer was clear: a specialized business application that users had been working with satisfactorily for years. Anything else is a step backward disguised as digitalization.

This article is based on a real-life scenario and reflects a widespread pattern in German companies and government agencies. The names have been withheld because they are interchangeable—the same story plays out in countless organizations. If you recognize yourself in this article: You are not alone. And it’s not too late to change course.