Software Defined Vehicles
Interview with Thomas Buck, ZF
“Our goal must be to end up with a single-digit number of ERP systems”
6 min
Since January 2025, Thomas Buck has been CIO at ZF, driving the German company’s IT transformation with a fresh perspective. In the following interview, he explains how he is reshaping IT, what challenges lie ahead, and why architecture plays a decisive role.
Mr Buck, you have been CIO at ZF since January 2025. How did you approach your first months in the role?
First of all, I am very pleased to have taken on this role at ZF. It is an exciting challenge for me. The smooth handover from my predecessor, Jürgen Sturm, was particularly important; without such a transition, a seamless start would hardly have been possible. At the beginning, I looked at the structures I found in place. They were fundamentally solid, but naturally needed to be tailored, to some extent, to my own profile and leadership style. In parallel, I quickly established contact with my management team and the global IT organisation. One aspect was especially important to me from the outset: maintaining an external viewpoint. I wanted to understand why things are the way they are, while also being ready to question them whenever I felt there might be a different, perhaps better, approach. Even after nine months, I consciously try to preserve this “fresh pair of eyes”. That has been, and continues to be, crucial for me.
This fresh perspective has led, for example, to a key project: “next.GenERP”, whose aim is to introduce SAP S/4Hana as the central platform. What makes this programme special?
The name “next.GenERP” may not be particularly creative, and many companies currently have an S/4 migration on their agenda – some are already in the middle of it, others have completed it, and still others have yet to begin. There is nothing unusual about that in itself. What is unique at ZF is the scale and complexity. We are talking about roughly 100 ERP systems worldwide, and not only SAP but also systems from other vendors. This historically evolved landscape, shaped by various mergers and acquisitions, brings considerable challenges. The first is the sheer number of systems. The second is the need to strike a balance between a high level of standardisation and a degree of flexibility that the individual business units reasonably require. The third is time; we must meet the challenges of transformation within an ambitious timeframe.
How did you address this challenge in concrete terms?
We adjusted our strategy. Previously, the plan was to migrate every system – SAP or otherwise – individually to S/4Hana and move it into the cloud. We have changed this approach. We are now moving all systems into the cloud – including legacy ones – and placing them on the SAP RISE platform. Even if they do not migrate to S/4 immediately, we first transition them to HANA databases. This gives us time and simplifies the management of databases and interfaces. I am also firmly convinced that the cloud gives us far better conditions for carrying out the actual S/4 transformation. We have access to different infrastructural possibilities, can use additional tools and benefit from new technologies, including AI-supported solutions such as Joule for Developers or Joule for Consultants. All of this will help us accelerate the transformation. Crucially, we also needed to establish a target architecture that all divisions could align with. Only with a shared architecture can the necessary acceptance emerge.
You have already mentioned reducing the variety of systems. What is your target figure?
Our goal must be to end up with a single-digit number of ERP systems. The decisive factor is establishing a clear standard wherever company-wide transparency and global end-to-end processes are required. Standardisation has absolute priority at those levels. At the same time, we must allow a degree of freedom deeper in the supply chain. Different business areas have specific requirements there that must be taken into account. Ultimately, system size also plays a role; an oversized system would simply introduce new complexities, which we want to avoid. That is why we are aiming for an architecture consisting of few but robust systems, capable of enabling standards without being overly rigid.
That sounds like a radical step. How did you balance standardisation with preserving local strengths?
It quickly became clear to us that this programme is not just a technological project but also a cultural one. For this reason, we completely redesigned the programme structure. Our aim was to involve the relevant stakeholders much more closely. We wanted participants not to feel like passive recipients of a project being imposed upon them, but rather to sit at the table as active co-creators who take responsibility. Only then does genuine commitment arise. This commitment is essential. We jointly defined a target architecture that everyone can support. Tacit approval is not enough; we need explicit backing to prevent the programme from stalling. Once we had established this foundation, things started to move noticeably.
This also includes a new IT architecture governance process. In future, enterprise and domain architects must approve every project. Critics might say this slows projects down…
My aim is always to increase speed, not reduce it. No one wants to introduce processes that slow us down. In fact, we spend more time at the beginning – what I call “frontloading”. But these early, deliberate architecture decisions, which require time initially, help us avoid later discussions and problems that would delay projects far more.
How does the process work in detail?
Our application landscape is highly heterogeneous and has grown over many years. The primary goal is to reduce this complexity. To achieve that, we need better architectural decisions. We must focus more strongly on platforms and move away from a pure best-of-breed logic. In practical terms, this means projects will no longer be matched with IT solutions that simply “fit somehow” into the existing architecture. Instead, architecture becomes a central decision criterion. Our process foresees that an architecture committee – organised by our enterprise architect and prepared by the domain architects – makes decisions together with business stakeholders. IT management then gives the final approval. I am convinced this will make us faster overall, as it prevents conflicts later on. I can already see examples where clear architectural steering has helped us avoid problems at an early stage.
Let us stay with the topic of architecture. It is often considered neglected. How do you ensure that architecture is taken seriously at ZF?
Architecture for us is not a side issue but a central steering instrument. Of course, we document the architecture in the appropriate tools, and we have processes to ensure this documentation is kept up to date. That is the foundation. But it is not enough on its own. Our approach goes further. We want not only to document architecture but to actively manage it. That includes identifying weaknesses and driving targeted change. It is equally important to develop an architectural target picture – a clear vision of what our IT landscape should look like in the future. This process has now begun. Documentation, active steering and a target picture together make architecture management effective.
How do you organise the interface between IT and OT in a company with around 160 factories worldwide?
I believe it is not very helpful to describe the IT/OT world in a classical pyramid, as is often done. I see it more as a table with different endpoints, each of which must be handled individually. A network switch in manufacturing requires different management from an automated guided vehicle, and that again differs from a machine connected directly to the network. For each of these categories, we need clear rules regarding where IT has management responsibility, where defined information about connected devices is sufficient, and where joint responsibility with the operational departments is required. The result is not an overly complex rulebook but a streamlined matrix with key categories and clear specifications. This creates transparency and ensures responsibilities are clearly defined – including the depth to which IT is involved and where OT retains authority.
IT is often accused of being too slow. Especially in times of AI and new tools, business units increasingly access data on their own. How do you respond to this?
Speed is a central issue for us. But speed does not arise automatically; it depends heavily on organisational structure and scalability. Organisationally, we have created structures that enable rapid decision-making: flat hierarchies, short decision paths and clear responsibilities. It is important to me that employees genuinely feel empowered. But empowerment also requires responsibility; only with clearly defined accountabilities can empowerment truly function. The second factor is scalability. A pilot project can often be implemented quickly, but rolling it out globally is complex and takes time. This is why we rely so strongly on standards and clear architectures. Only when these foundations are sound can we roll out solutions rapidly on a global scale. Both levers – organisational clarity and technical standards – are crucial to making IT faster and meeting the expectations of the business units.
In a previous interview, you said: “The more you have to save, the more IT is required.” But IT also costs money. How do you convince top management to invest in IT in times of high cost pressure?
In fact, this is less of a contradiction and more a question of prioritisation. Demand for IT projects remains high, even in difficult times. Business stakeholders are constantly looking for efficiency gains and improvements, which almost inevitably leads them to IT systems, because IT is precisely where the levers exist to optimise processes and reduce costs. Naturally, every area faces cost pressures. Therefore, selecting the right topics is essential. Business cases are decisive. Projects offering a rapid return on investment are currently receiving particular attention. My experience is that when we clearly demonstrate the concrete value IT provides – whether in savings, productivity increases or improved transparency – top management supports these investments. Our task is to deliver this evidence ever more convincingly and make IT’s value contribution visible.
