Enterprise Software

10 critical ERP upgrade mistakes

If your organization is preparing to upgrade its ERP system, this list will help you steer clear of common project pitfalls.

Major ERP software upgrades are often seen as a long, arduous process. But avoiding certain mistakes can help companies maintain maximum performance when implementing software improvements without disrupting users comfort with their current system. This is especially important for organizations that rely on their ERP software but need updates to keep their systems running at full potential. Here are 10 missteps to avoid when you're planning and implementing an upgrade.

1: Not explaining what a new system means to users before starting the project

If you want to doom an upgrade project, keep the users in the dark. We have done a lot of upgrades, and the one thing that always separates successful projects from the not-so-successful ones is communication with the users. The companies that explain up front the business case for upgrading, the benefits to the company and employees, and any changes in the end user experience (green screen to Web client, Windows client to Web client, etc.) are the most successful. Why? The software will work, the hardware will work, but it doesn't matter unless the users buy in. There is nothing more politically powerful than user perception, and if they decide the system doesn't work, it won't.

2: Not load testing the system with scripts and end users

Any system can run with a handful of users -- but what happens when it is fully loaded with users, batch jobs, and EDI? Most ERP systems today come preset to handle a typical user load, but is your load "typical"? How do you know? The only way to determine for sure is to load test the system. The most accurate way to load test a system is with load testing software and scripts... and with real users. If you just use scripts, you won't see the effects of user mistakes, and if you just use people, you can't really simulate the effect of batch jobs and EDI. But if you can't do both, pick one and run with it. Either one will be 10 times better than doing nothing.

3: Not performing a mock Go Live

A mock Go Live, or dress rehearsal, is the time when you find out whether everything will go as planned ahead of time. It is also the point when you capture timings for all the different Go Live tasks. If you don't practice under the same conditions you'll have when you plan to go live (e.g., if Go Live is on a weekend, mock Go Live needs to be on a weekend), you will run into issues that you never planned for, facing questions such as:

  • Do I have access to everything on a weekend?
  • Will we run into backups or maintenance windows?
  • Is the office open and is the AC on?

Some of these may sound trivial, but when you are under pressure and have spent thousands, sometimes millions, of dollars on a new system, the last thing you want is to be delayed because you missed something that was easy to catch. Always eliminate as many variables as possible.

4: Not taking change management and testing seriously

In the old days, we would apply "paper fixes" to address specific "opportunities in the software." Today, everything is electronically packaged to address as many "similar" issues as possible. This can be a problem because the change you need may be a small part of a much larger fix or Electronic Software Update (ESU). An ESU can touch thousands of objects, as opposed to a paper fix, which would directly address your specific issue. With the advent of ESUs, you must thoroughly understand the impact of the change and regression test every business process, even if it was working properly before the change. You don't want to introduce additional "opportunities" into your production environment.

5: Assigning an internal resource as the only project manager

A lot of customers think they can save money by eliminating the consultant PM and doing it themselves. For an upgrade, this is penny-wise and pound-foolish. A consultant PM's focus is on upgrades so they know the pitfalls. Navigating these pitfalls ahead of time will make the difference between an on-time/on-budget system and a perpetual money pit.

6: Not communicating changes before they happen

We have been working with ERP systems since the early 90s, and one thing has always rung true: End users don't like change because it causes them additional work. They would rather deal with the old system's quirks and inefficiencies than adapt to a new system. The only way to make them happy is to provide a consistent user experience, and to do this, you must communicate, communicate, and communicate some more.

7: Delivering Training 1.0 in a Training 2.0 World

Today, companies are doing more business with fewer people. This means employees have to wear more hats than ever before. More responsibilities = more training = more work = less time to spend with their families. This is why classroom training (Training 1.0) by itself does not stick. With Training 2.0, you augment the classroom training by creating a Knowledge Vault of recorded videos detailing the most critical business processes for on-demand retrieval. This on-demand training reinforces what was taught in the classroom. It also allows the users to "get help" 24/7/365.

8: Not moving proprietary components to open business standards

Moving proprietary components to open business standards will speed up future upgrades. In addition, components that follow open business standards are by definition more prevalent. The two proprietary areas to focus on moving to open business standards are reports and interfaces. If you can move one or both, your next upgrade will be a lot less time intensive.

9: Not addressing security and archiving before upgrading

This one is simple. If you archive before you upgrade, you will save time and money because the table conversions will run faster. As an added benefit, archiving will speed up queries on large tables, which will improve the end-user experience. (As we've noted, this is an important ingredient to a successful project.) As for security, every attempt should be made to follow the "all doors closed" model. This is not always practical, but you should at least make it a serious topic of conversation every time you upgrade. The more a system grows, the more vulnerable it will become. No company wants a competitor or terminated employee with confidential information.

10: Assuming your internal tech people can pick up 15 years of experience in a couple of weeks

Upgrades don't happen every day or every year. So it's important to utilize the most experienced technology consultants to keep your system running optimally during the upgrade. If you're like most companies, you probably have several consultants and internal people working on the project. If it is down all the time, no work is getting done but money is still being spent. Experienced consultants know the hundreds of INI settings, thousands of conversions, multiple OS/network settings, protocols, load balancers, etc., like the back of their hand and will keep the system performing during the upgrade. The technology part of the upgrade project is the foundation of your "house." If the foundation is cracked, the house will come down.

About the authors

Kevin R. Herrig is president and CEO of GSI. He has more than 21 years of experience in software engineering, systems integration, network engineering, and enterprise systems architecture. Shawn Scanlon is executive vice president of GSI and a senior systems implementation engineer, with expertise in JD Edwards (JDE) EnterpriseOne systems.

24 comments
jgs25
jgs25

right from the start, no end users were consulted...our local branch (in an upscale neighborhood with lots of IT specialists + elderly customers (me being both) was especially hard hit, as people were streaming in screaming! The new site is horrible to use.

gazeltan
gazeltan

This is a great article. In addition to these best practices, when upgrading your software make sure you have the right project team in place. As the article points out, having an experienced project manager and consultants with the right level of technical skills will set you up for success. Make sure to involve your business users throughout the project as they will be able to communicate their requirements and drive user testing. On the topic of testing, if you cannot test a fully loaded system, scale down the system and do a ‘proportional’ test. Finally, schedule as many performance dry runs and dress rehearsals as needed. I recommend at least two with the first being an opportunity to exercise all the steps and gather timings. The second rehearsal can serve as a validation of the first test. Accurate timings are critical for smooth go-lives and this approach will avoid unpleasant surprises.

delroekid
delroekid

We are planning to move to a new web based ERP, and I think this will guide me as part of the Core Team

dsmith
dsmith

This is definitely important before the project gets off the ground. The CEO / Owner / President need to establish change and like it or not this is the direction the company is going with its ERP system. He/she needs the buy in from all executive, directors, managers, employees or the project will fall short from its goal. I have seen where the lack of explanation and direction has had a major impact on an ERP implementation.

kpyx2709
kpyx2709

Hi, I thought this one from JDE E1 perspective. What if like AX which is each version are different. In JDE E1 actually the burden goes to CNC/technical, am I right to say so? No drastic or dramatic change like from World to OneWorld.

jamie.callaghan
jamie.callaghan

For all those focused on nit picking the title of the article... If you don't know what ERP is the article would have little relevance to you. I just assume that most of the IT crowd today would know what ERP means... Just sayin..

djcase
djcase

Do not try to make the new ERP system work like your previous ERP system did. I have been involved in many implementations where companies try to customise their new ERP system to look like (and work like) their old system thus limiting their take up of the new ERP system and limiting it's flexibility/effectiveness. They need reminding that they are changing because the old system no longer does everything they required. Also the nature of the business usually has changed over the years and it would be wrong to assume all existing business processes should automatically be carried over.

helzapoppn
helzapoppn

The massive failure of the ERP solution known as "DRMS" is just one example of the many ways corporations sucked money out of the City of Detroit, and the equal number of ways City leaders and IT professionals enabled the suckage with their combination of silo-based thinking, departmental fiefdoms and an earnest-but-overmatched IT Department trying to "manage" the whole thing. The initial contracts to Oracle (software) and IBM (consulting services, plus computers and other hardware) were signed in late 1996: DRMS didn't finally go 100% live until 2004 (and even then the HR and Payroll functions never worked right).

seven2seven
seven2seven

A very few and large org/corp need an ERP...let's be real. And if you have and ERP in place it means you have $ to burn so I really don't care if it blows up in your face. Now, as a customer...not my problem either 'just fix it' :)

jgs25
jgs25

Chase should have done this BEFORE trying to upgrade it's web site! All new such projects should have these first steps! The Chase system was a mess WELL BEFORE it went live.

mark1408
mark1408

We're about to start an upgrade. We're not "large-scale" by any measure but nevertheless there are some good reminders in here.

Pete6677
Pete6677

The biggest mistake is installing ERP in the first place. Never has there been an ERP implementation that was anything other than a massive clusterfcuk.

TsarNikky
TsarNikky

Perhaps "ERP" should have been defined at the beginning of the article, for those readers who don't know or are unsure what it means. Whatever it is, the suggestions make a lot of sense.

beaubouef
beaubouef

Thank you for the information but please allow me to challenge you a little more in this area. Many sources speak to the symptoms that result in perceived ERP implementation failure but few speak to the root cause of these failures. The root cause has more to do with the wrong implementation strategy. Today, the majority of ERP implementations follow a traditional, ???build-from-scratch??? approach that is not adequate for implementing packaged software like ERP. What is required is an approach that addresses both the inherent advantages and challenges associated with ERP. Following are what I feel are key strategies to assist you in build the right ERP implementation strategy. http://gbeaubouef.wordpress.com/erp-business-solution-manifesto/

daniel_waibel
daniel_waibel

Agree with most of the article and comments, but want to add a few additional points around a [b]large scale[/b] implementation or upgrade. 1. Business case - This is the most critical component and will determine the priority and funding of the project. The key here is to get the business leaders (Finance SVP/VP, etc...) to own the business case. Building the ROI can be tricky with an ERP but is possible. Focus on improvements to process cycle time and reporting, both of which are typically important to executives. Any consolidation of functions (accounting AP, HR, etc...) will also contribute to ROI. 2. Executive sponsorship - Gaining true exec sponsorship will be key to the success of the project. The business case should be constructed to align with the goals/expectations of the executive sponsor. This sponsorship should outweight project dissidence from any of the potentially rotating stakeholders, both at HQ and in the field; note that typical large scale ERP upgrades (or re-implementations) can easily take 18-24 months. 3. RFP and partner selection - Most big companies have a dedicated technical team for their ERP system. This tech team should partner with the key business stakeholders to help coordinate the building and distribution of the RFP to major players in the ERP upgrade space. Assembling a good RFP is very important and will dictate the quality of proposals you receive from potential partners. In some cases, it may make sense to outsource the RFP creation to a potential partner since they know the proper questions and can assemble a comprehensive document; your selection for this RFP creation task will provide a distinct advantage to the partner, so choose wisely. 4. Engagement - Depending on the scope of the project, your required engagement from key business decision-makers could range from total project commitment to weekly status attendance. For example, if the chart of accounts is being completely re-built, the key finance folks will need to dedicate themselves to the project. That may require temps to be hired to backfill the daily grind operations for all or part of the project; this should be included in the ROI and business case. 5. Testing - Building a complete "book" of regression tests will be key to a successful cut-over to the new ERP. This book should include both positive and negative tests and, optimally, will be recorded/automated for quick re-play. 6. Change management & training - The author mentioned this topic and, again, the criticality is correlated with the type of changes in each area. For example, if the upgrade/re-implementation is impacting the core supply chain processes, the operations/warehouse directors & managers will need significant input and training around the new system. In this case, onsite/live training is probably your best bet, probably in a centralized location. Adding CBT (computer based training) will create a self-service type of environment for any future resource turn-over and refresh activites. Caveat - as noted, these are suggestions for a "big company" implementation.

pauldenhart
pauldenhart

Believe it or not, major global groups still think that a project team can be part time, or is a place to dump deadwood. Wrong! The quality of the team, which should be the best people from the business, has a key impact on project success. This can be thought #13. Fully agree with the other points raised.

mlennerton
mlennerton

Perhaps #11 & #12 would be the pre-upgrade brief and the post-upgrade debrief. The first gathers key participants and goes over the final master tasks and responsibilities list. Discuss methods of communication to pass the baton and what to do if something goes wrong. The most important thing is that business has an ERP system (the new one would be great, but the old one is better than none) when the system is planned to be used again. Discussing an mitigating that risk management in a pre-brief is essential. The debrief is also important. It provides lessons learned for the next upgrade and should help to galvanize the team's experience. Key members (to include users that received training) should objectively submit three things that went well and three things that need improvement to the de-brief MC prior to meeting. Once the MC goes through the submissions and determines the juiciest ones the entire group should get together and discuss. The debrief should happen soon after go-live so memories are fresh and accurate. Lastly, adjust your overall upgrade process as necessary for next time using the lessons learned.

murrays99
murrays99

Totally agree!!! Number 4 is probably the most serious of all of them. More for thought: 11. Underestimating user training, assigning long term responsibility for department training within the organisation. IT does not run the system, the end users do, and they need to ensure staff turnovers do not impact their own processes. 12. MAINTAINING user buy in to the project. Often we get the users to commit to a project, then as time drags on, they forget why the signed onto this overwhelming and resource tapping state of affairs. When go-live comes around, the key users had better remember why they are giving up all their weekends. IT always takes the heat for a painful cutover.

rhonin
rhonin

After having done several ERP implimentations and upgrades, I look at your 10 list and totally agree with you. I have yet to see one project utilize all 10. Numbers 2, 4, 7, and 8 are the first casualties as deadlines approach or funding starts to be an issue. Sad to say you are right but the business world with few exceptions will agree to actually do these.

draco vulgaris
draco vulgaris

The title, above, is how it should be done! The first time you use an acronym you should spell it out in full and follow it with your acronym in parentheses. It saves a great deal of confusion! If you're only going to use your acronym once or twice don't; just spell it out. The world already has an over supply of acronyms!

TsarNikky
TsarNikky

Why wasn't the ERP acronym spelled out, at least once, at the beginning? It would have made the article much more appreciated by a lot more people.

mark1408
mark1408

...readers who don't know what ERP is probably don't have ERP so wouldn't be upgrading it :-)

rhonin
rhonin

All too often these implimentations take many months or a couple of years. By the time you approach go-live, the critical users and management may have changed. These new users will see things differently.

Fairbs
Fairbs

Giving me a serious Rolling On The Floor Laughing My Arse Off (ROTFLMAO) Smiley Face (:)) I thought we covered this already.