Why IT transformations still miss their business case, why the board has to own them, and which early warning signs every tech leader must act on.
Prefer to listen in English? You can find the English version on Spotify here:
https://open.spotify.com/episode/5OzZ1MUVwfh1TL9fDTdJjC?si=b194188c91254196
Protecting the Business Case: What 30 Years as CIO Teach About IT Transformation
Christian Graf spent almost 30 years running IT in large industrial companies: 18 years at Henkel, then as Group CIO at Schüco. He has been through global SAP rollouts, cloud migrations, M&A integrations and the arrival of generative AI. Today he advises boards and executives through his own firm, Nexus Tech&Turn Advisory (https://www.nexustechturn.de).
In Episode 19 of A Change in Conversation, Arne asks him an uncomfortable question. We know the protocol for successful IT transformation. Most programs have governance, stage gates, readiness checks and training plans, and most now talk about people as much as technology. So why do so many still fall short of their business case?
Christian's answer is more nuanced than the usual failure statistics, and more useful for anyone about to take a program live.
Why SAP and ERP transformations need the board from day one
Arne opens with a blunt challenge: is calling an ERP rollout a "business transformation" anything more than a change of label?
Christian says the label changes three things that decide the outcome: how willing the organisation is to release scarce people, the quality of the people it releases, and what it expects to get out at the end. Without that, colleagues keep doing what they are paid to do. Sales keeps selling, accounting keeps booking invoices, logistics keeps shipping. The transformation turns into a side activity, and the company pays a lot of money for old wine in new bottles.
His positive example comes from Henkel. Around 2008, business process owner organisations started to appear outside IT for the first time. Christian spent two years in California with a Henkel unit that made specialist adhesives for phones, laptops and watches. Its customers manufactured in Asia, while new products were conceived in North America. Within two years, the GEO program (Global Electronics Optimization) built a global process and system architecture for that business. It had a technology lead and a business lead working as a pair, and the division's CEO as sponsor. Christian is clear about why it worked: the sponsor was the CEO.
How delivery pressure changes what counts as evidence
Christian also describes a program where the governance was in place. The stage gates required evidence before the program could move on, and the warning signs were visible.
What gave way was judgement. When "we have to do this now" dominates, positive evidence gets overrated and negative evidence gets played down. Christian describes the balance a program needs: the transformation has to happen, but it doesn't have to happen kamikaze-style.
Training is where it showed. The business unit was in an exceptional boom, with revenue targets to hit and group leadership watching. Releasing people for training, or asking them to define future processes, was hard to justify. The program reported very high participation rates, and nobody asked what lay behind them. How good was the training? What had people learned? Were technical hurdles still open? What did the feedback say?
At the end of the transformation it emerged that the training had barely taken place. Christian calls that maximum go-live risk.
Arne adds a pattern he sees across programs: metrics chosen to keep the status light green, because nobody wants to be the one reporting amber.
What to look at after go-live
Arne takes the argument past the go-live date. After launch, most programs track login statistics. Few ask what is actually stopping people from using a system, or from using it properly.
The causes behave very differently. A tool may be too complicated or hard to access. People may lack knowledge, which extra training can fix. They may see no reason to change. Or their local manager may be signalling, openly or not, that the old tool is fine. Without knowing which applies, a program can only respond with more communication and more training for everyone. That is expensive, and it rarely reaches the resistance trigger that matters.
Customers and suppliers: the forgotten audience
Large ERP changes don't stop at the company boundary, and Christian sees this part forgotten again and again. New material codes, batch indicators or ordering processes change the work of suppliers and customers too. When nobody tells them, or tells them carelessly, the problem arrives at go-live: supplier trucks in the yard, goods receipt unable to book them in because the material numbers don't match, invoicing failing further down the chain.
Arne makes the reputational point. A single visible incident like this can become the story everyone tells about a program, whatever else it achieves.
Why business cases erode after go-live
Christian then challenges a premise of the whole conversation. In almost 30 years he has seen programs push teams to their limits, but never a company spending 200 million on a transformation and then shutting it down. Total failure is rare. Far more common is a gap between "good" and "not so good" that nobody can explain, because success was never defined.
He admits that calculating the efficiency gains of an SAP or ERP transformation is hard. Skipping it opens the door to speculation: that cost 60 million and nothing has changed. Defining the gains and then not tracking them has the same effect.
The harder part is follow-through. Transformation makes some activities redundant and puts roles into question. When the numbers are reasonably good, companies tend to shy away from the unpleasant steps that follow. Then the business case is gone, and the CIO faces the CEO's question: why are we still spending the same on IT, and why haven't we earned a single euro more?
Christian names a second pattern that is rarely said out loud. Business units sometimes use a difficult go-live to explain their own misses. Revenue fell short because the system can't do this or that. A 15-year-old Excel sheet suddenly looks better than an AI-supported process built into the ERP. These stories travel quickly and reach the board as a verdict on the program: my Head of Sales Europe tells me he can't do anything anymore.
AI adoption: the same questions, at higher speed
Christian and his team at Schüco moved early on AI. He describes how the hype first landed at board level, sometimes after a round of golf where one CEO told another how far ahead his company was. A CIO can't wait that out. You have to deliver a few simple cases early enough to stay in the game.
One of Schüco's first steps, three or four years ago, was a GPT-based dialogue model inside a protected company environment. The reasoning was practical. People would use public tools anyway, upload documents and ask for analyses, and information would leave the company. A safe tool was the minimum.
Beyond that, Christian works with five elements: technology; data, with a named owner for quality and sensitivity; governance, including legal and works council questions; education on what AI can and cannot do; and a cross-functional creative board that brings in and evaluates ideas. Which ideas get priority depends on the market. Under cost pressure, efficiency comes first. In a growth market, it is ideas that help the company grow faster than its competitors.
What to settle before the program starts
Christian closes with advice that is easy to overlook. A fundamental transformation will always disrupt normal business, and if sales can't sell, they want out as quickly as possible. Much of the groundwork can happen before the program starts: processes, data, code, infrastructure and the future operating model. Settled in advance, these shorten the program and reduce its impact on the business while it runs.
Questions to ask before your next go-live
Who in the executive team owns this transformation, and does the organisation know it?
What does our training data show beyond attendance?
Which negative evidence did we explain away at the last stage gate?
Have suppliers and customers been told what changes for them, and when?
How did we define success, and who will still be measuring it a year after go-live?
Listen to the full episode
Christian and Arne recorded this conversation in German. An AI-dubbed English version is also available: https://open.spotify.com/episode/5OzZ1MUVwfh1TL9fDTdJjC?si=b194188c91254196
About your host
Arne Kötting founded COSYN after years of seeing organisations struggle with the human side of tech change. He built the Change Playbook to codify what actually works based on 20 years of watching these patterns.
The Change Playbook is designed for IT program teams to confidently manage the human side of tech change in-house, without expensive consulting dependencies.
His conversational style cuts through complexity to reveal the fundamental principles that make tech change communication work - principles you can apply 1:1 to your own transformation challenges.
Get in touch
More podcast episodes from
a Change in Conversation
