Recently in Operational BI Category

In a prior post, I talked about having my credit card cancelled over a small purchase I made that the bank unexplainably could not tightly quantify. I spoke with Claudia Imhoff over the weekend and we decided this was really a failure of operational business intelligence.

It highlights the need for master data in the operational environment, where intra-day information is accessible along with profile summaries that are fed from the data warehouse. If a summarized profile from transaction data, such as length of service, average balance, late payment totals, credit limit, etc. were available to the operational intelligence in the approval process for the transaction, it may have made a different, and better, business decision.

Instead, it's likely that the bank made the decision in absence of this analytical information, looking at the transaction only on the face of it.

Operational business intelligence is becoming more and more important. Taking optimal advantage of the moment requires analytics, likely from a downstream data warehouse and fed back into master data management systems.

Data Warehousing systems are becoming much more “operational support” than “decision support” in nature. There used to be a significant difference between Operational Support Systems and Decisions Support Systems in the manner in which a company was dependent upon them.

Transaction processing systems tended towards 24 x 7 (or at least 20 x 6), and Data Warehouse systems were 12 x 5. Now, day-to-day business operations, end of the month accounting, compliance and even SEC filings are dependent on Data Warehouse systems, and the line between OSS and DSS systems is blurring. Modern application systems now routinely use Data Warehouse technology in support of day-to-day operations. For example, CRM systems almost always incorporate technology first developed for Operational Data Stores and Marketing Information Warehouses.

As a result, best practices for classical OSS architectural standards need to be incorporated into Data Warehouse systems such as:
• Separate test, development, and QA platforms, often full-scale
• Rigid change management
• Inclusion of “DSS” systems in Business Continuance (i.e., Disaster Recovery) planning
• Upgrade pathing
• User training and documentation

However, these are also the very same things that tend to forestall the full maturation of a data warehouse environment. Many data warehouses have been built that meet a specific business need, but the solution and platform are unable to be leveraged to other business needs. As a result, these systems fail to continue to deliver ROI, and fail to have the ability to deliver its initial value in a predictable (i.e., "production") fashion when natural events occur such as:

• Upgrading the hardware and software
• Dealing with failures in the ETL jobs
• Adding users who haven't had the luxury of learning about the data by being part of the warehouse development
• Adding new reports, new tables, or new columns
• Adding a backlog of data from an alternate source
• Users increasing their reliance on it such that if it were down, business would suffer

When initial warehouse development does not foresee these needs, it can be difficult to fold them in, yet that is one of the crucial challenges facing many warehouses today. If these are your challenges, you are not alone.