Background

I worked on a large-scale systems transformation program inside a large organisation. Over time, the organisation had grown into a patchwork of businesses, each with its own systems, processes and ways of working.

In many ways, the businesses still operated independently. They used different systems, followed different processes and managed information in different ways. This made it difficult to connect information and see what was happening across the organisation. What should have been one connected business was operating more like a collection of separate businesses.

Finance felt the impact daily. Multiple finance systems and different charts of accounts made reporting and consolidation difficult. Budgeting and forecasting relied heavily on spreadsheets, while fragmented customer, supplier and payment processes created significant manual effort and control challenges. Information had to be pulled together, reconciled and manipulated before it could be used. Teams spent too much time processing transactions and producing the numbers rather than understanding what they meant.

But this wasn't only a Finance problem. The business needed to see what was happening across the entire supply chain, from customer through to operations and Finance. When information sits across multiple systems, getting that complete picture is difficult.

The transformation was designed to change that. The aim was to simplify how the organisation worked, better connect the businesses and create a common systems and process foundation that could support future growth.

The problem

For the finance team, the key issues included:

• Multiple ledgers. Multiple systems, different charts of accounts and inconsistent master data made reporting, reconciliation and consolidation difficult.

• Manual planning and reporting. Budgeting, forecasting, consolidation and management reporting relied heavily on spreadsheets and manual data manipulation.

• Fragmented customer processes. Customer accounts were spread across multiple systems, making it difficult to see a single customer position, manage credit consistently and allocate receipts accurately.

• Inefficient supplier and payment processes. Multiple systems and incomplete end-to-end automation meant AP still required significant manual intervention, increasing processing effort and the risk of payment errors.

• Limited access to data. Fragmented systems made it difficult to create a single source of truth or provide deeper analysis.

• Inconsistent processes. Finance processes varied between businesses, with different workflows, approvals and ways of working creating additional complexity.

• Too much effort producing information. Finance teams spent significant time gathering and manipulating data rather than analysing performance and supporting decisions.

What we wanted to achieve

The goal was a more integrated and scalable business, supported by simpler processes, better information and modern technology.

For Finance, that meant:

• Standardised and simplified processes

• Fewer, better integrated systems

• More automation with stronger controls

• Better planning, forecasting and scenario analysis

• More capacity for business partnering and decision support

Ultimately, Finance needed to spend less time producing information and more time understanding performance and supporting the business.

What I learned - Transformation starts before implementation

One of my biggest takeaways was that many of the decisions that determine the success of a systems implementation need to be made before detailed system design begins.

A new ERP forces an organisation to answer fundamental questions about how it wants to operate. Leave those questions unresolved and they become implementation problems, creating delays, compromises, customisation, rework and additional cost. Some of the highest-value transformation work happens before implementation begins.

1. Start with how the organisation needs to operate

Before designing the system, be clear about how the organisation wants to operate in the future. Which activities should be common across the business? What should remain within individual businesses? Where should responsibilities sit? How should customers, operations and the supply chain work together? These are business decisions, not system decisions.

They also shape how Finance needs to operate. Decisions about the broader operating model flow through to Finance, including which activities should be centralised, where Finance teams should sit, what capabilities are needed and how Finance supports the business.

If these questions aren't resolved early, they don't disappear. They become implementation issues. System design can stall, different parts of the business can push for different solutions, or the technology can end up reinforcing ways of working the organisation was trying to change.

Technology should enable the operating model, not determine it.

2. Treat data as a transformation workstream

Don't leave data until migration. Start cleansing early. Identify ownership, establish standards and put clear data governance in place.

This becomes particularly important when years of working across different systems have created different definitions, structures and versions of the same data. Moving everything into one ERP doesn't automatically create one source of truth.

Poor data creates problems everywhere. It affects system design, migration, testing and reporting, and can consume a significant amount of time fixing issues that could have been addressed earlier.

Good data is foundational to a successful implementation.

3. Review policies and processes before configuration

A new system often exposes policies and processes that have evolved over many years without being reconsidered. Delegations of authority, procurement and credit policies, security models, approvals and financial controls all influence system design. Use the transformation to challenge how things are done today.

Avoid automating an inefficient process simply because that's how it works today.

4. Resolve enterprise structures early

Legal entities, business units, regions, cost and profit centres, and reporting hierarchies affect almost everything that follows, from configuration and master data to security and reporting.

These decisions can look like technical design questions, but they're really business decisions. How you structure the organisation determines how transactions are processed, how performance is reported and ultimately how management sees the business.

If those structures aren't agreed early, they can hold up design and create significant rework later. They need genuine business input and can take much longer to resolve than expected.

5. Simplify the landscape before you migrate

Don't move unnecessary complexity into the new environment. Review bank accounts, master data, interfaces, reports and legacy applications. Decide what can be consolidated, standardised, retired or simplified. Be clear about what needs to remain outside the ERP and how it will integrate. Every system you retain creates another dependency that needs to be designed, tested and supported.

The objective isn't to connect the new ERP to everything that existed before. It is to simplify the overall landscape.

6. Adopt standard wherever you can

One of the easiest ways to recreate legacy complexity is to customise the new system around existing ways of working.

Start with standard functionality and challenge the need for exceptions. Standard processes are often based on established best practice, so the question shouldn't always be “How do we make the new system work like we do today?” Sometimes the better question is “Why aren't we working the way the standard system is designed?”

Customisation also has a longer-term cost. The more you move away from standard, the more you have to maintain, test and potentially rework when the system is upgraded. What looks like an important requirement during implementation can become years of additional complexity and support cost. That doesn't mean never customise. Some requirements genuinely differentiate the business or are necessary for regulatory, customer or operational reasons. But exceptions should have a clear business case.

For S/4HANA, principles such as fit-to-standard, clean core and "adopt, don't adapt" help maintain that discipline: use standard functionality wherever it works, and customise deliberately where it genuinely adds value.

7. Put your best people on the program

A major transformation needs more than implementation expertise. It needs people who understand how the business actually works, including its customers, processes, data, controls and the practical issues that aren't always documented.

That often means taking some of your strongest people away from their day jobs and putting them on the program. It can be difficult to release them, particularly when the business still needs to operate, but leaving that knowledge outside the program creates a much bigger risk. Decisions get made without enough business context, requirements are missed and problems aren't discovered until testing or, worse, after go-live.

Be realistic about capacity. If key people are expected to deliver a transformation while still doing their full-time roles, something will eventually give. Backfill roles or bring in additional support where needed so people have the capacity to contribute properly.

Experience also matters. If your organisation hasn't been through a major implementation before, bring in people who have. They can challenge assumptions, recognise problems earlier and help the business avoid expensive mistakes.

8. Treat change and leadership as part of the implementation

Change management shouldn't begin shortly before go-live. Transformation changes processes, responsibilities and controls, and not everyone will welcome those changes.

One of the biggest lessons for me was how much time and program capacity can be lost when resistance isn't addressed early. A small number of influential people or process owners can delay decisions, challenge agreed ways of working and prevent the program from moving forward. What can initially look like a change management issue can quickly become a significant cost and delivery issue.

This is where leadership matters. Senior leaders need to actively support the transformation, reinforce agreed decisions and step in when resistance begins to affect delivery. People should have a voice in the design, but once decisions are made, there needs to be clear accountability for moving forward.

Involve key users throughout design, testing and readiness so practical issues are identified early and people understand not only how the new system will work, but why the organisation is changing.

Unresolved resistance has a real cost: more rework, more time and more money.

The bigger lesson

Successful systems transformation isn't primarily about technology.

Technology is the enabler. The harder work is deciding what the organisation is trying to achieve, how it should operate, which processes should change, how information should be structured, what data can be trusted and how people will work differently.

Done well, a new ERP can provide powerful new capability. But without the groundwork, it can also become an expensive way of recreating the problems you already have. Whatever the size of your business, the principle is the same.

The best systems transformations start before the technology does. Get clear on how you want the business to work, then use technology to make it happen.