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 on the steering committee knows whether the project is on track—because the governance framework between Finance, IT, and Business was never defined.
Why Finance Transformations Succeed Technically but Fail Operationally
Most SAP and finance transformation programs 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. This is 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 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 has no role in the program. In most transformation programs, Finance sits on the sidelines—as a budget controller and data provider, not as a governance body. Finance is invited when the forecast is due, but not when architectural decisions are made. This results in system design decisions being made without a Finance perspective—and Finance having to work with a system after go-live that does not meet its control requirements.
The third gap: Decision-making structures between the project and line organizations are not defined. During the transformation, there are parallel lines 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 program 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 developed in parallel with the system. This means not waiting until after go-live to define which metrics will apply, but asking from day one how the company should be managed in this new environment. What KPIs does the CFO need? What about the steering committee? And 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 program. Finance must not only provide figures 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 is the only thing that prevents a program 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 control logic that makes the program manageable in the first place.
At Rolls-Royce Power Systems, as Senior Project Lead for Finance & IT, I established a 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 the implementation in SAP Analytics Cloud. At Mast-Jägermeister, I developed the integrated corporate planning 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.
Why steering committees often provide information rather than make decisions.
Steering Committees
How project-based business models can be managed financially.

