1

Centralizing Credit Management with R12, Customer Data Hub and OBIEE

Wrightson Jackson and Craig Anderson

Hitachi Consulting Corporation

A Knowledge-Driven Consulting White Paper

2011 Hitachi Consulting Corporation

2

Contents

Introduction ........................................................................................................................ 3

Business Objectives .......................................................................................................... 3

Designing the Solution ...................................................................................................... 3

Credit Management in R12 ................................................................................................ 3

Credit and Collections Data Mart in OBIEE ...................................................................... 4

Customer Data Hub ............................................................................................................ 5

Approach to Integration ..................................................................................................... 6

Data and Flow ..................................................................................................................... 6

Oracle Advanced Queuing (Streams) ............................................................................... 7

JMN Messages .................................................................................................................... 7

XML Messages .................................................................................................................... 8

Conversion using Messaging ............................................................................................ 8

Conclusion .......................................................................................................................... 9

Acknowledgements ............................................................................................................ 9

About Hitachi Consulting Corporation ........................................................................... 10

About Hitachi .................................................................................................................... 10

3

Introduction

This case study covers integration of Oracle R12 eBusiness Suite with a custom Oracle Business Intelligence Enterprise Edition reporting solution plus an external implementation of Oracle Customer Data Hub. It highlights the uniqueness of integrating these three technologies for a robust credit management and analysis solution involving multiple legacy systems with high integration complexity. Each of these three technologies delivered a critical aspect of the overall solution. This paper emphasizes considerations for both the technical integration of these technologies and their deployment as individual components to unique user groups.

Business Objectives

As credit was relatively easy to attain in the early 2000s, many companies grew significant lines of business based on providing low interest loans to their customers who would then invest in more products and services. As the economy changed drastically during the recession of 2008, many businesses were faced with difficult decisions regarding their lending and credit management policies. The project described in this case study took place at an Oracle EBS client looking to enable a robust credit management and lending organization to address the challenges of the changing economy through the strategic deployment of Oracles Enterprise technologies. The business case for this project consisted of one primary goal: provide management with the tools required to most effectively manage overall debt exposure. The client pursued two core strategies to achieve this goal; the first was a process change to centralize credit analytics and the second was to provide the critical data points required for credit decisions in a consistent, reliable manner. Our client operated in a highly distributed model with locations across North America where policies and procedures had developed organically within each region, or, in many cases, at each site. Through centralizing the credit management process, the business planned to maximize efficiencies and increase risk management capabilities while enabling a consistent strategy for dealing with credit and collections. To support these processes, we deployed technology providing a comprehensive view of the customer including debt across all locations and enabled the analysis of trends to allow potential credit issues to be addressed before becoming actual delinquencies.

Designing the Solution

When designing the solution, it was important to remain within the overall enterprise IT strategy and provide a flexible data model and platform that would be compatible with other initiatives. The client was an early adopter of R12 Financials and had a long term strategy to increase their Oracle footprint. Early in the engagement we validated that a combination of R12 Credit Management, Oracles Customer Data Hub (CDH), and Oracle Business Intelligence Enterprise Edition (OBIEE) would provide the integrated solution required to achieve the goals set forth in the business case. While implementing each of these tools individually presents challenges, the requirement to deploy a fully integrated solution created a very unique project. The following sections will discuss our experiences, findings, and lessons learned for the deployment of each component technology as well as the integration of the complete solution.

Credit Management in R12

Oracles Credit Management module is relatively young and has typically been used for some Dunn and Bradstreet reporting and manual population of the Credit Limit field to cap the total value of outstanding sales orders. However, all the infrastructure and components required to support a robust credit management process exist in R12. Our task was to utilize these components and extend (not customize) them to deliver the functionality required by a mature lending and underwriting organization.

4

In order to address the many data requirements unique to an underwriting business, we utilized the Additional Data Points feature of Credit Management. Additional Data Points are very similar to Descriptive Flexfields (DFF) in that they allow for custom fields to be added to a standard Oracle form in a way that is fully supported. However, there are a couple of key differences. Unlike DFFs, one can create as many Additional Data Points as are required on the Credit Application; where most DFFs max out on any given form at around fifteen custom fields, we added over one hundred custom data points to the standard credit application form. These custom fields can also be configured in a parent-child structure that allows you to design an intelligent form that is more user-friendly. One limitation of the Additional Data Points that we have yet to solve is that there is not a way to configure them that will define the order in which they appear on the application. Another critical extension within Credit Management was to modify the approval workflow. The standard workflow is divided into two distinct processes. The first process is the standard application workflow which routes the application from initiation to data gathering and analysis before the application is finalized and submitted for approval. Upon submission for approval the second workflow process begins and the application is routed through a defined approval hierarchy based on recommended credit limit. This design is a good fit for many credit departments that operate with a standard structure involving credit analysts and credit managers. A larger and more complex credit department will require that applications are updated and analyzed by multiple specialized groups. This structure will require modifications through the Approvals Management Engine (AME). One extension the client required was an update to the second workflow to allow approvers more flexibility. By default, once the application is submitted for approval, it is frozen and can no longer be updated. Therefore, an approvers only option is to approve or reject the application. Because the application is frozen, a rejection will require complete rework of the application from square one, regardless of the reason for rejection. We extended the approval workflow to include a Request More Information option where an approver could ask for specific data points to be updated. The application was returned to an open status in the first workflow. Reporting out of Credit Management remains a custom build for each implementation as there are no standard reports available. Two reports that were deemed as business critical were the Pending Application report and the Standard Contract. The Pending Application report served as a communication tool for customer service representative to reference to keep customers apprised of their applications status. The Standard Contract was a template that leveraged the information stored in parent-child Additional Data Points to create formal contracts that could be provided to the customer upon approval of an application.

Credit and Collections Data Mart in OBIEE

One aspect of this engagement that was critical to the success of the project was providing the decision makers in the credit department with the information they needed to make quick and effective decisions. OBIEE provided ideal framework to sustain the reporting solution: a custom built, best practice layered architecture including a staging layer, a 3rd-Normal-Form (3NF) relational Data Warehouse layer and a dimensional Data Mart. The OBIEE Data Mart is easily accessible by any Oracle EBS user and could provide the comprehensive view of the customer that the client required. Multiple systems would feed data into the Data Mart including their global CRM system, legacy operations systems, Oracle Financials and CDH. The intent was to collect all relevant transactional data associated with a customer (or potential customer) to be provided as a point-in-time view, as well as historical views for trend analysis. The attributes collected, calculated, and stored for each customer belonged to one of six areas of analysis: Application, Decision, Payment, Accounts Receivable, Write-Off, and Recovery. These were captured at the customer account level but could be aggregated to customer party or internal organizational views. The unique requirements of this project led to advanced RPD development techniques. One technique was to use session variables populated in a prompt to limit the data on a

5

logical table source. Additionally, reports were populated with different logical table sources from the same physical fact on one report, which allowed each section within a report to span different time frames.

Customer Data Hub

Two major deficiencies of the legacy system architecture that impacted not only the credit department, but also the rest of the enterprise, were the existence of multiple views of the same customer and the inconsistency of data. Our approach was to use this project as an opportunity to deploy best practices in Master Data Management (MDM) enabled through Oracles R12 Customer Data Hub. We designed CDH as a true MDM hub integrated with established source systems to become the system of record for master customer data. Our benchmarks for master data activity on customer records indicated that we could expect ten thousand to fifty thousand updates each day. The ideal architecture in this circumstance was to deploy CDH in a stand-alone environment on its own hardware. The other option was to utilize the CDH functionality as it existed in their current eBusiness Suite environment. However, this would encumber the financial system with processing of each update to the customer record. By deploying the CDH as a true central MDM hub, it could collect and merge the updates from multiple sources and send final consolidated updates to the transactions systems in batches. The feature of CDH that makes this solution possible is Single Source of Truth (SST). SST allows you to determine survivorship of customer attributes as records from multiple systems are merged into one. A challenge we faced with SST was that its scope is limited to certain attributes and decision criteria that prevented the solution from addressing several critical requirements. The final design included utilizing the User Hook option on the customer merge process as well as some custom business event subscriptions to enhance the native SST functionality.

6

Approach to Integration

The volume and nature of the customer data involved necessitated that all three technologies be deployed in one production release. We mitigated the inherent risks of this approach through sophisticated messaging tools and a consistent data exchange protocol that could be utilized during data conversion and cutover in addition to steady state interfaces. The essential components of this integration strategy are described below.

Data and Flow

As depicted in the diagram above, one aspect of this project is the enterprise-wide policy to utilize XML messaging for all interfaces and to centralize the transport in a spoke-and-hub communications architecture using TIBCO as the hub. On a nightly basis, the customer information from the CRM and Operations systems (new and changes) are published as XML messages. TIBCO routes that message to CDH where the Data Quality Module assesses whether this is a potential duplicate of an existing dealer based on the keys (primary keys) in the XML message. The party merge is run on a daily basis to merge the CRM and Operations parties based on the Registration ID (unique primary key from 3rd Party). CDH publishes the dealer message to TIBCO for the survivor party which routes it to both EBS and Credit & Collections Data Mart (CCDM) built on OBIEE technology.

7

All systems process the inbound message as an UPSERT. All messages contain a section containing unique keys for the entity on each system. When a message is processed by any system it first checks its key repository to determine if the entity already exists; if it does then the data is treated as an update, but if not the data is treated as an insert, hence the term UPSERT. Applications for new lines of credit or increase in credit lines are collected at the Stores and sent via an imaging system to the credit department where it is entered in Oracle Credit Management (OCM). In the case of new customers this application may arrive in EBS before the customer information propagates through the messaging system, requiring the analyst to search for the customer and create a new one if not found. The creation of the account (there is no message triggered on creation of a party in EBS) triggers the publish process from EBS to CDH and CCDM. If the credit application is approved then the new account information is published to the Operations system.

Oracle Advanced Queuing (Streams)

Oracles Advanced Queuing product, Oracle AQ, is one component within the broader Streams product. The full Streams product is designed to facilitate replication of database data across multiple instances. In this context, messaging is simply one step in the middle of a logical sequence: capturing database changes staging the change records in an Advanced Queue, potentially propagating the queued changes to other queues, application of the change records to one or more target databases, and resolution of conflicts. AQ itself is available by default in every Enterprise Edition database instance and is the foundation for EBS Workflow. It is implemented as a set of tables with several supporting views and processes. Each queue is a table that holds the message. All queue tables have the same structure and the message is actually kept in one Large Object Binary, or LOB, field. You may define any structure you wish as the payload to be stored in that column. A queue is defined, started, stopped, written to, and read from, using methods in the DBMS_AQ and DBMS_AQADM packages. These packages are described in the Oracle Streams Advanced Queuing Users Guide which is available on line on the High Availability page. Defining a new queue is a three step process: create the queue table (where the messages are actually stored), create the queue (the views and processes that implement the queue logic), and the start the queue (start the processes). All the features one expects in a message queue such as message sequencing (FIFO, LIFO, etc.), publish/subscribe, multi-consumers, robust store and forward capabilities and guaranteed delivery, are provided by processes that are implemented on the database server as separate threads dedicated to queuing (processes can be seen in the OS as qmn001, qmn002, etc.). For this reason, it is not possible to perform operations (insert, update, delete, etc.) on the queue tables directly. Doing so is very likely to destroy the integrity of the queue beyond recovery.

JMN Messages

There are two basic components to the message being queued: the data (payload) and the envelope it in which it is delivered (JMS, in our case). The payload can be any data in any format, as long as it fits in a LOB and is in a format both the sender and recipients agree upon. In our case, the payload is always an XML document, one of many XML messages which conform to a set of XSDs, each representing a particular kind of data. The payload is wrapped in a logical envelop, a protocol, which is defined by the JMS standard. This determines which protocol and supporting structures will be used as the message envelop. The JMS protocol consists of a header structure and a means of

8

adding properties. The header typically contains standard values: fields for destination, priority, timestamp, unique ID, etc. The properties are name-value pairs; some pairs are pre-defined by the JMS standard, some are pre-defined by Oracle, and some may also be defined by the developer. In our case, we used two custom parameters: one to hold the name of the message used by the TIBCO routing process to efficiently determine where to send the message, and a second version property. The version is intended to make it easier to transition gracefully to future changes in the message structure. Before calling the enqueue method of DBMS_AQ, we fill in the various parameters, header values, and properties using other methods of the package.

XML Messages

The development standards we defined with the long term goals in mind required that each message must conform to an XSD defined by the enterprises Canonical. The messages are never fragments and always hold the entire dataset for one of the top-level objects: Customer (Organization), Person, Account, or Relationship. XSDs are hierarchal lists of elements and, in our model, went eight levels deep for some of the objects. One of the challenges of the solution was the creation of the XML document from code. Oracle provides several tools for generating XML, such as:

SQL functions (i.e. XMLROOT, XMLFOREST, etc.)

DBMS_XMLGEN

SYS_XMLGEN and SYS_XMLAGG

XSQL Pages Publishing Framework

XML SQL Utility (XSU)

XML DB

A very simple, quick method to create XML text from code is to create an XML document with all the expected elements of the XSD. Often, an XML tool like JDeveloper can make this job easy, since it can create an XML document using the XSD as a template and it can create the XSD from an XML document. We were able to copy and paste the XML document into our code as literal text, then replace the actual data with variable names surrounded by concatenation operators. This was quick and eliminated the risk of many simple mistakes, but only works well for simple documents. If the XML document includes repeating or optional elements, the code can become difficult to read and maintain. The next challenge was retrieving the data to write to the XML document. It is good design to separate the function of retrieving the data to be written from the function of formatting the output of the data. This design required a means of communicating a fairly large amount of data (typically several dozens of element names and values) efficiently. Ideally, we wanted to reflect the hierarchal data structure that implements the XSD; this could easily be done as an object and was a good application for Object Tables. In this case, we built object tables for each of 4 XSD nodes which corresponded to messages: Customer (Organization), Person, Account, and Relationship. The tables are populated either by processing an inbound message from another system or by events triggered when TCA data is entered in the front end. The data is then read by a process that formats the data into an XML document and queues a message for transmission to other systems.

Conversion using Messaging

Prior to go-live, the messaging system was used to load the customer data from the source system. It was viewed as a way to avoid developing throw-away conversion code, as well as an opportunity to thoroughly validate the interface logic to be used

9

once the system was live. However, when the data extraction queries were run against the actual production databases, we received nearly three million records approximately four times as many as anticipated. This amount of data would normally be processed in a day or two using traditional conversion techniques. However, it is far less efficient to convert data to a text-based message, parse the text data, and transform from the XSD format to data needed by the TCA layer of Oracle Applications. These are all added steps incurred by the use of messaging, on top of the TCA calls to actually validate and load the data. This conversion took seven days of continuous processing as the data was sent to the CDH tier, de-duplicated, then propagated via messaging to EBS. During this process, we identified an important procedure for running high volumes of data through the CDH Automerge process. The step within the Automerge that prepares the individual batches for the merge of records for a single party operates in a loop without any commit. It does this because it sets a SAVEPOINT so that it can roll back to that point if necessary. However, that means that very large batches consume rollback and temporary segments, potentially exhausting them. Our test, which should have created 160,000 batches, each merging two or more parties, ran for more than thirty hours without completing before we elected to terminate it. Our solution to this problem was to define multiple, smaller batches based upon the fist letter of the customer name.

Conclusion

In addition to the findings highlighted above, the Conference Room Pilot (CRP) approach to testing proved critical to the quality assurance process on this engagement. Bringing key stakeholders and user groups for all three technologies together to execute focused testing activities helped ensure that the overall strategic integrity of the project was maintained across the entire solution. Integrating these three unique but complementary to achieve a strategic goal made for an extremely challenging project that was equally as rewarding.

Acknowledgements

We would like to thank Anita Chow, Brian Hill, Sergei Kiriukhin, Glynn Malagarie, and Suja Subramanian for their contributions to this project and case study. Without their support and tremendous effort, neither could have been accomplished.

10

About Hitachi Consulting Corporation

As Hitachi, Ltd.'s (NYSE: HIT) global consulting company, with operations in the United States, Europe and Asia, Hitachi Consulting is a recognized leader in delivering proven business and IT strategies and solutions to Global 2000 companies across many industries. With a balanced view of strategy, people, process and technology, we work with companies to understand their unique business needs, and to develop and implement practical business strategies and technology solutions. From business strategy development through application deployment, our consultants are committed to helping clients quickly realize measurable business value and achieve sustainable ROI. Hitachi Consulting's client base includes 25 percent of the Global 100 as well as many leading mid-market companies. We offer a client-focused, collaborative approach and transfer knowledge throughout each engagement. For more information, call 1.877.664.0010 or visit www.hitachiconsulting.com.

About Hitachi

Hitachi, Ltd., (NYSE: HIT / TSE: 6501), headquartered in Tokyo, Japan, is a leading global electronics company with approximately 390,000 employees worldwide. Fiscal 2007 (ended March 31, 2008) consolidated revenues totaled 11,226 billion yen ($112.2 billion). The company offers a wide range of systems, products and services in market sectors including information systems, electronic devices, power and industrial systems, consumer products, materials, logistics and financial services. For more information on Hitachi, please visit the company's website at http://www.hitachi.com. For more information on Hitachi, please visit the company's Web site at http://www.hitachi.com/. 2011 Hitachi Consulting Corporation. All rights reserved. Building the Market Responsive Company, is a registered service mark of Hitachi Consulting Corporation.