TruTek r12.1.3UpgradeEssentials

the little r12.1.3 upgrade essentials for managers and team members

an overview from the three primary perspectives: managerial, functional and technical

by

Mike Swing

the little r12.1.3 upgrade essentials

2

Copyright 2011 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

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.shop.trutek.com/category.sc?categoryId=30

Table of Contents

3

Table of Contents THE LITTLE R12.1.3 ESSENTIALS FOR MANAGERS AND TEAM MEMBERS ...................................................................................................... 7

AUDIENCE ..................................................................................................... 7 AVAILABLE REFERENCES .............................................................................. 8 OUR PARTNERS ........................................................................................... 11 THE BIG PICTURE ........................................................................................ 13

CHAPTER 1 PLAN TO UPGRADE ........................................................ 15 FIRST STEPS ................................................................................................ 15 WHY MIGHT A BUSINESS DECIDE OR HESITATE - TO UPGRADE? ............. 16 DECISION: REIMPLEMENT VS. UPGRADE ..................................................... 17

Reimplementation Consequences ........................................................... 17 Transform and Upgrade with eprentise ................................................. 19 The Functional Business Analysis .......................................................... 20 Other Obstacles to Upgrading ............................................................... 21 Process to Re-implement ........................................................................ 21 Oracles Re-implementation Tools ......................................................... 21

CAPABILITY MATURITY MODEL ................................................................. 22 UPGRADE BENEFITS: AN OPPORTUNITY TO IMPROVE YOUR HARDWARE CONFIGURATION ......................................................................................... 23 UPGRADE BENEFITS: IMPROVED TOOLS SIMPLIFY THE PROCESS ................ 23

Real Application Testing ........................................................................ 23 Database Replay .................................................................................... 24 Maintenance Wizard .............................................................................. 25

UPGRADE BENEFITS: USE SHARED SERVICE CENTERS TO DRIVE COST SAVINGS AND INCREASE INFORMATION QUALITY ....................................... 26 UPGRADE PROCESS: THE R12 FUNCTIONAL UPGRADE REQUIRES GAP ANALYSIS .................................................................................................... 26 UPGRADE PROCESS: ASSESSMENTS CAN HELP THE PLANNING PROCESS .... 29

Functional Upgrade Assessment ............................................................ 30 Technical Upgrade Assessment .............................................................. 30 Customization Assessment ..................................................................... 31 Architecture Assessment ......................................................................... 31 Hardware Assessment ............................................................................ 33

UPGRADE PROCESS: UNDERSTAND THE FUNCTIONAL FINANCIAL R12 NEW FEATURES ................................................................................................... 34

Integrated Financials ............................................................................. 34 Subledger Architecture ........................................................................... 34 Key R12 Modules ................................................................................... 34 Subledger Currency Views ..................................................................... 35 Multi-Org Access Control ...................................................................... 36

UPGRADE PROCESS: BUILD A STRONG UPGRADE TEAM .............................. 37 Dedicated Team Members ...................................................................... 37


4

Upgrade Roles and Responsibilities ...................................................... 38 Technical Upgrade Responsibilities ...................................................... 38 Functional Upgrade Responsibilities ..................................................... 38 Upgrade Project Manager Responsibilities ........................................... 39 Steering Committee ................................................................................ 40

SUCCESS FACTORS FOR UPGRADE PROJECT MANAGERS ............................. 40 Time and Money ..................................................................................... 40

Customization Costs ....................................................................................... 41 Skills ....................................................................................................... 41

Identify Skill Gaps in Your Upgrade Team .................................................... 42 Teamwork ............................................................................................... 42

Team Obstacles .............................................................................................. 43 Minimize Risk ................................................................................................ 43 The Team Must Recognize Competing Priorities........................................... 44

SUCCESS FACTORS FOR FUNCTIONAL USERS .............................................. 44 Gap Analysis .......................................................................................... 45 Customizations ....................................................................................... 46 Cumulative Business Value of Small Business Productivity Improvements ......................................................................................... 47 Cost - Benefit Analysis for Business Process Improvement for Smaller Implementations ..................................................................................... 48

SUCCESS FACTORS FOR TECHNICAL UPGRADE MANAGERS ........................ 49 Patches ................................................................................................... 50

Upgrade Patch Types - CPCs, UPCs, CPUs, PSUs ........................................ 50 Use Patch Wizard from Oracle Application Manager (OAM) ....................... 52 The Patching Process ..................................................................................... 53 The Testing Process ....................................................................................... 54 Create Custom Development Upgrade Plan ................................................... 55

How to Upgrade Customizations ........................................................... 55 Obsolete Technology Components with Release 12 ............................... 57

mod_plsql ....................................................................................................... 57 Oracle Reports Server Reports ....................................................................... 57 Oracle Graphics Integrations with Oracle Forms ........................................... 57 AK Mode ....................................................................................................... 57

JOINING FUNCTIONAL AND TECHNICAL VIEWS ........................................... 57 Upgrade Success Without Customizations ............................................. 58 Tools of Choice for Rooting Out Customizations ................................... 59

CHAPTER 2 PREPARE TO UPGRADE ................................................ 61 PRACTICE TESTING ..................................................................................... 61 OPTIMIZE THE UPGRADE ............................................................................. 61 MAINTENANCE WIZARD.............................................................................. 61 UPGRADE BY REQUEST ............................................................................... 62 DEFAULT UPGRADE PERIODS - MINIMUM DOWNTIME UPGRADE ................ 62 INSTALL THE SLA PRE-UPGRADE CONCURRENT PROGRAM ....................... 63 RUN THE SLA PRE-UPGRADE CONCURRENT PROGRAM.............................. 63 ADJUSTMENT PERIODS ................................................................................ 65 SLA POST UPGRADE PROCESSING .............................................................. 65

Table of Contents

5

Upgrade by Request ............................................................................... 65 THE UPGRADE IS AN ITERATIVE PROCESS ................................................... 65 MANAGE-EVOLVE-OPTIMIZE ...................................................................... 66

Manage .................................................................................................. 66 Evolve ..................................................................................................... 66 Optimize ................................................................................................. 67 Aligning and Improving the Business Processes with R12.1 New Features is an Iterative Process ............................................................. 67 When Are We Ready? Are We There Yet? .............................................. 67 Technical Upgrade Paths - Release 12.1 Upgrade Paths ...................... 69

RELEASE 12.1 UPGRADE PATHS .................................................................. 70 DATABASE UPGRADE REQUIREMENTS ........................................................ 71 DATABASE UPGRADE STEPS ........................................................................ 72 UPGRADE TIMEFRAME ................................................................................ 72 UPGRADE DOWNTIME WITHOUT THE DATABASE UPGRADE ....................... 74 UPGRADE WEEKEND ................................................................................... 74

CHAPTER 3 PERFORM THE UPGRADE ............................................ 77 TUNE THE UPGRADE .................................................................................... 77 OPTIMAL NUMBER OF WORKERS ................................................................ 78 OPTIMIZE ADPATCH ..................................................................................... 78 TIME THE UPGRADE .................................................................................... 78 AD_TASK_TIMING ................................................................................. 79 REDUCING DOWNTIME ................................................................................ 80 AUTOCONFIG IN PARALLEL MODE ACROSS MULTIPLE NODES ................... 80 AFTER THE UPGRADE DRIVER FINISHES ...................................................... 81

CHAPTER 4 FINISH THE UPGRADE .................................................. 83 TESTING METHODOLOGY ............................................................................ 83

Functional Testing ................................................................................. 83 Load Testing ........................................................................................... 84 Technical Testing ................................................................................... 84

TEST MANAGEMENT ................................................................................... 84 TEST ENVIRONMENTS ................................................................................. 85 FUNCTIONAL TESTING ................................................................................. 85

Global Accounting Engine Verification Tasks ....................................... 85 Run Accounting Reports ................................................................................ 85

E-Business Tax Verification Tasks ......................................................... 86 Tax Transaction Audit and Reconciliation Reports........................................ 86 Payables and Receivables Transaction Query ................................................ 86

Payments Verification Tasks .................................................................. 86 Legal Entity Configurator Verification Tasks ................................................ 86 Trial Balance Reconciliation .......................................................................... 86 Invoice and Payment Processing .................................................................... 87 Accounting Setup and Processing .................................................................. 87 System Security Options ................................................................................ 87 Oracle Payables Impact .................................................................................. 88


6

CONCLUSION ............................................................................................. 89

7

the little r12.1.3 essentials for managers and team members

That which we persist in doing becomes easier, not that the task itself has become easier, but that our ability to perform it has improved.

Ralph Waldo Emerson (1803 - 1882)

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.


8

Available References

PLAN PREPARE PERFORM In addition to this upgrade essentials guide, TruTek has also published a project plan CD called the little r12.1.3 project plan that we use to perform the upgrade in our upgrade class. Weve also documented step by step everything that our TruTek E-Business Suite R11i to R12 Technical Upgrade class goes through when they upgrade a Release 11i Vision Instance to the latest version of Release 12 in our book the little r12.1.3 upgrade guide. Topics include:

A comparison of the Release 11i and Release 12 architectures

A list of the 125+ patches that we apply to upgrade to Release 12.1.3 of the E-Business Suite with Version 11.2.0.1 of the RDBMS

A list of the 100+ My Oracle Support Notes that we read through to decide how to successfully perform the upgrade

Gotchas Every time we hold a class, theres a new opportunity to break the upgrade. Weve included warnings of what not to do to avoid having to start over.

The details for upgrading from RDBMS 9i to 10g to 11gR2, including modifications to initialization parameters

Sections and Appendices that show how to use Oracles tools, including AD Merge Patch, Applying Database Patches with opatch, and Oracle Patch Application Assistant (admsi.pl)

The intricacies of Critical Patch Collections (CPCs), Consolidated Upgrade Patches (CUPs), Critical Patch Updates (CPUs), Patch Set Updates (PSUs), TUMS, and OATM, as well as a detailed upgrade guide that includes step-by-step details about how to do the upgrade.


9

While the TruTek E-Business Suite R11i to R12 Technical Upgrade class offers a one-week intensive opportunity to upgrade Oracles test Vision instance, we have other clients who want to practice the upgrade with their own data. We now offer a special upgrade experience, the TruTek Release 12 First Pass Upgrade. For the First Pass Upgrade, we start with a TruTek Release 12 Upgrade Readiness Assessment, where we send a list of questions and scripts to run against your production environment. We take the results and meet with the you to ask more questions and dig deeper into the current environment, and we prepare a lengthy document (around 250-300 pages) that describes the current state of the E-Business Suite environment, and where we see issues that need to be addressed to upgrade to Release 12. After this one week Assessment engagement, we schedule the TruTek First Pass Upgrade. For that, we come onsite and work with your technical staff to run through the Release 12 Upgrade against a clone of your production environment. We work through issues, we document problems, and we add what we learn to the little r12.1.3 upgrade guide. We also provide a separate document of the patches and workarounds that were specific to your environment. The TruTek First Pass Upgrade lasts two weeks, including nights and weekends. We can only do this upgrade for clients with a strong DBA and a robust hardware environment. If you want to do your upgrade testing on your grandmas first computer, then the First Pass Upgrade may not be for you. Because we believe that working through the functionality issues is much more important in the beginning than the performance issues, we now offer an added-cost First Pass Upgrade where we bring in our own equipment and use the clients data.

You can buy our books and DVDs online at: http://www.shop.trutek.com/category.sc?categoryId=30

and if youd like to take a training class with us or bring us in to consult, give us a call at:

801 486-6655.

Remember, your upgrade is bound to be hard, but if you train and practice, it doesnt have to be awful.


10

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

11

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 four areas that require special attention:

Reimplementation not! There are several reasons why you might consider reimplementing, which means, essentially, starting over with the E-Business Suite, but with the advantage of having used the applications for a number of years. Reimplementing is considered more costly than upgrading because you really do have to go through all the setups and make decisions about what their values should be for your environment. Sometimes reimplementation is the only way to go. Our TruTek consultants can help you decide if reimplementing is unavoidable, or we can talk about a tool from eprentise that solves many of the common issues including changes to the Chart of Accounts that make it necessary to decide if you need to reimplement. With software available since 2007 from eprentise, an Oracle Partner, now it is possible to upgrade from Release 11i even if you need to change the Chart of Accounts, reorganize operating units, adopt a different calendar, leave behind corrupt data, or consolidate multiple instances into a single global production instance.

Customizations tracking down those extra reports that youve placed under $CUSTOM_TOP is one thing, but what about all those changes that youve made over the years to menus, value sets, and profile options? We think that 2e2 has the best solution available, called ConfigSnapshot. We use ConfigSnapshot to take a snapshot of the current environment. Then we perform the upgrade and take a second snapshot, and use the ConfigSnapshot tools to root out the differences changes made by users, as well as those made by Oracle with the new release.


12

Security security is often the last thing Oracle customers take the time to look at, but our friends at Integrigy have tools and wisdom that we think is superior and grounded. When we do a TruTek Release 12 Upgrade Readiness Assessment, Integrigy provides a tool that looks for some of the most common security issues for the E-Business Suite. Integrigy analyzes the output for inclusion in your Assessment report. They can also provide additional services using their tools, AppSentry and AppDefend, for a much more thorough review of your security situation and defense of environments data.

Confios Ignite 8 is a comprehensive performance solution that you can use with your E-Business Suite environment. Ignite focuses on measuring response time, and adds server resources, expert advice, and trends ranging from one second to one year. Confios Alarm Trail leads you right to the root cause, simply by clicking on the alarm icons to navigate. Only Ignite leads you on a path directly to the problem. Ignite includes correlation of all metrics including response time, server health, real time sessions, and query statistics. Only Ignite correlates all the server health indicators with response time data from wait events.

If youd like to learn more about our partners, contact us at www.trutek.com, or call us at 1 801 486-6655.


13

The Big Picture There are four upgrade categories, according to Oracle, and we will follow this convention to be consistent. As you read this book, we devote a chapter to each of these four topics:

1. Plan to Upgrade 2. Prepare to Upgrade 3. Perform the Upgrade 4. Finish the Upgrade

15

1. Plan to Upgrade 2. Prepare to Upgrade 3. Perform the Upgrade 4. Finish the Upgrade

Chapter 1 Plan to Upgrade

A man that does not plan ahead, will find trouble at his door.

Confucius

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 re-implement 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 re-implement 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. Understand the Hardware Requirements and the Upgrade Path. Significant cost savings can be achieved by simplifying and standardizing hardware.


16

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.

Why Might a Business Decide or Hesitate - to Upgrade? The best reasons to upgrade are to take advantage of new functionality, to decrease costs, and to provide your business with a competitive advantage. De-support of your current version of software is not one of the best reasons, but it is compelling. Not staying current also has significant security implications. Why is waiting until Oracle is ready to pull the plug compelling? Because:

it costs so much to upgrade, although it is much less than re-implementing

higher levels of management need a compelling reason

nobody wants to run the latest release, especially .0 releases

the upgrade impact is unpredictable

if you have lost track of customizations, it is a lot of work to review them

if you cant upgrade your customizations, delaying the inevitable is tempting

if the business processes seem too complex to map to R12, you may want to wait for as long as possible before making the change


17

Decision: Reimplement vs. Upgrade The decision to re-implement versus upgrade is simple do everything possible to upgrade. Dont reimplement unless you explore all alternatives and find none work. If you have a relatively uncomplicated environment, and there are no fundamental configuration changes you need to make, then upgrade. Most of this guide is about these straightforward upgrades. This section is for if you need to make significant changes and have considered reimplementation. If there are complications or you want to change fundamental implementation-time setups in Oracle, you will evaluate each change and see whether you can transform your instance prior to upgrading, so that you can use the standard upgrade from Oracle. But first, note that since Oracle offers no way to change these fundamental configurations, they often suggest reimplementation, without regard for the implications in the customers environment. The customer usually looks for alternatives from Oracle Partner independent software vendors, system integrators, and consultants. When Oracle first released R12, they guided customers to reimplement if the customer needed to change any obsolete fundamental setup configurations or to consolidate multiple production instances. Oracles R12 documentation conceded that reimplementation is more difficult, complex, and resource intensive compared to an upgrade. "It is a project that you would generally undertake with the support of a professional services provider, such as Oracle Consulting."

Reimplementation Consequences Here are some reimplementation consequences in the areas of implementation, data history, disposition 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 the tools and utilities mentioned in the section below on reimplementation tools.

You are on your own to get your open transactions and historical data from the legacy Release 11i instance 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.


18

The usual choices include most recent and current fiscal year, current year, and only open transactions.

Even though data conversion tools these days are powerful, and programmers in global data centers can be inexpensive, 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 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. That includes translations, reconciliations, mappings, and external reporting environments.

If you have a business intelligence environment or data warehouse, you will make need to make changes to incorporate the frozen legacy Release 11i and operational R12 environments.

11iNot

Upgradable

Implement NewE-Business Suite

R12 FreshImplementation

R1211i Data

R12 Data Seeded Configured

R12 Data Seeded Configured History [partial]

Customer Extract & Transform

Selected 11i Data11i Data History

[partial?] Customer Load 11i Data History

Via Public API & Interface

Tables

Custom SQL & DB Utilities

11iHistory

Restricted Access

11i Data Read-Only History

Clone R12 emp

ty instance befo

re history load

Create sunset ins

tance read-only re

stricted access

Two instances, one active Historical data spans both,

but different formats

Reimplementation = Customer Implementation + Data Migration

Path from one 11i instance to a single global R12 instance plus legacy instance

11iNot

Upgradable

Implement NewE-Business Suite

R12 FreshImplementation

R1211i Data

R12 Data Seeded Configured

R12 Data Seeded Configured History [partial]

Customer Extract & Transform

Selected 11i Data11i Data History

[partial?] Customer Load 11i Data History

Via Public API & Interface

Tables

Custom SQL & DB Utilities

11iHistory

Restricted Access

11i Data Read-Only History

Clone R12 emp

ty instance befo

re history load

Create sunset ins

tance read-only re

stricted access

Two instances, one active Historical data spans both,

but different formats

Reimplementation = Customer Implementation + Data Migration

Path from one 11i instance to a single global R12 instance plus legacy instance

This diagram shows the reimplementation approach. Customers following this path usually end up with the two instances (one Release 11i and one R12), and keep workaround mechanisms in place to span the instances or to make adjustments in a downstream BI environment.


19

The reimplementation environment gets even more complex if there are multiple Release 11i instances, multiple custom extract, transform and load operations, and you end up with multiple Release 11i sunset instances.

Transform and Upgrade with eprentise An Oracle Partner, eprentise, offers software to transform fundamental setups in Oracle EBS such as the Chart Of Accounts (Accounting Flexfield), calendar, organizations, all other key flexfields, and sets of books. eprentise software can be used to eliminate or fix corrupt data. You can consolidate multiple instances. You can remove all data related to sold or inactive business units. If you want to make these major changes, use the eprentise software to transform your Release 11i instance so it can be upgraded. Consolidate your Release 11i instances so you can have a single upgrade process and get to a single R12 instance. You can use eprentise software to:

Transform the fundamental setups of your Release 11i instance(s) to reflect how you need your business to run now.

Adjust or re-do any unsatisfactory or obsolete setups.

Consolidate Release 11i instances as required so there is only one instance to upgrade.

Close seemingly huge functional alignment gaps between Release 11i and R12.

Minimize the downtime for the upgrade. Then you run the Oracle upgrade. Heres a diagram that describes the process.


20

eprentiseTransformation

11iUpgradable

Oracle 11i R12 Upgrade R12

11i DataTransformed

R12 DataTransformed &

R12 formats

11iObsolete Setups

11i Data

11iObsolete Setups

11iObsolete Setups

11i Data

Instance you always wished for, AND its upgradable.

Use it as long as you want, until you need the valued-added R12 features.

11i Data

Business process changes Business structure changes, incl. OUs COA changes Clean data, compliant with standards Shared service centers Instance consolidation

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

No data loss No data loss

Upgrade = eprentise Transformation + Oracle Upgrade

Single Global Instance Lowest future cost

structure Highest business value

Path from one or more EBS 11i instances to a single global R12 instance

eprentiseTransformation

11iUpgradable

Oracle 11i R12 Upgrade R12

11i DataTransformed

R12 DataTransformed &

R12 formats

11iObsolete Setups

11i Data

11iObsolete Setups

11iObsolete Setups

11i Data

Instance you always wished for, AND its upgradable.

Use it as long as you want, until you need the valued-added R12 features.

11i Data

Business process changes Business structure changes, incl. OUs COA changes Clean data, compliant with standards Shared service centers Instance consolidation

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

No data loss No data loss

Upgrade = eprentise Transformation + Oracle Upgrade

Single Global Instance Lowest future cost

structure Highest business value

Path from one or more EBS 11i instances to a single global R12 instance

The Functional Business Analysis It is important to keep the upgrade vs. reimplement discussion in the context of the overall transition to R12. First understand what the R12 target needs to be. Compare that to the Release 11i instance(s). Itemize and inventory all the gaps everything that needs to change. Then consider how you would make each change.

If the Oracle upgrade and standard setup capability is all you need, this is the best case. You do not need any further upgrade vs. reimplement discussion.

You could use eprentise Transformation software and then do the Oracle upgrade.

You could reimplement (implement R12 fresh and migrate your historical data).

A parallel analysis considers everything in the Release 11i instance(s) that does not need to change on the path to R12. What do you not need to touch if you upgrade? What do you need to replicate anew if you Reimplement? What extra historical data that is supposed to be unchanged must be managed and migrated if you reimplement? Oracle provides useful documents, including The R12 Adoption Best Practices and Upgrade Considerations by Product. These supplement each module or product familys implementation guide.


21

When you have this inventory of items that either need transformation or reimplementation, check with eprentise to find out if the transformation would be practical for your situation. If not, then look at reimplementation.

Other Obstacles to Upgrading If any of the following obstacles to upgrading apply, ones the eprentise transformation software does not directly address, we suggest you contact experts in that area. The analysis may be a complex exercise, and the experts may be able to help you avoid reimplementation: 1. If you need to simplify NLS, MLS, and currency configurations. 2. When the upgrade path is too complex, for example, if you need to

perform a Release 10.6 to 12.1 upgrade with forms customizations. 3. If you need to completely replace old EBS application modules. This

will depend on the gaps between the older EBS module and the R12 one, and the specific changes youre looking to make.

Process to Re-implement This section is for if you have explored all the upgrade options and still decide to reimplement. First, set up the applications, migrate the data, and install the customizations. It is possible to go live with a subset of the original data and convert the remaining data in phases.

Oracles Re-implementation Tools Oracle provides a number of tools that can help with re-implementation:

iSetup - can migrate functional setups from one E-Business Suite instance to another. During migration, setups can be extracted selectively using filters on setup attributes. Extracted data can be optionally transformed before loading into a target instance.

fndload see the paper, Customization Survival Guide: How to Use E-Business 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


22

exp/imp Oracles export and import utility.

Datapump - For RDBMS Version 10g and 11g you can use DataPumps expdp and impdp 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.

Oracle Application Management Pack (AMP) and Application Change Management Pack (ACP) are additional cost toolsets provided by Oracle that provide a framework around tools like iSetup, but also offer new functionality, including the ability to document your customizations.

Capability Maturity Model Use the Capability Maturity Model as a framework to simplify and standardize your business processes and hardware. The Capability Maturity Model (CMM) is trademarked by Carnegie Mellon University and refers to a development model derived from data collected by the U.S. Department of Defense. The model is based on observation rather than on theory. The CMM provides an effective method to improve the software development process. Eventually, the CMM was applied more generally to business processes. For this book, our goals can be summarized with the Capability Maturity Model to simplify and standardize business processes using a framework to achieve efficiencies and cost savings. Actually achieving costs savings through Business Process Improvement (BPI) requires hard work to understand the new functionality and the existing business process model.


23

Following this model, technology and process convergence lead to simplification, standardization and shared services.

Upgrade Benefits: An Opportunity to Improve Your Hardware Configuration Probably the least invasive time to implement a new hardware upgrade is during a software upgrade. Youll need to test how the operating system works with the new E-Business Suite software anyway, so why not take advantage of some of these benefits:

Migrate to more cost-effective 64-bit Linux servers

Migrate Application Servers to 64-bit hardware to support more users with more addressable memory

Utilize Virtualization to help standardize hardware and software

Implement a SAN with block virtualization capabilities, aka snapshots to dramatically improve cloning and backup performance

Upgrade Benefits: Improved Tools Simplify the Process Oracle provides a number of tools that simplify upgrading the Applications, including: Real Application Testing, Database Replay, and Maintenance Wizard.

Real Application Testing Oracle Database 11g introduced Database Replay and SQL Performance Analyzer as part of the Real Application Testing option to enable businesses to identify issues with system changes before production deployment The Oracle Real Application Testing option includes two solutions to test the effect of system changes on real-world applications, Database Replay and SQL Performance Analyzer (SPA). Database Replay enables you to effectively test system changes in test environments by replaying a full production workload on the test system, to help determine the overall impact of the change. With the SPA, you can assess the impact of system changes on SQL performance by identifying any variation in SQL executions plans and performance statistics resulting from the change.


24

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.

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


25

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. The Maintenance Wizard contains the following:

Upgrade Assistant: 11i to 12 [version 2.x]

Applications Database Upgrade Assistant: 8i, 9i to 10g [version 2.x]

Maintenance Pack Assistant: 11i to 11.5.10 [version 1.x]

Upgrade Assistant: 10.7, 11.0.3 to 11.5.10 [version 1.x] 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


26

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 Many of these centers may be combined into one center.

Upgrade Process: The R12 Functional Upgrade Requires Gap Analysis The R12 Upgrade is not just a technical upgrade, it is a functional upgrade. The functional upgrade consists of mapping new business requirements with new functionality in R12 and determining the differences. This is called gap analysis. Gap analysis requires superusers/functional analysts to understand the new features of R12 and understand the existing customizations. Gap 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.


27

Filling the gap is another term for aligning the business processes with Oracle Applications.

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? Process

Integrate business changes with Oracle Applications new functionality

Develop new process models. Retire/modify customizations that are replaced by new functionality

Business

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?

Identify business areas that should adopt best practices that may differ from current business practices


28

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

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.


29

Upgrade Process: Assessments Can Help the Planning Process In order to better plan for the upgrade, assessments can help estimate the impact and scope of work. There are four major types of upgrade assessments:

Functional align the business with Oracle Applications

Technical review patches, tech stack versions, the upgrade path, and performance issues

Customization review customizations to ensure that they are adequately documented, and to find customizations that can be eliminated as a result of new functionality introduced with an upgrade

Architecture review hardware and capacity requirements 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.


30

The Report phase of the assessment defines the issues, recommends solutions and summarizes process improvements.

Functional Upgrade Assessment The Functional Upgrade Assessment documents the modules in use and modules that are to be implemented as part of the upgrade. This type of assessment identifies business issues and prioritizes business goals to clearly define and set measurable performance targets and prioritize goals. The Functional Upgrade Assessment should identify the gaps between the current release and the latest certified R12 release to determine the functional, platform, network and operating system gaps. Functional experts must map custom processes from Release 11i to R12. Because of new functionality in R12, existing custom processes may be replaced by new functionality in R12. This assessment should review application reporting and interface transition issues, and evaluate management controls required, including timing, resources and training issues. Finally, this assessment should recommend an overall upgrade approach (upgrade vs. re-implementation, the appropriate upgrade path, etc.)

Technical Upgrade Assessment The technical assessment investigates future capacity requirements, tech stack version compatibility, and patch levels, including CPUs, current


31

issues from log files, current unresolved service requests, and potential issues with the R12.1 upgrade.

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.


32

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 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 , 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.


33

Most users dont know how to restart a failed job. Therefore, the failure of a concurrent manager that is not set up with PCP will terminate running jobs. 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


34

MRP and other programs run much more quickly in a 64-bit database

Upgrade Process: Understand the Functional Financial R12 New Features

Integrated Financials The new bank account and disbursement models facilitate the payment of invoices and other payables out of different operating units, from an appropriate bank account, and with the appropriate intercompany handling. Intercompany processing is dramatically revised by enhancements in both Financials intercompany management and Supply Chain Managements Enhanced Drop Shipments. Rather than a GL only system, Financials now links into Receivables and Payables to generate matching and tied documents (configurable though Bill Presentment) and a new reconciliation scheme. Related SCM products provide transfer pricing modeling and enforcement, inventory consignment (at subsidiaries or otherwise), and tracking of profit in inventory.

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.

Key R12 Modules Modules and new features that are key to the operation of R12 include: Approvals Management, (AME), User Management (UMX), Sub Ledger Accounting (SLA), Governance and Risk (GRC), Multiple Organization Access Control and Advanced Global Intercompany processing.


35

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.

Subledger Currency Views Accounting for subledger transactions at the event in a standard manner with a single accounting engine allows us to provide multiple accounting representations for a single event. A purchase can be simultaneously accounted for an increment to inventory for your US GAAP or IAS/IFRS accounting, and as a debit to the P&L for your national compliance accounting. The accounting entity involved can maintain multiple ledgers, each complying with a different set of accounting principles we call them accounting methods, and, of course, the transactions and ledgers can be valued and denominated in different currencies. You can now generate currency views of a ledger at the subledger transaction, general ledger transaction, general ledger balance, or consolidation workplace levels.


36

Multi-Org Access Control Multi-Org Access Control (MOAC) enables companies with a Shared Services operating model to efficiently process business transactions by allowing them to access, process and report on data for an unlimited number of operating units within a single applications responsibility. This increases the productivity of Shared Service Centers, as users and processes no longer have to switch applications responsibilities when processing transactions for multiple operating units at a time. Data security and access privileges are still maintained using security profiles that now support a list of operating units.

The MOAC feature primarily uses two features namely 'Fine-Grained Access control' and 'Application Context'. Combined known as Virtual Private Database (VPD). Fine-grained access control allows you to build applications that enforce security policies at a low level of granularity (such rows/columns in table). Application Context provides a way to define, set, and access attributes that an application can use to enforce access control specifically, fine-grained access control . Please note Multi-Org Access Control replaces usage of CLIENT_INFO(Org Context) function in Multi-Org Architecture.

Steps to Setup MOAC (from My Oracle Support Note 414003.1):

Define Operating Units(Optional) (Using form function 'Define Organizations')

Define Security Profile (Using form function 'Define Global Security Profile')

Assign MO: Security Profile

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 previous release, it will be set in 12.

If you dont want to implement MOAC features in Release 12, no additional setups are required.


37

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.

Upgrade Process: Build a Strong Upgrade Team The Upgrade Team is not a democracy. The upgrade project management should not be shared. The upgrade team is composed of functional and technical representatives from the business and report to the upgrade project manager.

Dedicated Team Members The Upgrade Team should be independent from daily operations. Team Members should be selected from the business by the upgrade project manager.


38

Upgrade Roles and Responsibilities

Technical Upgrade Responsibilities

The DBAs and Developers are in charge of technical testing and should try to improve the technical foundation: hardware and software. The DBAs perform the technical upgrade and the developers modify and implement the new customizations and extensions. Developers should work with the functional analysts to understand the existing customizations. The functional users should work with the developers to help them understand how new requirements affect the existing customizations. Much of the developers work, coding and testing, is done in advance of the upgrade weekend. During the upgrade weekend the developers have 4-6 hours to implement and test customizations. Developers may need to practice rapidly implementing the customizations. DBAs, Developers, Functional Analysts and Testers should all try to reduce downtime.

Functional Upgrade Responsibilities Functional responsibilities include testing the business use of Oracle Applications. In order to be an effective functional analyst, you must understand the AS IS business process model and the TO BE process model. Functional analysts should document the gap between the business process and the Oracle Applications processes, and:


39

align the business and Oracle Applications

understand existing customizations

understand how new requirements affect the customizations

investigate, improve and implement setups

train the users for example, iProcurement

reduce downtime

verify the upgrade

Upgrade Project Manager Responsibilities Manage the following managers:

Development Manager Customizations

DBA Manager Technical Upgrade

Systems Manager Hardware Upgrade

Functional Superusers Develop Process Alignment

Functional Business Process Experts

Testing Manager Report progress of priorities as established by the Steering Committee


40

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.

Success Factors for Upgrade Project Managers

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.

Time and Money Companies whose staff is experienced with upgrades and has an efficient testing process may be able to complete the upgrade in as few as three months. Typically, upgrades take six to nine months and very large upgrades (number of users and number of customizations) may take longer than one year. An upgrade might cost:


41

$1000 per user + $500 per iUser with $150K minimum (an iUser is a user of iExpense, iProc, OTL, etc) 20 full users + 400 iUsers = $220,000 Upgrade costs vary drastically depending on the number and type of customizations. This estimate typically includes customizations. This estimate does not include implementing new modules, hardware migration, etc. Categories and Range of the Percentage of the Total Budget Budget Average Budget Typical $400,000 Upgrade Budget

Training 10% - 20% 10% $40,000

Functional Analysis 20% - 40% 25% $100,000

Technical Upgrade 10% - 30% 25% $100,000

Customizations 0% - 50% 20% $80,000

Testing 15% - 30% 20% $80,000

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.

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


42

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 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.


43

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., team in name but consistently underperforming. 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.

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, 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


44

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 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.

Success Factors for Functional Users Functional users of Oracle Applications may have a different view of success than the managers and technical staff. The functional staff may declare upgrade success even though from the management or technical point of view that upgrade may not have been a complete success. This is because the functional, technical and managerial success criteria may not be the same. Functional users should expect to gauge their success on their ability to accurately determine the gap analysis, and work with developers to make sure the customizations appropriately address the functional gap. The following diagram illustrates the functional view of success.


45

Gap Analysis Gap analysis requires superusers/functional analysts that understand the new features of R12.1 and understand the existing customizations. Gap 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


46

Customizations and Modifications can help align the business with Oracle Applications.

Customizations 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.


47

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.

Cumulative Business Value of Small Business Productivity Improvements Even small improvements in business process performance can yield large business savings over a 5-year period. This example illustrates how 1,000 employees over a 5-year period with a 2% improvement per worker results in $8 million in savings over 5 years. This equates to $400 million in labor costs.

Assumptions

Number of employees 1,000

Avg. Annual Fully Burdened Cost/Employee $80,000

Employee Hours Worked per Year 2,000

Time Frame (Years) 5

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.


48

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


49

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.

Success Factors for Technical Upgrade Managers


50

The technical view of success depends on applying the correct patches in the right order, installing and configuring new hardware, and 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 - CPCs, UPCs, CPUs, PSUs See My Oracle Support Knowledge Document 557869.1, EBS: R12 Oracle Financials Critical Patches for links to the latest Critical Patch Collections (CPCs) and Upgrade Patch Collections (UPCs). A new type of patch collection was introduced in July, 2009 called Patch Set Updates (PSUs). See My Oracle Support Knowledge Document 854428.1, Intro to Patch Set Updates (PSU) for more details about PSUs. Oracle also releases quarterly Critical Patch Upgrades (CPUs) that should be applied as they become available. Critical Patch Collections (CPCs) - Oracle Financials Release 12.0 Critical Patch Collections (CPC) 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. 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.


51

If a CPC becomes available after you complete your upgrade, you should research the CPC and consider implementing it at some point to your environment. Release 12.1 Financials Upgrade Patch Collection (UPC) - The latest Release 12.1 Financials Upgrade Patch Collection (UPC) contains Release 12.1 Upgrade patches for the following products:

Payables

Receivables

Tax

Subledger Accounting

Intercompany

Financials for India The Release 12.1 Financials Upgrade Patch Collection is created specifically for customers who have yet to upgrade their product environment to Release 12.1. This UPC contains improvements to the upgrade process to Release 12.1. These fixes are not required to be applied to environments that have already been upgraded to Release 12.1. These patches are critical to the upgrade process and it is essential that they are applied to your Applications Code Tree (APPL_TOP) prior to running the R12.1 Upgrade Driver. You should look for the latest UPC on My Oracle Support and add it to your upgrade plan. 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 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.


52

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 free 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 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, to find additional patches that have yet to be uncovered.

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


53

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

TruTek r12.1.3UpgradeEssentials

Documents

Transcript of TruTek r12.1.3UpgradeEssentials