ERP implementation in a scale-up: why projects fail and what a CFO changes about it

Why ERP projects fail in a scale-up

A scale-up or a growing mid-sized company has no spare capacity for an ERP project. The people with the knowledge for the new system are the same people who do the month-end close, serve the customers and deal with the auditors. That is the starting position from the Diagnosis page: selection, migration or go-live tie up capacity that day-to-day business lacks, and the project threatens to fail. I see five patterns again and again.

System before process

The system is chosen before it is clear how the company should post, calculate and report. Chart of accounts, cost centres, product structure and posting logic are then decided on the side during the project, under time pressure and by the implementation partner. The result reproduces the old problems in the new system.

Uncleansed data

Master data, open items and fixed assets are taken over as they are. Duplicate customers, dead articles and wrong payment terms migrate along. At PeriGuard, data cleansing therefore came before any improvement to the ERP; without clean data every subsequent analysis is worthless.

Underestimated interfaces

CRM, bank, payroll, web shop, production planning: every interface is a small project of its own with its own test. At the automotive OEM, the challenge lay in the re-implementation of complex interfaces and the complete system change from Infor to Monitor ERP, during a massive ramp-up of production with the workforce at full capacity.

Nobody from finance leads

IT leads, the partner delivers, finance sends requirements when it has time. In the end the system keeps the books, but nobody has checked whether the first close works in it.

Wrong timing

Go-live falls into the annual audit, a financing round or peak season. Then the project collides with exactly the weeks in which the finance team is already at its limit.

What a CFO as project lead does differently

As a CFO with project management experience, I connect the functional requirements from finance and controlling with realistic implementation planning. In concrete terms:

• Process before system: chart of accounts, cost centre structure, posting logic and the reports that should come out at the end are defined before the selection. The new system has to be able to deliver the first month-end close before it goes live.
• Data first: master data and open items are cleansed in the old system, not in the new one.
• Interfaces as separate work packages with their own owner and their own acceptance test.
• Dedicated capacity: the project gets leadership that is not doing the close at the same time. That is exactly what a fixed-term mandate is built for, see Can an interim CFO lead an ERP implementation?
• Go-live by the closing calendar: on the first of a month, ideally at the start of a quarter or financial year, with the last close in the old system and the first in the new one reconciled.
• Handover from day one: process documentation and team training run within the project so that the system works without me after the mandate.

Which system fits which structure

The system question is decided by size, internationalisation and industry. From my mandates:

Further systems from earlier roles: MS Dynamics NAV, SYCOR, Infor. The list shows experience; the selection is part of the mandate.

New implementation, migration or optimisation

Three project types, three risk profiles. The greenfield implementation is the cleanest: at Fairtrade International a global cloud ERP was implemented for an organisation across many countries and the IT landscape was realigned in the process; at vialytics a full-stack ERP with Salesforce integration in parallel with two financing rounds. The migration is the riskiest, because the old system runs while the new one is being built: at the automotive OEM the migration from Infor to Monitor ERP ran in 6 months alongside input to a restructuring opinion under IDW S6. Optimising an existing system is the most underestimated: at PeriGuard, data cleansing and process adjustments in the existing ERP delivered more than a switch would have.

A realistic plan over 6 to 9 months

1. Requirements and selection: define processes, define reports, test two or three systems against real business cases, select the partner.
2. Design: chart of accounts, cost centres, master data model, authorisations, interface list.
3. Data cleansing in the old system, test migration, reconciliation of balances.
4. Build interfaces and accept them one by one.
5. Test close: a complete month-end close in the new system with real data before the go-live date is confirmed.
6. Go-live on the first of a month, hypercare, switch-off of the old system only after the first reconciled close.

What a project costs depends on licence, partner and internal capacity; what an interim CFO as project lead costs is on the page What does an Interim CFO cost?

CRM is part of it

The separation between ERP and CRM is artificial in practice: quotes, orders, invoices and revenue recognition run through both systems. At KRÜSS I was responsible as project lead for the company-wide CRM rollout from selection to go-live; at vialytics the Salesforce integration was part of the ERP implementation. Whoever dismisses the CRM as a sales topic gets the revenue figures twice later, from two systems, in two versions.