International and Global Oracle Implementations Myths and Reality

Hans Kolbe

Celantra SystemsHanskolbe@celantrasystems.com

(415) 846-2623

What I will cover today

- Multi-Org impact- Legal Compliance choices- Implementation Strategies

Not Covered today

- Language - Character sets and Multi-Byte- Technical Architecture

A Typical Wish-List

- “create a multi-national multi-language finance and logistics system

- global chart of accounts and accounting standards - global supply chain visibility - compliance with local regulations and statutory demands for

accounting and reporting - shared regional logistics and financial service centers to use

economies of scale wherever possible - allow effective operational support for international and

intercompany transactions while complying with regulations for inter-company pricing

- provide effect structures for regional logistics and production centers while avoiding unproductive data duplication.”

Myth: Global Implementations are not successful

• Success: Texas Instruments - International Roll-Out after US

implementation in 16 countries (Europe and Asia). Single install, Version

11.03, 12 months to go-live. Achieved global planning and Europe-wide

logistic and finance visibility.

• Success: Rational Software - International Roll-out after US implementation

to 23 countries with 11I upgrade (Europe and Asia). Single install, 10

months to go-live. Achieved international order and logistics visibility

• Mixed: PPG - After US template 9 country roll-out in Europe. Version

10.7. Separate instance. 2 ½ years implementation country by country.

Parallel Australia and Latin America. Areas of fragmentation remain in

Order and PO management.

Key Differences in Design and their Impact - Examples

• INTERNATIONAL TRADING MODEL, INTERCOMPANY TRANSACTIONS AND ORACLE MULTI-ORG STRUCTURE

• LEGAL AND STATUTORY COMPLIANCE STRATEGIES, LEGACY SYSTEMS AND ORACLE GLOBALIZATIONS

• IMPLEMENTATION STRATEGY – GLOBAL OR REGIONAL VERSUS COUNTRY BY COUNTRY

Issue 1: International Trading Model and Multi-Org Strategy

Global Trading Model and Multi-Org Impact – Myths

• If employed globally, Oracle Applications will give us global visibility automatically (optimistic).

• With a correct setup, Oracle will give operations, planning, finance, and reporting what they need. (optimistic)

• We have a working US Implementation. With some minor adjustments it will be our global template. (optimistic)

Reality• Supply Chain visibility across entities and countries – must impact

multi-org strategy.

• Shared service center requirements must impact multi-org setup

strategy. Data Visibility and Access for users is restricted by SOB and

Multi-Org constraints.

• Intercompany requirements must impact multi-org setup strategy.

Oracle Intercompany functions are limited.

• There is not ONE correct setup for international implementations.

• Balancing planning, operational, finance and legal requirements is

important.

• Early impact analysis is needed to achieve global objectives

Standard ERP Multi-Org Model - Silo PPG Europe

PPG FR

OM, AR, IC, PO,

AP

PPG ES

OU

OM, AR, IC, PO,

AP

PPG DE

OU 3 x

OM, AR, IC, PO, AP

PPG NL

OU

OM, AR, IC, PO,

AP

PPG IT

OU

OM, AR, IC, PO,

AP

PPG UK

OU

OM, AR, IC, PO,

AP

Issues: - duplicate setups and maintenance - no visibility for order management across OU boundaries - no Blanket PO’s across OU boundaries- logistics operations are limited to one OU at a time - business reporting across OU only through financial consolidations or special tools – Purchasing data base, Toad, etc. -Duplicate inter-company transactions without value to the business

PPG FR Sypsy

OU

OM, AR, IC, PO,

AP

OU

Multi-Org Proposal - The Challenge

Traditional Situation

Traditional ERP implementation models have been built on the basis of separate legal entities and country organizations. These entities cooperate and exchange goods and services. Essentially all subsidiaries operate as independent units.

The “Silo” model is assumed in most of Oracle applications, including existing inter-company, localization and globalization functionality as well implementation and training models. This model is the base for the standard Multi-Org Setup in Oracle applications.

Regional Operating Unit Model – The Alternative

PPG IT

European Operating Unit

AR, INV, PO, AP, OM, OPM

PPG SA, FR PPG GmbH, DEPPG BV,

NLPPG ES PPG UK

All Business Transactions including Order

Management and Customer Transactions, Cost of Sales,

Margins; Purchases and Vendor Management are

handled through European Operating Unit

Direct Regional View of all Business Transactions, Orders, Revenue, Purchasing, Expenses, Margins

Local Legal Adjustment Entries are booked at country level

Legal Set of Books, General Ledger Entries, Trial Balance Submission

for Corporate Reporting and Consolidations, Statutory Reporting

External Bolt-On manages IC relations, prints required document and directs

entries to Local Entity books

Simplify – Eliminate Duplication: • Simplify Implementation and Ongoing Maintenance (no duplication and continual synchronization of setups) • Simplify Shared Service Centers (Customer Service, Procurement, Finance) - no changing responsibilities• Simplify and Speed up Monthly Closing, only one sub-ledger

Impact of Regional Operating Unit Model – 1 -

Cross-Entity Visibility• Order View and Fulfillment•Accounts Receivable and Collections • Backlog, Allocations and Release Management • Vendors, PO’s and Contracts (buy and receive anywhere)• True external Revenue and Margins without intercompany distortions

Automate Intercompany Transactions•Intercompany Transactions (Commissionaire, Buy/Sell, Agent) are automatically generated on both entities

Impact of Regional Operating Unit Model – 2 -

Risk Potential: - Common processes and setups across entities may be very difficult to establish. - Correct Intercompany and Legal Entity statutory reporting must be ensured through external add-on process (see case studies). - Business may operate in single entity mode. Evaluate business performance measures and analysis.- Cross-entity visibility, reporting, and access may not be desired.

Impact of Regional Operating Unit Model – 3 -

The Standard Multi-Org Setup fits well, when- Subsidiaries operate essentially as independent entities. - Data separation through Operating Unit Entity is desired for security and reporting reasons. - Intercompany sales and purchases are handled much in the same way as external ones. - Business Model and Organization can be changed to fit the Oracle “independent entity” approach.

Standard Multi-Org Setup will not always avoid the need for extensions

or bolt-ons.

Multi-Org Options

Alternative Approach needs to be investigated when: - Multi-Tier trading model is used (supply chain through subsidiaries with specialized production and sales entities) - Commissionaire structure is employed or fluctuating IC pricing- Shared Services across entities and countries, cross-entity purchasing, cash settlements, or IC settlement automation are desired.

Intercompany Simplification can be established within traditional setup. Multi-

Org options can be mixed and individualized.

Multi-Org Options

Issue 2: International Legal Compliance with Oracle Apps

International Legal Compliance Issues with Oracle Apps – Myths

• We have a US Implementation. With some minor adjustments it will be our global template (optimistic).

• Oracle has a plug-in set (Globalization, Localization) to take care of most local compliance issues (optimistic).

• Major customizations are needed for compliance in difficult countries (Italy, China, Brazil, Israel, Portugal) – (pessimistic)

• MRC is needed in international implementations (only in very specific circumstances)

Chart of Accounts and Accounting Standards

• Government recommended COA in France, Spain, Belgium, Greece, China, Korea and Japan.

• Inventory Accounting, Accruals, Depreciation, Year End closing are different in most countries.

• Not all US accounting principles are readily accepted.

• Separate Set of Books for legal reporting with use of consolidation functionality or AX Global Accounting Engine

• Use of separate balancing segment within the same Set of Books

• External Bolt-On application for legal compliance transformation and reporting

• Custom Extensions to be built or re-used from other implementations

Mechanism needed for dual posting and recording of adjustments:

* One US to many Local Accounts - One Local to Many US Accounts (Payroll and Benefits)

* Accounting Method Differences

- Purchasing and Inventory Receipts (total purchase price vs standard cost +- Variances)

- Cost of Sales and Inventory

* Accounts don’t exist in Fiscal Accounting Books (example: Goodwill)

* Value Differences - separate accounts (1,2,3 codes), (example Depreciation) - separate entries - risks and options

* Date Differences - (example Period Closing/accruals) separate entries - risks and options

Issues in Global COA Implementation

Legal Compliance – Transactions Tax (VAT and Sales/Use Tax)

• Different requirements on VAT reporting, VAT assessment and offsets. Detail review in each country required. Validation of Oracle Globalization needed in each country. Special attention to be given to VAT calculation and reporting on adjustments, discounts, bonuses., pre-payments, credits, refunds.

• Synchronization of VAT requirements across Europe and Asia can be achieved. (See Case Study Texas Instruments). One set of parameters across Europe with consolidated VAT and Intra-stat reporting and country specific formats.

Legal Compliance – Other Issues

• Fiscally Required Audit Reports (Libro Giornale, Grand Livre) may not be immediately available through Oracle Standard Applications or Globalizations. AX Global Accounting Engine may be needed.

• Sequencing requirements for VAT and Journal Reporting may force additional setup work or custom programming to ensure compliance (Italy, Spain, France)

• HR reporting - payroll, contractors, data privacy laws

• Bank formats, AP payments, AR receipts, future dated payments, bill of exchange

• International customs, duty, and export control regimes may impose complex additional requirements, depending on business and trading model.

• Language of screens, reports, and data may be regulated.

Issue 3: Global Implementation – Strategies and Decisions -

Implementation Stages

Objectives

Ongoing Support

Implementation

Template

Objectives transformed into Scope and Template by

- Technology / Apps Versions- Business Priorities and Involvement

- Resources- Time Line

Template is transformed into Implementation by - Program and Project Team

- Deployment Sequence - Adaptation of Local Differences

- Changes in Objectives, Scope, Technology, Resources, Time Line

- Test Sequence and Quality Standards

Implementation turns into Support by

- System in Production- Project Team transforms

- Evaluation of Implementation

- Measure against Scope and Template

- Assess future requirements for objectives and scope

- Assess changes in Objectives and Resources

External

Define Global Deployment Model

•Global Trading Model•Supply Chain Planning

•Sales Management/Customer Relations•Purchasing and Vendor Relations

Legal

Mechanism and Compliance Standards for Statutory and Legal Requirements (Accounting and

Reporting)

•Implementation Strategy (central, regional, local)• Program and Project Management

Systems

Define Global Deployment Model

Implementation

•Technical Base (Servers, Databases, Connectivity)•Legacy Systems and Interfaces

•LogisticsShared Services

Chart of Accounts, Intercompany, Consolidations“Virtual Close”, Financial Analysis

Internal