Top 10 JD Edwards Upgrade Mistakes

Written by stbadmin | Mar 17, 2020 4:00:00 AM

Kevin R. Herrig, President and CEO

Today is St. Patrick’s Day so what better day to discuss some JD Edwards Upgrade Mistakes that will make you feel green if you don’t avoid them…

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 the business case for upgrading , benefits of the system to the company and employees, and changes in the end user experience (e.g., green screen to web client, Windows client to web client, etc.) up front, 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? Most ERP systems today come pre-set to handle a typical user load, but is your load “typical?” How do you know? The only way to know 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. Why both? If you just use scripts, you will not see the effects of mistakes, and if you just use people, you can’t really simulate the worst case load. 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 or not 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 exact same conditions as 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, 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?

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). ESUs 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. The last thing you want to do is introduce additional “opportunities” into your production environment.

5. Assigning an internal resource as the only Project Manager (PM)

A lot of customers think they can save money by eliminating the consultant PM and doing it themselves. This is penny-wise and pound-foolish. The consultant PM’s focus all day, every day, year-after-year are “upgrades,” so they know the pitfalls. Navigating these pitfalls ahead of time is the difference between an on-time/on-budget system and a perpetual money pit project.

6. Not communicating changes to the system 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 do this and test 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. Using Training 1.0 in a Training 2.0 World

Today, companies are doing more business with less 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 and 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 really 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 very 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 (a very important ingredient to a successful project). As for security, every attempt should be made to follow the “all doors closed” model. We understand 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. The last thing any company wants is 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. It's important to utilize the most experienced technology consultants to keep your system running optimally during the upgrade. If you are 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. An experienced consultant knows the hundreds of INI settings, 1000s 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.

View full post