Finance transformation is not an IT project

SAP S/4HANA is live. The migration is underway. The system integrators are delivering. And yet no one at Steering Committee knows whether programme is on track—because the steering logic between Finance, IT, and Business was never defined.

Why Finance Transformations Succeed Technically but Fail Operationally

Most SAP and financetransformation programmes s are set up as IT projects. There is a system integrator, a project plan, a budget, and a go-live date. The organization focuses on data migration, customization, testing, and cutover. That’s necessary—but it’s only half the story.

The other half of the question is how the company will be managed after the go-live. What KPIs will apply in the new environment? Who is responsible for the forecast—Finance or the project team? How will variances be escalated? Who makes the decision if the new process isn’t working and the old one no longer exists?

Most programs fail to address these questions—not because they are unimportant, but because no one is responsible for them. The system integrator builds the system. The PMO manages the project plan. Finance provides the numbers. But the governance architecture that holds it all together falls under no one’s purview.

The result: Technically, the system works. Operationally, however, the management system does not. The CFO receives reports that are formally correct but do not enable decision-making. The Management Committee ( Steering Committee ) meets but does not provide guidance. And six months after go-live, the Executive Board asks why the transformation is not delivering the promised results.

Three Governance Gaps That Jeopardize Every Finance Transformation

The first gap: KPI logic isn’t taken into account. In the old world, there were established metrics, established reports, and established interpretations. In the new world—with S/4HANA, SAC, and new posting logic—these metrics are no longer automatically comparable. Anyone who fails to redefine the KPI architecture in parallel with the system migration is building a system that produces data but does not enable control.

The second gap: Finance plays no role in the “ programme.” In most transformation programs, Finance is on the sidelines—acting as a budget controller and provider of numbers, not as a governance body. Finance is invited when the forecast is due, but not when architectural decisions are being made. As a result, system design decisions are made without the Finance perspective—and after go-live, Finance is left to work with a system that doesn’t meet its management requirements.

The third gap: Decision-making structures between the project and line organizations are not defined. During the transformation, there are parallel areas of responsibility—the project organization and the line organization. Both make decisions, but the interfaces between them are not clearly defined. Who decides on the chart of accounts—the project or the CFO? Who approves the planning logic—the workstream lead or the head of controlling? Without a clear decision-making matrix, bottlenecks arise that hold up the “ programme ” for months.

Thinking of Finance Transformation as a Governance Project

A finance transformation that delivers lasting results requires three structural elements beyond system implementation.

First, a KPI architecture that is built in parallel with the system. This means: Don’t wait until after go-live to define which metrics will apply; instead, ask from day one how the company should be managed in this new environment. What KPIs does the CFO need? What about the Steering Committee? What about the workstream lead? The answers to these questions determine the system design—not the other way around.

Second, a clearly defined finance governance role within the programme. Finance must not only provide numbers but also be involved in architectural decisions. This requires a role that bridges the gap between system design and governance requirements—someone who understands SAP FiCo and also knows what the CFO needs in the Steering Committee . In most programs, this role does not exist. It should exist.

Third, a decision matrix between the project and the line organization that is established before go-live—not after. Who decides which issues, at what level, and based on what data? Which decisions does the project make autonomously, and which require approval from the line organization? That sounds like bureaucracy. In practice, it’s the only thing that prevents a “ programme ” from being overwhelmed by its own complexity.

My Role in Finance Transformations

I have been working at the intersection of finance, IT, and business in SAP and finance transformation programs for over 20 years. My focus is not on system implementation—that’s what system integrators are for. My focus is on the “ steering logic,” which is what makes the “ programme ” manageable in the first place.

At Rolls-Royce Power Systems, as Senior Project Lead for Finance & IT, I established an “ project controlling ” framework based on SAP PPM and SAC and was responsible for integrating quotation, product, and financial data into SAP. At Hamburger Hochbahn, I led the finance-side support for the S/4HANA implementation—from the group-wide planning guidelines to implementation in SAP Analytics Cloud. At Mast-Jägermeister, I developed the integrated corporate planning system in SAC and oversaw the migration from R/3 to S/4HANA.

I work with companies in the DACH region, both remotely and on-site. My unique value lies in bridging the gap between technical transformation and the question of how the company will actually be managed afterward.