What to expect at your ERP go-live

Go-live is both an end and a beginning, exciting and stressful, longed-for and dreaded. It is the culmination of months of preparation, data cleansing, system design and testing, and training. The actual go-live date may have been enforced by another event, such as a new financial year or the withdrawal of support for the old system, but triggering go-live just because the calendar says so is not always a good idea.

Before going live with the new system, some things are essential and non-negotiable:

• All data must have been entered, checked, and verified.
• There must have been a successful conference room pilot, in which all software, hardware, documentation, and people performed faultlessly. Going live with the belief that 'everything will be OK on the night' is a serious gamble.
• All department heads must have visibly and loudly nailed their colors to the new system mast. Any hesitation, equivocation, or caveats will weaken the resolve of their staff to persevere if teething troubles occur. If they are not prepared to give unequivocal support, then, regardless of the upheaval it will create, the go-live must be paused because turning around a failed go-live is an enormous task, even when it is possible.
• Following that, everyone must be told that teething problems will indeed occur. People will make mistakes, checked data will turn out not to have been checked properly, and, at some point, Murphy's Law will kick in. People must be told this and be told what contingency plans are in place to cope (reverting to the old system is not a contingency plan and should be explicitly ruled out).

Some things are not mandatory but can be useful:

• If customer and supplier-facing documents such as purchase orders, invoices, etc, are dramatically changing, it can be a good idea to let key trading partners see examples (clearly marked 'SAMPLE'!) in advance.
• Likewise, it can be helpful to write to both customers and suppliers, advising them that the company is moving to a new system and requesting their patience and forbearance should anything go wrong and they be affected.
• Lastly, there will be go-live nerves amongst the users. Giving them simple instruction sheets, that walk them through the things they will be doing, greatly increases their confidence in being able to cope. (Such documents are also very useful later when people are off ill or on holiday).

It is worth remembering that, when things go wrong, the system will be blamed and, by inference, the implementation team. It is useful to remind all staff that the users have had training and that the data both belong to them and have been checked by them.

The vast majority of problems at go-live are user problems and, though the implementation team is essential to resolving problems, they are not responsible for those problems, only for helping to resolve them. This also means that, when problems occur, the reasons for them must be communicated to everyone.

If it genuinely is a system problem, then everyone should be told. But, if is a people problem, everyone must also be told. When trying to assuage people's feelings, 'the system' will take the blame for their failings and, when companies allow that to happen, they shouldn't be surprised when people lose faith and revert to notepads and spreadsheets.

Everyone should also be aware that, at go-live, it takes longer to correct mistakes than to make mistakes. For that reason, companies need as many hands on deck as they can get, and that includes the consultants, from their system supplier.

Some companies try to save money by avoiding this, and it is undeniably painful to see expensive consultants sitting around drinking coffee with nothing to do (surely you can find them something?) but, if there are times in life when companies can do without insurance, this is not one of them.

Post-go-live

The system has successfully gone live and any initial teething problems have been overcome. But the team still has vital roles to play. Firstly, following the go-live, the users should be encouraged to write down all niggles and problems they are having with the new system.

The implementation team will be capable of resolving a lot of these quickly but, after one month, three months, and twelve months, external consultants should be invited back to discuss any that are outstanding. If companies try to avoid the 'expense' of these reviews they will find themselves limping along with problems and irritants that often take just minutes to fix.

The users must, of course, be told that not all of their problems can be resolved but they can be told that, whilst there is no guarantee that all problems they report will get fixed, there is a guarantee that any problem that doesn’t get reported will not be. In the original justification for the new system, measurable targets will have been set for things such as inventory reduction, service level improvement, reduction in debtor days, etc.

The team should continually monitor performance against these targets. If expectations are not being met, the team must, perhaps with the assistance of the external consultants, find out what areas of the system are underperforming and must deliver plans for remedial action.

On the other hand, if the system is meeting or surpassing expectations, everyone in the company must be told. The more they are told that the system is working, the more they will have confidence in it, and the more they have confidence in it, the better they will use it.

The company should also get details of any user groups from their system supplier and the team should maintain contact with such groups so that the company can benefit from other people's experiences. Lastly, they should try to maintain informal contact with the implementation consultants.

Giving away free consultancy will not be in their remit but most will be happy to answer brief questions over the phone or via e-mail.

And finally

There is now a team of people who know the company and its systems better than could ever have been imagined. They can be used. They can be used to monitor changes in the company and the way that it operates so that the system can be continuously re-tuned to meet developing business requirements.

They can be used to review radical changes, such as acquisitions or new product lines, so that effects on the system, or ways in which the system might help, can be evaluated. And they can be used to continually look at new and potentially better ways of doing things.

The company has invested time and money in its new system: now is the time for it to reap the rewards.