12.1 Multiple Dimensions of Oracle Insurance Allocation Manager for Enterprise Profitability

Oracle Insurance Allocation Manager for Enterprise Profitability allows you to construct customized solutions for enriching financial data to generate multidimensional Management Accounting profitability views. Without restricting your ability to select any dimension you choose, the following are representative examples of the types of multi-dimensional performance management views you can construct using Oracle Insurance Allocation Manager for Enterprise Profitability.

Organizational View

An Organizational View facilitates the measurement of profitability at any level in your organizational structure, such as Financial Institutions, Insurance institutions, Bank, Region, Company, Legal Entity, or Division levels; or at lower levels such as Branches, Cost Center or Department. While the Organizational Unit Key Processing Dimension is normally designed to match Responsibility Centers (Cost Centers or Profit Centers) that are found both in your source systems and in your General Ledger extract, you may define additional “organizational” Key Processing Dimensions. For example, you might use the seeded Organizational Unit dimension in reconciling your instrument extracts to your Management Ledger data (where your Management Ledger table is populated with an extract from your General Ledger) and you might use a second user-defined “organizational” Key Processing Dimension for Legal Entity or Company if one of those dimensions is present in your source General Ledger.

Alternatively, if you have more than one kind of Organizational dimension in your source General Ledger (example, Cost Center, Company, Legal Entity, Line of Business), you may be able to concatenate one or more such General Ledger dimensions in your ledger and source system extracts (example, Cost Center plus Company) to populate a compound Organizational Unit dimension in your OFSAA data model.

Product View

A Product View facilitates the measurement of profitability of specific product lines including:

  • On balance-sheet customer-facing products such as Checking, Savings, Time Deposits, Credit Cards, Commercial Loans, Consumer Loans, Credit Lines, or Mortgages.
  • On balance-sheet, internal products (non-customer facing products) such as Wholesale Funding or Investments.
  • Off-balance sheet customer-facing services such as Merchant Card, insurance policies, or mutual fund positions.
  • Off-balance sheet products that may be either internal or custom facing such as options, other derivatives, and so on.

Customer View

A Customer View facilitates the measurement of customer profitability under any definition of customer you choose to implement. Examples of customers or customer segments might include demographic segments, commercial customers, high net worth customers, retail customer segments, and so on.

Channel View

A Channel View facilitates the measurement of the profitability of various methods for delivering products or services to your customer base. As with Customer, you may define your channels any way you wish. Examples of channels might include ATM, Electronic Banking, Telephone, Retail Branch, and Mail. A better understanding of the cost structures of your delivery channels can assist you in steering your customers to lower-cost channels or in doing a better job of aligning true costs with revenues through fee structures designed to encourage customers to utilize lower-cost channels.

Key Processing Dimensions in the OFSAA Data Model

Key Processing Dimensions are the keys that the OFSAA engines use to access and segment business data. Every Key Processing Dimension is present in nearly all of your business fact tables, and the usage of processing dimensions permeates most OFSAA rule types.

Seeded dimensions include Financial Element (only found in the Management Ledger), Organizational Unit, General Ledger Account, Common Chart of Accounts, and Product. You may add your own user-defined processing dimensions to your data model.

Financial Element

Used only in the Management Ledger, Financial Element classifies your data in a fashion not typically found in most General Ledgers. When you initially load your Financial Accounting data from your General Ledger, Financial Elements are used to distinguish between:

  • Ending monthly balances (FE 100)
  • Average monthly balances (FE 140)
  • Interest Income or Expense (FE 420)
  • Non-Interest Income (FE 455)
  • Non-Interest Expense (FE 457)

Seeded Financial Elements

The Financial Element dimension is the only seeded Key Processing Dimension that comes with its own seeded dimension member values. Seeded Financial Element values – dimension members from 0 to 10,000 – may not be modified, but they may be used as storage targets for initial load data or as output targets from allocation rules or other processes. In addition to the five Financial Elements discussed above, OFSAA comes seeded with dozens of additional Financial Elements. For the most part, these other seeded Financial Element values are used as output dimensions member values for:

  • Storing final, ready to report, fully allocated multidimensional results. While user-defined Financial Elements may also be used for this purpose, there are a series of seeded Financial Elements that you may choose to utilize as they are pre-built to function as “reporting lines” within the Oracle Financial Services Enterprise Financial Performance Analytics (OFS EFPA) application.

    For a complete listing of all seeded Financial Elements, see Seeded Financial Elements. For examples of the usage of user-defined Financial Elements, see the sections Initial Loads to the Management Ledger and Usage Examples of User-Defined Financial Elements.

Organizational Unit

Found in your Management Ledger as well as in all of your Instrument and Transaction Summary tables, Organizational Unit is generally mapped to your General Ledger responsibility center (cost center or profit center) or department.

User-Defined Organizational Units

Additional organizational dimensions may be added as user-defined key dimensions. For example:

  • In a Management Ledger implementation, you may wish your profitability implementation to record the organizational source of allocated expense balances to facilitate inbound-outbound center-to-center allocation reporting.
  • When loading account-level data into the OFSAA Data Model, you will normally map your Book-of-Record cost center to the Organizational Unit dimension (the value that reconciles to your General Ledger). You might also, however, wish to define a Relationship Owning Center or a Company, Line of Business, or Legal Entity dimension.

General Ledger Account

General Ledger Accounts are mapped from your source General Ledger systems. Financial Accounting systems sometimes refer to this dimension as GL Account or Natural Account.

Common Chart of Accounts

The Common Chart of Accounts dimension is a high-order product dimension that is typically used to link budgeting definitions of products with Oracle Insurance Allocation Manager for Enterprise Profitability definitions of the product (see Debit and Credit Conventions).

Product

Nearly every Oracle Insurance Allocation Manager for Enterprise Profitability implementation is interested in a Product view of profitability.

User-Defined Key Processing Dimensions

You may customize your data model by adding your own user-defined Key Processing Dimensions. See the section entitled “Overview of Dimensionality in OFSAA” or the OFS Advanced Analytical Applications Infrastructure Installation and Configuration Guide for details on adding your own user-defined Key Processing dimensions.

You may also add Standard Dimensions or Simple dimensions to your data model, but the Oracle Insurance Allocation Manager for Enterprise Profitability engine can only actively utilize Key Processing Dimensions within allocations rule sources, drivers, or outputs.

Additional Profitability Dimensions

One reason for adding user-defined Key Processing Dimensions is that your institution's design calls for additional profitability dimensions such as Channel, Customer, Geography, Line of Business, or Relationship Owning Unit, Company, or Legal Entity.

Additional Working Dimensions

Another reason you may wish to add a user-defined Key Processing Dimension is that you need an additional working dimension, i.e., a dimension along which you do not intend to fully develop Management Accounting analytics. For example, you may wish to add a user-defined Key Processing Dimension for Cost Pool, Transaction, or Activity. These dimensions may be actively used within your allocation rules but are typically “in-process” dimensions, i.e., dimensions used as stepping stones along the path to fully allocated profitability dimensions.

Yet another reason you may wish to add Key Processing Dimensions is that you must map all of the dimensions present in your source General Ledger to OFSAA Key Processing Dimensions. If your source General Ledger has dimensions such as Company or Legal Entity, you may need to add these dimensions to your model. If a dimension present in your source General Ledger is “organizational” in nature (i.e., Company or Legal Entity), it may be possible to concatenate such dimensions into the single OFSAA Organization Unit dimension as you design and build your ETL for loading source data for your OFSAA data model (ledger data, instrument data, or transaction summary data).