The 10 Commandments of a Successful @Oracle #EBS #R12 Upgrade

When I attended OHUG earlier this summer in Orlando, I heard from a LOT of people about R12. Tons, in fact. The overwhelming conversation about the topic was, well... overwhelming. Users -- functional and technical alike -- are overwhelmed by the daunting task of migrating, patching, upgrading or re-implementing from EBS 11i to EBS R12. The project is big, has tons of people involved and can take anywhere from six to 12 months to implement. No wonder people are freaked out!

 

In that vein, I've co-authored a whitepaper to summarize some key things to think about when you're preparing for the upgrade. Whether you're a project manager, a technical user or perhaps a functional lead tapped to influence the project, this summary should help you get your bearings simply enough. Yes, R12 is a big important project for your organization, but it can also be done with success and relative ease. Have a read to learn how...

 

The 10 Commandments of a Successful Oracle R12 Upgrade

 

Commandment #1: Thou Shalt Understand the Key Metrics of Change

 

American philosopher William Edwards Deming believed that the careful balance between project results and project costs was at the heart of quality. To drive up quality in any process, the trick was to improve results and minimize costs – something attainable through the continuous improvement.

From results to costs, what are the key metrics in an ERP implementation? Organizations target any number of results. For many, productivity of functional users is key. How can users be more productive? Can some of the simpler user tasks be automated to free up resources to spend on more complex tasks? For other organizations, efficiency is the targeted result. How can users do their work faster or less expensively? Can we better schedule shop floor employees to reduce their downtime or overtime?

 

The costs of an ERP implementation tend to be much more uniform. No matter what the user’s functional role or the organization’s industry, stakeholders care most about system defects, downtime, and time spent managing the system. Does the ERP system present a number of defects that require time-consuming patches or upgrades? Do these patches or upgrades require system downtime? How much downtime? Do they require a high degree of staff resource to implement?

When managing the upgrade to R12, focus on increasing the targeted results and decreasing the associated costs to achieve maximum quality in your implementation.

 

Commandment #2: Thou Shalt Implement Planning and Process Control

 

A change management process must account for both short-term and long-term demands of the change management process.

For example, planning for future patch sets and maintenance releases is essential because significant organizational resources are needed to deploy these patches and system downtime may be lengthy; accurate planning can prepare organizational resources to accommodate these demands. Best practices suggest planning for one major patch upgrade each year, a major event that incorporates testing from all business units. However, you should also plan and budget for periodic patching throughout the year for break fixes and to accommodate changes in business requirements.

 

Planning is critical to control the process, including security and workflow, which are detailed in the next three commandments. (Note that this is different from controlling the people involved with the process; for that, see Commandments #5 and #9.)

 

Commandment #3: Thou Shalt Secure the Tides of Change

 

Processes are defined by rules, and security policies are the means by which those rules are enforced. An effective process must allow security policies to be easily adapted to a changing workplace. Employees leave the organization and new employees are hired to backfill; new initiatives and skill sets affect employee functions. The security policy must evolve to address these changing needs.

 

As an example, Oracle E-Business Suite requires that the security policy define who can apply patches and to which environments. It may be fine for certain users to apply a patch to a development environment to validate whether a patch will correct an issue in production.

 

Read the rest here

 

As always, your stories from the trenches are always welcome. How are you becoming more proficient with the R12 upgrade?

Anonymous