The old saying, “nothing happens until the deadline gets close” certainly applies to ERP (Enterprise Resource Planning) projects. In the case of ERP, the deadline is called “Go-Live” meaning the new system is turned on and the old system turned off or at least idled. Unfortunately, many Go-Live dates become known as the Day of Disaster. Follow these guidelines to make Go-Live survivable.
Training Early and Training Late
Demand your consultants helping with your ERP project have completely separate teams for training and implementation. Letting the team leads “manage” training as one of their bullet points guarantees problems on Go-Live.
Related: The Most Important Thing About ERP
Training for end user leaders begins with the first demonstration of the first potential ERP vendor. You can never have too much end user feedback during an ERP project, because those end users, or the end user representative, know they are the ones who will have to live with the system on a daily basis.
The majority of the users should be trained the month before Go-Live. Too much training too soon just means the refresher memos at Go-Live will be replaced by full training sessions. When the end users know they’ll be using the new ERP system in a matter of weeks, more attention will be paid during training.
End user team leaders, however, should be trained constantly during the customization process. Every workflow change, each new screen item, and each new report should be taught to the team leaders, so they can give their feedback and verify the final training classes will be up to date.
Incorporate Changes from User Acceptance Testing
UAT, or User Acceptance Testing, is a critical step in all ERP projects. Too often, however, UAT becomes just a check-list item to be rushed through. When this happens, and UAT feedback is not incorporated into the ERP customization process, Go-Live bombs because the user’s contributions were ignored.
This UAT dismissal causes two major problems. First, the users expect one thing and get another, slowing their work. Second, they then realize their comments and demands for workflow improvements were ignored, and they can imagine the system will only get worse going forward. Complaints will fly up the management chain, meetings will be called, and real work will grind to a halt.
Go-Live is not the time for surprises. Aggravating entire user departments leads to far more extra work than making the changes they asked for during UAT.
Three is the Magic Number
Every project needs deadlines, and ERP projects are certainly no exception. Don’t tell anyone, but expect to have two false Go-Live dates before you finally commit to the complete cutover.
No ERP project can Go-Live on the first date set, because that date was set at the beginning of the project and based on the vendor’s promises of how smoothly everything will run. In reality, your project will take, typically, twice as long, and cost twice, as much as first estimated.
Go-Live project date Number One will come and go. The second Go-Live date will be about 50 percent later than the first date. So if your project was supposed to take a year and end in October, the next Go-Live will be about April the next year.
From Inside CRM: CRM And The Long-Cycle Sell
The third Go-Live date, following our example above, will be either September or November. This will be the real deadline, and Go-Live will function more or less correctly. Why? Because your company will have had the right amount of time to make the customizations and the Go-Live process will have been partially tested twice.
A third Go-Live date is a successful Go-Live date
About the Author
James Gaskin writes books, articles, and jokes about technology, and consults for those who don’t read his books and articles. Email him at email@example.com.
Original : http://it.toolbox.com/blogs/inside-erp/avoiding-erp-golive-disasters-58074