The 10 Commandments

of a Successful Oracle
E-Business R12 Upgrade
Written by

David Fisher, Senior Oracle Applications Architect

Tracie Stamm, Product Marketing Manager of ERP Solutions
Quest Software, Inc.

WHITE PAPER

Contents
Abstract........................................................................................................................................................................... 3

Introduction ..................................................................................................................................................................... 4

The 10 Commandments of a Successful Oracle E-Business R12 Upgrade .................................................................. 5

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

Commandment #2: Thou Shalt Implement Planning and Process Control ................................................................. 5

Commandment #3: Thou Shalt Secure the Tides of Change ..................................................................................... 5

Commandment #4: Thou Shalt Thoughtfully Plan Process Workflow ........................................................................ 6

Commandment #5: Thou Shalt Leverage Approvals as Check-and-Balance Controls .............................................. 6

Commandment #6: Thou Shalt Maintain Project Sanity via Proper Versioning .......................................................... 6

Commandment #7: Thou Shalt Explore Potential Issues Proactively ......................................................................... 6

Commandment #8: Thou Shalt Check your Work with Auditing and Reporting ......................................................... 7

Commandment #9: Thou Shalt Seek to Automate Manual Processes ....................................................................... 7

Commandment #10: Thou Shalt Be a Great Communicator ...................................................................................... 8

Conclusion ...................................................................................................................................................................... 9

About the Authors ......................................................................................................................................................... 10

The 10 Commandments of a Successful Oracle E-Business R12 Upgrade

Abstract
Complex enterprise resource planning (ERP) systems like Oracle E-Business Suite are critical to many organizations,
serving diverse business needs and supporting both functional-level and business-level decision-making. Therefore,
it is essential to effectively manage change to those systems, especially change as major as upgrading to Oracle EBusiness Suite R12. This white paper provides 10 key best practices to help your organization effectively manage
change to your ERP systems, with particular attention to upgrading to R12.

The 10 Commandments of a Successful Oracle E-Business R12 Upgrade

Introduction
Enterprise Resource Planning (ERP) systems like Oracle E-Business Suite are large, complex applications that serve
diverse business needs. In fact, these systems typically span finance and accounting, HR, manufacturing, sales and
marketing essentially the entire business, end-to-end. This breadth of use gives rise to the value of ERP in
supporting functional- and business-level decision-making. Users share data with functional peers and users in other
departments to make business decisions every day, such as: How many pieces of our product can we produce next
week? Do we have enough of the right staff to do the work?
Because large numbers of users varying in skill, geography and job function often depend on these systems and their
data, ERP systems present a certain amount of risk as well. In particular, system change, whether from a migration or
an upgrade like Oracle R12, is inevitable and can lead to downtime, which puts the productivity of all the diverse
users who depend on ERP systems at risk.
The complexity and risk inherent to ERP systems demands a solid change management strategy. How will your
organization manage something like a major system upgrade? How will you upgrade the system comprehensively
and with minimal downtime to the business? The following commandments are critical to any successful ERP
implementation and especially so for those users upgrading to Oracle E-Business Suite R12.

The 10 Commandments of a Successful Oracle E-Business R12 Upgrade

The 10 Commandments of a Successful

Oracle E-Business 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 users functional role or the
organizations 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.

The 10 Commandments of a Successful Oracle E-Business R12 Upgrade

Commandment #4: Thou Shalt Thoughtfully Plan Process

Workflow
Workflow defines the lifecycle for change according to rules, activities and relationships defined by the organization.
For instance, for patch management, workflow ensures that issues are researched before a patch is applied and that
every patch is fully tested. A workflow for the patch process may begin with the identification of an issue. Depending
on the nature of the issue, the issue may have to be researched through collaboration by several team members. If a
patch is identified as the solution, the workflow rules may require the patch to be applied to a development
environment first so that testers can certify that the patch addressed the issue without affecting the functionality of
standard or custom applications.
A workflow may even include post-deployment activities, such as a post-mortem to identify any process
improvements. For instance, customized objects may need revisions with any patch. Workflow for the patch
management process should also support custom development. Large development teams may also need to support
concurrent development.

Commandment #5: Thou Shalt Leverage Approvals as Checkand-Balance Controls

A policy for security and workflow should be complemented with a mechanism for approvals to authorize change. In
fact, approvals may be an activity in the workflow: A change flowing through the process may reach several critical
points that may require business-level approvals before continuing. Approvals provide check and-balance controls.
For instance, once a patch has been applied, testers must validate that the patch addresses the issue while not
adversely affecting standard and customized functionality. The testers may need to provide their approval before the
patch can continue through the change process. Similarly, business owners may need to provide their approval
before a patch can be applied to the production system.

Commandment #6: Thou Shalt Maintain Project Sanity via Proper

Versioning
Versioning is essential for managing change of individual objects. Groups of objects can be labeled and associated
with change requests. Older object versions can also be used to restore or back out a change. Large development
teams may also need to support concurrent development of objects.
When a change is introduced to an E-Business application environment, the original version of the modified objects
should be retained in an object repository. Oracle patches affect many objects; identify what those objects are and
archive them in the object repository. Versioning is necessary in the event one needs to back out of a patch. For a
change as substantial as the upgrade from Oracle E-Business 11i to R12, versioning is especially critical because it
allows you to back out of a particular step and return to a prior version should an unexpected issue arise.

Commandment #7: Thou Shalt Explore Potential Issues

Proactively
Whats this about an unexpected issue at the end of Commandment #6? Its common for a patch to affect files that
may seem unrelated to the patch. Testers can try to determine what a patch will do to an environment before it is
applied by manually inspecting the patch file, but this approach is fraught with inefficiency and prone to error. Relying
on Oracles readme.txt is even more risky since these files tend to be too generic and lack critical information.
The best approach to determining patch impact is to use the preview option for Oracles AutoPatch utility, which
identifies affected files without modifying the environment, and using other tools to determine which database objects
will be modified based on modified files. Although identifying the modified objects can be exceptionally tedious,

The 10 Commandments of a Successful Oracle E-Business R12 Upgrade

especially for large patches, the risk of applying a patch blindly is typically greater. Simply identifying the modified
objects leaves a gap between what files were modified and what should be tested. Users may reference many
changed objects either directly or indirectly through the application. Good reporting will not only identify what objects
are impacted, but also how the objects affect users. For example, mapping an impacted form to the responsibility and
navigation path for a user helps guide testing of the patch.
Oracle best practices provide methods for customizing objects without fear of a patch destroying these
customizations. New custom objects are often created from objects provided by Oracle. Customizing in this fashion
prevents the customization from being destroyed by a patch, but other objects referenced by the custom object may
change and break the custom object. Although these best practices are relatively easy to adopt, they are often not
followed, and failure to adopt the best practices means each patch has the potential to destroy the customization. It is
important to know whether a changed object was customized or used to create a custom object. Patch impact
analysis executed in advance of the patch even in the development environment can bring rewards. The
development team can prepare resources to modify impacted customizations prior to the patch being applied, thus
minimizing the risk to the stability of the development environment and not delaying other development or testing
projects.

Commandment #8: Thou Shalt Check Your Work with Auditing

and Reporting
Security, workflow and approval controls do not prevent errors from occurring; even the most well-designed change
process is vulnerable to errors. But once an error is identified, auditing can be very useful in isolating what events
might have introduced the error. There are two types of auditing: auditing the change process and auditing the
change:

Auditing the change process is concerned with the who, what, where, when and why. For example, when a
security policy is changed, auditing tells us who changed the security policy. When a patch is applied,
auditing tells us which patch was applied, when it was applied, who applied it, who approved the patch, who
tested it, which files were modified, etc. Auditing will also tell when a customized object has been changed,
or when the original object used to create the custom object was changed.

Auditing change itself is all about issue tracking. Before a patch is ever applied, theres a reason the patch
was applied either a bug was found or a new patch set was released. The issues should be tracked from
inception to postmortem for proper auditing of change. Auditing data can be used to report the current,
future and past state of an environment; activity that has been performed affecting the state; and the
difference between two or more environments.

To that end, reporting capabilities are critical for assessing the state of each environment. Whats the difference
between production, test and development? What will a patch do to a system before it is applied? How do testers
know what to test when a patch is applied? What area of the business could be put at risk and to what extent? Proper
change reporting brings this key information to light for the stakeholders involved.

Commandment #9: Thou Shalt Seek to Automate Manual

Processes
Manual processes for repetitive tasks can be automated to minimize downtime, reduce staff resources, eliminate
human error, and control soft costs. These repetitive tasks are typically tedious, and automation frees skilled
resources to focus on more fulfilling tasks.
For example, Oracles AutoPatch command-line tool asks the same series of questions and returns consistent
responses. Oracle has improved the automation of AutoPatch dramatically with the defaults file, but the tool still
requires an experienced resource to log into systems, transfer large patch files (typically with insecure protocols),
execute the tool and monitor the output. Automating tasks like executing AutoPatch can improve the change process.

The 10 Commandments of a Successful Oracle E-Business R12 Upgrade

For another example, there is a balance between effective use of resources and security. Because of security
concerns, only a few people may be allowed to access the production servers. Restricting access is good practice,
but can also place those few people on the critical path of the change process. Automation can eliminate the need to
distribute passwords by allowing key contributors to be identified for tasks or phases of work and provisioned
accordingly, rather than using a common password shared by the group. By storing that password in a centralized
location, not everyone needs to know the password. Instead, users can log into a chosen change management
application and complete tasks as they have been provisioned.
Automation can also help ensure that customizations to E-Business Suite applications are not destroyed by a patch.
Even when you follow Oracles best practice for patching, its still necessary to monitor each patchs activity to identify
when the source object for a custom object is modified. When Oracle-provided objects are customized, its even more
critical to monitor what a patch is doing to avoid losing the customizations that a user has made to an Oracledelivered object.

Commandment #10: Thou Shalt Be a Great Communicator

When issues are identified, change status, or are resolved and closed, people with a stake in the issue should be
notified. For example, QA should automatically be notified when development has completed their work so that
testing can begin in a timely fashion. Users should be notified when QA has completed their testing so user
acceptance testing (UAT) can begin and the process can continue to flow smoothly. Likewise when activities fail or
do not get completed on time, people with a stake in the activity should be kept informed. Notifying stakeholders of
these changes is particularly critical with patches; if a patch should fail, systems may be left in a corrupt state and
business functions may not be available. Therefore, users associated with the affected business functions need to
know when a patch has been applied successfully or unsuccessfully.
How and when will stakeholders be informed? Managing change in ERP means seeking solutions that have a built-in
communication element via automated alerts and reporting. Even better, marry this to Commandment #8 (automate
manual processes), and this information should push to named stakeholders via automated email alerting.

The 10 Commandments of a Successful Oracle E-Business R12 Upgrade

Conclusion
ERP gives organizations tremendous support in functional- and business-level decision-making. A diverse set of
users depend on these applications to complete their day-to-day work. Complex upgrades like R12 can require a host
of cumbersome changes to these business-critical applications. Therefore, it is imperative that IT admins manage this
change in a comprehensive, proactive way. Successful Oracle E-Business R12 upgrades and other ERP
implementations will obey the commandments of change management described here.
To learn more about managing the R12 upgrade or other change in your ERP systems, visit the Quest Software
community dedicated to the topic.

The 10 Commandments of a Successful Oracle E-Business R12 Upgrade

About the Authors

David Fisher is a Senior Oracle Applications Architect with 18 years experience developing and administering
database systems. Daves domain-level expertise has been invaluable in the conception and development of several
Quest products, including Stat for Oracle E-Business Suite. After developing proprietary database systems at Bell
Laboratories, he focused on Oracle-based applications, including implementation, upgrade, administration and
development for Oracle Applications 10.5 through 11i.
Dave earned his BS at Michigan State University, an MBA with an emphasis on international business and finance at
University of Illinois, and an MS from Northwestern University.
Tracie Stamm manages product marketing of change management and performance monitoring solutions for Quest
Software. Tracie joined Quest in product marketing in 2007 and has developed deep expertise in application
performance monitoring and management. She co-founded Quests Foglight Customer Advisory Board and helped
establish the virtualization and cloud computing solutions. She focuses deeply in the management and monitoring of
major ERP applications like Oracle E-Business and Peoplesoft.
Tracie holds two degrees from The Ohio State University: an MBA in corporate finance and investment management
and a bachelors degree in logistics and marketing.

The 10 Commandments of a Successful Oracle E-Business R12 Upgrade

10

 2011 Quest Software, Inc.

ALL RIGHTS RESERVED.
This document contains proprietary information protected by copyright. No part of this document may be reproduced
or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, for any
purpose without the written permission of Quest Software, Inc. (Quest).
The information in this document is provided in connection with Quest products. No license, express or implied, by
estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of
Quest products. EXCEPT AS SET FORTH IN QUEST'S TERMS AND CONDITIONS AS SPECIFIED IN THE
LICENSE AGREEMENT FOR THIS PRODUCT, QUEST ASSUMES NO LIABILITY WHATSOEVER AND
DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL QUEST BE LIABLE FOR ANY
DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING,
WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF
INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF QUEST HAS
BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Quest makes no representations or warranties with
respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to
specifications and product descriptions at any time without notice. Quest does not make any commitment to update
the information contained in this document.
If you have any questions regarding your potential use of this material, contact:
Quest Software, Inc.
Attn: Legal Department
5 Polaris Way
Aliso Viejo, CA 92656
www.quest.com
email: legal@quest.com
Refer to our Web site for regional and international office information.

Trademarks
Quest, Quest Software, the Quest Software logo, AccessManager, ActiveRoles, Aelita, Akonix, AppAssure,
Benchmark Factory, Big Brother, BridgeAccess, BridgeAutoEscalate, BridgeSearch, BridgeTrak, BusinessInsight,
ChangeAuditor, ChangeManager, Defender, DeployDirector, Desktop Authority, DirectoryAnalyzer,
DirectoryTroubleshooter, DS Analyzer, DS Expert, Foglight, GPOADmin, Help Desk Authority, Imceda,
IntelliProfile, InTrust, Invirtus, iToken, I/Watch, JClass, Jint, JProbe, LeccoTech, LiteSpeed, LiveReorg, LogADmin,
MessageStats, Monosphere, MultSess, NBSpool, NetBase, NetControl, Npulse, NetPro, PassGo, PerformaSure,
Point,Click,Done!, PowerGUI, Quest Central, Quest vToolkit, Quest vWorkSpace, ReportADmin, RestoreADmin,
ScriptLogic, Security Lifecycle Map, SelfServiceADmin, SharePlex, Sitraka, SmartAlarm, Spotlight, SQL Navigator,
SQL Watch, SQLab, Stat, StealthCollect, Storage Horizon, Tag and Follow, Toad, T.O.A.D., Toad World,
vAutomator, vControl, vConverter, vFoglight, vOptimizer, vRanger, Vintela, Virtual DBA, VizionCore, Vizioncore
vAutomation Suite, Vizioncore vBackup, Vizioncore vEssentials, Vizioncore vMigrator, Vizioncore vReplicator,
WebDefender, Webthority, Xaffire, and XRT are trademarks and registered trademarks of Quest Software, Inc in
the United States of America and other countries. Other trademarks and registered trademarks used in this guide
are property of their respective owners.

The 10 Commandments of a Successful Oracle E-Business R12 Upgrade

11

WHITE PAPER

About Quest Software, Inc.

Quest Software (Nasdaq: QSFT) simplifies and reduces the cost of managing IT for more
than 100,000 customers worldwide. Our innovative solutions make solving the toughest IT
management problems easier, enabling customers to save time and money across physical,
virtual and cloud environments. For more information about Quest solutions for application
management, database management, Windows management, virtualization management
and IT management, go to www.quest.com.

Contacting Quest Software

PHONE

800.306.9329 (United States and Canada)

If you are located outside North America, you can find your

local office information on our Web site.

EMAIL

sales@quest.com

MAIL

Quest Software, Inc.

World Headquarters

5 Polaris Way

Aliso Viejo, CA 92656

USA

Contacting Quest Support

Quest Support is available to customers who have a trial version of a Quest product or who
have purchased a commercial version and have a valid maintenance contract.
Quest Support provides around-the-clock coverage with SupportLink, our Web self-service.
Visit SupportLink at https://support.quest.com.
SupportLink gives users of Quest Software products the ability to:
Search Quests online Knowledgebase
Download the latest releases, documentation and patches for Quest products
Log support cases
Manage existing support cases
View the Global Support Guide for a detailed explanation of support programs, online services,
contact information and policies and procedures.

5 Polaris Way, Aliso Viejo, CA 92656 | PHONE 800.306.9329 | WEB www.quest.com | EMAIL sales@quest.com

If you are located outside North America, you can find local office information on our Web site.
2011 Quest Software, Inc.
ALL RIGHTS RESERVED.
Quest, Quest Software, the Quest Software logo are registered trademarks of Quest Software, Inc. in the U.S.A. and/or other countries. All other trademarks and registered trademarks are property of their respective
owners. WPA-OracleR12-10Command-US-KS