Oracle’s Profitability and Cost Management Cloud Service (PCMCS) provides a powerful service for allocating General Ledger profits and costs. Recently, we worked with a banking industry client to provide a model that calculates profitability at a Product/Channel level while maintaining Account level detail. We accomplished this through a framework we refer to as Micro-Costing where detailed profits and costs are calculated in a database using rates developed at the summary level in PCMCS. Alithya began development of this framework in 2016 to meet a functional gap in PCMCS and provide a common framework that can be used either on-premise or in the Cloud.
To highlight the capabilities of Micro-Costing, I will use the solution deployed at our banking client as a specific example. The following table describes the two layers where profits and costs are provided:
- Product – a loan or deposit offering. Examples of a loan are an auto loan or credit card; examples of a deposit are a savings account or a checking account.
- Origination Channel – where the account was originated.
- Service Channel – where the financial or transactional cost or profit is occurring or assigned to.
- Customer – a legal entity responsible for accounts; for example, a person with both a home loan and a savings account.
- Customer Account – a product that is assigned to a customer.
- Financial Costs and Profits – the cost or profit of servicing a loan or deposit for a customer; for example, interest paid on a savings account.
- Transactional Costs and Profits – the cost or profit of interacting with a customer; for example, the cost of an ATM transaction.
A simple way of thinking about the client’s business model:
- Origination channels offer Products
- Products are assigned to Customers as Customer Accounts
- Customer Accounts are used by Customers through Service Channels
The generation of an Account level profit or cost is a C = A*B calculation where
- A is the driver
- B is the rate of a driven value
- C is the driven value (profit or cost)
An example is:
ATM Expense = ATM Transaction Count * ATM Expense Rate
This summarizes the data model deployed.
STAGING – Contains transient data.
OPERATIONAL DATA STORE (ODS) – Persists the operational data with minimal transformation. Dimensional integrity is not enforced, but validation jobs are available for validating stored data regarding rules and dimensional integrity.
WAREHOUSE-STAR – Persists the drivers, the rates, and the calculated profits and costs at the Customer Account level. The Driver Lookup and Driven Value Lookup functions are used to define the drivers and driven values so that the addition of a driver or driven value is a configuration activity for an administrator rather than a coding activity.
A high-level summary of the data flows as deployed:
The source data is broken down into 3 types:
- General Ledger
- Operational Data
Data Integration uses interim flat files to maintain flexibility regarding the source data by establishing an API via the flat files without requiring knowledge of the source systems. This allows for the introduction of source data that comes from 3rd parties not available for automated extraction from the source.
The operational data includes both Customer Account financial information and transactional activities or fees. Product and Channel references are provided along with this information:
- 1 million+ Customer Accounts
- Approximately 6 million transactions per month
Some transactional drivers represent an activity that cannot be associated with a specific Customer Account; for example, a new loan application. Proxy Customer Accounts for each product are generated to provide a place for these activities.
Additionally, although not graphically displayed in the above diagram, Branch level drivers are directly fed into the PCM Model, examples of which are Branch square footage and number of branch employees. These drivers were used for non-Customer Account PCM costs and profits.
All Batch processing is built using SQL Server Integration Services. This is based upon an agreement with the client regarding the preferred tool sets with the database selected being SQL Server. Framework is transferable to other integration tools and databases including Hadoop framework, and in-house solutioning by Alithya was performed in preparation for use of the Micro-Costing framework with larger clients.
The data integration is as follows:
- Set POV
- Update metadata and stage
- Stage financial and transactional information
- Validate staged data and reprocess as necessary
- Load staged data to ODS and then to Star
- Upload PCMCS with GL and drivers
- Process allocations in PCMCS
- Download rates
- Run A*B calculations for each Customer Account and populate profit and cost table
Key Design Principles
The following design principles were focused on during development of the Micro-Costing framework. These principles facilitate an easy-to-use and easy-to-maintain solution as deployed for our client.
- Dimensional synchronization between the Micro-Costing warehouse and PCM
- Validation checks as close to the original data as possible
- Configurable drivers and driven values
All dimensional mapping must occur prior to the warehouse star schema. It is not possible to perform the Micro-Costing A*B calculations to derive profits and costs detail otherwise. This has an impact on any deployment that uses FDMEE or Cloud Data Manager as they cannot perform additional mappings during upload to the cube.
Dimensional Synchronization includes a Point of View: Year, Period, Scenario, and Version to allow for loading multiple sets of drivers during a month, and for transfer of ‘what-if’ rates back to the Customer Account level, if desired.
Validation kick-outs and checks occur as early in the data integration process as possible, with a “simple” validation during staging and a “complex” validation during generation of the fact information in the warehouse. This allows the administrator to catch quality issues with a minimum amount of overall process duration occurring. The data integration process is broken into a series of steps that allows for validation review and then re-running a step prior to moving on to the next step. This principle held up in deployment, ensuring that time wasn’t wasted running later processes with invalid data, the result being an improved overall process and a significant reduction in the number of days required to produce profit and cost analysis for a given month. A lesson learned during the initial roll-out was that our client had not previously required a rigorous validation of the drivers at the Customer Account level and had to develop new techniques for validating the source information to ensure accuracy.
Configurable Driver and Driven Values
A key feature of Oracle’s PCM applications is configurability, and the Micro-Costing framework is built to provide an easy-to-maintain solution that allows for rapid addition of drivers and driven values without the administrator having to manually update the tables and views required to manage the transformation and persistence of data. This was accomplished by defining the drivers and driven values in tables and providing stored procedures for maintaining the tables and views.
The process for adding a new driver and driven value is very straightforward:
- Backup the database and the PCM cube.
- Update the source feeds to include the new activity or fee.
- Update the activity to Driver Lookup and Driven Value Lookup tables with the new values. *Note: The driven value record references the driver for the A*B calculation.
- Execute the “Update Costing Tables and Views” stored procedure. *Note: removing a driver or driven value does not modify the tables.
- Update HPCM Account dimension for the new driver and driven value.
- Update HPCM rules to use the new driver and allocate expenses to the new driven value, and calculate the rate for the new driven value.
- Run the entire data integration process for the POV, and review results.
The successful deployment of the solution provides the following key business benefits:
- An improved ability to provide Product/Channel level costs and profits.
- Reduced monthly cycle time and effort. The prior data integration process was disjointed and required a large amount of effort to produce results.
- Drill-through capability to Customer Account level drivers, profits, and costs allows for root cause analysis of Channel and Product Costs.
- Aggregation along other dimensional paths. Starting at the Customer Account level allows for aggregation along Customer attributes such as zip-code or credit score, providing new insights and enhanced executive decision making. A follow-on project to use the Customer Account level data in OAC is currently being assessed.
Additionally, the following benefits to the administrative team are realized:
- Model flexibility. The configuration of an additional driver and driven value in Micro-Costing takes fewer than 15 minutes.
- Operational Data Store (ODS) and Warehouse. This allows for future projects to use a common curated source of information. This was a pot sweetener for our client who was dissatisfied with its prior warehouse, but needed a business reason to refresh. The prior warehouse lacked the following items that were addressed in the new ODS and warehouse:
- Explicit mappings such as Activity Code to Driver Code that are controlled by the business
- 3rd party data from partners and industry sources
- Consolidation of financial and transactional information into Customer Account level facts
- Hashing of Personally Identifiable Information (PII) for account security
- Easy troubleshooting, validation, and auditing capabilities with PCM. Errors or mismatches in profit or cost at the Product/Channel level can be reduced to either rule definition mistakes or driver data entry mistakes. Finding out where the issue is and correcting it with a few clicks has a positive impact on the overall analysis and maintenance effort.
Alithya has developed a Micro-Costing framework that allows an integrated view of profits and costs at both a summary and detailed level. This framework is successfully deployed at a banking industry client to provide a superior solution.
Framework is deployable either on-premise or in the Cloud and is available for other industries such as:
- Patient encounters in Healthcare
- Claims in Insurance
- SKUs in Retail
- Subcomponents in Manufacturing
…or anywhere the allocations occur at a summary level with drivers aggregated from a detail level.