The Trouble with ERP Programmes

A number of high profile disasters in the implementation of primarily tier one ERP systems have led to high levels of caution and fear when embarking on any ERP implementation programme. Having been involved in a string of ERP implementations of various sizes the lessons learnt has highlighted the following as being key to the success of any such programme.

1.      It’s not an IT project, the degree of change and the opportunity to create a much more efficient organisation means that the work must be viewed by everyone as a business change programme and be actively supported by all levels in the business

2.      Have a very formal steering group, this must contain senior management from the business, implementation team and all key resellers, ideally be chaired by the MD, have strong and clear governance, be formally run and meet at least monthly (more often as the live date gets closer). Progress (task and budget), issues and changes must be covered in these meetings and everyone must understand and agree with all the actions required to move the programme forward until at least the next meeting

3.      Build a strong relationship with the resellers, both contractually and informally it is important to understand exactly what they are providing in software, hardware and services, and if the services are important to success then it is essential to understand who is doing what and when (this may manifest itself as penalties against deliver or consultants being specifically named in the contract as being available for the programme). During the life of an ERP implementation the priorities of the reseller will change, it is important to remain at the top of their priority list. More informally, if the resellers feels part of the team then when times get tough they are more likely to go the extra mile rather than if they feel they are in a ‘them and us’ situation and are likely to be blamed regardless

4.      Planning and governance are essential, time spend determining how the programme can best be run and giving clear thought to timescales and dependencies is always time well spent. Simple procedures and an understood and agreed plan must always be the first task of any implementation team, and must be signed off by the steering group. There will be bumps in the road as the programme progresses but with procedures to deal with the bump and a plan which can be used to illustrate the effects of mitigating the bump allows clear decisions to be made. A lack of such control and clarity will lead to extra work, uncertainty and will risk maximising the benefits of the programme

5.      Data gathering, cleansing and loading is the hidden complexity of any ERP implementation, this must not be underestimated, it is often the first and last task of the programme and getting the data wrong will be at least a very costly mistake in terms of time, money and the ongoing benefit of the implementation

6.      Testing must be sacrosanct, by definition this is always one of the last tasks before go-live and usually suffers from the pressure of cumulative time losses resulting in a temptation to cut it short. This is a recipe for disaster and steps should be taken at the beginning of the programme to ring fence the testing time and effort, and put processes in place to trigger the slipping of the go-live if there is insufficient time for full testing.

No ERP programme should be underestimated in terms of complexity and having to deal with conflicting priorities, but by building a cohesive team marshalled through strong, sensible governance and recognising some of the likely pitfalls early on gives a much increased chance of success.