Transcript International and Global Oracle Implementations Myths and

International and Global Oracle
Implementations
Myths and Reality
Hans Kolbe
Celantra Systems
[email protected]
(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 MultiOrg 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
PPG FR
Sypsy
PPG ES
PPG DE
PPG NL
PPG IT
PPG
UK
OU
OU
OU
OU
3x
OU
OU
OU
OM, AR,
IC, PO, AP
OM, AR,
IC, PO, AP
OM, AR,
IC, PO, AP
OM, AR, IC,
PO, AP
OM, AR,
IC, PO, AP
OM, AR,
IC, PO, AP
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
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
Direct Regional View of all Business Transactions,
Orders, Revenue, Purchasing, Expenses, Margins
European Operating Unit
AR, INV, PO, AP, OM, OPM
All Business Transactions
including Order
Management and Customer
Transactions, Cost of Sales,
Margins; Purchases and
Vendor Management are
handled through European
Operating Unit
External Bolt-On manages IC relations,
prints required document and directs
entries to Local Entity books
PPG IT
PPG SA, FR
Local Legal Adjustment Entries
are booked at country level
PPG GmbH, DE
PPG BV, NL
PPG ES
PPG UK
Legal Set of Books,
General Ledger Entries, Trial Balance Submission
for Corporate Reporting and Consolidations,
Statutory Reporting
Impact of Regional Operating Unit
Model – 1 -
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 subledger
Impact of Regional Operating Unit
Model – 2 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 – 3 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.
Multi-Org Options
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, crossentity 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.
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.
Mechanism needed for dual posting and recording of adjustments:
•
•
•
•
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
Issues in Global COA Implementation
* 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
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 Intrastat 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
 Template
Objectives transformed into Scope
and Template by
- Technology / Apps Versions
- Business Priorities and Involvement
- Resources
- Time Line
 Implementation
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
Define Global Deployment Model
 External
•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)
Define Global Deployment Model
 Internal
•Logistics
Shared Services
Chart of Accounts, Intercompany, Consolidations
“Virtual Close”, Financial Analysis
 Systems
•Technical Base
(Servers, Databases, Connectivity)
•Legacy Systems and Interfaces
 Implementation
•Implementation Strategy (central, regional, local)
• Program and Project Management