Changes in financial reporting requirements have transformed the fixed asset accounting framework. International Financial Reporting Standards (IFRS) require fixed assets to be recorded at cost, but there are two accounting models – the cost model and the revaluation model. So what’s the difference, and when should you use each? This session will address fixed asset accounting and reporting under both models and how each is accounted for in Release 12.

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

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

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

5. Multi-Instance Environment
How did we get here?
What are the limitations of a multi-instance
environment?

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

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

8. Consolidation vs Migration or
Reimplementation
How does consolidation work?
What are the benefits of consolidation?

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

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

11. eprentise Compare Reports
11

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

13. eprentise Consolidation
13

14. 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
eprentiseMetadataAnalysis
eprentiseConsolidationSoftware
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

15. Changes Made Automatically During
Consolidation
Three Types of Changes:
Name Changes
ID Changes
Synchronization
15

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

17. Case Studies and Examples

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

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

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

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

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

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

24. GE GRC Consolidation Project Resources
(Does Not Include Resources for RICE-W Objects1)
1 Also does not include TCS external consultant help.
24

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

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

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

28. Roadmap to Consolidation

29. 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. 30

31. DURING THE FIRST
TEST CYCLE
31

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

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

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

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

36. Change Key Flexfields
36

37. Step 5: Resolve Other Differences
• Seed Data
• Configuration Data
– Value sets
– Descriptive flexfields
– Users, Responsibilities, Profiles
– Personalizations
• Master data
37

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

39. eprentise Consolidation
39

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

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

42. Questions? Comments?
42

43. THANK YOU
Helene Abrams
CEO
habrams@eprentise.com
eprentise, LLC
www.eprentise.com
Accelerating the time for change in
Oracle E-Business Suite
Visit eprentise at booth 1423!
43

44. 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!