Leading a finance transformation

# Leading a finance transformation

In 2018, General Electric's new CFO inherited a finance function that could not produce a reliable consolidated cash forecast across its industrial businesses. The technology wasn't the constraint, GE had spent hundreds of millions on ERP consolidation. The constraint was that 700 finance professionals across dozens of legacy business units had each built their own definition of "free cash flowfree cash flowFree Cash Flow is the cash a company generates from operations after funding the capital expenditures needed to maintain and grow its asset base.View full definition →," their own reconciliation habits, and their own reasons to distrust the corporate number. The transformation didn't fail because the target operating model was wrong. It stalled because the people who had to live inside it never believed in it.

This is the pattern you must internalize before you touch a single system diagram: finance transformations are not systems projects with a change-management component. They are change-management projects with a systems component. The CFO who reverses that ordering, who treats adoption as a downstream deployment task rather than the central design problem, will join the roughly 70% of transformations that consultancies quietly log as underperforming against their business case.

Why transformations fail on adoption, not design

The design of a target operating model is the easy part, and that is precisely the trap. Any competent advisory team can produce a defensible future state: a global process owner model, a shared-services or GBS footprint, a cloud ERP, an analytics layer, a redrawn RACI. These artifacts are convergent, most well-run companies end up in roughly the same place because the economics point there. Design is a solved problem.

Adoption is not solved because it is not an engineering question. It is a question of incentives, identity, and trust, and those variables are specific to *your* organization's history.

Consider what actually happens when a new close process goes live. The controller in a regional unit has spent fifteen years building a reputation on hitting the close deadline. Her personal credibility, the thing that gets her promoted, the thing that lets her sleep before quarter-end, is tied to a manual workaround she perfected. Your new automated flow makes that workaround obsolete. On paper this is progress. To her, it is a threat to the one system she trusts. So she runs the new process *and* her shadow spreadsheet in parallel "just to be safe." Multiply that by 400 people and you have a transformation that went live on schedule and changed nothing.

Adoption failure has three recurring signatures the CFO must learn to detect early:

• Shadow systems persist. The clearest leading indicator. If people are still maintaining the old spreadsheet three months post-go-live, they do not trust the new one, and no amount of training will fix a trust problem.
• Compliance without conviction. People follow the new process only when watched. The workflow is technically adopted but produces no behavioral change in judgment or speed.
• Data distrust at the top. The single most corrosive failure. If the CFO and the CEO still ask for the "real number" outside the system, they have publicly declared the transformation a fiction, and the organization will follow their lead within a week.

The strategic implication is uncomfortable: you can spend 80% of your budget on design and deployment and still lose, because the 20% you underfunded, the human adoption work, is where the value actually converts.

The adoption-first transformation architecture

Reframe your program around a simple principle: every design decision is also an adoption decision. Here is the architecture that operationalizes it.

Sequence for belief, not for logic

The classic mistake is to sequence the roadmap by technical dependency, infrastructure, then data, then process, then reporting. This is logically correct and psychologically fatal, because the organization waits eighteen months for anything it can feel.

Sequence instead for *visible wins that build belief*. Find a process where the pain is universal, the fix is achievable in one quarter, and the beneficiaries are influential. Account reconciliations are a classic choice: everyone hates them, automation delivers fast, and the people freed from drudgery become your evangelists. You are not optimizing for the largest NPVNPVNet Present Value is the sum of an investment's future cash flows discounted to today, minus the initial outlay. A positive NPV signals value creation.View full definition → in the first release. You are optimizing for the fastest accumulation of internal credibility, which is the currency that funds the hard releases later.

Build a coalition, then a plan

You already know from the leadership fundamentals that authority is not the same as influence. In a transformation, the specific coalition you need has three roles:

• The sponsor with skin in the game, ideally the CEO or COO, whose visible dependence on the new numbers makes distrust unaffordable for everyone below.
• The respected skeptic. Identify the most credible senior person who thinks this will fail, and put them on the steering committee. Converting your loudest internal critic into a co-author does more for adoption than any communications plan. If they stay skeptical, they will surface real design flaws you would otherwise ship.
• The process owners who will live in it. Not consultants, not the PMO, the people whose daily work changes. If they are informed rather than consulted, you have already lost them.

Design the incentive plumbing before the technical plumbing

Ask a brutal question of every affected role: *what does this person lose, and what do they gain?* Then make the answer explicit in how they are measured. If your shared-services migration strips a regional finance manager of a team of twelve, and their compensation and status were tied to headcount, no roadmap survives contact with that math. You must redraw the scorecard, reward process quality, cycle time, and business-partnering impact rather than empire size, *before* go-live, not after the resistance surfaces.

Instrument adoption like you instrument the P&L

You would never run FP&A without metrics. Run adoption the same way. Define and dashboard, from day one:

• Shadow-system decommission rate, the percentage of legacy spreadsheets and tools formally retired and confirmed dark.
• Self-service consumption, how many managers pull their own numbers from the new system versus requesting them from finance.
• Exception and override rates, rising overrides mean the process doesn't fit reality.
• Time-to-trust, the lag between go-live and the CEO citing a system number in a board meeting without hedging.

These are not vanity metrics. They are your early-warning system, and they belong on your steering committee dashboard next to cost and schedule.

Running the human side on monday morning

Frameworks are inert without the operating cadence that enforces them. Here is what the CFO personally owns.

Own the narrative, and make it about the work, not the tool

Your people do not get out of bed for a cloud migration. They respond to a story about what their jobs become. The transformation narrative must answer, for each finance sub-function, "what will your day look like, and why is it better?" Frame it as elevation: from reconciliation clerk to analyst, from report-runner to business partner. Then, and this is where most CFOs fail, *make the promise real by protecting the freed-up capacity.* If you automate 30% of a team's work and immediately load them with 30% more of the same work, you have taught the entire organization that transformation means "do more for the same pay," and you will never get discretionary effort again.

Absorb the fear, don't dismiss it

When the respected controller raises the shadow spreadsheet, the fatal executive move is to treat it as resistance to be overcome. Treat it instead as information. Sit with her, understand exactly which control she doesn't trust the system to enforce, and either fix the system or show her the evidence. Every legitimate fear you resolve visibly converts a skeptic and signals to the watching organization that concerns are heard, not punished. Adoption is contagious in both directions.

Redesign roles explicitly, and grieve the losses honestly

Transformation eliminates work, and often people. Pretending otherwise destroys the trust the whole program depends on. The CFO who says "no one will lose their job" and is proven wrong in month six has forfeited credibility for the duration. Be specific and early: which roles change, which are retrained, which are exited, and on what terms. Dignity in how you handle the losers of the transformation is watched intensely by the survivors, who are deciding in real time whether to invest their careers in your new model.

Set the tone from your own chair

The most powerful adoption lever you own costs nothing: use the new system yourself, in public, and refuse to accept numbers from anywhere else. The moment you ask a controller for the "real" cash figure over email because the dashboard "isn't quite right yet," you have authorized the entire organization to bypass the system. Conversely, when you run your board prep off the new platform and defend its numbers in front of directors, you have made adoption a condition of relevance. Behavior at the top propagates faster than any policy.

Judgment calls the framework won't make for you

The architecture above tells you *how* to run the program. It does not tell you *how hard to push*, and that judgment separates CFOs who transform from those who merely reorganize.

Pace versus stability. Push adoption too fast and you break the close, spook the auditors, and lose the credibility you needed most. Push too slow and momentum dies, sponsors move on, and the shadow systems calcify permanently. There is no formula. Read the organization's absorption capacity, how much change it has already digested this year, and calibrate. A team fresh off an ERP cutover cannot swallow a simultaneous operating-model redesign, no matter how elegant your roadmap.

How much to standardize. Global standardization delivers the efficiency case, but every forced standard that ignores a genuine local reality, a tax regime, a regulatory filing, a currency control, breeds the exact distrust that kills adoption. Distinguish ruthlessly between "local variation that is legacy habit" (eliminate it) and "local variation that reflects real difference" (accommodate it). Getting this wrong in either direction is fatal: over-standardize and you ship a system that doesn't work in Brazil; under-standardize and you've digitized the chaos.

When to declare victory. Transformations rarely end cleanly. The discipline is to convert the program into business-as-usual before the funded initiative expires, embeddingembeddingAn embedding is a numerical vector that represents data (text, images, or items) in a way that captures meaning, so similar items sit close together in space.View full definition → the process owners, the metrics, and the continuous-improvement cadence into the permanent finance operating model. A transformation that depends on the program office to survive was never adopted; it was merely occupied.

Key Takeaways

• Treat adoption as the central design problem, not a downstream deployment task. Every process, system, and role decision should be interrogated for "who resists this and why", before go-live, not after.
• Sequence the roadmap for belief, not technical logic. Deliver a fast, visible, painful-problem win in the first quarter to build the internal credibility that funds the harder releases.
• Fix the incentive plumbing before the technical plumbing. Redraw scorecards and protect freed-up capacity so that transformation elevates roles rather than quietly meaning "more work for the same pay."
• Instrument adoption with hard metrics, shadow-system decommission rate, self-service consumption, override rates, time-to-trust, and put them on the steering dashboard beside cost and schedule.
• Set the tone from your own chair. The single highest-leverage act is for the CFO to use the new system in public and refuse the "real number" from anywhere else; behavior at the top propagates faster than any communications plan.