Finance IS modernisation projects are now a priority in many organisations: replacing an ageing ERP, improving the reliability of financial flows, automating close processes, improving reporting quality, or integrating the new capabilities offered by artificial intelligence and autonomous agents. And the pressure is increasing: the end of SAP ECC support on 31 December 2027, with optional extended maintenance until 2030, is forcing thousands of companies to launch a project that has been deferred for several years.
These projects represent a major challenge: according to several studies, the failure rate of ERP deployments exceeds 50%, and some Gartner estimates put it as high as 75%. But complete failure is not the only risk to consider. There is a category of issues that is far more common, and often more insidious: projects that technically “go through”, but that durably weaken the operational performance of the finance function in the months that follow.
What Finance IS projects systematically underestimate
Most ERP projects are managed from a technology angle: solution selection, systems integration, data migration, functional testing. That is legitimate. But the tensions observed after go-live rarely come from the tool itself. You think you are modernising a system, but in reality you are disrupting a critical function without really being able to measure the cost.
These tensions come from elsewhere: processes that have changed without teams being able to grasp them, internal controls that have disappeared in standardisation, financial flows that have become more opaque as they have been automated.
These risks—let’s call them post-deployment operational risks—share one common feature: they do not show up in UAT. They appear at the first real close, or during the first incident not anticipated by the procedures.
That said, these risks are not inevitable. They can be identified and, above all, managed—provided they are built into the project trajectory from the design stage.
Deterioration of close cycles
This is often the first signal. Even when the solution works properly, teams have to rebuild their operational reference points: screens have changed, master data has evolved, and some operations are performed differently in the system.
During the first closes, a significant share of time is spent understanding how flows behave, identifying the source of an entry, checking a reconciliation, understanding why an operation remains stuck in a workflow—rather than producing financial information.
This phenomenon is well documented in ERP projects. Deployment does not stop on the migration date: the first accounting close is a critical milestone in its own right, and must be anticipated with as much rigour as go-live itself.
In organisations where the reporting calendar is already tight, one or two degraded closes can quickly create tensions with senior management or shareholders, and create lasting doubt about the system’s reliability.
Internal control weakened by standardisation
Modernising the Finance IS almost always involves redesigning processes. New systems automate certain approvals, introduce different workflows, and redistribute responsibilities across teams. In practice, it is rare to be able to reproduce the existing organisation identically in a modern ERP.
Yet in many companies, a substantial part of internal control relies on operational practices built up over time: informal cross-checks, reconciliation habits, alert reflexes between teams. These practices do not appear in any project documentation.
When processes are standardised in the system, these mechanisms disappear, without necessarily being replaced by equivalents. The control framework can therefore lose robustness progressively and silently, until a significant discrepancy reveals it.
The risk is not theoretical. It directly affects the organisation’s ability to detect anomalies, justify its positions in an audit, and maintain the quality of its financial statements.
Cash tensions directly attributable to the transition phase
Post-deployment operational difficulties can have measurable effects on cash. Two mechanisms are frequently observed.
On the one hand, delays in processing supplier invoices or in internal approval workflows: DPO (Days Payable Outstanding) temporarily deteriorates, not by strategic choice, but due to a loss of process fluidity. On the other hand, delays in issuing or following up on customer invoices: DSO (Days Sales Outstanding) tightens, with direct effects on working capital requirements.
These drifts are generally not linked to a tool defect. They result from a period of team adaptation to new processes, in a context where routines have not yet been rebuilt. In organisations where cash is closely monitored—especially groups with banking covenants or explicit cash targets—a few weeks of drift can have real consequences.
Loss of financial readability of flows
This may be the hardest risk to quantify, but it is frequently cited by finance teams after a migration.
In an environment that is still partly manual, teams understand the mechanics of accounting entries: they know how a transaction translates into the accounts and how it is reflected in the financial statements. This understanding underpins their ability to analyse variances, challenge data, and detect anomalies.
With modern ERPs, an increasing share of this mechanics becomes invisible. Entries are generated automatically by system rules, interfaces between applications, and automated processing. The operation is more efficient, but also more opaque.
The result, observed in several projects: teams know how to use the tool, but their ability to read and interpret financial flows has diminished. This is not a training issue. It is a transition design issue, which did not invest enough in transferring the business logic of the new system.
Change management is not a project deliverable, but a condition for operational success
Faced with these challenges, change management is too often treated as a peripheral component of the project—a budget line for training and internal communication—activated at the end of the programme once technical choices have been made.
This view is not only too narrow, it is also counterproductive.
A Finance IS transformation profoundly changes how flows move, how teams work, and how responsibilities are distributed within the organisation. Change management’s role is precisely to anticipate these effects and secure the operational transition—not just tool adoption. To fulfil this role, it must be integrated into the project from the design phase, not bolted on just before go-live.
In practical terms, this requires three things.
Make new flows readable, not just documented
Target processes are generally well described in project documentation, but that documentation often remains far removed from the reality of day-to-day work. What teams need is to understand how flows work in the system: when an entry is generated, in which cases an operation gets stuck, and how an anomaly can propagate.
An approach that has proven effective in this area is peer-to-peer learning. Rather than entrusting this transfer solely to external consultants, key users are identified upfront, fully trained on the solution, and become the true internal experts. They then train their colleagues, explain the flow logic, and answer day-to-day questions.
The effect is twofold: system understanding is more grounded in operational reality, and adoption is easier because it comes from peers rather than an external party. This is not a user manual issue; it is the transfer of financial logic, and it can only work if the project teams themselves have invested sufficiently in mastering business processes—not just configuring them.
Map organisational impacts before go-live, not after
IS transformations shift responsibility points: approvals embedded in a workflow, tasks that disappear with automation, new responsibilities that emerge in teams that did not expect them. These changes must be identified by the end of the design phase—not at training time, and certainly not after go-live.
This mapping has a dual purpose. It provides the foundation for the change management approach, ensuring the right topics are addressed with the right teams at the right time. But it also structures the testing phase: organising tests around new processes, rather than tool features, enables operational teams to take ownership of process flows in real situations, validate that responsibilities are properly allocated, and detect grey areas before they become production issues. Testing thus becomes a moment of collective learning, not just a technical validation exercise.
Treat the first weeks post go-live as a project phase in their own right
This is the most sensitive period and the one most often under-resourced. It is when teams discover the real behaviour of flows, when business rules reveal their full complexity, and when certain malfunctions not anticipated by testing surface.
In the best-prepared projects, this phase is planned well before go-live: project teams kept mobilised for the first closes, key users positioned as operational relays, a clear escalation process for blocking situations. Added to this is an often overlooked element: the level of support from the software vendor or integrator in the first weeks. This hypercare set-up—enhanced availability, guaranteed response times, and dedicated contacts—must be designed and contractually agreed well ahead of go-live, not negotiated in a rush once problems appear. It is a safety net whose value is measured precisely when everyone is under pressure.
The objective is not to extend the project indefinitely; it is to avoid degraded practices taking hold, which will then be very difficult to correct. The benefits of an ERP deployment generally materialise within 12 to 24 months after go-live—provided the first weeks do not compromise the trajectory.
In summary
Finance IS modernisation is often managed as a technology project. In reality, it is a transformation of the finance function’s operational practices.
The most frequent post-deployment difficulties do not come from the tool. They come from the gap between the new processes and teams’ ability to master them quickly. When not anticipated, this gap generates invisible operational debt: close cycles that tighten, internal control that loses robustness, cash indicators that drift during the transition.
Reducing this gap is precisely the purpose of change management in these projects—not as a generic support activity, but as rigorous work to anticipate operational impacts and rapidly rebuild teams’ control over their financial flows.
This is the dual dimension on which Althéa supports its clients. Our approach combines expertise in operational finance, an understanding of close processes, internal control mechanisms, cash challenges, and a change management practice grounded in the on-the-ground realities of finance departments. Not to support the deployment of a tool, but to secure the transition as a whole: from mapping organisational impacts in the design phase through to stabilising teams during the first operating cycles.
Written by
Emmanuelle Rassek
Director, People & Transformation
