The myth: finance transformation is painful. The reality: it doesn’t have to be.

The biggest blocker isn’t awareness—it’s the (understandable) concern that change means replacing systems, retraining teams, and rewriting models from scratch.

Meet Aleph, the AI-native FP&A platform that quickly meets finance teams where they are, connecting the dots between existing data sources, strategy, and spreadsheets.

No rebuild. No disruption. Just unified data, automated workflows, deeper insights, and a smarter way to FP&A—delivered in hours, not months.

Secret CFO readers can try Aleph with their own data for free.

When potato-processing giant Lamb Weston printed their Q3 FY2024 earnings report on April 4th, 2024 there was a surprise or two, to say the least.

The share price fell roughly 20% on the day, after they reported a year-over-year fall in underlying sales of 12% and Earnings Per Share well below expectation. The main cause of this performance bomb? Our old friend, a botched ERP roll out.

CEO Tom Werner explained it like this:

In other words, Lamb Weston’s SAP rollout (why is it always SAP?) tipped the business into operational chaos, and the company metaphorically shit the bed financially.

They reported an estimated ‘lost sales’ impact of $135m due to failing to fulfill customer orders, and a further ~$40m of additional costs from factory downtime, customer penalties, and external advisory support.

Total EBITDA impact: ~$95m.

By my (McDonald’s) napkin math, $135m of lost sales for Lamb Weston equates to roughly 100,000 tons of raw potatoes. Illustratively, that’s enough to fill around half of MetLife Stadium in New Jersey, site of next year’s World Cup final, with spuds.

Could make things interesting:

Shareholders were pissed. Lawsuits followed. Investors argued management had underplayed the risks of the ERP rollout. The ERP implementation program had started the year previous with the corporate center (that’s the easy bit) and, until the Q3 shock, had not disclosed any major issues.

But before you start gnashing your teeth and saying “how could this happen” and assuming you could do better, let’s do some more napkin math:

Lamb Weston processes roughly 250 potatoes per second. Or about 12,500 French fries. All flowing through a tightly coupled, deeply interdependent supply chain.

To put that in context, imagine 250 M134 miniguns (which fire ~50 rounds per second), all loaded with very similar but non-identical French fries. All firing continuously, 24/7. And then being told you have to account for every single one.

The processes required to manage that volume didn’t appear overnight. They evolved organically over decades. Tweaked, patched, stress-tested, and hardened in small increments at each stage.

Then along comes an ERP transition that attempts to rewrite every one of those processes from the ground up. All at once. All synchronized. Every operator’s role changes simultaneously, across thousands of people and several locations.

Now add chilled and frozen supply chains. Different potato varieties. Different specifications. Different shelf lives. Different weights. No two potatoes are identical. You thought that was just snowflakes?

Blink for a millisecond and you drop the ball.

Still think you could do better?

CFO at the time (and current) Bernadette Madarieta has a rock-solid résumé by any measure, coming up through the food industry. Lamb Weston does not struggle to attract high-quality finance talent. I’ll bet there were very smart people working on that rollout. Much smarter than me.

In the same earnings call, Tom Werner said:

The board and the auditors had enough confidence that the issues were temporary that they did not trigger a material weakness or undermine internal control disclosures.

Which is actually pretty impressive as a reaction. Given the level of operational chaos during the quarter, restoring control that quickly is no small feat.

The takeaway here isn’t that Lamb Weston screwed up (although they definitely did).

It’s that ERP rollouts are brutal, especially in businesses that move physical products. In my view, they sit right at the top of the Everest of CFO responsibilities.

They’re not as sexy as ringing the NYSE bell at an IPO, or pulling off a big exit. But done well, they can be just as valuable.

A well-implemented ERP is a selfless gift from leadership that can last decades. Not just because of the system, but because of the painful, necessary process and cultural change that comes with it.

I’ll bet a hedge fund could build a very uncomfortable but profitable thesis simply by shorting companies at the start of major ERP rollouts. (And maybe going long again once the rollout is done.)

This is not investment advice, btw.

This week, we dive into the most clutch moment of any finance transformation program. The point where you replace a major piece of the CFO tech stack.

The SaaS era has created an explosion of CFO tech products. There are literally thousands now. That’s mostly a good thing. It means we can combine highly specialized software to fit what we actually need.

Take cap table management. Tools like Carta are critical for VC-backed companies with hundreds of private shareholders, employees with different vesting schedules, strike prices, and grant histories. For most other businesses, they’re largely irrelevant.

With that in mind, I want to put a clear scope around what follows in this piece.

This isn’t about every new finance tool under the sun. It’s about major platform shifts. The riskiest rollouts. The ones that touch large parts of the organization and materially change how finance and the business operates.

Today, I think about the CFO tech stack in six layers.

One caveat. This definition won’t age well. The sixth layer is already eating its way into the other five. Layer two keeps creeping into layer one. The boundaries are blurring. We need to let this play out a little more before I make a bold prediction for the future of the CFO Tech stack. Anyone who says today they know what this looks like in 5 years is hallucinating.

There are, of course, other specialist parts of the CFO tech stack. Tax systems. Cap table tools. Treasury point solutions. These tend to be ringfenced to specific parts of the function and don’t cut across the business in the same way. I’d put them in a much lower risk category than anything sitting in layers one to six.

Put bluntly: screw something up in layers one to six and you can create serious business consequences. Screw up your cap table or tax software and you’ll cause a major headache for a small group of people, but you won’t stop the business from operating or making decisions.

One final note. I’ve deliberately avoided the term ERP above. In theory, ERPs promised to do all of this and more. In practice, that rarely happened. “ERP” is a vague label that can mean anything from layer one alone to a sprawling attempt to cover most of the stack. It’s not precise enough to be useful here.

Crudely I think about it this way:

Finance Tech Roll Out Difficulty = Technology Specific Risk ÷ Cultural Readiness

It’s not something I measure precisely. It’s a mental model. But it’s a useful way of thinking about how hard a rollout  can be.

Last week, we spent time on building cultural readiness; the denominator in the difficulty equation. Now, let’s get into thinking about the risk specific to a particular technology change.

Here are eight parameters to frame technology-specific risk.

Naturally, the higher the difficulty, the higher the cost.

And I don’t mean the cost of the software. I mean the cost of distraction. The risk of losing control. The risk of a stadium full of potatoes…

That will cost far more than the software (and even more than the $3,000-a-day implementers) every single time.

The higher the cost, the stronger your business case needs to be.

If you’re forcing a high-complexity ERP rollout onto a business with low cultural readiness, it’s usually only justified if the business will break if you don’t. You’ve hit a volume ceiling. The platform is actively constraining growth. Or it’s genuinely end-of-life. Not the “out of support” argument IT sometimes uses prematurely to justify CapEx, but actually the end of the road.

In those situations, no neat benefits case will make the risk feel comfortable. You’re choosing the least bad option.

But if cultural maturity is higher and the tech specific risk is lower, the bar drops. The disruption risk is smaller. The decision is easier. And the odds move back in your favor.

But the truth is, no finance platform rollout is ever easy.

I don’t claim to have “best practice” here. I’m not even sure it exists. What I do have are scars. And from those, here are seven CFO tech stack upgrade lessons I learned the hard way.

For the CFO, there is no hiding from the outcome of a major system upgrade. These rollouts carry real career risk.

Your vendor won’t save you. Neither will your implementation partner. They sell software seats and implementation hours. Sure, they’d prefer a good outcome they can put in a case-study deck.

Never assume it will “just be ok”. In a high-risk rollout, especially one that replaces the system of record, it almost certainly won’t be unless you brute-force it to work.

And once you fall behind, it’s hard to catch up. So don’t let it happen. Don’t drift. Don’t miss steering committee meetings and project updates.

You CANNOT outsource the accountability and governance for a project like this.

Great project management is beautiful to watch in action. It’s a skill to be admired.

Great PMs can break down actions, personalities, interdependencies, challenges, costs, resourcing requirements, etc. into a clear plan for the project team and steering committee.

The Project Management Office (PMO) will be the driving force for a project when the going gets tough. Even if it’s only one person. They’ll be constantly identifying roadblocks, their root cause, and unblocking them.

Project management is a discipline in its own right. And not something for someone to manage off the side of their desk. Your PMO doesn’t own any actions themselves beyond making sure everyone else is doing theirs (and reporting the results).

ERP implementations touch everyone eventually. If you use technology at work and your company is changing ERP, it will affect you in some way.

The real danger is that everyone ends up “half pregnant” on the project. Not close enough to move it forward, but distracted enough to damage the day job.

To avoid that, you want a barbell.

At one end is the implementation team. They need to be full-time. One hundred percent focused on the rollout. These should be people with real tribal knowledge of the business, the ones who know how things work. Take them out of their day jobs and backfill them properly.

At the other end is everyone else. Their job is to keep the business running with as little disruption as possible until it’s time to engage them properly.

I learned this the hard way. Early in my career, I watched a whole business use the day job as an excuse for doing a terrible job on the implementation, and the implementation as an excuse for dropping balls in the day job.

For serious rollouts you need to take your best people out of their day jobs to work on it. Sounds extreme, but who better to write the future design of your finance operations? What could be more important?

An audit mindset helps enormously in a system rollout. You need someone whose job is to chase exceptions, edge cases, and reconcile items. Letting these issues go unresolved will fester and breed like bacteria in the new system, undoing all the hard work.

If you have an internal audit function, use it. Have them play man-to-man defense on the key choke points in the project. Make sure everything ties through and that no critical controls have been missed. In my most recent ERP rollouts, I’ve made it a habit to have internal audit review the balance sheet at GL-code level, month by month, before, during, and after the rollout. It stops issues building up. Don’t ask me how I know.

If you don’t have an internal audit function, appoint someone who isn’t emotionally invested in the rollout and isn’t living it day to day. A strong controller or financial accountant is ideal. Their instinct is to test, challenge, and find what’s wrong.

And if you don’t have that capability in-house, hire it in. This doesn’t require a Big Four logo. You can find capable people on platforms like Upwork. The cost is trivial compared to the downside.

Experience is a cruel teacher. On one treasury system rollout, internal audit spotted a backdoor that would have allowed unauthorized payments. Everyone else missed it. Had that gone live, it could have been a disaster.

Any system (with the exception of AI) is just tables of data smashing into each other at different angles. Charlie Munger said if you mix raisins with turd, what you have is a turd. In this analogy, raisins are the shiny new system, and the turd is useless data.

Good data hygiene at the master data and metadata level is the key input. It’s hard to get right, but it’s 100x easier than trying to fix it once you are live.

Also, if you do need some different taxonomy for master data or coding, doing it before you go live means you can test that new data structure against a familiar system.

This is not just a problem reserved for accounting. FP&A tools are full of important relationships and mapping tables too. FP&A that runs seamlessly out of the accounting function is the best kind… it doesn’t happen by magic.

A great transformation program will focus on data hygiene and governance long before it’s writing any new system specifications.

Everyone thinks their business or department is special in some way. And therefore needs custom code.

In reality, most businesses can survive perfectly well with off-the-shelf finance software, provided that they:

Everyone has a reason why their business is “different.” Ninety-nine percent of the time, that uniqueness is in the combination or sequencing of fairly standard processes, just executed really well.

That said, there is usually something genuinely unique in the middle. Your business’s equivalent of the Colonel’s blend of eleven herbs and spices.

If you do end up developing something bespoke and moving away from off-the-shelf products, make sure:

I’ve been kicked on the shins by this before. In the integration project I mentioned in week one, the acquired business had custom code baked into its ERP from a rollout ten years earlier. Because of that code, we couldn’t change the year-end to match our own. We eventually had to outsource the fix at a cost of over $500k. Just to change the f*cking year-end date in the system.

That’s the hidden interest rate on “special.”

The organizational load on finance, and the business around it, is huge during a major system change. You have to pick your moment carefully.

Projects like this almost always involve delays and tricky timing decisions. How milestones fit around the finance calendar. Close cycles. Budget season. Audit. All of it matters. There are good delays and bad delays.

Holding off six months because you’re strengthening the team, improving data governance, and building capacity, is a good delay.

Letting the project drift because everyone is too busy to think about it, while quietly moving six months closer to obsolescence, is a bad delay.

Pick your moment deliberately. Then execute hard against it. These projects are massively distracting. You want the door open and shut as quickly as possible, only when the time is right..

Leading major system change as a CFO is one of the toughest and least glamorous responsibilities we have. But done well, your team will emerge stronger, more capable, and more energized. But they’ll probably need a long vacation to recover.

Systems are the glue that hold transformation in place. In the final week, we’ll talk about how to make sure that transformation actually lasts after the project has finished.

:::::::::::::::::::::::::::::::::::::::::::::::::::
:: Thank you to our sponsor ::
:: Aleph ::
:::::::::::::::::::::::::::::::::::::::::::::::::::

If you enjoyed today’s content, don’t forget to subscribe.

Disclaimer: I am not your accountant, tax advisor, lawyer, CFO, director, or friend. Well, maybe I’m your friend, but I am not any of those other things. Everything I publish represents my opinions only, not advice. Running the finances for a company is serious business, and you should take the proper advice you need.