Interview with Thomas Buck, ZF
“Our goal must be to end up with a single-digit number of ERP systems”
At the automotiveIT Congress, Thomas Buck gives an insight into his first months at ZF
Marko Priske
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.
