Traditional views of enterprise technology have historically depicted a straight-line continuum, a sort of Masters and Johnson benchmark for technology, with operational systems on one side of the continuum and analysis applications on the other. Even the widely accepted Corporate Information Factory in its prior incantations read from left to right - picturing operational systems on the far left (outside the BI environment) and the operational data store, data warehouse and data marts moving progressively to the right (inside the BI space). Only in the last several years have we started to view things differently.
Today, our platform horsepower and data movement capabilities have improved to the point that technology has caught up to vision, and the wall between operations and analytics is coming down. The latest version of the CIF as we see it now depicts operational data inside the BI environment, subject to integration and aggregation processes and available to analytic applications as needed.
Operational BI is no longer simply theory as teams (not necessarily on the bleeding edge of technology advancement) are starting to investigate how to more closely link analytics to their operational activities.
The objective of the operational BI environment is to provide the analysis infrastructure from which people from both inside and outside the organization can make better, faster and more informed decisions. Operational analytics, once opposite ideas now comfortably joined, represent the techniques by which organizations are leveraging the BI infrastructure. Companies employ operational analytics to improve business decisions by directly supporting specific operational processes and activities with analytics. They provide an environment where the organization can learn and adapt based on analysis of operational processes. And they reduce the latency between business events and the organization's ability to react to those events by closing the loop between analytics and operations.
How does this actually work? First, we require an event detective or BI service that can continually monitor business events or transactions that happen in the operational world. These events can be generated by applications, by customer transactions or by service personnel. Once the events have been detected, the related information must be pushed through analysis applications to validate the event and determine the course of action. This generally involves moving the event information into the data warehouse in real or near real time. More traditional data warehouse analyses will also be required prior to starting the initiative in order to determine which events are going to be part of the program. Lastly, the results of the analysis must be married with an operational process so the relevant action can be taken.
An example: a bank wants to serve an immediate need for customers who need cash for emergency purchases and have insufficient cash reserves. With timely, relevant communications, the bank plans to offer these customers a credit card with cash advance capability, overdraft protection or a personal loan. First, the bank must detect that the event has happened - a customer has attempted to withdraw funds at the ATM or at a bank branch and has been rejected due to insufficient funds in the account. This requires continuous data mining for rejected transactions at ATMs and branches. Once the event occurs, information about a specific transaction must be pulled from the transaction system and moved through the data warehouse into a special analysis application designed to determine the significance and relevance of the event for that particular customer.
Habitual offenders, potential fraud perpetrators and people who have simply misjudged their account balance (and can get the funds from other accounts within the bank) must be eliminated from consideration. Eliminating these customers requires a look at past behavior patterns and recent transactions to determine that the account has not had an insufficient funds transaction in the past six months, that the card has not been reported lost or stolen, and that the customer does not have another account from where they could withdraw a similar amount in the 24 hours following the initial attempt. Further analysis to ensure an honest need for emergency cash can include verification that the account does not have a paycheck direct deposit due but is simply late arriving (again requiring past account transaction detail mixed with current state information). Once the bank confirms the need for cash, it must perform a credit score on the customer to ensure that the products offered are appropriate. Next, the bank must deliver the resultant product offer back to the operational process where the customer is experiencing the rejection - in this case, to the ATM or branch interaction.
Implementing the operational analytics program in the example requires a closed-loop environment between the operational world and the analytical one. It offers the possibility of tremendous benefit and will become the norm as organizations harness the intelligence in data warehouse for competitive advantage.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access