R12 Upgrade Guidance

1 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.

Oracle R12 Upgrade GuidancePam Fisher, Oracle Consulting Senior Director

Safe Harbor Statement

The following is intended to outline our general

product direction. It is intended for information

purposes only, and may not be incorporated into any

contract. It is not a commitment to deliver any

material, code, or functionality, and should not be


material, code, or functionality, and should not be

relied upon in making purchasing decision. The

development, release, and timing of any features or

functionality described for Oracle’s products remains

at the sole discretion of Oracle.

Table of Contents

• What is an R12 Upgrade?

• When is an R12 Re-implementation required?

• R12 Re-implementation vs R12 Upgrade

• Key Activities of an R12 Upgrade

• Approach and Methodology for an R12 Upgrade


• Approach and Methodology for an R12 Upgrade

• Governance Structure for an R12 Upgrade

• Key Focus Areas

• Detailed Case Study

<Insert Picture Here>What is an R12

Upgrade?


What is an R12 Upgrade?

• An R12 Upgrade is when a current 11.5.x Oracle EBS Customer wants to ‘upgrade’ their

current Production instance(s) (Both configurations & data) to an R12 Release

• The Upgrade always includes an Application upgrade (R11i to R12)

• The Upgrade sometimes includes a Database upgrade – this depends upon the

Customer’s current database version

• Oracle Development has released ‘Upgrade Scripts’ which are run against the R11i

Instance. These scripts perform the following:

• Move R11i configurations & data to R12 tables / fields, where applicable

• Populate new R12 tables / fields, where applicable (Example: SLA tables)


• Populate new R12 tables / fields, where applicable (Example: SLA tables)

• After the Upgrade, the instance contains the following:

• All R11i data within the old R11i tables

• New R12 tables / fields populated with configurations & data, where applicable

• Latest R11i CEMLI code, prior to the upgrade

• Latest R11i Patch sets, prior to the upgrade (includes Localizations & installed Languages)

• There are both Pre & Post Upgrade Tasks that are required to be performed in order to

have a functioning instance. These will be discussed in detail within this presentation.

EBS 12.1.3Upgrade Paths

ReleaseRelease

Auto

mate

d,

Ste

pU

pgra

des

12.1.212.1.2

12.112.1

Next ReleaseNext Release

12.1.312.1.3


Auto

mate

d,

One-S

tep

Upgra

des

12.012.0

11.5.9 and below11.5.9 and below

11.5.10 *11.5.10 *

Types of R12 Projects – Initial Scope

R12 Technical

UpgradePure ‘Like for Like’

R12 Upgrade

PlusUpgrade + Optional

R12 features and/or

new applications

R12

Reimplementation

Fastest Timeline 1 2 3

Upgrade of their current Oracle 11i

EBS Production environment to R12xYes Yes No

Update Mandatory R12 Feature Yes Yes Yes


Update Mandatory R12 Feature

ConfigurationsYes Yes Yes

Configure Optional R12 Feature

ConfigurationsNo Yes Yes

Retrofit existing broken CEMLIs Yes Yes Yes

Retire existing CEMLIs with new R12

Feature functionality

ONLY if it does not

impact the Project

Timeline or Resources

Yes Yes

Large Design / Build Phase No Yes Yes

Typical Questions We get from Clients

Question Answer

Does all of my R11i information come over to R12? Yes

Including CEMLIs code, Reports, Patches, Responsibilities, etc

Yes

Why do my custom reports work for historical data, but not new data?

The data within the R11i tables is still within the R11i tables pulled by the report. The new R12 transactional data is placed within the new R12 tables; therefore, the report must be retrofit to


include the relative R12 tables as well (this includes DISCO Business Areas)

Does the instance size grow after the upgrade? Yes – we have seen a growth anywhere from 30% -80%. This is dependent upon each client’s instance. The more Payables & Assets data, the bigger the growth.

What is the fastest, least risk way to get to R12? R12 Technical Upgrade – if no COA or Organizational change is required

Do all my business units have to upgrade at the same time? Do I have to go ‘Big Bang’?

If they are all within 1 instance, then all must be upgraded at the same time. You cannot partition an upgrade within an instance.

<Insert Picture Here>Re-Implementation or

Upgrade?


When to Re-implement:• Redesign of Organizational Structure

• Introduction of new Functionality/Significant changes to configuration

• Redesign of Chart of Accounts Structure

• Data corruption issues

• Extensive Customizations to previous release

Re-implement or Upgrade?

High-Level “Rule of Thumb”


• Elimination of Legal Entities, (Mergers and Acquisitions)

When to Upgrade:• Minimal Data corruption in legacy system (due to customizations)

• No current demand or design for Subledger Architecture or MOAC – can

utilize current R11 configurations. ‘Implement than Optimize Approach’

• Minimal changes in application configuration

• Minimal Integration issues between third party applications

1. Decrease Downtime – Configure & Prepare new R12 Production instance prior to cutover

2. Infrastructure Requirements - Purchase, configure, test new Production, or Production-Like, infrastructure

3. Data Conversions – Design, Build, Test Master & Open Transactional data conversions from R11i to R12

4. Application Configurations – Design, Build, Test mandatory

R12 Re-Implementation Facts


4. Application Configurations – Design, Build, Test mandatory R12 Application Configurations such as SLA, Ledger Architecture, eBus Tax, MOAC, etc.

5. Business Transformation / Standardization – Opportunity to design & build business transformational & standardized processes

6. Change Management – Design, build, communicate organizational transformation impacts

1. Testing Events (including Performance Testing) – Same, but less coordination for R11i Production copies, Pre-Upgrade Tasks & Patching

2. RICE Retrofit – Same, but more opportunity for retirement since designing / configuring environment from scratch

3. Data Quality / Cleansing Opportunity – Key advantage from both historical and custom data perspective

R12 Re-Implementation vs Upgrade Activities


4. Transition & Contingency Planning – More flexibility

5. SOx / Internal Audit – Additional reviews / coordinated efforts

6. Governance / Project Organization – PMO will remain the same, but Project Organizational Structure & resource requirements will be different

<Insert Picture Here>Key Activities of

an R12 Technical

Upgrade


Upgrade

1. Upgrade of the Applications / Database – Upgrade Lab DBA Team

2. CEMLI Retrofit – Upgrade Lab Technical Architects

3. Update Configurations – Functional Team

4. Update Test Scripts & Test – Upgrade Lab Testing Team

5. Change Management / Training – Change Management Team

Key Activities of an R12 Technical Upgrade



6. Governance / Project Management – PMO

Optional:a. Automated Testing – Upgrade Lab Testing Services

1. Upgrade of the Applications / Database – Upgrade Lab DBA Team

a. The Experts - All they do is run/support R12 Upgrades 24 x 7

b. Team works remotely via VPN access to Customer hardware

c. Approach is Nearshore Management + Offshore support, around the clock monitoring

d. Monitor the Upgrade scripts + tune them, where appropriate

e. Support the upgraded instance including CEMLI migrations, patching, Oracle Support SR

technical requests, etc

f. Perform at least 4 - 5 Upgrade rounds during the Project in order to work through issues

and ensure Production downtime is kept to a minimum



and ensure Production downtime is kept to a minimum

g. Nearshore Team will come onsite for one week and train client DBAs on how to patch,

clone, etc on R12 environments

h. Deliverables Provided:

i. Pre / Post Upgrade Detailed Task List (TE.085)

ii. This same deliverable is updated & provided after each upgrade round

i. Resource Timeline:

i. Upgrades Only – resources required for each Upgrade Round + 1 month instance

support

ii. Upgrades + R12 Instance Support – project timeline duration

2. CEMLI Retrofit – Upgrade Lab Technical Architects

a. Run CEMLI Discovery Tool within Customer’s instance to provide the listing of customer specific CEMLI objects that will require retrofits in R12

b. Lead the CEMLI Impact Analysis to review each CEMLI and determine their disposition code for R12

i. Will work ‘As Is’ii. Requires Retrofitiii. Eliminate CEMLI with R12 Functionality

c. Key Asks from the Client –i. Need the R11i Functional and/or Technical Design Documents for each CEMLI



i. Need the R11i Functional and/or Technical Design Documents for each CEMLIii. Have they kept the Design Docts up to date since the implementationiii. If documentation does not exist, need a Technical Workshop where the client

Tech team describes each CEMLI, purpose, complexity, maintenance effort, business use volume (daily, monthly, etc)

d. Deliverables Provided:i. ME.010 – CEMLI Impact Analysis Resultsii. ME.110 – CEMLI Team delivers a document describing all changes made to the

CEMLI codee. Resources Timeline:

i. Depends upon volume of CEMLIs requiring Retrofit & Supportii. Normally full team from project start through 2nd / 3rd test event, then downsize

through go-live

3. Update Configurations – Functional Teama. First Upgrade / Impact Workshops

i. Updates the System Administration mandatory configurations in order to log into the applications / operating units properly

ii. Unit tests the instance to see what is brokeniii. Reviews & Updates the additional mandatory configurations relative to the

Application Footprint and retestsiv. Discuss current business processes & pain pointsv. Explains R12 Mandatory Features vs Optional Features **Scope Control Area**

b. Review of CEMLI Descriptions – map to R12 Feature functionality & determine configuration impact

c. Review R11i Test Script Inventory for completeness. Assist in creating new Test Scripts,



c. Review R11i Test Script Inventory for completeness. Assist in creating new Test Scripts, where applicable

d. Lead the SuperUsers through the Testing Eventse. ‘Train the Trainer’ Approach – train the SuperUsers on the R12 Changes during the 1st &

2nd Test Eventsf. Lead the effort on any Oracle SR Resolutionsg. Support the CEMLI team with functional R12 questionsh. Deliverables Provided:

i. MU.110 – Application Configuration Change Document - provides a listing / description of the Mandatory Configuration Changes required per Application within the R12 Footprint

i. Resource Timeline:i. Onsite for Project Start through 2nd Test Eventii. Offsite support through post Go-Live **Optional onsite support is available

4. Update Test Scripts & Test – Testing Team + Functional Teama. Upgrade Lab Testing Team:

i. Update R11i Test Script Navigation to R12 Navigationii. Execute manual test scripts for assigned areasiii. Provide testing results to the Test Lead within approved format (Word

Document/Shared Drive, Test Director, etc)iv. Log testing issues within Project toolsetv. Participate in Morning Test Event Status Meetingsvi. Deliverables Provided:

i. TE.040 - Updated R12 Test Scriptsii. TE.091 – Test Results for each test round

vii. Resource Timeline:



vii. Resource Timeline:i. Offsite for the duration of the project – roll off prior to UAT

b. Functional Team:i. Assist SuperUsers with creating new R12 Test Scripts, where applicableii. Perform ‘Train the Trainer’ sessions at the start of the Test Eventiii. Assist client Testers with executing Test Scripts for 1st & 2nd test eventiv. Ensure testing issues are logged with adequate information and assigned to the

proper resourcev. Work Test Issues relative to Application Configurations and Product defectsvi. Participate in Morning & Afternoon Test Event Status Meetingsvii. Deliverables Provided:

i. TE.040 – New R12 Test Scripts relative to the customer business processesviii. Resource Timeline: Same as described in Key Activity #3


a. Ensure both Business & Technical Stakeholders are engaged with the Projectb. Ensure proper ‘What is Coming’ communication is provided to all Stakeholders

throughout the Projectc. Lead the End-User Training design, build and execution

i. Key Areas of Training have been within the Financials Areas of:a) Payablesb) Paymentsc) eBusiness Taxd) Receivables



d) Receivablese) General Ledger

ii. iExpense and iProcurement training is required for those companies with a large volume of end users

d. Assist with the Production Transition Planning and Execution taskse. Deliverables Provided:

i. Communication Planii. End-User Training Plan

f. Resource Schedule:i. Onsite throughout the duration of the projectii. Can be done by the Customer if proper resources are available

6. Governance / Project Management – PMO

a. Ensure a proper Governance Board Structure is created which represents both Business & IT. Meet weekly with Key Decision Makers to ensure proper levels of communication & the following is completed in an expedited manner:

i. Scope Creep decisionsii. Manage Cross Dependency Project(s) – Timeline / Resource impactsiii. CEMLI Retirement vs New Optional R12 Feature Functionality decisionsiv. Manage current Production Freezev. Manage Test Environment changes & Regression Test requirements

b. Ensure Executive Sponsors are assigned from Oracle Consulting, Support and Development and regularly scheduled status meetings are held

c. Build and maintain a fully integrated, networked project plan which includes all Third



c. Build and maintain a fully integrated, networked project plan which includes all Third Party Interface tasks and Milestones for Cross-Dependency projects / resources

d. Create detailed Transition and Contingency Plan including:i. Interim procedures for all business areas to process emergency transactions during

the downtime business daysii. Decision on Date / Time of Production shut-downiii. Hourly Project Plan with estimated Start / Finish times iv. ‘Go / No Go’ Tollgates with Decision standards/definitions for eachv. Controlled ‘Kick the Tires’ Activity prior to releasing the instance to the Public

e. Deliverables Provided:i. CR010 – Project Management Plan (includes all PM Standard Operating Procedures)ii. WM020 – Project Workplaniii. PM010 & PM030 – Transition and Contingency Plan

f. Resource Schedule:i. Onsite throughout the duration of the project

<Insert Picture Here>Oracle Methodology

and Approach


Oracle Unified Method for Upgrades


Upgrade 2

CRP 2

(Reference Process

documentation)

Upgrade 3CRP 3

(Timing round)

Upgrade 4 & 5SIT & UAT

Upgrade 6Final Production

Round

Tech

Upgrade

Lab (db & apps)

Validate the upgrade process.

Confirm and document

performance metrics

Successive iteration performed to support

test cycle rounds. Address performance

tuning and issues on all upgrade scripts.

Revalidate and time the upgrade process

documented in previous iteration .

Perform production dress rehearsals to

confirm upgrade process and timing.

Production cutover.

CEMLI

Retrofit

Support

Apply all existing CEMLI objects and

identify those that need remediation.

Conduct CEMLI retrofit impact

analysis & baseline object

development plan – may include

retrofit, reduction and/or

redevelopment.

MD.70 (TDD) design docs for updated

code per Tech Build standards.

Recompile and Unit Test. Apply subset

of CEMLI’s remediated at this stage for

initial validation. Subset to include

most business critical and/or most

complex

Apply all remediated CEMLI’s and

Function Test. Provide CEMLI break/fix

support from offshore as needed to

augment onsite resources.

Support UAT steps with CEMLI break-fix

support. UAT to include all retrofit CEMLIs

and re-architected interfaces. Obtain signoff

on updated MD.70s (TDD).

Address any pending CEMLI break/fix

issues.

Upgrade 1CRP 1

(Impact Analysis)

Oracle Approach – Upgrade Iterations


R12.1.3

Functional

Assistance

Functional impact verification and

analysis for possible

setup/configuration changes,

CEMLI reduction or simplification.

Initial SuperUser training

Functional Validation of setups and

business processes with SuperUsers

SuperUser Training continues

Conduct CRP 3 with custom objects applied.

Functional and business process

verification working along with

SuperUsers and business resources.

Support testing team on the tests performed

on application and retrofitted objects.

Conduct SIT & UAT and address any

upgrade functional issues. Assist with

Transition go-live planning and any

potential training requirements.

Address functional and business process

issues and support Transition, Go-Live

and Post Production Support

Testing

Support

Update existing test scripts to

validate initial impact of R12

upgraded configurations, data and

CEMLIs. Execute scripts per plan

Identify missing test scripts &

create build plan

Update Test Plan. Update and build

relevant Test scripts to expose

remediated code and functionality

changes in R12.1.3 for your processes.

Execute scripts per plan

Determine Automated Test Case

Inventory & initiate build in WinRunner

Provide completed Automated Test

Scripts to the Performance Testing Team

Execute both manual & automated test

scripts per the Test Plan.

Update QC & WinRunner, as appropriate

Test upgrade with complete set of Manual

and Automated Test scripts per the Test

Plan. Run multiple regression runs.

Follow Release Management processes

and support with automated test

regression runs in pre-production

environments as needed.

Project /

Integration /

Program

Management

Provide support and guidance for the

R12 Upgrade activities including

project planning & replanning,

scope management, issue & risk

management, cross team

dependencies, testing mgmt

Same as CRP1 activities +

• initiate Transition and Contingency Planning discussions

• Update & drive plan for designing test

plan for all integration touchpoints


• Coordinate SR escalations and planning

• Assist with managing readiness & testing

of all Oracle EBS integration touchpoints

• Build detailed Transition and Contingency Plan including Go / No Go

Tollgates


• Finalizing detailed Transition and Contingency Plan

• Finalizing cross dependency / integration plans

• Monitoring / bucketing testing issues found

Support and Manage Production

Cutover activities

Inception Elaboration Construction Transition Production

Business Requirements (RD)

Requirement Analysis (RA)

Analysis (AN)

Design (DS)

Implementation (IM)

Technical Architecture (TA)

Oracle Unified Method for Implementations


Testing (TE)

Data Acquisition & Conversion (CV)

Organization Change Management (OCM)

Transition (TS)

Training (TR)

Documentation (DO)

Operations & Support (PS)

Performance Management (PT)

<Insert Picture Here>Governance


Governance Components

Benefits Management

Business Process

Decision Making & Accountability

Strategy

• Business and program strategic alignment

• Organizational design

• Goals and funding prioritization

• Transformation success accountability

• Decision rights and input rights

• Trade-off analysis decision-making framework

• Business value identification

• Metrics definition, baselining, and measurement

• Cascading benefits achievement targets

• Business process improvement design


Program Management

Business Process Improvement

IT Strategy

OrganizationalChange Mgmt.

• Program management - planning, scheduling, resources, costs, issues, and risks

• Program communications cadence

• Guiding principle of vanilla/out-of-the-box

• Efficiency and effectiveness measures and analysis

• Stakeholder Analysis, Roles and Responsibilities

• Change impacts, readiness, mitigation plans

• User adoption strategies

• Enterprise infrastructure and application architecture design and standards

• IT operational cost and risk

Governance - Program Management

Prioritization

Risk Management

Change Advisory Board

Sponsorship• Support vision for Program

• Business Continuity

• Provide required resources for program success

• Enterprise Architecture Decisions

• Global Design Approvals/ and Cross-program Decisions

• Non-std Process Change/ Customization/ approvals

• Cross-program risk identification and management

• Related enterprise risk identification and management

• Prioritization approach and execution


Prioritization

Common Standards Common Standards and Language

Quality

Communications and Reporting

• Financial management for affordable acceleration

• Methodology

• Cross-program dependencies

• Assumptions and constraints

• Communications Cadence

• Impact and Action Reporting

• Exception Process and Escalation Process

• Acceptance of delivered systems

• Quality Plan execution, Controls and Assurance

Governance Board Example

Executive Vision & Commitment

EXECUTIVE SPONSORS

OPERATIONAL SPONSORS

Enterprise Program Enablement and

Strategic Alignment

Enterprise Architecture

Cross-Program

Enterprise Org Change Communications

and Escalations

Reporting and Financial

PROGRAM OFFICE

Business Lead(s): IT Lead(s)

Program Lead, Enterprise Architect, Enterprise Change Mgmt. Lead

Business Sponsor Names; IT Sponsor Names

Business Sponsor Name; IT Sponsor Name


Name

Name

Name

Enablement and Governance

Project Execution R12

UpgradeProject 2 Project 3 Project 4 Project 5 Project 6

NameBusiness

IT

PgM + PMs

Name

Name

Name

Name

Name

Name

Name

Name

Name Name Name

Name

Name

Name

Architecture Decisions

Program Decisions

Org Change Management

Prioritization and Risk

Management

Business Continuity

Non-std Process Change/

Customization/ approvals

and Escalationsand Financial Management

Common Standards,

Methodology

Global Design

Approvals/ Decisions

Program

OfficeProject

Manager

Acct to Fin Rpt

Procure to Pay

BPO

BPO

App SpecialistITO

PMO

Leadership Team

Chair

Chair

R12 Upgrade Project Team Structure

R12 B

usin

ess P

rocess A

doptio

n

Oracle Executive Sponsorship- Consulting, Sales, Development

Oracle Project Sponsors- Consulting, Support, Development

ProjectManager

Integration Management

IntegrationManagement

Executive Sponsors

Core Team

Change Management


CEMLI Upgrade

InfrastructureUpgrade

Testing / Validation

Projects / Assets

Procure to Pay

ABC CoIT Team

ABC CoBusiness Team

BPO

BPO

Oracle Core Team

Technical Architects

Upgrade Lab

ABC Co

Oracle

R12 B

usin

ess P

rocess A

doptio

n

ITO

ITO

App Specialist

App Specialist

Testing ServicesITO

ITO

ITO

NOTE: To decrease client price, ask if Client can take on more of the Red Boxes

<Insert Picture Here>Key Focus Areas


Critical Success Factors

1. Implementation of solid Governance Board with Key Decision & Scope Control

procedures created, documented and communicated

2. Well Defined Scope

3. Executive Sponsorship of the Project / Program

4. Solid, understood Program Management Office established & Rules of

Engagement documented, communicated

5. Provide required, qualified resources to the Project

6. Cross Project / Program Decisions made efficiently, communicated properly and


6. Cross Project / Program Decisions made efficiently, communicated properly and

implemented

7. Prepare the Organization - Proactively engage stakeholders to help prepare for

the project and the changes that will be experienced once deployed

8. Secure User Buy-In – Provide end users good information on how the resulting

solution will impact their roles, whether the changes are functional, user interface,

or technical in nature

9. Go Live – Detailed, complete Transition & Contingency Plan created and

distributed early in the upgrade process to ensure all impacted organizations are

prepared and to verify that the success criteria has been achieved

1. Determine Your Upgrade Path - More recent releases have a direct upgrade path to the latest release

2. Treat Your Upgrade Activity as a Formal Company Project - Structured approach for managing the tasks, resolving issues, and measuring progress is critical. Build a team with broad, comprehensive skills

3. Prepare the Organization - Proactively engage stakeholders to help prepare for the project and the changes that will be

R12 Upgrade Best Practices


3. Prepare the Organization - Proactively engage stakeholders to help prepare for the project and the changes that will be experienced once deployed. Explain ‘Not Just Technical’

4. Understand and Mitigate Project Risks - Specific mitigation plans should be developed for high probability, high impact risks

5. Inventory Your System - Examine current business requirements and Inventory modifications and determine what is still needed

6. Plan for Upgrade Architecture - Accurate sizing information will help guide decisions to reuse existing hardware and resources

7. Identify Custom Code and Scripting - Identified customized interfaces, forms, and reports that will require additional testing through the upgrade process. Prioritize by Business Criticality

8. Optimize Training Processes - -Ensure project and support teams are proficient in the new technology. Train users at an optimal timeframe will help resolve most issues early. Most users prefer training proximate to

R12 Upgrade Best Practices


will help resolve most issues early. Most users prefer training proximate to going live on the new system

9. Secure User Buy-In - End users must have good information about how the resulting solution will impact their roles, whether the changes are functional, user interface, or technical in nature

10. Go Live - Go live checklist created earlier in the upgrade process should be leveraged to verify that the success criteria have been achieved. Set up sufficient support mechanisms to optimize early rollout experience

<Insert Picture Here>Detailed

Case Study


Employees: 3,000 Oracle UsersLocation: San Bruno, CA

Beginning in 1969, Gap Inc. has grown into one of the world's largest specialty retailers, with more than 3,100 stores and fiscal 2008 revenues of $14.5 billion. They operate four of the most recognized apparel brands in the world — Gap, Banana Republic, Old Navy and Piperlime. They have offices and stores located

Case Study - Gap, Inc

Background


Banana Republic, Old Navy and Piperlime. They have offices and stores located throughout the world with headquarters in San Francisco, CA.

In 2004, Oracle Consulting took Gap, Inc live on a Global Oracle 11.5.8 Financial Solution and in August 2007, Gap, Inc again engaged Oracle Consulting to assist them with their Oracle Financials R12.0.4 Upgrade

Gap’s Oracle Financials R12 Upgrade project was influenced by the following business drivers:

• Loss of Premier Support – Gap, Inc. was facing a de-support issue and sustainingsupport did not include critical patch updates, tax and regulatory updates. Current release was R11.5.8

• Not on Terminal Release – Gap’s existing solution platform did not provide a


Objectives


• Not on Terminal Release – Gap’s existing solution platform did not provide a direct upgrade path to the next generation of Oracle applications (“Fusion”).

• Tech Stack - Upgrade from 9i to 10g database will allow for Gap compliance with data encryption policies & improved performance.

• Global Financial Platform – The upgrade was necessary to ensure Gap, Inc.’s integrated suite of financial systems remain relevant to the Global Financial Community by providing new features and functionality, while managing risks associated with new technology.

• Technical Upgrade to current release = R12.0.4

• Oracle eStudio DBAs managed the technical upgrade activities on the

project

• Offshore functional resources managed the upgrade of CEMLI’s and all

testing services (automate test scripts using Mercury, and provide remote

testing services)


Approach


testing services)

• Onsite consultants to support the upgrade and test activities

• Full PM/PMO oversight

Applications to be included in the upgrade:• Oracle General Ledger

• Oracle Payables

• Oracle Receivables

• Oracle Assets

• Oracle Project Costing

• Oracle Purchasing

• Oracle iProcurement

• Oracle iExpenses

• Oracle Cash Management


Scope of the Upgrade

New R12 applications implemented:• Oracle Payments

• Oracle Report Manager

• Oracle Advanced Global Intercompany System

• Oracle Advanced Collections

• Oracle iSupplier Portal

• Oracle Subledger Accounting

• Oracle eBusiness Tax - foundation


• Oracle Cash Management

• Oracle Discoverer

Technical Work Performed:• Database upgraded from 9i to 10g

• Total CEMLI’s Upgraded / Built = 800 (started with 1,149)

• Total Automated Test Scripts Built = 188

• Total Global Operating Units = 40 (North America, EMEA, Asia-Pac)

• Total Countries = 36

• Total Languages = 5

• Total Upgrades / Test Events = 8

Project Team Onboarded = 01-Oct-2007

Original Go-Live Date = 16-Sep-2008

NOTE: On 12-Sep-2008, Gap made a ‘No-Go’ decision due to volume of open defects / product bugs. Contingency Plan executed

Project Timeline



Actual Go-Live Date = 19-Mar-2009 **

Oracle Team Rolloff Date = 10-Apr-2009

** Delayed to March due to Peak Period & Quarter-end close timing

• New R12 functionality / defects with upgraded data within the Oracle Payables / Oracle

Payments areas

• Gap’s large volume of complex CEMLIs to upgrade and retest after each defect resolution

implemented

• Coordinating all proper, global Gap Business Partners to conduct 8 test events with over 2,000

integrated test scripts and 800 Private Discoverer Queries

Challenges

Lessons Learned



• Plan to test the upgrade process as many times as possible within the project schedule

• Each Upgrade practice should use a different date from the customer’s current Production

copy in order practice upgrading different types of data in different statuses

• Test events should focus on processing transactions against upgraded data as well as entering

new transactions. The majority of the defects found during our project were for transactions

being processed against upgraded data

• Ensure to engage a strong Governance Structure to manage Scope Creep and Key Decisions

• Ensure to engage Executive Sponsorship with active participation from Oracle Development,

Oracle Support, Oracle Consulting and Gap

Lessons Learned


