10 critical ERP upgrade mistakes | TechRepublic
http://www.techrepublic.com/blog/10things/10-critical-erp-upgrade-mistakes/3202?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+techrepublic%2F10things+%28TechRepublic+10+Things%29
- Follow this blog:
- RSS
- Email Alert
10 Things
10 critical ERP upgrade mistakes
Takeaway: 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.
Get IT Tips, news, and reviews delivered directly to your inbox by subscribing to TechRepublic's free newsletters.
(via Instapaper)
Brief message sent from a mobile device
No comments:
Post a Comment