Académique Documents
Professionnel Documents
Culture Documents
an overview from the three primary perspectives: managerial, functional and technical by Mike Swing
Copyright 2013 by TruTek All rights reserved. No part of this document may be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording or otherwise without explicit permission from the authors. Published by TruTek. TruTek 1740 South Main Street Salt Lake City, UT 84115 Phone 801 486-6655 Last Updated: 3/15/13
http://www.trutek.com
Oracle is a registered trademark of Oracle Corporation. Other trade and service marks are the property of their respective owners. Order additional copies at http://www.trutek.com
Table of Contents
Table of Contents
THE LITTLE R12.1.3 ESSENTIALS FOR MANAGERS AND TEAM MEMBERS ...................................................................................................... 7 AUDIENCE ..................................................................................................... 7 THE BIG PICTURE .......................................................................................... 7 AVAILABLE REFERENCES .............................................................................. 8 TRUTEK TRAINING ........................................................................................ 8 Release 12.1 New Features Training ....................................................... 8 TruTek Release 12.1.3 First Pass Upgrade Onsite Training ................... 8 Other Training ......................................................................................... 9 TRUTEK CONSULTING ................................................................................... 9 TruTek Release 12.1.3 Technical Upgrade Readiness Assessment .......... 9 Release 11i Extended Support Mandatory Patching Consulting Engagement .............................................................................................. 9 TruTek Release 12.1.3 Ongoing Technical Support ............................... 10 TruTek Release 12.1.3 Functional Upgrade Readiness Assessment ...... 10 TruTek Functional Upgrade Support ..................................................... 10 TruTek Testing/Quality Assurance Support ........................................... 10 TRUTEKS RELEASE 12.1 BOOKS ................................................................ 11 OUR PARTNERS ........................................................................................... 13 CHAPTER 1 PLAN TO UPGRADE ........................................................ 19 FIRST STEPS ................................................................................................ 19 WHY MIGHT A BUSINESS DECIDE OR HESITATE - TO UPGRADE? ............. 20 DECISION: REIMPLEMENT VS. UPGRADE ..................................................... 21 Upgrade vs. Reimplementation .............................................................. 21 Transform and Upgrade with eprentise ................................................. 22 Oracles Reimplementation Tools .......................................................... 30 Other Third Party Tools That Help Reimplementation .......................... 32 CAPABILITY MATURITY MODEL ................................................................. 35 UPGRADE BENEFITS: AN OPPORTUNITY TO OPTIMIZE YOUR HARDWARE CONFIGURATION ......................................................................................... 36 UPGRADE BENEFITS: IMPROVED ORACLE TOOLS SIMPLIFY THE PROCESS .. 38 Real Application Testing ........................................................................ 38 Database Replay .................................................................................... 38 Maintenance Wizard .............................................................................. 39 UPGRADE BENEFITS: USE SHARED SERVICE CENTERS TO DRIVE COST SAVINGS AND INCREASE INFORMATION QUALITY ....................................... 40 UPGRADE PROCESS: THE R12 FUNCTIONAL UPGRADE REQUIRES GAP ANALYSIS.................................................................................................... 41 UPGRADE PROCESS: ASSESSMENTS CAN HELP THE PLANNING PROCESS .... 44 Functional Upgrade Assessment ............................................................ 45 Technical Upgrade Assessment .............................................................. 45 Customization Assessment...................................................................... 46 3
Skills ........................................................................................................58
Identify Skill Gaps in Your Upgrade Team .................................................... 58
Teamwork ................................................................................................59
Team Obstacles .............................................................................................. 59 Minimize Risk ................................................................................................ 60 The Team Must Recognize Competing Priorities........................................... 60
SUCCESS FACTORS FOR FUNCTIONAL USERS ...............................................61 Gap Analysis ...........................................................................................61 Known Gaps ............................................................................................62
Financial Reporting Gaps ............................................................................... 62 Drill Down Restrictions ................................................................................. 63 Limited Chart of Accounts Access ................................................................. 63 MS Word Becomes the Report Layout Editor ................................................ 63
Customizations ........................................................................................65 Cumulative Business Value of Small Business Productivity Improvements ..........................................................................................66 Cost - Benefit Analysis for Business Process Improvement for Smaller Implementations ......................................................................................67 SUCCESS FACTORS FOR TECHNICAL UPGRADE MANAGERS .........................68 Patches ....................................................................................................69 Upgrade Patch Types Release 12.0 Critical Patch Collections (CPCs), Oracle E-Business Suite Pre-install Patches, Financials RPCs, Generic Data Fixes (GDFs), CPUs, PSUs ...........................................................69
Release 12.0 Critical Patch Collections (CPCs) ............................................. 69 Oracle E-Business Suite Pre-install Patches ................................................... 70 Recommended Patch Collections (RPCs) ...................................................... 70
Table of Contents
Generic Data Fixes (GDFs) ............................................................................ 71 Critical Patch Updates (CPUs) ....................................................................... 71 Use Patch Wizard from Oracle Application Manager (OAM) ....................... 72
The Patching Process ............................................................................. 74 The Testing Process ............................................................................... 75 Create Custom Development Upgrade Plan .......................................... 75 How to Upgrade Customizations ........................................................... 76 Obsolete Technology Components with Release 12 ............................... 77
mod_plsql....................................................................................................... 77 Oracle Reports Server Reports ....................................................................... 77 Oracle Graphics Integrations with Oracle Forms ........................................... 78 AK Mode ....................................................................................................... 78
JOINING FUNCTIONAL AND TECHNICAL VIEWS ........................................... 79 Upgrade Success Without Customizations ............................................. 80 Tools of Choice for Rooting Out Customizations ................................... 80 CHAPTER 2 PREPARE TO UPGRADE ................................................ 83 PRACTICE TESTING...................................................................................... 83 OPTIMIZE THE UPGRADE ............................................................................. 83 MAINTENANCE WIZARD .............................................................................. 83 UPGRADE BY REQUEST ............................................................................... 84 DEFAULT UPGRADE PERIODS - MINIMUM DOWNTIME UPGRADE ................ 84 INSTALL THE SLA PRE-UPGRADE CONCURRENT PROGRAM ....................... 85 RUN THE SLA PRE-UPGRADE CONCURRENT PROGRAM .............................. 85 ADJUSTMENT PERIODS ................................................................................ 87 SLA POST UPGRADE PROCESSING .............................................................. 87 Upgrade by Request ............................................................................... 87 THE UPGRADE IS AN ITERATIVE PROCESS ................................................... 87 MANAGE-EVOLVE-OPTIMIZE ...................................................................... 88 Manage................................................................................................... 88 Evolve ..................................................................................................... 88 Optimize ................................................................................................. 89 Aligning and Improving the Business Processes with R12.1 New Features is an Iterative Process ............................................................. 89 When Are We Ready? Are We There Yet? .............................................. 89 Technical Upgrade Paths - Release 12.1 Upgrade Paths ...................... 91 RELEASE 12.1 UPGRADE PATHS .................................................................. 92 DATABASE UPGRADE REQUIREMENTS ........................................................ 93 DATABASE UPGRADE STEPS........................................................................ 94 UPGRADE TIMEFRAME ................................................................................ 94 UPGRADE DOWNTIME WITHOUT THE DATABASE UPGRADE ....................... 96 UPGRADE WEEKEND ................................................................................... 96 CHAPTER 3 PERFORM THE UPGRADE ............................................ 99 TUNE THE UPGRADE.................................................................................... 99 OPTIMAL NUMBER OF WORKERS .............................................................. 100 OPTIMIZE ADPATCH ................................................................................... 100 5
CONCLUSION ............................................................................................113
Audience
The intended audience for this handbook is upgrade managers and all team members participating in the upgrade to Release 12. This team may include the following team members: Super Users, DBAs, Developers, Quality Assurance Testers and Hardware Architects. Team members should be able to understand the basics of all phases of the upgrade. This handbook provides an overview of the upgrade, the transition from an Oracle E-Business Suite Release 11i environment to Release 12.1, from three primary perspectives: technical, functional and managerial. Understanding these perspectives will allow for better communication between the primary groups of upgrade participants. Each point of view has slightly different criteria for success. Team members should understand that success can be claimed only when all the success criteria have been met. As teams grow larger, the skills required to manage large groups grow as more ideas are expressed. The intimacy of a small group is lost, and the opportunity for misinformation and disruptive rumors grows. Managers may encounter difficulties based on Daglow's Law of Team Dynamics: "Small teams are informed. Big teams infer." Communication is essential.
the little r12.1.3 upgrade essentials 1. Plan to Upgrade 2. Prepare to Upgrade 3. Perform the Upgrade 4. Finish the Upgrade
Available References
Check out our training, our consulting, and our books, and youll see weve developed a comprehensive approach to upgrading to Release 12.1.3.
TruTek Training
Release 12.1 New Features Training
One could argue that the changes to the E-Business Suite of Applications for Release 12.1 are the most significant part of a Release 12.1 upgrade. Our expert trainers cover new features provided by Release 12.1, including changes to General Ledger, Purchasing, Payables, Fixed Assets, Receivables and Cash Management. Our class also discusses changes to Inventory, Order Management, Projects, iExpense, iSuppler, iProcurement, iReceivables, and TCA. We can also tailor the class to cover just the modules that you plan to use, and if were assisting with your upgrade, our trainers also do the consulting work, so they can tailor classes to your unique environment.
the little r12.1.3 upgrade essentials classes and consulting engagements, we can streamline the first pass to two to three weeks. So if youre ready, give us a call.
Other Training
Our Oracle E-Business Suite R11i to R12 Technical Upgrade class takes students through a full upgrade of the Vision instance for Oracle customers who arent ready to establish a test environment for our onsite upgrade class. We also offer DBA classes that include Oracle R12 Applications DBA Concepts and Admin, 11g DBA Boot Camp I and 11g DBA Boot Camp II.
TruTek Consulting
TruTek Release 12.1.3 Technical Upgrade Readiness Assessment
Before you start your upgrade to Release 12.1.3, we strongly recommend a Release 12.1.3 Upgrade Readiness Assessment. We send you a questionnaire and list of scripts to run, and then we come onsite and evaluate your environment to help you decide if youre ready to upgrade. Our detailed report covers your environment and describes issues that you need to address before you start your upgrade. Do you have the right hardware to support Release 12.1.3? Do you have the right skillsets to support Release 12.1.3? Do you have the right patches in place to support your Release 11i environment while you are preparing to upgrade to Release 12.1.3? We look at those questions and more to help you prepare.
the little r12.1.3 upgrade essentials spreadsheet of all the required patches, and then applying and testing them. TruTek has been down this road a few times and would be happy to assist.
the little r12.1.3 upgrade essentials build on your quality processes and ease into full quality automation. We will work with your functional subject matter experts to create manual tests in TestDrive for Oracle Application web pages and forms, or customers can take advantage of TruTeks repository of Oracle Application test scripts. TestDriver test scripts can then be used with TestDrive Assist to facilitate full-blown test automation. TestSmart can be used to populate your test scripts with different data on each test run, allowing you to create many business scenarios with one script. TestBench can be used to manage your test environment, provide intelligent data extraction with obfuscation techniques, compare test runs, and implement database undo to return data to a prior state, thus allowing multiple test runs to quickly fix defects for successful test results. TruTek consultants will help you configure Qualify to fit your organizational quality methodology whether you use Agile, waterfall, or a hybrid approach. We will show you how to take advantage of Qualifys many features, such as drill down dashboards for access to instant information by all users including functional, technical or management, cross project resource management, integrated workflows, email integration, role-based access control, and built-in and customized reporting.
11
TruTek is a national leader in technical and functional Oracle training and consulting. We specialize in Oracle database and Oracle E-Business Suite technical and functional consulting. TruTek offers a full range of Oracle training classes.
You can sign up for TruTeks monthly TruTalk Newsletter at: www.trutek.com
12
Our Partners
Weve come to the conclusion that a successful upgrade requires the best tools and the best partners. As weve worked through the Release 12 Upgrade process, weve concluded that there are five areas that require special attention:
Testing What everyone hates and what no one can avoid! Inadequate
testing of your Oracle Application implementation or upgrade can result in an over budget project with an unpredictable extended timeline, negatively impacting your organizations business processes and putting your upgrade at risk.
Original Softwares Qualify product, including TestBench, TestDrive, TestSmart, and TestDrive-Assist, can bring organization, improved project control and visibility and quality testing to your upgrade, while enhancing collaboration between management, functional and technical project members. Original softwares easy to use test solutions include a project management platform with manual testing that can be transformed into full test automation without requiring programming skills. Subject matter experts are empowered to define and execute sophisticated testing scripts to use on updated Oracle Applications development and test environments. Defects can be detected and changes automatically incorporated into updated test scripts. Original Software ensures test data privacy with obfuscation techniques for audit compliance, database checkpoint and rollback functionality for errors to be identified, corrected and tests quickly repeated. Not only is Original Software technology easy to use, but it accelerates the quality process, allowing for faster delivery of business critical Oracle Projects.
13
the little r12.1.3 upgrade essentials Eleven Reasons to Use Original Software for EBS Testing Original Software products provide these features: Qualify 1 2 3 4 Full project management, planning, estimating, assigning, and tracking capability Project workflow, design custom workflows for your company Effective project collaboration for management, functional, and technical users Issue tracking system for managing your upgrade tasks, testing, and SRs Training made easy with Fast-Track test scripts; teach as you test! Manual system and user acceptance testing with screen capture and test steps Code free and self-healing test script technology Performance, server, and browser statistics Manual to full automation
TestDrive 5 6 7 8 9
TestBench TestSmart 10 Smart data creation Fast-Start Test Packs for EBS 11 R12.1 test scripts for Financials, Procurement, and Inventory
14
the little r12.1.3 upgrade essentials versions. This frees up technical resources to focus on deciding how the code should be modified to work correctly in the upgraded environment, rather than spending significant time trying to manually locate which of the thousands of modified objects may be included somewhere in each item of custom code.
16
If youd like to learn more about our partners, contact us at www.trutek.com, or call us at 1 801 486-6655.
17
First Steps
There are three main perspectives for the upgrade: functional, technical and managerial. We will show how these points of view work together, especially when customizations are present. With each point of view comes a definition of upgrade success. Each point of view must succeed in order for the whole upgrade to succeed. The following steps are the starting point for the upgrade plan: First, organize executive sponsors and superusers into a Steering Committee. Have the Steering Committee identify and prioritize the reasons to upgrade. Special consideration should be paid to implementing new R12 functional features and achieving more efficient processing. De-support dates by Oracle should also be considered. Before making the decision to upgrade using Oracles upgrade process or reimplement from scratch, identify the current issues. Some issues may be resolved by new functionality, others may require new customizations. Broken processes are very likely to exist after the upgrade. Purge unnecessary data and clean up interface tables. Data cleanup should be an on-going process, but becomes a priority during upgrades because of the additional processing required during the upgrade downtime. Deciding whether to reimplement or upgrade depends on a number of factors. Doing a fresh implementation will likely take much more time and be more disruptive to your business. Most Oracle professionals prefer to upgrade if at all possible.
19
the little r12.1.3 upgrade essentials Understand the Hardware Requirements and the Upgrade Path. Significant cost savings can be achieved by simplifying and standardizing hardware. Procure Upgrade Hardware. The upgrade hardware in most cases should be newer and faster than the current production environment. This will allow a seamless cutover from the old production environment to the new upgraded environment on upgrade weekend. Because the upgrade occurs on the new upgrade machine, if the upgrade fails, production doesnt need to be recovered. Establish the Upgrade Team. The Steering Committee should select an upgrade project manager, who in turn selects the upgrade team. Train the Functional Users on the New Features of Release 12. The new features should be integrated into the upgrade plan to replace customizations, when possible, and improve efficiencies. Create an Upgraded Instance for Gap Analysis. Once trained, functional users will want to understand how the upgrade affects their data and their processes. This should include the most important customizations.
20
the little r12.1.3 upgrade essentials Support. With an upgrade, all of the data (configuration, master data, and transactions) is available for use after the upgrade, and has been converted into the format required by R12 (i.e., sets of books become ledgers, a Legal Entity is associated with a balancing segment value, etc.). There are minor setups such as secondary ledgers or subledger accounting that need to be configured to take advantage of new R12 functionality. For a Reimplementation, a new R12 environment is installed and the customer (usually with the assistance of a consulting firm or system integrator) configures all of the setups for every module. Then, decisions must be made on how much history to convert and what to do with open items. The consulting organization writes custom scripts (which are not supported by Oracle) to migrate the master data (customers, suppliers, employees, etc.) to the newly configured R12 environment. Then structures (such as charts of accounts, other key flexfields, calendars, and organization structures) need to be converted to the new environment. This usually involves custom scripts (again not supported by Oracle) to extract the structure, transform it into the new structure, and load it into the R12 instance. Finally, all the open transactions, and usually about a years worth of history, must be migrated along with beginning balances. Did we mention that these are all done by custom scripts that are not supported by Oracle, or that if there is a chart of accounts change, every transaction must be converted to the new chart of accounts? Did we discuss the reconciliation process between the R11 environment and the new, reimplemented R12 instance?
Consolidate multiple production instances. Change existing configurations like charts of accounts, other key flexfields, calendars, and currency. Merge, split or move all structures including business groups, sets of books, legal entities, operating units, and inventories. Retain all history
Chapter 1 Plan to Upgrade The following tables show the pros and cons of a reimplementation effort versus a technical upgrade with eprentise remodeling:
Cons
No standard extract/transf orm scripts. Very similar to a custom development project requiring a more formal development and testing methodology including documentatio n, error handling, and development standards. Requires reconciliation from old structures, configuration to new structures, configuration.
Cons
Not widely understood among Oracle professionals or system integrators. Customer needs strong sponsor.
23
APIs do not exist for all tables. There is a risk of compromising the data integrity by extracting and loading data incorrectly. Oracle Support not available.
24
No need to configure R12 instance Full documentation of existing instance and changes made including comparison of instances 6-9 months duration
25
the little r12.1.3 upgrade essentials Ten Reasons to Upgrade 1. Reduced schedule and technical risk. Upgrade relies on commercial EBS conversion software from Oracle and independent software vendors, rather than reimplementations technical analysts and data conversion programmers. 2. You can change your chart of accounts. Upgrade uses remodeling software to change one or more COAs segments and values so you can adopt a single global COA. 3. You test new EBS setups in familiar 11i. Upgrade uses remodeling software to change any fundamental EBS setup you have postponed until reimplementation. The common setups Oracle says are not easily changed include: Legal Entities, Sets of Books (Ledgers), Operating Units, Key Flexfields, Calendars, Costing Methods, Inventory Organizations, and Asset Categories. 4. Transaction data will be changed, too. Upgrade uses remodeling Software to convert all 11i data to reflect all COA and fundamental setup changes. 5. Your history matters. Upgrade uses Oracle upgrade to convert all 11i data to R12. Business users are happier with all EBS history and current data in a single R12 instance, rather than distributed between legacy and active instances. 6. Avoid custom data conversion. With reimplementation, you are on your own to create extract and load scripts to convert and migrate your 11i data into R12. Unless you load everything, compromises lead to complexity, delays, and continuing expense. 7. True single instance for past and future data. With upgrade the result is a single R12 instance, whereas with reimplementation you will have R12 plus the legacy 11i instance in read-only mode as a reference to history and the prior business structures. 8. Avoid multiple custom conversions and legacy instances. For multi-national organizations with multiple EBS 11i instances, reimplementation requires data migrations from each legacy 11i instance into the single R12 instance. You will also retain all legacy 11i read-only instances. 9. Upgrade offers the most direct path and shortest time to single instance R12 business value. The most powerful upgrade advantage for multi-nationals is consolidation to a single global instance with standard business processes and all history data prior to the Oracle upgrade to R12. 10. Upgrades cost less. EBS customers pay for Oracle upgrade software even if they select reimplementation. Why leave money on the table and pay extra to do it yourself?
26
Chapter 1 Plan to Upgrade A technical upgrade and a remodeling effort can circumvent all of the justifications previously given for a reimplementation.
You need a new Chart of Accounts, have multiple COAs and would like to consolidate to one global COA or have a single COA that needs to split into multiple COAs. An organization structure that was planned for growth but is now outdated and is some cases obsolete because of unanticipated changes. Or an organization structure that has experienced a merger/acquisition or a divestiture. Currently have multiple instances and need or want to consolidate into a single instance. Want to upgrade to R12 to take advantage of new functionality but existing structure doesnt seem to support an upgrade. Up to now, reimplementation and a potentially costly multi-year project with a staff of consultants manually making the necessary changes seemed the only option. Years of history are often left behind in order to speed up the project and reduce cost.
Consolidation software from eprentise enabled a leading automotive distributor to consolidate two regional production instances into a single global instance within 7 months and at a cost of under $1,000,000, including their technical upgrade to R12. The automotive distributor used only 5 full-time- equivalent (FTE) resources during the entire project and brought over all their history. This compares to similar projects costing between $12,000,000 and $15,000,000 and utilizing over 250 consultants over an18 month project duration.
Reimplementation Consequences Here are some reimplementation consequences in the areas of implementation, data history, handling of the Release 11i instance, reporting and business intelligence. You have to implement a fresh installation of R12. Enter all setups from scratch or with Oracles Reimplementation tools and utilities.
27
the little r12.1.3 upgrade essentials You are on you own to get your open transactions and historical data from the legacy Release 11i into R12. Oracle Support cant help if the data is incompatible once it is in the R12 environment or if it breaks the E-Business Suite database integrity constraints. You have to decide what history to load and what to do with the remainder. You will need a policy for each different type of data. The usual choices include most recent and current fiscal year, current year and only open transactions. Dealing with data history will be a significant part of your reimplementation project. It will cost money and require several iterations to get it right. You may need to keep the Release 11i instance in legacy mode. Some call this a sunset instance. It must be frozen and restricted to read-only access. You will not have a single global instance. You will have to keep it available for external regulatory data retention purposes as well as operational analyses. You will need to devise reporting mechanisms to span the legacy Release 11i and operational R12 instances. This includes translations, reconciliations, mappings and external reporting environments. If you have a business intelligence environment or data warehouse, you will need to make changes to incorporate the frozen legacy Release 11i and R12 environments.
The following diagram shows the reimplementation approach. Customers following this path usually end up with the two instances (one Release 11i and R12) and keep workaround mechanisms in place to handle the instances or to make adjustments in a downstream business intelligence environment.
28
icted a
ccess
11i Data
Read-Only History
11i Data
R12
Via Public API & Interface Tables
R12 Fresh
Implementation
mp R12 e Clone
lo istory
ad
R12 Data
Seeded Configured History [partial] Custom SQL & DB Utilities
Path from one 11i instance to a single global R12 instance plus legacy instance
The reimplementation environment gets even more complicated if there are multiple Release 11i instances, multiple custom extract, transform and load operations, ending up with multiple Release 11i sunset instances. This diagram describes the upgrade process:
Upgrade = eprentise Transformation + Oracle Upgrade
Business process changes Business structure changes, incl. OUs COA changes Clean data, compliant with standards Shared service centers Instance consolidation 11i 11i Obsolete 11i Obsolete Setups Obsolete Setups Setups eprentise Transformation Instance you always wished for, AND its upgradable. Use it as long as you want, until you need the valued-added R12 features. Single Global Instance Lowest future cost structure Highest business value
11i Upgradable
R12
No data loss
11i Data
Transformed
No data loss
R12 Data
Transformed & R12 formats
Path from one or more EBS 11i instances to a single global R12 instance
Upgrade enables R12 Features Centralized accounting architecture Global tax engine New ledger and ledger set architecture Multi-org access control features Centralized banking model Advanced global intercompany system
29
the little r12.1.3 upgrade essentials Transformation Benefits Shorter project duration with fewer resources translates to lower costs. Repeatable results, reusable as requirements change. Requires less than half the time and resources of consulting efforts. Accurate, consistent results (no need to worry about different coding styles, standards, skill levels, corrupting database, differences in different versions). Eliminates need to qualify consultants on technical skills. Maintains database integrity. Retains all history. Avoids reimplementation. Reduces risk. No Oracle Application software is changed or customized. No need for external mapping, data warehouse or reporting to reconcile different businesses. Make the most of existing resources. An eprentise Reimplementation Success Story A global leader in the mining industry needed to consolidate over 25 different charts of accounts into a single global chart of accounts. They used eprentise FlexField software to percolate changed accounting flexfield code combinations to each subledger of E-Business Suite for setup data and all transactions. All code combinations were changed and there was no on-going reconciliation between old and new charts of accounts. The results were a standard global chart of accounts, consistent reporting and a simplified financial consolidation process. All historical transactions were changed to reflect the new chart of accounts resulting in operations and reporting that looked as if the company had always been doing business using its new global chart of accounts.
30
Chapter 1 Plan to Upgrade fndload see the paper, Customization Survival Guide: How to Use EBusiness Utilities to Migrate Your Custom Code, by Brad Simmons and Donna Campbell. FNDLOAD can be used to: transfer Request Groups, move Concurrent Programs, and download and upload Forms Personalizations migrate Key FlexFields, Descriptive Flexfields, Responsibilities and almost every other FND entity transfer value set definitions
exp/imp Oracles original export and import utility. Datapump - For RDBMS Versions 10g and 11g, you can use DataPumps expdp and impdp utility. This tool is much faster than Oracles older exp/imp utility. DataLoad - DataLoad will load data into any application and contains extra functionality for loading data and setup into Oracle E-Business Suite. A number of loading technologies are provided so that the most appropriate approach can be chosen for the target application. DataLoad will load data via an application's forms, which may be browser-based Self Service forms or core/professional forms, or data can be loaded directly into a database. SQL Plus - SQL*Plus, the primary interface to the Oracle Database server, provides a powerful yet easy-to-use environment for querying, defining, and controlling data. SQL*Plus delivers a full implementation of Oracle SQL and PL/SQL, along with a rich set of extensions. Open Interfaces - Open Interfaces refers to a programming interface, usually a database table, that automates the execution of Oracle APIs. You can use the Oracle Integration Repository (iRep) to view all the interfaces in the E-Business Suite in one place. The E-Business Suite Plug-in - this is an added cost set of tools that supports security, cloning, customization, patching and setup for the EBusiness Suite. These tools provide a framework around tools like iSetup, but also offer new functionality, including the ability to document your customizations.
31
ConfigSnapshots planning capability enables organizations to design their configurations prior to deploying them to a new environment. Far more flexible than relying on manual documentation methods, it allows you to report flexibly on your plan and also to ensure that the planned setups are correctly configured in the environment itself.
32
ConfigSnapshots comparison capabilities enable you to ensure that all setups are correctly deployed across environments as the project progresses.
33
Baselines enable you to capture setup at key stages of the project; allowing you to control the changes made during each phase.
Comprehensive security reporting, including segregation of duties, allows you to ensure that users have only the required access to perform their duties
34
35
36
37
Database Replay
Database Replay makes it possible to capture a workload on a production system with negligible performance overhead, and replay it on a test system with the exact timing, concurrency, and transaction characteristics of the original workload The Database Replay process can be broken down into the four steps described below: 1. Workload Capture When workload capture is enabled, all external client requests directed to the Oracle server are stored into compact capture files on the database host file system, while incurring negligible overhead. These files contain all relevant information about the call needed for replay, such as SQL text, bind values, wall clock time, SCN, etc. The workload capture start and end time, as well as criteria for targeted capture (e.g., by user, service, action, etc.) can be specified by the user. The workload captured on Oracle Database Release 9.2.0.8 and higher can be replayed on an Oracle Database 11g release. Workload capture and replay in shared-server environment is also supported.
38
2. Workload Processing Once the workload has been captured, the information in the capture files has to be processed, preferably on the test system. This processing transforms the captured data and creates all necessary metadata needed for replaying the workload. 3. Workload Replay Before performing workload replay, the test system has the intended system change applied and database restored to the point in time before the capture started, using various mechanisms such as RMAN backups, Oracle Database 11g Snapshot Standby, Datapump export/import, etc. The replay can be configured appropriately to re-map connection strings, database links, and directory objects to that of the test system. Once replay is initiated, a special client program called the replay client replays the workload from the processed files. It submits calls to the database with the exact same timing and concurrency as in the capture system and puts the exact same load on the system as seen in the production environment. The replay driver automatically re-maps physical locators and preserves sequence numbers or GUIDS during replay. The replay driver is client-agnostic and uses a scalable multi-threaded architecture with support for client estimation and running on multiple hosts. There are various options that are available to control the behavior of the replay, such as to scale up or down the think and login times, and maintain commit synchronization. These are useful for throttling the user call rate to the database. 4. Analysis and Reporting Extensive reports that encompass both high-level summary and detailed drill-down information in terms of errors, performance and data divergence are provided to help understand how the replay fared in comparison to capture or other replays.
Maintenance Wizard
Maintenance Wizard guides you through the Applications upgrade and code line maintenance process. It helps you reduce upgrade tasks by dynamically filtering the necessary steps based on criteria it obtains from your Applications environment. The result is a set of step-by-step instructions of exactly what you need to do to complete your specific upgrade, including any critical patches that your system may require. It can also automatically execute many of the tasks for you, so as to reduce the possibility of errors or accidental omission of vital tasks.
39
the little r12.1.3 upgrade essentials With the Maintenance Wizard, you can: Automate Patching and Provisioning Automate Diagnostics and Tuning with the Diagnostics and Tuning Packs for OEM Automate Change and Configuration Management with the Change Management Pack for OEM
Upgrade Benefits: Use Shared Service Centers to Drive Cost Savings and Increase Information Quality
Where possible, you should consolidate non-revenue generating, administrative tasks into Shared Service Centers. With Shared Service Centers, you can: Eliminate redundant processes Utilize self-service Automate processes Standardize common business practices to reduce costs Help create a consolidated view of essential global decision-making information Enhance the timeliness and accuracy of data. With consistent business processes throughout the enterprise, information can be gathered uniformly, with consistent quality
Services can be shared at many different levels, and shared service centers can exist for different reasons: General Ledger Centers Receiving Centers Inventory Management Centers Procurement Centers
40
You should align the Business with the Process, and align the Process with Oracle Applications by considering the following: Application How has R12 changed? Is there new functionality that could improve the process model? Should we change our process to align with Oracle Applications processes? Do we understand Oracles long term strategy?
41
the little r12.1.3 upgrade essentials Process Integrate business changes with Oracle Applications new functionality Develop new process models. Retire/modify customizations that are replaced by new functionality Has my business changed? What are the new business requirements? What is the long term strategy for the business? Does the long term business model align with Oracle Applications long term strategy?
Business
Identify business areas that should adopt best practices that may differ from current business practices Align the Business Model with the Process Model and Oracle Applications
Aligning the business with Oracle Applications can be accomplished by modifying the business to match the process and customizing Oracle Applications to match the process. Most businesses are reluctant to change, and instead prefer to bring the process and applications into alignment with the business, as shown in the following diagram. Align the process and Oracle Applications to match the business
42
One of the best options is to convince the business to adopt vanilla processing and change the business and process to match the functionality provided by Oracle Applications. This works best for small and medium sized businesses, as large business may significantly benefit from customizations.
43
TruTek detailed assessments typically have three phases: Audit, Investigate, and Report: The Audit phase of the functional assessment identifies the current issues, documents the AS IS processes and documents the TO BE processes. The Investigate phase of a functional assessment is more detailed than the Audit phase and includes functional application tuning and a review of setups, since they can affect performance. The primary goal of the investigate phase is to improve functional processes and to review user defined functions and fast formulas, if present. The Report phase of the assessment defines the issues, recommends solutions and summarizes process improvements.
44
45
Customization Assessment
Start by identifying all customizations. In some environments the customizations arent well documented and some customizations may have been lost due to previous patching. Check-in all customizations into configuration management. Customizations are easier to customize if you can find them and have some version control. Determine the customizations that are replaced by new R12 functionality. This requires an analyst that knows the new functionality of R12 and understands the customizations. Finally, determine the customizations that need to be fixed or added to the upgrade to preserve or extend the process alignment.
Architecture Assessment
The Architecture Assessment investigates the implementation of more advanced configurations, depending on the requirements, including the following: Shared Disk SAN, NAS, NFS Shared disk is required for RAC, for each node to access the same disks. This is also required for a Shared Apps Tier and distributed AD. Shared disks come in three primary flavors: SAN, NAS and NFS. RAC Many companies require continuous database operations, and Real Application Clusters (RAC) is a possible solution. RAC can also be used for companies that need to scale quickly. With RAC, you can add another server to the cluster relatively quickly. The performance issue with RAC is pinging, not the classic disk block pings, but cache block pings across the inter-connect. While cache pings are roughly 100 times faster than disk pings, large volumes of pings can create database waits, queuing, and degraded performance. The best method to resolve this issue is to partition the application, so the data is mostly used in the cache of one server. RAC is not free and the maintenance of RAC is not free. The necessary hardware environment will have shared disks, probably a SAN; backups and clones must use RMAN. Shared Application Tier with Distributed Processing If there are four applications servers connected to shared disks and we run adpatch in distributed mode, each application server can be
46
Chapter 1 Plan to Upgrade assigned a range of workers that run patch jobs in parallel, while each server accesses the same files on shared disk. For example, Start 5 workers on each machine, by running the following command on each application server: adpatch localworkers=5 workers=20 The following diagram illustrates four application servers, each running 5 adpatch workers. This allows the patch to be applied simultaneously on each application server, and to run the patch more quickly because the workers are run in parallel.
Without shared disk, each patch must be applied separately on each application server. The shared disk will have a path to the software that includes the <CONTEXT_NAME>, the combination of machine name and instance name. Parallel Concurrent Processing Parallel concurrent processing allows distribution of concurrent managers across multiple nodes. Benefits are better: performance, availability and scalability (load balancing). With parallel concurrent processing implemented with GSM, the Internal Concurrent Manager (ICM) tries to assign valid nodes for concurrent managers and other service instances. When one node is not available, the managers that are defined with PCP fail over to another machine.
47
Most users dont know how to restart a failed job. Therefore, if a concurrent manager is not set up with PCP, it will terminate running jobs upon failure. Users will see that their jobs have failed and call to request assistance in restarting the job. With PCP, when a failure occurs, the system can use PCP to automatically restart the concurrent managers that are defined to fail over to another machine. This avoids calls to the help desk and the system administrator.
Hardware Assessment
If the upgrade plan includes buying new hardware, consider migrating from the current 32-bit platform to a 64-bit platform. Reasons to migrate to a 64-bit environment include: Release 11i doesnt support running the Application Tier on a 64-bit hardware platform; however, Release 12 does support 64-bit architectures for the Application Tier. Release R12 supports running the database on a 64-bit operating system, in a split or mixed architecture There are five hardware platforms supported for Release 12, and all of the platforms support a 64 bit version There are less memory restrictions on a 64-bit machine because of additional addressable memory Because of more addressable memory, more users can be supported on each Application Tier
48
Chapter 1 Plan to Upgrade MRP and other programs run much more quickly in a 64-bit database
Subledger Architecture
A Set of Books (Release 11i) becomes a Ledger with its own Ledger Set, in Release 12. SLA will return the same accounting as the earlier accounting engine did. If the MO:Operating Unit was defined in Release 11i, after the upgrade MO:Operating Unit will be set the same.
49
Benefits include the new Subledger Accounting model, XML publishing applied to reports, additional DBI portlets and pages, AR-AP netting, and gross margin analytics in AR.
50
If both 'MO: Security Profile' and 'MO: Operating Unit' are defined at a responsibility level, then 'MO: Operating Unit' will be ignored and 'MO: Security Profile' will be effective. MO:Operating Unit is preserved through the upgrade, so if it was set in the previous release, it will be set in Release 12. If you dont want to implement MOAC features in Release 12, no additional setups are required.
51
the little r12.1.3 upgrade essentials Responsibility-level profile options will apply to all OUs of the security profile. Other new features include improvements in Multiple Reporting Currencies, E-Business Tax and the Payments modules.
52
53
the little r12.1.3 upgrade essentials If you have customizations, usually the developers can't (and probably shouldnt, for separation of duty reasons) implement customizations; they need a DBA to handle this. On upgrade weekend, dealing with customizations is a significant task. When the DBAs are at the end of their rope, you need someone awake and responsive to handle the customization tasks. Otherwise, an overworked, overtired DBA may make mistakes. Finally, you need two DBAs that can tag team effectively during the upgrade and keep the upgrade running. Often, one DBA will be tasked with email and communications while the other DBA works through the upgrade tasks. Sometimes, they may even get some sleep.
54
Chapter 1 Plan to Upgrade Testing Manager Report progress of priorities as established by the Steering Committee
Steering Committee
The Steering Committee is quite often established as a democracy with the CIO and CFO having veto power. The Steering Committee has some very important responsibilities: maintain executive support, supervise the gathering of user requirements, document upgrade success factors, and prioritize goals/issues. The Steering Committee should also measure progress against user success factors and report to the executive team. The Test Manager can work with the Steering Committee to organize users to execute test scripts, and document users issues.
Upgrade Tactics
Release 12.1 upgrades are complex, long running exercises filled with thousands of tasks that must be done consistently each time. Because of the massive opportunities to make mistakes, a strategy that minimizes backup/restore time is absolutely necessary. You need to minimize the amount of time and risk required to restore the old database and application tiers. You also need to simplify the tasks and minimize the time required to implement customizations. As you plan your upgrade, you should assume 5-10 iterations of the upgrade will be necessary to fix the issues encountered. As you approach the upgrade, consider these tactics:
55
the little r12.1.3 upgrade essentials 1. Minimize the time for each upgrade for everyone involved. 2. Simplify the R12.1 upgrade tools, data, project management, and architecture. 3. Consider the R12.1 upgrade to be an iterative process: measure, evolve, and optimize as you iterate, tracking changes carefully as they are made. 4. Build a strong foundation for the technical team: o Maximize IO bandwidth and minimize IO latency. o Use a machine that is faster than the current production system. Use another machine for testing and training. o Avoid doing an in place upgrade. o Give the Applications Tier and the Database Tier a large amount of disk space. 5. Build a strong foundation for the functional team: o Ensure adequate testing develop and execute test plans. o Consider your testing methodology for the R12.1 upgrade. Do you need Technical, Functional, and Load Testing? o Include training both before and after the upgrade, and provide exposure to an R12 system and tools early in the upgrade process.
56
Chapter 1 Plan to Upgrade Project managers can feel some satisfaction, when they allocate the money and time required for the upgrade. However, without the right skills the upgrade will probably fail. Even with all the right skills, issues with teamwork can cripple the upgrade.
The range of values is to allow for different levels of proficiency that may exist in an organization before the upgrade begins. For example, if the testing process in your company is well established and accurate, the minimum percentage of 15% of the budget should be acceptable.
57
the little r12.1.3 upgrade essentials Customization Costs Customization costs can inflate the lifecycle effort cost by at least 70%, when compared to non-customized systems. The actual complexity and required effort cost may be much higher
Skills
Organizations and their employees understand their business processes better than most external consultants. However, companies usually upgrade and/or consider business process changes relatively infrequently, for example, every five years. Consultants that focus on upgrades and implementations may not understand the detail of your business processes as well as your functional superusers, but they understand the new features of Release 12 and the resulting consequences for your business. They can work with your experts to efficiently identify existing and future functional gaps between your business process and the process Oracle Applications uses. Good consultants have exposure to many clients and can use this knowledge to suggest best practices based on similar clients. Identify Skill Gaps in Your Upgrade Team Your upgrade team should be capable and experienced with upgrades and should understand the new functionality of R12.1. The following four primary skills are critical to the success of your team: 1. Testing 2. Functional Analysis 3. Customizations 4. Technical Upgrade If your team lacks expertise in these skills, often the best way to get through an upgrade is to supplement your staff with upgrade experts; consultants who have been through several upgrades who can fill gaps in expertise and mentor and guide your teams to use established best practices. Upgrade experts understand the R12.1 new functionality and they can efficiently integrate your companys business processes and customizations with R12 and can help improve your testing processes and increase the probability of success for your upgrade. An additional way to fill gaps in expertise is to have functional consultants conduct formal training on-site, using client specific environments. This can reduces redundant learning curves that result
58
Chapter 1 Plan to Upgrade from multiple consultants providing new features training separately from the consultants that are providing the R12.1 gap analysis.
Teamwork
The upgrade will not succeed without TEAMWORK. Communication is essential. The upgrade team is not intended to be a democracy, but unwilling team members can slow down and cripple otherwise viable upgrades. The upgrade manager is responsible for picking the team members. He is also responsible for firing disruptive team members and replacing them with the best available team member. If the Steering Committee cant find a mutually agreeable internal candidate, sometimes a neutral external consultant can be the best choice. Teamwork is the concept of people working together cooperatively, as in a sports team. Many large, ambitious projects require that people work together, so teamwork has become an important concept in organizations. Industry has seen increasing efforts through training and cross-training to help people to work together more effectively and to accomplish shared goals, whether colleagues are present or absent. Team Obstacles There are a number of issues that can decrease a teams effectiveness: Infighting - Effective teams don't have to be made up of people who like each other, but there must be mutual respect. Without respect, misdirected energy can turn to bickering and undermining colleagues. Team members must be willing to set aside petty differences Shirking Responsibilities - When members avoid taking responsibility for both running of a group and for specific assignments, a team becomes a "pseudo team"; i.e., a team in name that consistently underperforms. Lack of Trust - If trust is lacking, members are unable to depend on each other. Critical Skill Gaps - When skills are lacking, teams flounder, members have trouble communicating with each other, destructive conflicts result, decisions aren't made, and technical problems overcome the group.
59
Minimize Risk There are a number of steps that a team can take to minimize risk: Improve Testing Proficiency - Test scripts should be run after each patch or clone in order to ensure accurate patching or cloning steps. If testing is not efficient, practice testing more often until critical tests can usually be completed in 4-6 hours. Enable Fast Backup and Restore - with block virtualization or snapshots. The key to fast, efficient upgrades is to do several upgrade iterations to identify and resolve critical issues. Cloning can become a major bottleneck during test upgrades, and especially during the production upgrade. The ability to restore in a few minutes saves time and money when compared to 4-8 hour restore times. Independent DBA and Developer Instances - Let the DBAs and Developers practice their piece of the upgrade in independent environments, separate from DEV or TEST. Reduce Scope - Decouple other projects from the upgrade: new modules, fix customizations, hardware migration, and new business processes. Load Test - to avoid career limiting, Go Live capacity issues, perform load testing if there is any question about system capacity. For example, if the upgrade includes implementing Oracle Time and Labor for a large number of employees - more than 1000 - then load testing is highly recommended. The Team Must Recognize Competing Priorities An upgrade is rarely just an upgrade it is tempting to pile on additional changes in order to accomplish as much as possible. Your team may have to decide about whether to include hardware migrations, data cleanup and data archival, new modules, and customizations in the upgrade plan. Hardware Migrations are generally outside the scope of normal upgrades, however, if well planned, hardware migrations can be accomplished with a little extra time and without too many extra testing cycles. Hardware migrations, depending on the size and whether disk snapshots are in use, can be completed with one extra day. Data cleanup and data archival are two tasks that should be on-going. It is especially important, in order to reduce the downtime, to perform data cleanup and data archival before the upgrade begins. Data errors
60
Chapter 1 Plan to Upgrade discovered during the upgrade should be investigated for possible bad processes and resolved. Implement new modules either before or after the upgrade as separate projects. In some cases, it makes sense to implement new modules during the upgrade. Customizations that have changed because of an upgrade must be migrated. When possible, use a separate project before the upgrade to investigate the feasibility of migrating customizations to a Service Oriented Architecture.
Gap Analysis
Gap analysis requires superusers/functional analysts that understand the new features of R12.1 and understand the existing customizations. Gap
61
the little r12.1.3 upgrade essentials analysis is the process of aligning the business process with Oracle Applications. The gap can be resolved by changing the business process to use the Oracle Applications process or providing a customization to fill the gap between the existing business process and the functionality that Oracle Applications provides. Further investigate the functional gap by examining the following: Reasons for the change and areas that benefit from new functionality Functionality that is temporarily disabled or has been made obsolete Changes to user interfaces, terminology or concepts, and menu options
Known Gaps
In our experience, the following gaps are encountered in typical R12 upgrades. By raising awareness of these gaps, planning for them, and proposing cost effective add-ons, a painful upgrade experience can be avoided entirely. Financial Reporting Gaps With an R12 upgrade, Client ADI is replaced by Report Manager for the publishing of FSGs into Excel. Client ADI used to allow users to produce ad-hoc FSG reports, but the new Report Manager was designed for storing point-in-time reports. Report Manager was not designed as an ad-hoc enquiry tool and does not allow users to easily define or modify reports. Users submit ad-hoc FSG or standard reports from the Report Manager, but they must re-create each template in a special editor before its first use. Also, while FSG reports are still published to Excel, HTML, PDF and text formats, submitting an FSG report from R12 becomes a five-step process, which increases report submission time compared with Client ADI. For complex reports, users relate that R12 submission takes up to five times longer per report than with Client ADI. Reports must be saved in a repository, where chronological instead of alphabetical storage makes access to recent reports difficult and counterintuitive. Clearing out reports is also time consuming and requires running a batch job to delete old reports.
62
Chapter 1 Plan to Upgrade Drill Down Restrictions Client ADI used to allow drill down to transactions for amounts in an FSG report published to Excel. The drill down feature displays journal entries associated with the amount queried and supports further drilling to related sub-ledger transaction details. R12 only supports account analysis and drill down for reports published through the Account Analysis and Drilldown function in Report Manager. Many users have found this function cumbersome and report an increase in time required for viewing data. Sorting and searching data are also time consuming and limited in scope. Limited Chart of Accounts Access With Client ADI, users had a graphical view of the chart of accounts (COA) hierarchy. This feature allowed users to understand and traverse the structure of each segment in the COA, which was especially useful for new employees. The graphical COA was replaced by a Java-based form in the R12 GL module that is now only accessible by system administrators and designated business analysts. For the feature to be accessible to all users, the form must be moved to an unrestricted area within the GL menu. MS Word Becomes the Report Layout Editor To produce ad-hoc reports without Report Manager, Oracle users can submit a Publish FSG Report request via the standard request submission form. While this method does allow users to produce any FSG report, the report layout templates used are built with Microsoft Word and do not offer the same flexibility as an Excel editor. Another complication is that all templates built using an Excel editor must be rebuilt in Word to use this report creation method.
63
the little r12.1.3 upgrade essentials Excel-based GL Wand makes an attractive option, both from a price and user acceptance standpoint. Because finance users have strong Excel skills, they easily create and modify ad-hoc reports in just minutes through the familiar Excel interface in GL Wand, without programming support. Reports are similar to those they are accustomed to from Client ADI, yet the process is much faster that with either Client ADI or the new Report Manager. GL Wands real-time results are obtained more quickly than with FSGs or boxed Oracle reports, allowing users to work more efficiently. With this Excel-based reporting tool, users can access up-to-the-minute GL data. Finance users can also drill into subledger transaction details in just a mouse click with GL Wand, which utilizes Oracles security settings to maintain appropriate data accessibility. They can quickly view set-up information relating to the GL, including the COA and its hierarchies. Users report that submitting ad-hoc reports that took 15 minutes with Client ADI and 45 minutes with Report Manager take less than five minutes with GL Wand, leaving more time for valuable analysis and less time for frustration. The IT staff also benefits from GL Wand on many levels. The software installs quickly with minimal IT intervention, and users typically perform upgrades. IT is also less burdened with programming required for reports, because finance users are self-sufficient in running their own queries and creating their own reports. For organizations already invested in customized FSG reports, a GL Wand conversion tool easily converts existing reports into Excel. Overall, it is important for users to take into account the effects of an Oracle EBS R12 upgrade, or even reimplementation, on the GL reporting process. Understanding these effects and identifying available solutions like GL Wand can not only satisfy the GL reporting requirements of finance users without impacting IT, but also improve financial reporting processes altogether. An intuitive product like GL Wand can easily be trialed with minimal effort during an upgrade project, validating the expected benefits prior to purchase.
64
Customizations
Customizations and Modifications can help align the business with Oracle Applications.
Customizations can save the business money by filling critical gaps in functionality and allowing the business to function more efficiently. However, the design, implementation, maintenance and upgrade of customizations are neither cheap nor painless. In many cases, new functionality that is standard in a newer release of Oracle Applications may replace some customizations. It is primarily the responsibility of the functional analyst to identify, document and eliminate customizations that are replaced by seeded functionality. All customizations should be identified and documented. Some customizations may be able to be migrated to Service Oriented Architecture (SOA) and provided as a web service. There are two basic flavors of Oracle Applications: 1. Out Of The Box, OOTB or non-customized, also known as Vanilla. Vanilla assumes that OOTB processes will work at least 80% of the time. Vanilla can be effective because the focus is on the true gaps that require customization. Gap analysis is more effective because the scope is narrower and scope creep will be less.
65
the little r12.1.3 upgrade essentials 2. Customized Oracle Applications. There are 19 different types of customizations, modifications, and extensions. Vanilla Applications may have modifications and extensions but will have very few customizations (objects that may be replaced during upgrades or patching).
Customized Oracle Applications assumes that more than 20% of the code will be custom. This requires analysts that understand the current and future business processes. This can require significant time spent understanding current process flows. Abstract thinking required for detailed gap analysis can be difficult for inexperienced upgrade analysts and lead to excessive scope creep. Simplification and alignment are more difficult without Customizations.
Small improvements can yield large dividends over time. However, as the size of the operation decreases, the percentage improvement must increase in order to make the customization worth creating and maintaining.
66
Cost - Benefit Analysis for Business Process Improvement for Smaller Implementations
In the following example of a small implementation, the initial implementation cost is $300,000. With annual operating costs of $1 million, the business was able to implement business process improvements that lowered operating costs by 10%. Over five years the business saved $500,000. The customizations cost an additional $60,000 per year to maintain, because of patches that affect the customizations. In the fifth year the business completed an upgrade. The five year total costs are $250,000 for the customizations.
However, in this scenario the business was able to implement business process improvements that lowered operating costs by 20%. Over five years the business saved 1,000,000. The customizations cost an additional $60,000 per year to maintain, because of patches that affect the customizations. In the fifth year the business completed an upgrade. The five year total cost savings are $250,000. Annual Operation Costs 1,000,000:
67
While cost savings is relative, this example illustrates the value of customizations in organizations that can effectively design and implement business process improvement and integrate those improvements with Oracle Application by using customizations.
The technical view of success depends on applying the correct patches in the right order, installing and configuring new hardware, and
68
Chapter 1 Plan to Upgrade implementing customizations that satisfy the functional gap requirements.
Patches
Getting the right list of patches in the right order for compatible hardware is one of the more important tasks. the little r12.1.3 upgrade guide and the little r12.1.3 project plan have a list of all the patches that weve encountered in our upgrade classes and consulting engagements, in the order they should be applied . The following section explains the new upgrade patch types that have been introduced since Release 11.5.10.2.
Upgrade Patch Types Release 12.0 Critical Patch Collections (CPCs), Oracle E-Business Suite Pre-install Patches, Financials RPCs, Generic Data Fixes (GDFs), CPUs, PSUs
Release 12.0 Critical Patch Collections (CPCs) Oracle Financials Release 12.0 Critical Patch Collections (CPCs) are consolidated critical patches that all Release 12.0 Oracle Financials customers must apply to ensure proper operations of their systems. CPCs are specifically targeted for Oracle Payables and Receivables, and include dependent fixes for Subledger Accounting, Tax, and Payments. See MOS Doc. ID: 557869.1, EBS: R12 Oracle Financials Critical Patches for links to the latest Critical Patch Collections (CPCs). Advantages of applying CPCs over one-off fixes and RUPs are as follows: CPCs are fully quality assured against current RUP levels. Individual one-off patches are not. CPCs are consolidated and only contain critical patches that apply to broad customer usages. They are smaller in footprint and therefore much easier to apply and uptake than RUPs. CPC Readmes have detailed business and functional information about the fixes included. Customers can leverage the Readmes to determine impact and testing required for specific process flows and software components involved.
For the Release 12.1.3 upgrade, the CPCs are applied after you install Release 12.1.1 with RapidWiz.
69
the little r12.1.3 upgrade essentials Oracle E-Business Suite Pre-install Patches According to MOS Doc. ID: 1448102.1, Oracle E-Business Suite Preinstall Patches Report [Video], The Oracle E-Business Suite Pre-install Patches Report provides a list of essential patches that you must apply in pre-install mode before upgrading from Release 11i to Release 12.1. This report serves as a single point of reference for upgrade-related patches that can ONLY be applied prior to running the main upgrade driver for Release 12.1. These pre-install patches help you avoid certain upgrade script failures, upgrade performance issues, and data corruption and upgrade integrity issues. These patches are merged with the R12.1 EBS Consolidated Upgrade Patch 1 (CUP1), Patch 7303029. The patchlist may be updated monthly by Oracle, so you should re-check the list periodically during an upgrade. Recommended Patch Collections (RPCs) See MOS Doc. ID: 954704.1, EBS: R12.1 Oracle Financials Recommended Patch Collection (RPC) for links to the latest recommended patches by Oracle Development after the EBS 12.1 was released. Oracle E-Business Financials Recommended Patch Collections (RPC) for R12.1.3 are consolidated critical patches that all Release 12.1 Oracle Financials customers must apply to ensure proper operations of their systems. CPCs are specifically targeted for Cash Management, Collections, E-Business Tax, Financials for India, Fixed Assets, General Ledger, Internet Expenses, iReceivables, Loans, Payables, Payments, Receivables, and Subledger Accounting. According to MOS Doc. ID: 954704.1, the RPCs are created with the following goals:
Stability: Address issues that occur often and interfere with the normal completion of crucial business processes, such as period close--as observed by Oracle Development and Global Customer Support. Root Cause Fixes: Deliver a root cause fix for data corruption issues that delay period close, normal transaction flow actions, performance, and other issues. Compact: While bundling a large number of important corrections, we have kept the file footprint as small as possible to facilitate uptake and minimize testing.
70
Reliable: Reliable code with multiple customer downloads and comprehensive testing by QA, Support and Proactive Support.
If a RPC becomes available after you complete your upgrade, you should research the RPC and consider implementing it at some point to your environment. Generic Data Fixes (GDFs) Generic Data Fixes (GDFs) are patches created by Oracle Development to fix data issues caused by Bugs/Issues in the Application Code. See MOS Doc. ID: 1360390.1, R12: Master GDF Diagnostic to Validate Data Related to Invoices, Payments, Accounting and Suppliers [Video]. Also see MOS Doc. ID: 874903.1, What is a Generic Datafix Patch (GDF) and what GDFs are available for Payables? [Video]. Note that Oracle includes an important point in MOS Doc. ID: 1360390.1, R12: Master GDF Diagnostic (MGD) to Validate Data Related to Invoices, Payments, Accounting, Suppliers and EBTax [VIDEO]:
IMPORTANT: In conjunction with the diagnostic described in this note, R12.1 customers should review the notes indicated below which describe the Recommended Patch Collections (RPC) for related products. The vast majority of the data integrity issues detected by this diagnostic could be proactively avoided by applying the RPC's for these products: Doc ID 1397581.1: R12.1: Payables Recommended Patch Collection (AP RPC) Doc ID 1481235.1: R12.1: E-Business Tax Recommended Patch Collection (ZX RPC) Doc ID 1481221.1: R12.1: Payments Recommended Patch Collection (IBY RPC) Doc ID 1481222.1: R12.1: Sub Ledger Accounting (SLA) Recommended Patch Collection (XLA RPC)
Note that the list of MOS documents may change as RPCs evolve, so check MOS Doc. ID: 954704.1, EBS: R12.1 Oracle Financials Recommended Patch Collection (RPC) to track the RPCs. Critical Patch Updates (CPUs) A Critical Patch Update (CPU) is a collection of patches that address multiple security vulnerabilities. It also includes non-security fixes that are required (because of interdependencies) by those security patches. Critical Patch Updates are cumulative, except as noted, but each advisory describes only the security fixes added since the previous Critical Patch Update. Thus, prior Critical Patch Update Advisories
71
the little r12.1.3 upgrade essentials should be reviewed for information regarding earlier accumulated security fixes. Critical Patch Upgrades (CPUs) are released quarterly. When you upgrade to Release 12.1, you should plan to apply the latest available CPU. You should look for the latest CPU on My Oracle Support and add it to your upgrade plan. We recommend applying the CPU patches on another weekend following the upgrade. However, if time allows on the R12.1 upgrade weekend, it is possible to apply the latest CPU. Patch Set Updates (PSUs) - Patch Set Updates (PSUs) are database patches. The PSU strategy is to deliver low-risk, high value content that has a limited scope and is thoroughly tested. This new type of patch collection was introduced in July, 2009. See My Oracle Support Knowledge Document 854428.1, Intro to Patch Set Updates (PSU) for more details about PSUs. According to My Oracle Support Knowledge Document 854428.1, Intro to Patch Set Updates (PSU): Patch Set Updates (PSUs) are proactive cumulative patches containing recommended bug fixes that are released on a regular and predictable schedule. PSUs are on the same quarterly schedule as the Critical Patch Updates (CPU), specifically the Tuesday closest to the 15th of January, April, July, and October. The Patch Set Updates include a Cluster Ready Services (CRS) patch. Like the Database server patch, the CRS patch is a well-tested, low-risk patch of recommended fixes. Use Patch Wizard from Oracle Application Manager (OAM) The E-Business Suite includes a tool called Patch Wizard that is part of Oracle Application Manager (OAM). You can use Patch Wizard to help you determine if there are available recommended E-Business Suite patches. Patch Wizard will even automatically download them, which is easier than locating the patches through My Oracle Support and downloading them from there. While Patch Wizard does have its flaws it does not currently, for example, locate prerequisite patches it does make the research effort less painful and does find a good percentage of patches. We use Patch Wizard in two critical areas of the upgrade, for the Release 11i Mandatory Extended Support Patching Exercise, and after upgrading to Release 12.1.3, to find additional patches that have yet to be uncovered.
72
Chapter 1 Plan to Upgrade Use Patch Wizard for the Release 11i Mandatory Extended Support Patching Exercise As part of the preparation for upgrading to Release 12, we recommend that E-Business Suite clients bring their Release 11i environments up to the standards documented in My Oracle Support Doc. ID: 883202.1. This document describes a substantial collection of patches needed to ensure that Oracle Support will provide Extended Support for your Release 11i environment while you are working to upgrade it to Release 12. Meeting the Extended Support requirements is no small feat most customers have to apply dozens of patches, many of them with daunting pre-requisites and post application steps. If youve lagged behind on maintaining your Release 11.5.10.2 environment, the Mandatory Extended Support patching effort will take several weeks, and will require considerable testing. There are two ways to figure out what patches to apply you can build a spreadsheet and use MOS Doc. ID 883202.1, which tells you all the patches that need to be applied across all modules, or you can use Patch Wizard to tell you what it thinks you should apply. Weve covered the details in our other book, the little r12.1.3 upgrade guide, about how to set up Patch Wizard so it limits its recommendations to just those modules that you have licensed, rather than all 200+ modules. Weve applied the Release 11i Mandatory Extended Support Patches both ways, using the MOS document and using Patch Wizard, and weve concluded that we prefer using Patch Wizard. The tool is not as streamlined for Release 11i as it is for Release 12, but it still gets the job done. Use Patch Wizard After Youve Upgraded to Release 12 and Think Youre Done, But, Sadly, Find That You are Not We recommend that when you finish your upgrade to what you believe is the latest version of 12.1.3, with all the patches and Family Packs identified from patchsets.sh, our other book, the little r12.1.3 upgrade guide, and your own research, you should run Patch Wizard again to see if additional patches are found. When we ran a Vision upgrade in February, 2011, Patch Wizard identified 78 more patches above and beyond everything we found for 12.1.3. Note that Patch Wizard may require patches for both Release 11i and Release 12.
73
the little r12.1.3 upgrade essentials Other Patching Reports As well as the patching reports provided with Patch Wizard you can use enhanced reports provided by other vendors. For example, ConfigSnapshot includes reports that show the functional name for affected components, such as forms and reports, making it easier for the team to determine which areas should be the focus of testing.
74
the little r12.1.3 upgrade essentials Identify columns that become obsolete during the upgrade Create a script to remove obsolete columns
Developers may need to enhance their skills with OA Framework and XML Publisher to stay current with the technology changes in Release 12.
Modifications are defined as customizations that survive upgrades.. Personalizations are an example of a modification. Extensions include reports and interfaces that are not replaced by new code from the upgrade, because these extensions are custom and not named the same as any seeded object. Extensions and Modifications usually survive an upgrade, but changes to underlying tables and objects will certainly affect this custom code. Customizations are defined as custom code objects that will be replaced by new objects during the upgrade. Custom workflows are a good example of code that will usually be replaced during an upgrade.
76
Chapter 1 Plan to Upgrade Personalizations are an example of modifications that should not be replaced or altered by the upgrade, but again, if a table upon which they rely is changed, the personalizations will likely have to be revisited. The diagram below illustrates the relationship of customizations, modifications and extensions to the upgrade.
77
the little r12.1.3 upgrade essentials Run the reports through the Concurrent Manager.
Oracle Graphics Integrations with Oracle Forms Convert both the form and the chart to an Oracle Application Framework-based application. Convert the chart to an Oracle Application Framework-based page that can be launched from Oracle Forms.
AK Mode If OA Framework-based pages have personalizations in the AK repository, then during the upgrade from Release 11i to Release 12, all custom personalizations will automatically be migrated from AK to MDS, if the AK and MDS repositories are in the same database instance. If AK/ICX Web Inquiries were used in Release 11i, use the Oracle Application Framework Search feature to recreate personalizable search regions.
78
Since the customizations the functional users have defined is the code implemented by developers, we should be able to superimpose the customization object to illustrate the relationships between the three primary perspectives.
79
Chapter 1 Plan to Upgrade determine if your menus have been customized? How about your responsibilities, your profile options, or your value sets? To help in that area, were now using 2e2s ConfigSnapshot. ConfigSnapshot identifies and documents configurations and configuration differences in the E-Business Suite over time, across instances, entities and even versions. Key features include: Ability to automatically generate BR100 style configuration documents (modules and technical development work) Configuration baselines and built in planning capability allow you to manage the introduction of enhancements and the setup of mandatory new features Clearly identify your configuration settings separately from the Oracle seeded values Directly compare configuration settings of the Oracle modules and technical components across environments, operating units, sets of books, inventory orgs, etc. View patch impact, which makes it easy to focus testing on actual changes introduced Identify upgrade impact reduce risk and uncertainty (shows any effect to your existing setups, new/obsolete data fields, new seeded data, table changes, etc.) Review and track key Oracle licence compliance metrics Identify and track customizations Audit & Compliance support user access control/ visibility, configuration change tracking, etc. Easy to install (5 minutes) and intuitive to use Cost effective
ConfigSnapshot provides the capability to automatically detect the majority of customization types. In addition, it provides a Customization Impact Analysis process that will check every identified customization for references to objects that Oracle has indicated have changed between versions; this is based on Oracles EBS Data Model Comparison Report. Rather than having to manually review all of your code searching for changed objects, this can now be done automatically. As well as listing the affected objects it has found, the impact analysis will even show you where in the code you have included the objects.
81
the little r12.1.3 upgrade essentials This allows technical resources to focus straight away on how the code should be updated to function correctly in the upgraded environment. Last of all, we recommend research on My Oracle Support, and training. TruTek offers classes that describe the new features of Release 12. Our instructors particularly enjoy working through students real life examples, and have commented that oftentimes E-Business Suite Release 11i customers are using workarounds and customizations for functionality that is already available as part of Release 11i. We can also bring our instructors onsite for consulting engagements, where they can help your functional users determine if a customization really is needed in the Release 12 world.
82
Failure is natures plan to prepare you for great responsibilities Napolean Hilll
Practice Testing
To prepare for testing, the test manager should review the test scripts with the superusers. Periodically, after clones or large patches, the superusers should run the test scripts to ensure they are efficient at executing them. Testing resources should be dedicated to the upgrade projects. Upgrade testers should be the most knowledgeable users and the most likely to find issues. Sometimes its not possible to get the best personnel to be dedicated to the upgrade project. In this case, it is OK to borrow them, but they should not be your primary testing resources.
Maintenance Wizard
The Maintenance Wizard provides a step-by-step, graphical user interface for performing upgrade tasks, and consolidates instructions from multiple sources to present a comprehensive upgrade picture. It reduces upgrade tasks by filtering out those that do not apply to you (using TUMS) and indicates critical patches that your system requires. The Maintenance Wizard can automatically execute upgrade tasks for you If possible, complete the following prior to the R12.1 upgrade weekend:
83
the little r12.1.3 upgrade essentials Upgrade the Database to 11.2.0.3 Migrate to OATM Install the R12.1 software Run pre-upgrade Downtime Reducing steps Run pre-upgrade verification steps
Upgrade by Request
You can, if you choose, upgrade the most important data - the last fiscal year or other periods - during the upgrade downtime, and upgrade the rest of the historical data later for some of the E-Business Suite modules. The products that use Upgrade by Request are: Customer Relationship Management (CRM) Financials and Procurement Projects Supply Chain Management
See My Oracle Support Knowledge Document 604893.1, R12: FAQ for the SLA Upgrade: SLA Pre-Upgrade, Post-Upgrade, and Hot Patch. A historical data upgrade depends on the product. For some products, only SLA data will be upgraded, and for others, both transactions and accounting data will be upgraded. Implementation is a two step process: 1. Set the range of periods of the historical data to be upgraded before the R12 Upgrade and run the pre-upgrade concurrent programs 2. Run the SLA post upgrade (upgrade by request option) after the R12 upgrade Review Appendix G in Oracles R12 Upgrade Manual for more details
84
Chapter 2 Prepare to Upgrade least six periods in the upgrade (if the upgrade is performed in the first half of the fiscal year).
Set of Books: Set of Books to be upgraded where you have selected to upgrade one Set of Books. Start Date: Date used to determine the first period to be upgraded. The first period is the first period the Start Date falls in; it does not have to be the starting date of the first period. The start date can be changed to a date earlier than the 6 months minimum, but not shortened to less than the default.
You may need to run the SLA Pre-Upgrade program if you are using Oracle General Ledger and at least one of the following subledgers: Assets Cost Management Payables Receivables
85
This optional program allows you to change the default number of periods of historic data to be upgraded. The Release 12 SLA Pre-Upgrade program considers the following modules: Payables Receivables Purchasing Project Accounting Inventory/Costing Fixed Assets (Fixed Assets uses GL periods)
The SLA Pre-Upgrade program uses the GL_PERIOD_STATUSES table. The MIGRATION_STATUS_CODE column indicates the status of the record in the GL_PERIOD_STATUSES table: P = Pending Upgrade - The system is preparing to upgrade the accounting periods in this table that have a status P. The accounting transactions in these corresponding accounting periods will be upgraded from Release 11i to Release 12 by the Subledger products (i.e, AR, AP etc). U = Upgraded - The accounting records have been upgraded from Release 11i to Release 12 N = New - Only used by GL <blank> = These records do not meet any of the criterion mentioned and will therefore not be considered in the upgrade. The parameters for the SLA Pre-Upgrade program are: Upgrade all Sets of Books, or The specific Set of Books and the Start Date.
The Release 12 SLA Pre-Upgrade Program tags the accounting periods in the GL_PERIOD_STATUSES table with P for pending upgrade when the records are for AP, AR, Project Accounting, FA, Inventory/Costing and PO products only. No other products are considered by this pre-upgrade program
86
Adjustment Periods
The accounting period under consideration must be a NONAdjustment period. Adjustment periods are not upgraded because the upgrade that was designed by the Subledger Product teams (AP, AR etc) caters to the transactions created by those products and posted to GL. Typically, the Subledger Product teams do not generate transactions that post into adjusting periods. Given that adjusting periods overlap dates with non-adjusting periods, the logic for mapping a transaction into an accounting period is to take the GL date and figure out which non-adjusting period it falls into.
The period has a status of closed, open, future, and never opened. Note: Never opened is only applicable to the Inventory/Costing product.
87
Manage-Evolve-Optimize
Manage
Managing the upgrade consists of setting expectations for the Steering Committee, including time, money, and perceived benefits, and communicating these expectations across the upgrade team. Providing training to the superusers, users and technical staff is also part of the upgrade management responsibilities. One of the primary responsibilities of the Upgrade Project Manager is to align the business processes with Oracle Applications R12.1 and to control the subsequent scope creep. The project manager should also encourage the Steering Committee to allow the developers to migrate the customizations to a Service Oriented Architecture (SOA) when possible. Another goal of the Upgrade Project should be to implement comprehensive business reporting. While this may not be part of the upgrade, comprehensive reporting will improve the effectiveness of any release of Oracle Applications.
Evolve
To evolve, we must change and adapt, so as to not become extinct. In order to evolve, we must incorporate R12.1 new functionality and seek to replace customizations with existing R12 new functionality. Business process gap analysis should be a continuous process if you hope to evolve.
88
Optimize
One of the most important goals of the optimize phase of the upgrade is to reduce the downtime of the upgrade. Optimization affects postupgrade tasks and should improve uptime and improve the reporting capabilities, while improving the response time and reducing costs. Optimization improves the visibility and productivity of the overall system.
Aligning and Improving the Business Processes with R12.1 New Features is an Iterative Process
The iterative process of improving the business processes is dependent on improving the technology foundation, aligning the technology with business processes, creating or modifying customizations and, finally, the stage is set to improve the business process and realize cost savings.
the little r12.1.3 upgrade essentials recommend for this first iteration installing and then upgrading Oracles Vision instance, as it provides a seeded database that will allow technical team members to experience the different issues that occur with the installation and upgrade, and gives functional users an environment with all features implemented for experimenting with new functionality. Even with the best planning, this iteration usually has errors. See the little r12.1.3 Upgrade Guide for a complete walkthrough of this upgrade, with solutions to many of the issues that occur. The next iteration, labeled the 1st Pass, is the first iteration that includes customizations based on functional gap analysis. The 1st Pass also includes solutions, called fixes. These are the fixes for some or all of the issues identified in the Test iteration. This is the 1st iteration that is visible to the developers and functional analysts The second pass uses the customizations from the 1st Pass and any new customizations, plus fixes from the 1st Pass all added to the objects that are installed by rapidwiz. When there are no New Fixes, use the timings from the upgrade to predict the downtime foe upgrade weekend.
When there are No New Issues, use the timings from the performance upgrade to measure downtimes and more accurately plan for the production upgrade.
90
This guide assumes we start with Release 11.5.10.2, but the following upgrade paths show how to upgrade from earlier versions of Release 11i. Implement OATM and upgrade the database to the highest compatible level.
91
Release 12.0.0
11.5.7. 11.5.8, 11.5.9* or 11.5.10* 11.5.7, 11.5.8, 11.5.9.2, 11.5.10.2 11.5.9*, 11.5.10*, 12.0** 12.1.1 12.1.1
Release 12.0.0
4440000
Release 12.0.4
6394500
* includes CU1 and CU2 (consolidated update) ** use Release 12.1 CUP 1 The highlighted section indicates that a direct upgrade path exists from Release 11.5.7 to Release 12.0.0. The database version must be compatible with the old and new versions of Oracle Applications as shown above. If upgrading from a release prior to 11.5.7, the upgrade path may require an interim upgrade to Release 11.5.10.2. Because of the significant downtime required to upgrade from Release 11.0 to Release 12.1, it may be more feasible to first upgrade to Release 11.5.10.2 and then some time later upgrade to Release 12.1. This requires the functional users to learn Release 11.5.10.2, and perform all the testing for another upgrade. The amount of work necessary to perform two rounds of system acceptance testing may justify another day or two of downtime, so that the upgrade from Release 11.0 to Release 12.1 can be completed in one longer period of downtime. The bubbles in the following diagram show the primary upgrade paths between versions of Oracle Applications. Most EBS customers are
92
Chapter 2 Prepare to Upgrade running Release 11.5.10.2. In order to upgrade to Release 12.1.3, first upgrade to 12.1.1 and then apply the 12.1.3 patch. Notice that Release 11.0 customers must first upgrade to Release 11.5.10.2 before upgrading to 12.1.1 and then 12.1.3.
There is no database version that is certified with both Release 11.5.7 and Release 12.1. Therefore, we cant do the database upgrade separately from the application upgrade.
93
the little r12.1.3 upgrade essentials The database installed by the 11.5.10.2 RapidWiz is Version 9.2.0.6. This database version does not support Daylight Savings Time (DST). Therefore, we have two choices: Upgrade the database to Version 9.2.0.8, which has support for DST, and then upgrade to Version 11.2.0.3, or Upgrade the database to Version 10.2.0.3, using the database Oracle Home provided with the 12.0.4 EBS install, and then upgrade to 11.2.0.3.
Since we require an interim step, and we already have the 12.0.4 DVDs staged, it is easier to use the 10.2.0.3 Oracle Home than to download the 9.2.0.8 patch and apply all the E-Business Suite-specific database patches.
Upgrade Timeframe
Typically, the upgrade to Release 12.1 from 11.5.10.2 will require a 3 to 4 day weekend for downtime, starting at the close of business on Wednesday or Thursday, for a 3 or 4 day downtime window. Four day weekends usually are the best time to upgrade because the extra day of downtime has less effect on the business. The first weekend of the month is usually not a good weekend, because month-end close just occurred and month-end close processing probably hasnt finished. Similarly, during the last weekend of the month, functional analysts are getting ready to close the books. The middle two weeks of the month
94
Chapter 2 Prepare to Upgrade present the best opportunities. In 2010, Memorial Day is observed on a Monday, July 4th is on a Monday, Labor Day is on Monday, Columbus Day is on a Monday, Thanksgiving is on a Thursday with business operations on-hold on Friday during the upgrade. Christmas and New Years are horrible times to do the upgrade, primarily because of mandatory year-end processing. The database upgrade generally takes 8 to 12 hours. If the database upgrade is complete prior to upgrade weekend, it is possible to do a 2 day applications upgrade from Release 11.5.10.2. The database upgrade can be completed independently of the Release 12.1 applications upgrade. If possible, the database upgrade should be completed weeks or months before the Release 12.1.1 Upgrade. The Applications portion of the upgrade will take 14 to 32 hours depending on the speed of the server and the amount of data to upgrade. Testing will take 8-12 hours after the upgrade is complete. Backups can be time consuming and recovery should be tested before the upgrade weekend. Upgrade Downtime with the Database Upgrade
If you need to upgrade your database in the downtime window, youll need to add an extra day to your schedule. This will require the downtime to begin Thursday night.
95
Upgrade Weekend
This is a typical plan for upgrade weekend and shows the approximate times for each phase. Start the Upgrade on Friday Afternoon Clone Upgrade instance from PROD 2 hours (In many environments that can take 16 hours or longer. Get a SAN!) Plan to Upgrade Perform Category 1 Steps 4 hours These steps can be completed in PROD in advance of upgrade weekend Prepare to Upgrade Perform Category 2 Steps 6 hours These steps can be completed in PROD in advance of upgrade weekend Perform the Upgrade Perform Category 3 Steps 18 hours Finish the Upgrade Perform Category 4 Steps 8 hours Customizations 4 hours Setups 4 hours iSupplier / SSL 4 hours Perform Category 5 Steps 4 hours
96
Chapter 2 Prepare to Upgrade Developer Testing 2 hours Backup the Upgraded instance 2 hours User Acceptance Testing 8 hours Restore the Backup if Testing was destructive
97
98
"Resolve to perform what you ought; perform without fail what you resolve." Stonewall Jackson 1824 - 1863 Performing the Upgrade should not be iterative. The production upgrade should work predictably. What happens if the upgrade fails? Do you fire the consultants? Whose fault was it? Usually, the fault lies with inadequate testing, not enough communication about changes to the system, or possibly one of the steps on the checklist was missed. If the Upgrade fails, you havent practiced enough. Look at failed upgrades as forced practice. There are many reasons the upgrade can fail; the trick is to be able to identify the issue and prepare for another upgrade weekend. If the failed upgrade was on the second weekend of the month, the third weekend may also be a good upgrade weekend, assuming everyone is confident that all the issues were resolved. Usually, it takes a month to regain confidence and proceed with the next upgrade weekend. Management should be aware that a secondary upgrade weekend should be part of the overall upgrade plan.
the little r12.1.3 upgrade essentials Add extension plsql_no compile yes line in the upgrade driver file to enable the PL/SQL no compile option
Optimize adpatch
Choose the proper batchsize Batchsize=10000 Choose the proper number of workers # of workers = CPUs - 1
100
Chapter 3 Perform the Upgrade The software installed by RapidWiz includes all the application tier filesystem changes; therefore, the copy portion and the generate portion of the adpatch process are not required. These changes should be applied to the database by running the patch with the nocopyportion and nogenerateportion options. Other possible options to reduce downtime include nocompiledb, nocompilejsp, and noautoconfig. Use the AD_TASK_TIMING table to gather timing information. The elapsed time is in fractions of a day. Multiply the elapsed time by 24 hours per day to get the units in hours. The following diagram shows the most time consuming jobs in the upgrade. Compiling objects always takes the longest, followed by statistics and parallel compiles. Use this table to find jobs that have large elapsed times. Some long running jobs have scripts that can be run before upgrade weekend to reduce the processing required during upgrade weekend.
AD_TASK_TIMING
The following is an example of the rows in the ad_task_timing table that have the largest elapsed time. The time to run each job is recorded in this table. The most time consuming jobs are jobs that compile invalid objects. By keeping track of the times, its possible to identify jobs that have encountered some new problem. Large amounts of data will cause some jobs to run for a long time. Some of these jobs can be run in advance, as mentioned in the next section, Reducing Downtime.
JOB_NAME adobjcmp.sql adobjcmp.sql adsstats.sql adstatrp.sql adpcpcmp.pls adpcpcmp.pls adobjcmp.sql adpcpcmp.pls invmenu.ldt PRODUCT PROGRAM ad ad ad ad ad ad ad ad inv AutoPatch AutoPatch AutoPatch AutoPatch PHASE elapsed time hrs 27 79 346 346 5.652222222 2.133611111 1.908888889 1.908888889 1.842222222 1.768611111 1.758055556 1.656944444 1.288333333
AutoUpgrade 12 AutoPatch 41
101
Reducing Downtime
JOB_NAME facpupg.sql glrsgup2.sql PRODUCT PROGRAM FA GL AutoPatch AutoPatch PHASE elapsed time hrs 245 244 0.005277778 0.010833333
Fixed Assets has a potentially long running sql script, facpupg.sql. The script is run by AutoPatch (adpatch) and takes about 19 seconds to run in our upgrade. The script takes so little time to run that it should be run during the downtime window and would not save a significant amount of downtime if run in advance. You, on the other hand, may have a very large Fixed Assets environment, so as part of the testing you should look at how long programs take to run to decide if any downtime reducing steps are worth trying. AutoConfig has large elapsed times during the upgrade and can be run after the upgrade in parallel mode in order to further reduce downtime.
Chapter 3 Perform the Upgrade perl <AD_TOP>/bin/adconfig.pl contextfile=<CONTEXT_FILE> [product=<product_top>] parallel On the Database tier: perl <ORACLE_HOME>/appsutil/bin/adconfig.pl contextfile=<CONTEXT_FILE> parallel When running AutoConfig simultaneously on multiple nodes, the parallel option must be specified while starting AutoConfig on every node. Otherwise, the execution of AutoConfig processes on individual nodes will not be synchronized, and may result in an inconsistent file system or database.
Merge all the NLS patches and apply them as single merged patch Isolate post upgrade concurrent programs to a separate manager queue as mentioned in the best practices MOS Doc. ID: 399362.1.
103
104
We rate ability in men by what they finish, not by what they attempt Anonymous
Testing Methodology
Testing is the basis of success for upgrades. Testing requires practice. Testing requires management. Testing requires the best and most knowledgeable users. There are three types of testing: Functional, Technical and Load Testing:
105
Functional Testing
Functional testing is one of the most important skills to develop within your internal staff. After a clone or a large patch, technical tests are executed to confirm the availability of technical components. Functional testing should then be performed to confirm the availability of key functionality. Functional test scripts take time to develop and really should be a continuous effort to improve the test scripts. Test scripts should be run often enough that users are proficient with the execution of the test scripts, and know what test results to expect. Typical steps in testing include: Develop test scripts Execute test scripts Perform unit and integration tests Test customizations
Be sure to test Release 11i existing data in R12 - functional testing usually is centered on entering new R12 transactions. Make sure transactions that were entered in Release 11i can still be used in R12.
Load Testing
106
Chapter 4 Finish the Upgrade Characterize the workload Identify bottlenecks Improve performance
Technical Testing
Identify potential issues Understand the R12 Architecture Apply patches or customize to correct issues
Test Management
The lack of effective testing is the single most frequent cause of failure to Go Live. Testing is a dedicated job. Most companies only lend one resource to a test initiative. The Test Manager should be a dedicated resource. The Test Managers tasks include mentoring the testers, stressing the importance of testing to the organization, ensuring adequate testing, monitoring and improving the Test Development process, and coordinating testing with the technical and functional staff.
Test Environments
The following R12 test instances may be required: A Development instance for the developers A Test instance for each new module being implemented A Patch instance for the DBA A Training instance for training
Functional Testing
Functional Testing includes updating existing E-Business Suite test scripts to reflect valid navigation paths for Release 12, developing new Oracle EBusiness Suite Release 12 test scripts, incorporating any customizations, and performing regression testing. Release 12 introduced functional verification tasks to help identify issues before making a Go Live decision. In addition to tests your users should run to verify day to day operations, they should also run the verifications tasks listed in Appendix F of the Oracle E-Business Suite
107
the little r12.1.3 upgrade essentials Upgrade Guide, Release 11i to 12.1.3, Part No. E16342-03. The following verification tasks are to verify GL and Payables:
108
Invoice and Payment Processing To verify the integration with Oracle Payments and the upgrade of existing invoices, submit a payment batch with limited selection criteria in order to pay a few invoices. Accounting Setup and Processing Query an invoice that was not validated prior to the upgrade, then submit accounting for that invoice. Query an invoice that was accounted before the upgrade, cancel it, pay it, and then account for the payment. Also see Global Accounting Engine. These tasks apply only to Oracle Payments. In general, your planning for upgrade verification should involve testing in the two payment process areas:
109
the little r12.1.3 upgrade essentials Funds Disbursement If you used Oracle Payables for issuing payments in Release 11i, you should plan to test the funds disbursement processes equivalent to the former payment batch flow to ensure that your upgraded data correctly reflects your business process. Funds Capture If you used Oracle Receivables for electronic payment processing such as direct debits or bills receivable remittances, you should plan on testing these areas to ensure that your upgraded data correctly reflects your business process. If you used Oracle iPayment for capture of funds from credit cards or bank account debits, you should plan on testing these processes to ensure that the upgraded data results in the process you expect System Security Options Oracle Payments provides this new page where system-level settings for encryption, masking, and credit card security can be controlled. When your upgrade is complete, you should plan on reviewing the seeded settings in this page to ensure they meet your business needs. For example, in Release 11i masking of credit card values is controlled in different ways throughout the applications. In this release, the central setting in this page controls all masking. You will want to review the setting in this page and modify it if needed. Oracle Payables Impact You may want to run reports for use in your upgrade verification testing. For example, you may want to use the Suppliers Report in Oracle Payables to verify the data upgrade for payment details and bank accounts on the payees created in Oracle Payments. You can use any reports that you ran before the upgrade to help verify upgraded data. In addition, there are some key setup entities that should be reviewed and used in testing payment processing. Payment Process Profiles - You should plan on reviewing the settings for the seeded profiles created by the upgrade. These settings come from a variety of sources, and since the profile drives the entire funds disbursement flow it is important to verify that the setup supports your business process. You should pay special attention to
110
Chapter 4 Finish the Upgrade the usage rules set on the seeded profiles as these can be changed if the upgraded values do not align with your needs. It is recommended that you run a test payment process with each profile that you plan to use in production. Payment Methods - A new setup page is provided where payment methods can be created or updated. You should plan on reviewing the payment methods seeded by Oracle Payments to ensure that they meet your business needs. Payment Systems and Accounts - You should plan to verify these entities after the upgrade, and in particular the required settings, values, and their links to the payment process profiles. This setup controls important parts of the funds disbursement process such as payment file transmission, so you should test this area to be sure that the process is working as you expect.
111
Conclusion
Don't cry because it's over. Smile because it happened. Dr. Seuss Thats right, when all is said and done, you should have an upgraded system, an exhausted staff ready to celebrate, and, perhaps, some followon work. Follow-on work? you say. Yes, the work of the E-Business Suite Upgrade Team is never really done. Oracle will continue to publish fixes for problems you didnt even know you had. There will continue to be evil ner do wells out there, trying to break into databases, so you will continue to have to apply and test the quarterly Critical Update Patches (CPUs). New functionality will surely come about, as will performance patches and patches that your company simply cant live without. Take it in stride, and remember that we at TruTek are a hardworking band of consultants and trainers who understand what youre going through and would be happy to help you work through the details.
www.trutek.com 801-486-6655
113