Saturday, December 19, 2009

Can BI Strategy ever become real?

When a super BI consultant recommends a whole stack of To-Do items in the information curve, how real is his recommendation? How real is the BI Strategy? 30%, 50% or 70%. Have you as a customer asked your vendor about it? Ask it. The typical response would be - "Depends".

The problem is not with the BI consultant; the problem is with prediction. BI is such a game where the variables are too many - money, business benefit, pain problems, information maturity, tool consolidation, vendor proliferation, data volumes, system integrators, application support, advanced visualization, data conformance, data quality, stewardship, etc....The list just goes on and on. BI Strategy almost turns into a weather forecasting system. So is there no answer to being real? There is. Answer is "Stop doing it. Get Real."

BI comes with a cost. Its not something that you can purchase it during a sale. BI is something that every organization needs. It has become ubiquitous. A strategy is just a sales tool to your governance board for approval. Do you need one? Why do you want to spend on a sales tool to prove that it is required for your organization? Would you construct a business case for seeking an admission for your son or daughter into the IIMs or the MITs of the world. Instead spend it on building a 60-day data mart. Make the users use it for a month. After a month, pull the plug off. The # of calls you recieve to get the system back would talk about the ROI of BI.

Let me know what you think.

Sunday, July 05, 2009

Operational BI - Part 2

Having set the need for an Operational BI in my previous post, I will sketch out the architecture of an Operational BI solution.

The four important blocks to be considered while designing an O-BI system are

  1. Sourcing/Extraction Module
  2. Transformation & Load Module
  3. Data Retention Module
  4. Reporting Module
Sourcing/Extraction Module discusses the extraction strategy from the source. This Module covers the change data capture (CDC) design & data transfer mechanism. Choosing the right extraction strategy would spell success or failure for the project. Almost 70% of O-BI projects fail because of the wrong sourcing strategy implemented.

Transformation & Load Module discusses the kind of loading tool-set that would suit an O-BI system. Details about the expected load volumes, the loading patterns and the hand-shaking mechanisms with the source will be discussed

Data Retention Module discusses about the parameters required for estimating the size of the sliding data storage windows.

And finally the Reporting Module discusses the kind of reports that an operational executive would need for taking his tactical decision on a hour-hour basis.

These sections would be discussed in detailed in my further posts.

Saturday, April 18, 2009

Operational BI - Part 1

The genesis of BI has always been the need to seek for the BIBLE of decision making. But BI over a decade has transformed itself from a night watchman to more of a 24/7 call-center representative. It has become real-time. What made this change? Why was the mutation to real-time necessary? What are the challenges in data integration? And finally, how can Operational BI (O-BI) be coupled with the Enterprise Analytical Reporting framework? I will be assessing each of the questions posed in greater detail and arrive at a design pattern for modeling a Operational BI Solution.

Let us drive the need for implementation of an operational BI solution with an example.

A store manager at a retail outlet manages various aspects of retailing - visual merchandising, customer experience, resource scheduling, loss prevention, product management (ordering, receiving, pricing, inventory). Let me explain each one of these facets of the retailing business briefly.
  • Visual Merchandising: Promotion of the sale of good through visual appeal in the stores (source: Wikipedia).
  • Customer Experience: Reduced customer wait-time in the check-out counters.
  • Resource Scheduling: Monitoring the efficiency of the employee schedule for improved load balance of employee work-hours.
  • Loss prevention: Real-time monitoring of 'shrinkage' because of shoplifting, employee embezzlement, credit card fraud, system errors and many more.
  • Product Management: Real-time monitoring of product inventory.
Given this background, I would proceed on to connect all these process areas with a business case that would put a Store Manager in trouble and how an Operational BI solution can save his day.

Let us assume that the Store Manager has access to a reporting solution which refreshes once in a day. He notices that the daily sales has dropped as compared to the previous day. He drills further down to investigate the cause of the decline. He finds out that the drop can be traced to one particular hour in the day. A deeper look into the problem highlighted the issue of an increased average customer wait-time per hour causing a poor conversion rate. The wait time finally was attributed to reduced work-force in that hour because of an increased lunch break taken by the employees (since they turned up very early to work).

This problem could have been easily rectified if the store manager had access to data earlier than what he had. Had he had real-time access, he would have noticed the dip in sales for that hour immediately and would have taken corrective action, thereby not affecting the sales during that hour. With a decent business case established for a real-time BI system, let's analyse what an operational BI is and how does it facilitate to solve the problem.

The architecture of Operational BI and the challenges associated with it will be posted in the next article.