eprentise consolidation overvie · transformation software that remodels any setup data or...

© 2016 eprentise. All rights reserved.

eprentise® Consolidation Overview

Transforming Oracle® E-Business Suite


Organization Business Problem eprentise Solution

GE Global Research Global mandate to consolidate ~40

instances into ~20 instances and ~200

charts of accounts into a global COA.

Went live with merging 3 charts of accounts into 1

new one, changed the asset key flexfield, and

consolidated the India/China instance into the US

instance.

Xerox Long-term goal of a supply chain

instance and a go-to-market instance

Went live with merging 3 inventory organizations into

a new operating unit. The project involved a chart of

accounts change a calendar change, repointing to a

new OU, a new legal entity, and a new set of books.

Also merged sets of books and operating units for all

US operations.

Barrick Gold of North America Global Chart of Accounts

Merge Canada operations into US

Operations

Changed over 25 charts of accounts, Merged 9 sets of

books, 4 operating units, 2 legal entities, and 6

inventory organizations

Changed currency from CAD to USD for a public

company - had to reconcile to reported balances.

Novell Acquired by Attachmate

Attachmate had a different fiscal year.

GAAP rules required an asset

revaluation.

Attachmate’s legal entity in Ireland was

using a Euro as a functional Currency,

Novell’s legal entity in Ireland was

using USD

Calendar Change from beginning in October to begin

in May

Changed date placed in service, asset valuation,

remaining life to align with date of acquisition.

Currency Change (functional currency) from USD to

Euro for Irish Legal Entity.

Recent Significant Customer Solutions

| 2


eprentise Can… …So Our Customers Can:

Consolidate Multiple EBS Instances

Change Underlying Structures and

Configurations

Chart of Accounts, Other Flexfields

Merge or Split Ledgers or Sets of

Books, Operating Units, Legal

Entities, Inventory Organizations

Calendars, Currency, Costing

Methods

Asset Revaluation, Inventory

Valuation

Separate Data

Introduction: Finished but not Done

: 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

Avoid a Reimplementation

Reduce Complexity and Control Risk

Improve Business Continuity, Service Quality

and Compliance

Streamline Operations with Visibility to All Parts

of the Business

Establish Data Quality Standards and a Single

Source of Truth

Company Overview: Incorporated 2007, Helene Abrams, CEO

| 3


Chosen as a "Cool Vendor" in the Cool Vendors in Master Data Management (MDM), 2011 report by Gartner, Inc.

Awarded Patent for eprentise Consolidation Software, 2012

Does not violate Oracle Support Agreement

Delivering CPE credits in educational webinars

Marketing Awards

Collaborate12

User’s Choice

Traffic Stopper

Visionary

Collaborate13

Best Exhibitor Marketing

Collaborate14

Best in Show

Significant Accomplishments

| 4


Out-of-the-Box Software


Transformation Software Solutions

Two Product Lines:

FlexField® Change chart of accounts in EBS

Built-in Rules

Changes data in all subledgers, add-in for HR Cost Allocation

Retain all historical transactions

Quick, easy project, low price point

eprentise® Transformation Software that remodels any setup data or consolidates

multiple instances

Reorganizes configuration, master, and transaction data

Maintains all history resulting in a single source of truth

Based on a source that is transformed into a target

Generates rules and code to resolve conflicts

Metadata Analysis and intelligent knowledge repository

| 6


Transformation Software Solutions eprentise provides software to make enterprises agile

by giving them the opportunity to change their Oracle

systems to align with their changing businesses.

| 7


Metadata Analysis and Knowledge Repository Enforces Data Quality and Standards

Underlying technology that understands every

relationship between each piece of data in the

E-Business Suite database, allowing eprentise

to maintain 100% data integrity.

Maintains relational and data integrity (up and

down all EBS hierarchies)

Copy, Filter, Change, and Merge

Profiles and analyzes to look for changes

between source and target

Automatically generates code to implement

required changes

Complete, Consistent, and Correct

Maintains History

Metadata Analysis

Core of the eprentise software suite

Identifies, documents, and validates

internal data structures and data

content of both source and target

databases

Allows eprentise to copy, filter,

change, and merge existing data

according to built-in or user-defined

business rules eprentise Metadata Analysis and Knowledge

Repository are intelligent, learning and

building from each successive implementation.

| 8


Hi-Definition Transformation

Technology

We have the engine to

drive change in Oracle®

E-Business Suite.

| 9


Configuration Analysis

| 10


Include or Exclude

| 11


eprentise Consolidation

| 12


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

ep

ren

tise

Meta

data

An

aly

sis

ep

ren

tise C

on

solid

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

| 13


Changes Made Automatically During

Consolidation

Three Types of Changes:

Name

Changes

ID Changes

Synchronization

| 14


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


eprentise Compare Reports

| 16


Case Studies


Consolidation Projects

| 18

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


Every Difference Resolved, Every Table, Every Row

Example: Flex Value Differences

FLEX VALUE SET NAME MAXIMUM 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

| 19


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

1 Also does not include TCS external consultant help.


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


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


Best Practices for Consolidation

Tools instead of manual efforts

Governance

Reporting and statutory compliance

Remove silos What needs to be different?

RICE-W/ CEMLI costs

Consolidate or change COA first?

Other changes before or after R12?

Implement new features after other changes

Test changes in isolation

Cutover window?


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


Getting Started

Client Download Site Diagnostic script

FlexField software download

Articles, data sheets, project plans

System Requirements for eprentise Access

Server, OS, and DB details

Reference instance

License Requirements for FlexField Name of source COA

Server, DB details


Timing and Resources

FlexField – Run cycle usually completed in a day (sometimes just a few hours)

eprentise run time Consolidation – GRC under 30 hours for cutover,

CARQUEST under 40 hours

Other products vary, but usually less than a day

DBA required for install, access

Testing resources – 1-2 business analysts per business area (financial close, purchase-to-pay, etc.). Should represent all business areas/locations.

Project Management


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

| 27


DURING THE FIRST TEST CYCLE

| 29


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


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

| 31


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

| 32


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:

| 33


Change Key Flexfields

| 34


Step 5: Resolve Other Differences

Seed Data

Configuration Data

Value sets

Descriptive flexfields

Users, Responsibilities, Profiles

Personalizations

Master data

| 35


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

| 36


eprentise Consolidation

| 37


DURING THE SECOND TEST CYCLE

| 38


Preparation for Second Test Cycle Make changes to eprentise rules and freeze code

Create test environment

Install eprentise Software

Run Metadata Analysis

Update RICE-W modifications as needed

Resolve conflicts

Key flexfields, descriptive flexfields, users, responsibilities, profiles, personalizations, etc.

Master data


Second Test Cycle Align sequences of target environment


Consolidate instances (move each source into target instance (sequentially)

Update to R12 (Optional)

Update RICE-W Objects

Full UAT, System Integration test cycle

Resolve issues and prepare patches if necessary

Freeze code

Update run book for Dry Run

| 40


DRY RUN AND CUTOVER TO PRODUCTION

| 41


Dry Run (Same as Cutover to Production) Prior to Dry Run

Install, run Metadata Analysis, reports

Update all RICE-W Objects

Dry Run

Align sequences of target environment


Move each source into target instance

Update to R12 (optional)

Test, resolve issues

Prepare for cutover to production

| 42


Analysis of Traditional Approach Custom ETL Scripts Issue Discussion

Create Extract, Transform, Load

Scripts to move data from current

structures to new structures

No standard extract/transform

scripts provided

Code is custom and does not go through formal

development and testing process with version control,

error handling, development standards.

Custom code is not supported

by Oracle

Oracle does not support or assist in the creation of custom

extract, transform, and load scripts.

APIs do not exist for all tables There are no tables to load any structural data or

configuration data into a new (R12) environment.

Migration scripts are written for

the current state of the data

Any changes require re-writing of the scripts. The change

control process may not be documented. It is easy for a

developer to perform a quick fix without documenting it

or determining the impact of the change.

Requires technical expertise of

all tables and usage in the E-

Business Suite

Oracle does not enforce standards across all modules. A

code combination may be stored in a column called

Reference2, or Event8. An Org ID may refer to an

Operating Unit, an HR Organization, or an Inventory

organization. Developers who are not experienced in a

particular type of migration or the business processes

generally do not understand the complexity of the data

structures in EBS and may compromise the relational or

data integrity.

Results not available until all the

code is written

As requirements change, or as the results are tested, any

change results in a coding change. The impact of code

changes may trickle down to other dependent code, and

may involve rewriting of all scripts.

| 43


Custom ETL Scripts Issue Discussion

Movement of History Generally only one year of

history and open balances

moved to the new structures

Generally, a historical entity (a sunset instance) is

required for reporting, reconciliation, business

intelligence, and audits.

Historical information not in

the same format as new R12

instance or new structures

Every time the historical operating unit, key flexfield,

set of books, or instance, is accessed, data must be

transformed to align with the new (R12) structure.

If history (from a sunset

instance) is to be accessible,

then it must be upgraded,

patched, and supported, or a

“complete” EBS environment

along with the apps tier must

be maintained

Can’t access data from prior EBS versions from a R12

application. If there are multiple instances, then

multiple sunset instances need to be maintained. This

approach significantly reduces any cost savings that

would have been recognized from going to a single

environment.

Audit Trail No audit trail of data as it is

moved from an old structures

to the new structures

At most, developers create a count of records for

each transaction table. There is no trail of what data

has been changed, split, or merged.

Difficult to reconcile changed

data

The data in a new structures has been transformed,

and there is no drill down to the historical detail or

roll up to the general ledger. For example, if a set of

books or ledger is split, an auditor would need to

review every transaction in the source set of books

and in the target set of books. Oracle has no cross-

instance functionality or reports.

Analysis of Traditional Approach

| 44


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

| 45


Phase 2: Common Business Processes

Merge Ledgers, LEs, OUs, Inv Orgs

Merge ledgers

Currency MAY be the only "road block" in merging ledgers

Each ledger will have one operating unit with a standardized name

Legal entities have one-to-one relationship with balancing segment values

Responsibilities, currencies, and rate configuration consolidated as part of merge

Document sequences (based on instance, ledger, or OU) standardized

| 46


Merge Legal Entities

| 47


Merge Operating Units

| 48


Merge Ledgers, LEs, OUs, Inv Orgs

| 49


Merge Ledgers, LEs, OUs, Inv Orgs (Continued)

| 50


Post-Change Steps (Not covered by Software)

Hard-Coded (RICE-W Activities)

Interfaces to third-party systems

Data Warehouse

Reports

Workflows

OFA – Oracle Financial Analyzer

ADI Templates

Uses Ranges

Approval Assignments

Budget Assignments

New EBS Features

New Modules/Functionality

Some Configuration – New CoA, Ledgers

Upgrade to R12

Definition of target

Testing and Cutover Strategy and Execution

COA Rules (Use Business Logic)

Cross Validation

Consolidation

Account Derivation Rules

Accounting Generator

Roll-up Groups

Security Rules

Summary Templates

Mass Allocations

Costing and Revenue Recognition Rules

Descriptive Flexfields

“Auto” - anything

| 51


Building the Business Case

Time/Duration Comparison (in person-months)

Services (For 2 instances) Traditional Approach eprentise Approach

Project Management

Creation of landing balances N/A

Identification of open items N/A

Migration of 1 year of history (includes extract, transform, load scripts, unit testing, issue resolution and error handling)

N/A

Migration of all history N/A

Included

eprentise Consolidation Software N/A 6-8 months

Upgrade (1 instance)

Configuration of R12 instance N/A

Identifying and modifying CEMLI (RICE-W) Objects

Functional Testing (xxx test cycles)

Unit testing of CEMLIs (RICE-W objects)

Maintenance of sunset instance N/A

Total Duration


Building the Business Case

Business/Quality Comparison

Traditional Approach eprentise Approach

All history available in single instance N/A Standard functionality

Resolution of conflicts (names, IDs) in target N/A Standard functionality

Resolution of duplicate data across instances N/A Standard functionality

Change of single instance key flexfields N/A Standard functionality

Drill down to detail in history, subledgers from balances N/A Standard functionality

Risk of custom coding/ loss of data integrity High Low

Configuration data and structures (sets of books, operating units, inventory orgs, etc.) migrated

N/A Standard functionality

Master data migrated Limited Standard functionality

Ability to change in mid-project due to changing requirements High impact on time, cost Refresh of database, addition of rules – impact is days

Time to value (Oracle Support Costs) 18 months to multiple years 6-12 months

Risk High Low

Issues/tickets encountered during testing cycles High (hundreds- thousands) Low (total issues were under 20 for entire project)

Resource Availability Long conference room pilot, technical testing resources, development resources

Minimum amount of time for functional users


Project Planning

| 54


Thank You! Contact

407.591.4950

888.943.5363

[email protected]

One World, One System, A Single Source of Truth

| 55

One World, One System, A Single Source of Truth

www.eprentise.com

mailto:[email protected]

http://www.eprentise.com/

eprentise consolidation overvie · transformation software that remodels any setup data or...

Documents