Eliminating a Multi-Instance Environment

44
Session ID: Prepared by: The Search for the Single Source of Truth: Eliminating a Multi-Instance Environment # 10815 @heleneabrams Helene Abrams CEO eprentise, LLC

Transcript of Eliminating a Multi-Instance Environment

Session ID:

Prepared by:

The Search for the Single

Source of Truth: Eliminating

a Multi-Instance Environment

# 10815

@heleneabrams

Helene Abrams

CEO

eprentise, LLC

Agenda

Introduction

Multi-Instance Environment

• History

• Limitations

Consolidation vs Migration

• How Does Consolidation Work?

• What Are The Benefits?

Case Studies and Examples

Roadmap to Consolidation

2

3

eprentise Can… …So Our Customers Can:

Consolidate Multiple EBS

Instances

Change Underlying Structures

and Configurations

Operating Groups,

Legal Entities, Ledgers

Chart of Accounts,

Other Flexfields

Inventory

Organizations

Calendars

Costing Methods

Resolve Duplicates, Change

Sequences, IDs

Separate Data for a

Divestiture

: Transformation Software for E-Business Suite

Reduce Operating Costs and

Increase Efficiencies

Shared Services

Data Centers

Adapt to Change

Align with New Business

Initiatives

Mergers, Acquisitions,

Divestitures

Pattern-Based Strategies

• Make ERP an Adaptive

Technology

Avoid a Reimplementation

Reduce Complexity and Control Risk

Improve Business Continuity, Service

Quality and Compliance

Establish Data Quality Standards and

a Single Source of Truth

Company Overview: Established 2007 l Helene Abrams, CEO

With Out-of-the-box Software

Learning Objectives

After this session you will be able to:

Objective 1: Understand how a multi-instance

environment impairs financial operations and creates

barriers to growth and innovation.

Objective 2: Discover the top benefits of consolidation

projects for the business and IT, and how it leads to a

single source of truth.

Objective 3: Learn how companies who completed

consolidation projects improved reporting, eliminated

duplicate efforts, and achieved sharing real-time

information.

4

Multi-Instance Environment

How did we get here?

What are the limitations of a multi-instance

environment?

Why Do Companies Have Multiple Instances?

• Acquisitions

• Earlier technologies didn’t support global environments – Bandwidth

– Single sign-on

– Regional and statutory differences

• Limited understanding of how global businesses should operate – Shared processes, services

• No internal champion – Enforce standards

– Mandate sharing of data

– Establish enterprise-wide governance and control

• Existing environment does not meet business needs – Upgrade to new release

– Customizations

– Restructuring

6

Limitations of a Multi-Instance Environment

• Infrastructure Costs

– Hardware, maintenance, licenses

– Duplicate integrations and interfaces

– Redundant personnel for support

• Reporting and Analytics

• Customer Service

– Consistency

– Availability

• Growth and New Initiatives

• Transparency

• Regulatory Requirements

• Complexity

7

Consolidation vs Migration or

Reimplementation

How does consolidation work?

What are the benefits of consolidation?

Incentives & Drivers of Global Operations

• Consolidate repetitive data-centric processes

to support implementation of a shared

services center or a centralized data center

• Generate financial reports directly from the

system of record

• Reduce operating and maintenance costs to

improve the bottom line

• Create a single source of truth to improve

business processes and business intelligence

• Enable revenue optimization whenever and

wherever possible to improve the top line

• Capitalize on enterprise-wide synergies to

leverage purchasing and to better understand

customers

• Obtain access to new markets and the

opportunity to scale the business

9

Traditional Approach vs. Consolidation

Migration or

Reimplementation • Configure new instance (all

setups, all master data)

• Technical team writes custom code to extract transactions from each source instance to the target instance

• Developers create transform scripts to fit (usually one year’s data, balances, and in-process transactions) into new configuration

• Using APIs, developers load data into new instance

Consolidation

• All database objects and every

row of data are compared

between source(s) and target

• All differences and all conflicts

are resolved automatically

• All source data (configurations,

master data, and transactions)

including all history is moved

from the source to the target.

• There is no need to write any

Extract, Transform, or Load

scripts, no need to find landing

balances, close in-transit items,

or maintain a sunset instance

for the history

10

eprentise Compare Reports

11

Every Difference Resolved, Every Table, Every Row

Example: Flex Value Differences

FLEX VALUE SET NAME MAXIMU

M SIZE ALPHANUMERIC ALLOWED FLAG

UPPERCASE ONLY FLAG

APPLICATION TABLE NAME VALUE COLUMN NAME ID COLUMN NAME

AP_SRS_OPEN_INTERFACE_SOURCE 25 Y N AP_LOOKUP_CODES DISPLAYED_FIELD LOOKUP_CODE

AP_SRS_OPEN_INTERFACE_SOURCE 80 Y N AP_LOOKUP_CODES DISPLAYED_FIELD LOOKUP_CODE

FA_ADI_CORP_BOOK 15 Y N FA_BOOK_CONTROLS_SEC BC2, GL_SETS_OF_BOOKS SOB

BOOK_TYPE_CODE

FA_ADI_CORP_BOOK 15 Y N FA_BOOK_CONTROLS_SEC BOOK_TYPE_CODE

FA_BOOK_DEFERRED_DEPRN 15 Y N FA_BOOK_CONTROLS bc, FA_CALENDAR_TYPES ct

bc.book_type_code

FA_BOOK_DEFERRED_DEPRN 15 Y N FA_BOOK_CONTROLS_SEC bc, FA_CALENDAR_TYPES ct

bc.book_type_code

FA_BOOK_TYPE 15 Y Y FA_BOOK_CONTROLS BOOK_TYPE_CODE

FA_BOOK_TYPE 15 Y Y FA_BOOK_CONTROLS_SEC BOOK_TYPE_CODE

GPIARSTMT_STMT_DATE 9 Y Y gpi_ar_statements_audit statement_date DISTINCT statement_date

GPIARSTMT_STMT_DATE 9 Y Y custom.gpi_custom_statements_audit statement_date DISTINCT statement_date

GPI_AP_CHECK_NUM 30 Y Y ap_checks ch, ap_bank_accounts ba, ap_bank_branches bb

ch.check_number distinct ch.check_number

GPI_AP_CHECK_NUM 30 Y N ap_checks ch, ap_bank_accounts ba, ap_bank_branches bb

ch.check_number distinct ch.check_number

GPI_AP_SITE_CODE_BY_SUP_NAME 15 Y Y po_vendor_sites_all povs, po_vendors pov povs.vendor_site_code DISTINCT povs.vendor_site_code

GPI_AP_SITE_CODE_BY_SUP_NAME 15 Y N po_vendor_sites_all povs, po_vendors pov povs.vendor_site_code DISTINCT povs.vendor_site_code

GPI_AP_SRS_ACTIVE_VENDORS 80 Y Y PO_VENDORS PO PO.VENDOR_NAME PO.VENDOR_NAME

GPI_AP_SRS_ACTIVE_VENDORS 80 Y N PO_VENDORS PO PO.VENDOR_NAME PO.VENDOR_NAME

GPI_AP_SRS_VENDOR_NAME 80 Y Y PO_VENDORS VENDOR_NAME VENDOR_NAME

GPI_AP_SRS_VENDOR_NAME 80 Y N PO_VENDORS VENDOR_NAME VENDOR_NAME

12

eprentise Consolidation

13

Data Quality - More than Just Master Data

Management

Jobs & Positions

Configuration

Field Label

Security

Report Content

Configuration

Constraints

Different but same DFF

Same but different DFF

Missing DFF Target

Missing DFF Source

Instance 1

Dir. Of Apps

July 9, 2010

Labor

Hierarchical

Report A

Biweekly

300 Hrs

XYZ

XA-01

1-2-3

Instance 2

Fin. Systems

10-07-09

Labour

No Security

Report A

Two-week

199.99 Hrs

Xyz-1

XA-01

RB

epre

ntise M

eta

data

Analy

sis

epre

ntis

e C

onsolid

atio

n S

oftw

are

Consolidated Instance

Fin. Systems

10-07-09

Labor

No Security

Report A, Report A-1

Two-week

199.99 Hrs

Xyz-1

XA-01, XA-02

1-2-3

RB

14

Changes Made Automatically During

Consolidation

Three Types of Changes:

Name Changes

ID Changes

Synchronization

15

Master Data

• Resolves conflicts - Identifies exact duplicates based on constraint columns

– Name – prefixed or suffixed

– ID or Number – incremented by max seq number of target

– Exact duplicate with different ID – repointed to target ID

• By default, for the non-constraint columns, takes the target attributes (tax id, credit limit, etc.)

• Data that exists in the source, but not in the target is moved into target as is

• Data in target but not in source remains

• Most data is at OU level. Comes into the consolidated instance within a separate ledger and OU.

• Use Oracle merge suppliers, customers functionality to resolve duplicates after consolidation is complete

16

Case Studies and Examples

Considerations for Consolidation

• Tools instead of manual efforts

• Governance

• Reporting and statutory compliance

• Remove silos

– What needs to be different?

– RICE-W/ CEMLI costs

• Other changes before or after R12?

• Implement new features after other changes

• Test changes in isolation

• Cutover window?

18

Technology

• Four main technology issues surrounding

globalization:

– Availability

– Access/Security

– Performance

– Functionality

• E-Business Suite Release 12 is designed to

support a global enterprise within a single

instance, and it has several features that

enable sharing of data and facilitate the

globalization effort.

19

A Single, Global Instance

• A single global instance means:

– Higher volumes

– Longer batch processing

time windows

– More network traffic

– Longer backup cycles

– Longer test cycles

• BUT, having several instances and systems

multiplies the cost (licenses, hardware, staff) and

introduces a different complexity in reconciling and

synthesizing corporate information.

Substantial

infrastructure

expenditures

20

Experian Globalization Process

Operating Principles of Experian’s Global

Financial Shared Services Center (GSSC)

• Standard processes and controls will be

implemented across the globe

• Processes will be consolidated where possible

• Local legal requirements will be incorporated to all

processes

• SSC should undertake as much processing work as

possible

• Financial models should include the cost of

Oracle® software and the cost of migrating to the

SSC

21

Experian’s Shared Services Strategy

• Reduce costs and improve efficiency

– Leveraged low cost locations and standardized on global business processes

– Eliminated redundant efforts that were common when many corporate procedures such as month-end close and expense reimbursement were regionalized

• Create additional capacity for growth

– Reduced operational complexity

– Opportunity to capitalize on Experian’s connection to a diminished number of entities (financial institutions, bank accounts, vendors, etc.)

– Made the roll out of global process automation a realistic opportunity

22

Consolidation Projects : Traditional Migration/Reimplementation Project

With eprentise Software

Resources ~5 FTE

Project duration 7 months

Cost under $1M

All history in single instance

Zero errors after production

cutover

No SRs logged with Oracle for

any eprentise product – ever

Done in R11.5.10

Manual Migration to New R12

Resources ~250 consultants

Project duration 18 months

Cost between $12 million and

$15 million

1 year history and balances

Maintain sunset instances

47 Priority 1 SRs logged with

Oracle after go-live

23

GE GRC Consolidation Project Resources (Does Not Include Resources for RICE-W Objects1)

1 Also does not include TCS external consultant help.

24

GE GRC Consolidation Project Timing

Environment Preparation

Run 1 Run 2 Dry Run

Cutover to Production

7-16-2012

Instance available

10/29/2012

10-30-2012 2-20-2013 4-18-2013 5-25-2013

Included asset category change

Turned over for

testing 1-11-2013

Total Consolidation ~6 Months

25

GE GRC Consolidation Results

• Much shorter duration than reimplementation

• Complete data history and integrity maintained for BOTH instances without having to maintain a “sunset” instance

• No manual migration or translation of existing data within Oracle® EBS, which provided accurate and consistent results for testing. Parallel activities were needed to align 3rd party/bolt-on applications.

• Risk reduction – repeatable, predictable solution from Run1 through Production implementation. Only a handful of total eprentise-related issues during the entire project. All issues were resolved expeditiously (some within hours).

• No issues after cutover period

26

GRC Benefits Realized

• Streamlining Operations. As a result of the consolidation, GRC is

now realizing the following business benefits:

– Standardizing of business processes, such as:

• Profile options now set consistently

• Common structure of the Fixed Assets module

• Rationalization of descriptive flexfields

– Elimination of outdated data/processes, such as:

• Localizations no longer in use

• Unused GL calendars

• Budgetary control

• Reducing Infrastructure costs. GRC has been able to eliminate

the costs associated with:

– Shutdown of the India/China Oracle® application

– Oracle® infrastructure licensing

– Simplified patching and maintenance (particularly in regard

to localizations)

– No need for sunset instance

– Elimination of redundant interfaces (3rd party applications,

shared services providers)

“Thanks to the

eprentise

software and

support team,

GE Global

Research

Center in

Niskayuna, New

York, now

operates on a

single, global,

Oracle® EBS

instance,

freeing up

resources to

further support

their focus on

industrial

research.”

27

Roadmap to Consolidation

Objective: Cutover in a Long Weekend

• Environment

– 3 or more EBS instances

• Challenges

– Reduce production downtime to a single long

weekend

– Possibly do an upgrade to R12 during the same

period

– Change many interfaces and customizations

– Need to retain history

29

30

DURING THE FIRST

TEST CYCLE

31

Step 1: Upgrade and Patch to Same Version

• eprentise works at the database tier

• Install needed products in the target production instance

• Add patches and localizations to the production environment that are

present in the source but not the target

– May result in database object differences (additional columns, indexes,

constraints, modules, etc.)

• Update database objects in the target production environment

• Create a test environment

– Add space and other resources to target environment to accommodate all

instances

– Reference instance clone same as test instance

– Need one reference instance for each source instance

32

Step 2: Analyze the Instances

• Prepare run book for first test cycle

• Install eprentise Software

• Run Metadata Analysis on each source instance

and on target instance

– Identify and resolve potential conflicts

• Key flexfields

• Descriptive flexfields

– Determine sequences and incremental factors that

need to be changed in the source instance

33

Step 3: Use Metadata Analysis Reports

to Resolve Conflicts

• Generate reports on maximum sequence number,

incremental factors

– Use results to modify RICE-W objects (reports, interfaces,

customizations, enhancements, workflows) to

implement/change in target instance

– Identify obsolete configurations (localizations, modules not

used)

• Make business decisions on standardization of data,

processes

34

Step 4: Prepare for Consolidation –

Key Flexfields

• Change “Single Instance” key flexfields in target

instance to accommodate source key flexfield

structures instance

• Single flexfields per instance listed below:

35

Change Key Flexfields

36

Step 5: Resolve Other Differences

• Seed Data

• Configuration Data

– Value sets

– Descriptive flexfields

– Users, Responsibilities, Profiles

– Personalizations

• Master data

37

Step 6: Consolidate Instances: Move Each

Source Data to Target Instance (Sequentially)

• Align sequences of target environment

• Synchronize IDs to target sequences

• All history moved

– No calculations of beginning balances

– No determination of “open items” or “in-transit” items

– No maintenance of sunset instances (transparency, consistency within EBS)

• Configurations will either default to target configurations, or be brought over from sources

– No need for manual configuration or scripts

– Transaction types, journal sources, journal categories, expense templates, expense report policies, signing limits, historical rates from each source instance

• Time required depends on I/O speed, but averages less than 10 hours to move each source into target

• Update run book for second test cycle

38

eprentise Consolidation

39

After Sources are Consolidated into Target

1. Create clones of consolidated instance for testing

2. Test consolidated instance EBS functionality

3. Upgrade to R12 (Optional)

4. Modify interfaces, customizations to align with target

instances

5. Unit test RICE-W objects

6. Implement security

40

No extract, transform, or

load scripts

Change-in-place software All data is changed in the current environment, so there is no need for

a sunset instance or maintenance of historical information.

No custom code Standard, out-of-the box software that fits

every customer’s environment

Standard development, rigorous testing and error handling, standard

reports generated documenting the changes.

Flexibility to adapt to

changing requirements

Rules-based system Rules may be changed as customer requirements change during the

course of the project, and as customers review the finished results.

Rule changes can be completed in hours or a few days, rather than

weeks with teams of developers.

Full audit trail available Reports generated from software before and

after transformations are made

All history is in the same format, in the same environment. (No need

to set up new instance or new books or new operating units) All data

(historical and current) is consistent, complete and accessible.

Maintains relational and

data integrity

Software will not proceed to next step if the

data integrity is violated

Code is automatically generated based on rules. When consolidating

instances, every row of data and every data object is compared , and

differences automatically resolved so there are no conflicts between

source and target.

Testing of results All changes are made by the software, so

there is no need for unit testing of code or

error handling.

Business users are given a functional system to test and reconcile.

Lower costs, shorter

duration

Shorter project duration with fewer resources

translates to lower costs.

Most projects completed in months. Costs are a fraction of migration

costs.

Customizations,

interfacing systems

Costs are the same with traditional or

eprentise approach

eprentise reduces the risks associated with creating migration scripts

only within E-Business Suite. (There is no impact on the time or effort

required to analyze RICE-W objects or CEMLIs.)

New functionality Process of adding R12 features like AGIS,

secondary ledgers is the same with traditional

or eprentise approach.

No need to re-configure what works in current environment. Only

need to set up new functionality.

Alternative

41

Questions? Comments?

42

THANK YOU

Helene Abrams

CEO

[email protected]

eprentise, LLC www.eprentise.com

Accelerating the time for change in

Oracle E-Business Suite

Visit eprentise at booth 1423!

43

Please complete the session

evaluation.

Session #10815 We appreciate your feedback and insight.

You may complete the session evaluation form on your COLLABORATE 16 agenda builder and networking app!