buchachon - Fotolia

What minefields should I add to my go-live checklist to prevent failure?

A successful go-live can be elusive, despite planning, money and time. Here's a look at some overlooked areas that can cause catastrophe if ignored.

Enterprise technology implementations -- from large-scale ERP to specialized components -- have a long history of go-live failures. The fallout from such failures can be extreme, such as drawn-out and ugly legal battles with the client company and the system integrator, each of whom is trying to prove the other's faults. But even less dramatic failures can cost your company precious time and money and contribute to its decline. That's why, as part of a solid project plan, a go-live checklist is critical to creating a successful go-live.

A go-live is when a company formally and officially starts using and transacting in a new ERP system, known as the production system, and many companies sunset their current legacy ERP systems soon thereafter. Though a go-live sounds simple -- as if you can just flip a switch and all will be well -- it is the outcome of many weeks or months of activities, such as project preparation, documentation, configuration, testing, training, system validation and cutover from the legacy system to the new ERP system. A go-live involves a company's internal and system integrator teams.

Because of this, it's imperative that the right leaders with enough authority contribute to the ERP project plan and, as part of that, that they proactively address factors from the go-live checklist that could lead to a failed go-live. Here are six of these factors.

Untenable transactional backlog

When an ERP system goes live, there's often a backlog of transactional data to enter to cover for the blackout period, which is a period in which no more transactions can be entered into the legacy system. This is a means of closing as many open items as possible, including unpaid vendor invoices, remaining deliveries of materials from vendors or incoming payments from customers.

Of course, the business cannot and does not stop during the blackout period and, hence, business users have to maintain manual (or Excel) records of all of the transactions so that they can enter them into the new ERP system as soon as possible upon its go-live. Further, a blackout period can serve as a cutover for all of the audited inventory and financial balances from the legacy system to the new ERP system, which can be a lengthy process.

To add to the potential for failure, companies often set their sights on getting a full financial year's data in the new ERP system by attempting to tackle a mountain of transactions backlogs. For example, a company with a financial reporting period spanning from January to December, and with an ERP project going live in March, may attempt to start entering the backlog into the new ERP system at the beginning of January. However, it will not take long to conclude that they are fighting a losing battle. The business users will never be able to get up to speed to the point where they can enter live, actual (and not backlog) entries, and they will face issues with incorrect or incomplete master data that prevent them from quickly tackling the backlog. Furthermore, due to the highly integrated nature of ERP systems, incorrect or incomplete transactions can have a snowball effect, and can often lead to reversals and re-entering of transactions, leading to an even greater backlog pileup.

To summarize: The larger the transactions backlog, the higher the risk of go-live failure. More than a week's backlog should not be allowed to build up.

Last-minute configuration changes

Making or requesting last-minutes changes to an already configured and tested ERP system is a sure sign of a fiasco. Often, configuration changes are tied to workflows, custom-developed programs and reports. But, due to the scarcity of time, the pressure for a timely go-live does not allow for another round of thorough testing of the affected objects due to the configuration changes made. For example, in a recent SAP project, and despite SAP consultants explaining the potentially disastrous consequences, a client insisted that previously configured and tested release strategies (which used an online approval process for procurement) be completely changed just two weeks before the ERP go-live. Doing so led to not only the entire procurement process coming to a complete halt, but also affected the subsequent processes, such as production, quality and sales stoppage, leading to a failed go-live.

Forming a change approval board, consisting of your company's management, where every change request is vetted for its business or financial criticality, can act as a control gate to minimize change requests made at the later stages of an ERP project.

Faulty master data

Project go-live failures are often due to incorrect and incomplete master data making it nearly impossible to smoothly conduct transactions. Master data is the data that remains in the ERP system for a much longer period of time, and it does not frequently change. Despite being the backbone of any ERP system, too many companies do not invest the appropriate time, effort and resources needed to adequately cleanse duplicate, dormant or obsolete legacy data. Companies do better on this front when they adopt a phased approach to tackling master data in the beginning and middle of an ERP project.

Overlooking integration

A key return on investment from a new ERP system's implementation is eliminating data entry redundancy, as well as bringing people and processes together to work in a completely integrated environment. However, if all of your stakeholders aren't equipped to understand how an end-to-end business process works in your new ERP system or how one process is dependent on another, quite often, chaos is the outcome.

The best way to prevent integration failure at go-live is to ensure there are enough rounds of testing involving all of the stakeholders as a means of checking their ability to independently resolve common go-live errors.

Overlooked change management

Change management too often gets short shrift in an ERP project, which leads to a lack of stakeholder engagement -- among many other problems. Beware: Ineffective change management is virtually guaranteed to lead to a go-live failure.

On the other hand, change management can foster fully committed and available stakeholders, which can do wonders during the most critical hours of an ERP project, and they can promote go-live success.

An unresponsive support desk

Despite all of the training companies conduct to bring users up to speed with a new ERP system, there will always be a steep demand for support with common go-live errors as soon as the new ERP system has gone live. Lacking an effective and responsive support desk or help desk often prolongs issue resolution, eventually snowballing with subsequent or remaining transactions that are also held up.

Companies should implement and use an ERP integrated tool to address any go-live issues and to track key performance indicators of support desk services.

These six areas are not the only potential minefields you'll need to add to your go-live checklist. However, these areas are some of the most potentially explosive and, as such, it can pay to watch for them closely and to build in plans to deal with them. 

Next Steps

Don't overlook important SAP training steps

Stakeholder mapping is key to change management

Why you really need comprehensive testing

Dig Deeper on SAP implementation