The “big bang” ERP go-live, where all of the main modules of an ERP system go live at the same time, is a widely-known approach for ERP implementation projects. The alternative approach is to adopt some level of phasing – whether by region, country, site, line of business, functional area or by business priority.
For most small organisations a big bang approach is feasible, while for larger and more complex organisations some degree of phasing is inevitable. Many organisations fall somewhere in the middle and choices will need to be made. It’s helpful to consider the main advantages and disadvantages associated with the two approaches from six different perspectives.
The general consensus in the ERP world is that big bang implementations are much riskier than phased implementations.
There are a few good reasons for this:
- It’s more difficult to revert to the old system if everything goes wrong. Within a few hours of operating on the new system it can become impossible to reverse out. There’s often a point of no return after which the option of going back becomes unfeasible.
- There’s a higher risk of serious damage to the business, simply because there are more things that can go wrong. The integrated nature of ERP systems means failure in one part of the system can have serious knock-on effects elsewhere.
- Full end-to-end testing is much more difficult to achieve; despite extensive testing there is always the risk that the individual elements won’t work together when the new system is switched on.
- A big bang go-live places a huge strain on all parts of the organisation, as well as the IT department and the system vendor, and dealing with a large volume of go-live issues with insufficient resources can become a nightmare.
In contrast, phased implementations tend to involve discrete business units or functions, so there’s a better chance that any serious issues at go-live can be contained. For the same reason it can be easier to revert to old systems if necessary. One of the main disadvantages of phased implementations is the potential need for temporary interfaces. Interfaces between systems can be difficult to get right and are a high risk point of failure, therefore the lower the number of interfaces the better. Another major risk with phased implementations is that rework may be required if assumptions made during earlier phases prove flawed when later phases are implemented.
2. Multiple sites / business units
The complexity introduced when dealing with multiple sites or business units often drives implementation strategy decisions.
As a general rule it tends to be easier to manage multi-site and multi-business unit implementations in a phased manner. There is no right or wrong here: it all depends on the circumstances.
For an organisation with multiple large sites across a region it would generally make sense to start with a pilot site and then roll out the template to the other sites. That’s very often the approach taken by large multinationals. The same thinking would apply for multiple business units.
One exception to this would be a scenario involving a hub site with satellite or regional sites dependent on the hub. A central factory and head office with regional sales offices and distribution centres might be an example of this. In this case, it may be easier to go big bang for this full group of sites due to the interdependencies involved.
3. Temporary Interfaces
Phased implementations often require temporary interfaces to provide an interim working solution. A temporary interface is a link between two systems that is only required on a short-term basis until the full solution is implemented. If we think of big bang as being “the full solution” then by definition temporary interfaces aren’t part of the picture.
By contrast a phased approach may involve the prospect of building interfaces between the new system and the remaining parts of the legacy systems until they are eventually replaced.
Temporary interfaces are costly to implement, and, by their nature, have no long term value: they’re simply a stopgap measure.
Every project is subject to time constraints of some description. In the main, phased implementations tend to take longer (in terms of elapsed time) than big bang implementations. Where a project’s duration is measured in years rather than months then project fatigue can become an issue, and it’s also worth noting that having an organisation in a constant state of change or transition for an extended period of time can have negative consequences. Staff burnout and a general loss of focus are definite risks.
The ERP project isn’t likely to be the only thing going on in the business. Factors such as regulatory compliance, acquisitions, new product introductions and other capital expenditure programs can influence the required timescale for an ERP implementation. Planning the project will need to take these other factors into account and could well influence the big bang versus phased decision.
5. Impact on the organisation
Any project of this nature takes a toll on the project team and on the wider organisation, and the choice of implementation strategy can make a difference.
A concentrated effort is required from the project team for the duration of a big bang project, while the rest of the organisation will really only become involved to any significant extent shortly before the go-live. In contrast a phased approach generally means a little less pressure on the project team as there’s less activity happening in parallel. That may mean there’s more time to devote to other activities, whether that’s other business projects or the day job.
System support during the cutover and early live period (sometimes known as the stabilisation period) of any system is always an important factor. A big bang approach exerts additional pressure on the business and the project team during the cutover – simply because there’s so much activity going on all at once. It’s vital to consider how much the project team can handle when contemplating a big bang approach over multiple countries, regions or business units.
Big bang projects can create a sense of urgency in the whole business and gather a level of momentum that can be difficult to achieve in long-running phased projects.
A phased approach can lead to quick wins (for example where a pilot business unit quickly sees some of the benefits of the new system), which provides confidence and helps in selling the advantages to the rest of the organisation. On the other hand, poor experiences in early phases can lead to negativity around the ERP project – in a worst case scenario it could even undermine a rollout plan.
The question of cost always comes into play in any decision of this nature. Phased implementations often take longer and may require more time from ERP consultants.
This translates into:
- Additional external costs (on ERP consultants)
- Additional internal costs (where staff are seconded to the project team for longer, with the associated costs of backfilling that staff)
- Additional costs for temporary interfaces
There can be situations where a phased rollout can actually save on external consultancy costs. For example, implementing a full ERP rollout country by country means that the project team builds up a level of expertise and experience, reducing the reliance on ERP vendors as the rollout proceeds.
To register for our IT training courses in London, UK, please call us on 07440631224 or send an email to firstname.lastname@example.org