6 Considerations for the deployment of an ERP

ERP implementations, by their nature, touch the key operational areas of any organisation. They impact on the way a business transacts and touch the many processes that weave through the different departments and functions.

 A key decision point around any ERP implementation is how the organisation will take the ERP solution into productive use. Typically, there are two approaches, a “Single Go-Live”, where all of the main modules of an ERP system go live at the same time, or some kind of phased go-live – whether by region, country, site, line of business, functional area or by business priority.

 For most small organisations a single go-live approach is feasible, while for larger and more complex organisations some degree of phasing might be inevitable. Many organisations fall somewhere in the middle and choices will need to be made. It is helpful to consider the main advantages and disadvantages associated with the two approaches from six different perspectives.

1.     Risk

The general consensus is that single go-live implementations pose more risk than phased implementations.

There are a few good reasons for this:

• It is more difficult to revert to the old system if things go wrong. Within a few hours of operating on the new system it can become impossible to reverse out. There is often a point of no return after which the option of roll back becomes unfeasible.
• There is 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 will not work together when the new system is switched on.
• A single go-live go-live places a huge strain on all parts of the organisation, as well as the IT department and the system vendor. Dealing with a large volume of go-live issues with insufficient resources can quickly become a challenge.

In contrast, phased implementations tend to involve discrete business units or functions, so there is 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 and business processes. 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.

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 is 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 single go-live for this full group of sites due to the interdependencies involved.

3.     Temporary Interfaces and Business Processes

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 single go-live as being “the full solution” then by definition temporary interfaces are not 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 are simply a stopgap measure.

Busness processes are an important consideration. It is highly likely that during a phased go-live the business will either be operating dual processes, or worse, entering data into two places. This has an additional cost and pressure to the business.

4.     Time

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 a single go-live implementations. Where a project’s duration is measured in years rather than months then project fatigue can become an issue, and it is 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 become more apparent when timescales are lengthy.

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 single go-live 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 single go-live 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 is less activity happening in parallel. That may mean there is more time to devote to other activities, whether that be other business projects or non-project work.

System support during the cutover and early live period (sometimes known as the stabilisation period) is an important factor. A single go-live approach exerts additional pressure on the business and the project team during the cutover – simply because there is so much activity going on all at once. It is vital to consider how much the project team can handle when contemplating a single go-live approach over multiple countries, regions or business units.

Single go-live 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.

6.     Costs

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.