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 MAIL

sales@quest.com 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