Phased ERP Implementations – Part 1: Benefits & Drawbacks
There are two basic approaches to implementing an ERP solution. “Big-bang” - meaning going live with all functions, for all divisions and all users at once – or phasing the implementation. What are the benefits of each and when should you decide on the right approach for you?
For the largest organisations implementing a single global solution, phasing will always be required. For many mid-size organisations though there are decisions to be made on whether and how to phase an ERP implementation.
Phasing can be done by organisational entity (business unit, location, region, plant or some variant of these) to spread the transition across the organisational units. It can also be done by function or business process. Typically, this involves deploying some foundational processes, like finance, first and then rolling out other processes bit by bit. Various hybrids of these two phasing approaches might be designed, depending on the scope and scale of an implementation.
Click Play on the video below for a 60 second summary of this blog.
This blog considers some pros and cons of taking a phased approach to implementing ERP. It's companion piece considers some key success factors if you are taking a phased approach ERP.
Why might phasing be attractive?
ERP projects almost always bring business change or transformation. Changing a lot of things at once is inherently risky. A phased approach can spread out the change and so spread the risk to a more manageable level.
Business change is typically the most challenging part of an ERP implementation. An honest assessment of the organisation’s appetite for this change and its capability to deliver it might dictate that a more cautious phased approach is appropriate.
By far the biggest spend on an ERP project is on human resources. This includes the consulting services from your implementation partner(s) and the cost of your internal implementation team. Some approaches to phasing can mean that the number of Full Time Resources (FTEs) working on the project at any one time is lower. While the overall cost might not differ, or even be higher, it may be more palatable from a cashflow perspective to spread the spend. Depending on the terms negotiated with the software provider it could also mean that software licences or subscriptions can be drawn down as needed. This too could contribute to spreading the initial expenditure out over a longer period of time.
Phasing may mean that an earlier “Go-Live” is achievable, albeit for a subset of the business. Depending on the target benefits that the project is expected to deliver this may mean achieving quick wins associated specifically with the functions or divisions to be deployed in an early phase. This can help with the overall justification for the project.
What drawbacks might phasing have?
While early initial “Go-Live’s” may be achievable in a phased implementation, inevitably the overall project duration tends to be longer. By definition, phasing means reducing parallel activities, so duration extends.
Related to extended duration is the potential for higher costs. These can come from fixed cost elements, like project management, which are required through the duration at a fairly continuous level. Another potential source of extra cost are inefficiencies due to reduced opportunity for resourcing economies of scale that might exist on broader scope single phased big-bang implementations.
One of the potential downsides of a longer deployment is “project fatigue”. This can apply particularly to internal resources seconded from “business-as-usual” roles to project roles. Maintaining motivation and focus has natural limits. Extended phased projects can feel like they have no end. Strong project leadership and a clear path to a role after the project can help address this.
As with the project teams experience of project fatigue, the business can experience “change fatigue”. If a phased approach means multiple waves of change to the same business units then the people working in those units can become less engaged and receptive to the change being deployed. Strong leadership and change management are key to mitigating this risk.
It is likely that temporary processes may be required in a phased implementation, particularly where the phasing is based on functions or business processes. While those new processes interact with functions relying on legacy systems, temporary processes and work arounds may be required until the new end-to-end process is in place. Effectively this means that some processes will change twice over the course of the project. As with avoiding change fatigue, this reality demands excellent leadership and change management.
In addition to temporary processes, temporary interfaces between new and legacy systems might be required while both are in operation. Naturally there is cost, and sometimes significant effort in developing, testing, deploying and managing such interfaces, which will eventually be discarded.
Continue to Phased ERP Implementations - Part 2 of this blog on success factors for phased ERP if you are considering this approach.
This blog was written by Ian O'Toole, Consulting Manager at Lumenia. For further information please send an email to Ian O'Toole