Mark-Clark headshot

Tips for Planning an ERP Upgrade

“The right strategies can help you reach your upgrade goals and deal with potential obstacles and risks.”

by Mark C. Clark, May 2012

Like most IT professionals, for those of us involved in supporting an enterprise resource planning (ERP) system, upgrades are a fact of life. Whether you embrace it, fear it, avoid it, attack it or procrastinate, an ERP upgrade requires careful planning and informed decision making.

Recently, Oracle sponsored a survey about the ERP upgrade approaches of Oracle Applications Users Group (OAUG) members. Titled “ERP Upgrades: What’s Your Philosophy,” the survey revealed four top areas of concern:

  • Testing
  • Limited staff
  • Maintaining customizations
  • End-user adoption

As the survey showed, although upgrading to a new version of an ERP system can be viewed as a daunting task, a vast majority of enterprise application managers say upgrade projects are often short in duration, fall within budget estimates, and rarely disrupt business operations. If you are transitioning from Oracle E-Business Suite (EBS) Release 11i to Release R12.1.3, the right strategies can help you reach your upgrade goals and deal with potential obstacles and risks.

Testing

Testing is one of the most important aspects of an upgrade process. To ensure success during the testing phases, the leadership team should pay attention to these key areas:

  • Ensure that personnel involved in testing understand the entire testing process and each team’s (or individual’s) role in the overall process.
  • Prepare for proper testing by training personnel on how to log, report and track errors; educating personnel on how to use test cases, test scripts and test data; and allocating extra project time for testing and issue resolution.
  • Focus test cases on upgraded objects as well as new objects to offer a more complete picture of how the data will be used post-upgrade.
  • Dedicate the right personnel to the testing effort by identifying and scheduling the people that can anticipate how the system may break, envision how someone may try to use it, and understand the overall process and functions of the software.

Limited staff

Project leaders might consider augmenting in-house capabilities with external, third-party skills and knowledge. Adding the expertise of an external consulting or service organization may make sense when the investment in developing in-house capability will not pay off in the long term.

Industry experts suggest third-party and internal personnel may require practice and training to develop new skills and knowledge to be prepared for the R12.1.3 environment. Identifying in advance the competencies required for the new environment, along with the training and/or staffing plan for closing the gaps, is essential. Project leaders should also look to leverage test cases and test scripts so that key, knowledgeable personnel can share their knowledge with less-experienced personnel who may have more time to devote to the project. Testers armed with expected test results are more likely to spot issues earlier in the project lifecycle.

By using tools such as Oracle User Productivity Kit (UPK) or other technologies that allow for recorded sessions with features such as voiceovers and pop-up windows, geographically disbursed personnel can attend training sessions on their own time. It also allows organizations to use recorded sessions and local language as opposed to live instructors for topics in high-use or high-turnover areas, such as AP entry, requisitioning, and expense reports. In addition, leverage the user community for suggestions on test scripts or areas that may require special attention during the upgrade. And with internet technologies, a number of remote services are available covering DBA, developers, analysts and other support personnel.

Maintaining customizations

Most organizations agree that custom code can be expensive and potentially disruptive in an ERP environment. However, most organizations have some code that was not provided by their software vendor. Minimally, most organizations will have some interfaces or reports. Good maintenance starts with robust record-keeping. A full catalogue of customizations should be part of any IT organization’s key documentation library. While some organizations keep good records on workflow definitions, interfaces, reports, customizations and extensions, some keep very robust records that also include folder definitions, personalizations, and end-user layers for reporting. All customizations and extensions should be reviewed to see if new functionality or business changes can allow them to be retired. This allows for fewer development resources and reduces testing needs in future patching and upgrades.

Early test instances used by the DBA team to map out the upgrade can be turned over to technical team members to allow them to research the amount and type of rework potentially required so that code can work properly in the upgraded environment. When working with objects that were supplied by the software vendor, yet tweaked or enhanced for a particular need, it is usually better to start with a clean object and reapply the changes. In many cases, it is quite difficult to get an object from an old release to function in a new release. Managers also always should ensure that key project timelines don't coincide with critical work seasons such as year-end or quarter-end closes or peak season/cyclical times such as enrollments and peak season.

End-user adoption

To facilitate the adoption of the upgrade by end users, project managers should provide new feature training at multiple points during the project lifecycle and follow it up with reinforcement opportunities, such as:

  • Getting key users involved with validating a test upgrade and researching new features
  • Conference room pilots to test new and upgraded data
  • User acceptance training to a wider audience, again leveraging upgraded and new data
  • Development of training materials and desktop procedures 

Also, give the user community rewards for their heavy participation in the upgrade project. Try to address pain points and present users with new features and functions that make them more efficient or provide more beneficial functionality. 

More upgrade resources

Additional resources to help with all of the risks mentioned above include those provided by Oracle, such as the Oracle Upgrade Advisor for R12. Input from the OAUG Customer Support Council and the International Oracle Users Group Community (IOUC) Global Support Committee provided user-based input during the development of this tool, which was created to guide users through the phases of the upgrade lifecycle: evaluate, plan, configure, test, implement and accept. You can request a copy of “Utilizing Oracle Upgrade Advisor for R12,” an article that appeared in the spring issue of OAUG Insight magazine, for more on a user’s experience with the Oracle Upgrade Advisor for R12.

Also, leverage your association with the Oracle user-group community. It provides an invaluable opportunity to learn from other customers who can accelerate your learning by sharing what they’ve learned from both their successes and challenges. Oracle’s association with more than 870 users groups provides a vast network of user resources.

Finally, I invite you to visit the OAUG website to get acquainted with the numerous and varied resources available through this organization.


Mark C. Clark is president of the OAUG and has been an active member since 1992. As a senior partner at O2Works LLC, Clark is currently engaged with customers worldwide in their Oracle E-Business Suite Release 12 and 12.1 efforts.