Northern California OAUG Oracle Trading Community Architecture June, 2006

Trading Community Architecture WHY EVOLUTION WHAT ’ S IN R12 SUMMARY

Trading Community Architecture WHY

To answer some questions What have they purchased? What else can I sell to them? Who can I sell to next? Who are my Trading Partners? Who are my Customers? What business have they done with us? What more can we do with them? How can we improve business with them?

Goals  For Customer information, bringing ERP and CRM to the same core architecture  Separating the entity that enters into a relationship from the business relationship itself  Allowing organizations and people to exist independently of their business relationship within a company  Sharing of party information across all of the ERP and CRM applications and reducing data redundancy  Providing complete view of a party and all of its relationships with you, and its relationships with other members of the trading community

Trading Community Architecture EVOLUTION

Evolution on a release scale OCO (CO) TCA Data Model Public APIs D&B Integration ODL (CDL) DQM Employee Integration 11iR211iR311iR411iR6 11iR711iR911iR10 Classification Model Online Fuzzy Match Party Merge BES Callouts OCO (CO) Web Services SSM CPUI Bulk Import Auto-Merge Address Validation CDH

Steps of Evolution  Started with building a best in class customer data model  Introduced inbound and outbound interfaces to the data model – Public APIs (Java and PL/SQL), Bulk Import, Event-Subscription  Focused heavily on building data quality – Fuzzy Match, DQM, Merge, Data Librarian  Introduced third party integration e.g. with content provider DNB, with address services providers  Built comprehensive UI to view and maintain customer information – Customers Online. Provided UI components to application products for consistent exposure of customer information – Common Party UI

Steps of Evolution  Introduced system cross-referencing mechanism – Source System Management  Provided unlimited extensibility to the model, to capture information specific to your company or your industry  Built 360 degree transaction viewer, graphical relationship viewer  Built integration with HRMS, HealthCare, Student System, User Management, B2B Gateways  Worked with product teams to streamline application flows having touch point with customer information

Evolution in 11i EBS  Became central person and organization master for majority of applications in EBS TCA Data Model HZ Schema TCA Enabling Infrastructure Common Party UI, DQM, D&B Integration, APIs CDMSalesServiceFinancialsHR Oracle E-Business Suite Application Families* * This diagram depicts only a small subset of the application families that utilize TCA CDM Areas of Responsibility

Business Flows  Campaign to Lead  Lead to Opportunity  Opportunity to Quote  Opportunity to Forecast  Quote to Order  Order to Invoice  Invoice to Cash  Cash to Compensation Campaign to Compensation E-Business Suite Applications  Marketing Online  Telesales  Sales Online  Territory Manager  Quoting  Pricing  iStore  Order Management  Accounts Receivable  Credit Management  Incentive Compensation  Human Resources  Payroll  Marketing & Sales Intelligence

Business Flows  Call to Resolution  Click to Resolution  Inbound Call to Depot Repair  Inbound Call to Dispatch  Dispatch to Resolution Service Request to Resolution E-Business Suite Applications  Teleservice  Contact Center  Customer Care  iSupport  Field Service  Installed Base  Scheduling  Depot Repair

Business Flows  Contract Creation to Renewal  Contract Usage to Cash Contract to Renewal E-Business Suite Applications  Sales Contracts  Service Contracts  Accounts Receivable  Service Intelligence

Evolution in 11i EBS  Became central person and organization master for majority of applications in EBS TCA Data Model HZ Schema TCA Enabling Infrastructure Common Party UI, DQM, D&B Integration, APIs CDMSalesServiceFinancialsHR Oracle E-Business Suite Application Families* * This diagram depicts only a small subset of the application families that utilize TCA HR Others

Evolution in 11i EBS … But what about organizations that are in a heterogeneous applications environment? Navision SAP PeopleSoft Oracle Epiphany Retek Siebel Lawson

Evolution of Customer Data Hub Extended the solution beyond Oracle e-Business Suite … Introduced Customer Data Hub  Central customer master data store  Data quality tools run in single instance for increased ROI  Platform for custom applications  Creates enterprise customer data ownership  Improved customer visibility – Real-time access to all data – 360 degree view of all transactions  Lower total cost of ownership – Simplified integration – Reduced maintenance costs Navision SAP PeopleSoft Epiphany Retek Siebel Lawson

Trading Community Architecture WHAT ’ S IN R12 (This is not a product announcement)

R12 – SOA Enabling TCA V2 API’s Entity Centric V2 Business Events Entity Centric Entity Centric V2 API’s and Events Business Object Layer Business Objects (DB Objects) Business Level APIs and Events Get Create Update Save Business Object Level APIs and Events Integration Repository (Web Service Provider) Servicebeans/SDOs/Generate Functions

R12 – Integration capabilities Integration based on TCA Entities Extensive Custom Coding No middleware integration Low level entity access Integration Components Business Objects based integration No coding required Out-of-the-box integration to Oracle SOA Suite Business Object level access Complete Integration Solution Release 12Release 11i      Java & PL/SQL APIs Web Services 

R12 – Supplier Integration  Supplier organizations are in TCA  Terms of doing business with the supplier are in Purchasing / Payables  Supplier organization, address, contact, phone, etc. are all in TCA  Employees are already in TCA, Payables using the same employee records in TCA  New supplier maintenance UI using TCA UI components

R12 – Shared Services Architecture  Oracle E-Business Suite introduces new Shared Services Architecture in R12  TCA leverages the new architecture in providing easier maintenance of Account layer information that are operating unit sensitive  No more changing responsibility to access account information from different operating units

R12 - What’s in TCA Customer Supplier Bank & Branch Student, Faculty EmployeeContact & User Patient & Doctor Legal Entity & Intercompany Partner & End Customer

Trading Community Architecture SUMMARY

The Guy from Australia

What you get from TCA  Prevent situation like the one we just watched!  Tools that deploying companies can use to model their customers as they see best for their business  Architecture that will grow with deploying companies ’ requirements  Features to maintain extremely reliable customer information  Glue that ties several E-Business Suite flows in a seamless way  Customer Data Integration solution even if deploying company is not running a single E-Business Suite module  Platform that can play a key role in your IT landscape for Master Data Management

What you have to do  Take a close look at how you do business and how your business processes are most efficiently performed  Ask questions about how you should model customer information e.g. which entities should be modeled as parties, when should you create an account, should you create multiple accounts for some parties, should you create multiple billing sites for an account, should you create account relationships  Even if you are implementing few modules of E-Business Suite to start with, keep in mind the bigger picture about customer information

MetaLink Resource  Oracle Trading Community Architecture – Modeling Customer and Prospect Data : The document talks about answering a set of key questions about your prospect and customer data. This document offers guidance on the order in which these questions should be asked and on how to answer each question given your objectives and business processes.  Oracle Customer Data Hub Implementation Concepts and Strategies : The purpose of this document is to address the various considerations and decisions that come into play when implementing the Customer Data Hub, and to outline a concrete methodology for successfully implementing the CDH.