Successful BI Strategy - Part II

A BI initiative is of no use if it is not driven by the objectives of the enterprise. Implementing a BI solution should help an enterprise achieve the objective of advancing business by making the best use of information.

Dos and Don'ts for successful BI/DWH project implementation:

Do not start with a big bang implementation approach. Iterative implementation approach works well with BI project. Identify a business objective and deliver it via BI/DWH within first two-three months. Longer you take to deliver your first output from BI/DWH, higher is the possibility of failure. It is very important to deliver first output from BI/DWH on time with good quality. This will also help in selling BI/DWH vision to business teams. The shorter implementation cycles would be quite beneficial for the end users as well in terms of cost and time as they would have a much better feel of the end product, they would be able to modify the scope based on what is implemented after each cycle.

Do not try to roll out BI/DWH to many departments/groups at a time in first phase. If possible choose either Sales or Finance department for first phase as these areas are more closer to heart of CEO/CFO of the organization. It is easier to gain acceptability of an initiative if it has C-level executives acceptability & support.

Do not over burden end users with lot of trainings initially. If end users have to go through multiple days of trainings to use new BI/DWH system then there is a high probability that they will not use the system. Always look at maturity of a user group before delivering reports to them. If a user group has been using excel based static reports for past few years then give them reports which has drill down and parameter selection criteria. If someone has been using parameters based reports then give them OLAP based reports which will allow them to slice & dice the data on the fly. If someone has been using OLAP based reports then give them access to adhoc reporting tool.These will help in reducing training efforts that are required to use new BI/DWH system.Also, it makes transition to the new system easier and smooth. Lot of time static report users are given access to OLAP cubes which requires huge training efforts and time.Also, it requires steep learning curve, and it often demotivates them from using new BI/DWH system. Do not drastically change the way they are consuming information now. The change has to be gradual.

Application Data Warehouse

The definition of data warehouse is changing in Indian Market. Earlier people use to build data warehouse to cater to MIS reporting need of an organization nowadays data warehouse is built to support various business applications such as

• Cross Sell/Up Sell
• Retention
• Campaign Management
• Marketing Optimization
• Market Mix Modeling
• Basel II compliance
• Market Risk Analysis
• Op Risk Analysis
• Warranty Analysis
• Supply Chain Optimization etc...

I started my BI implementation career with a data warehouse implementation at one of the media company in India.  The objective of data warehouse project was to replace all excel based MIS reporting with automated reporting system. The sponsor of data warehouse project was IT director.  We designed our data warehouse schema based on reporting requirements of different business functions within the organization. It took 10 months to build a warehouse. We delivered some 25 odd reports using Business Objects. While the data warehouse project was appreciated well within IT department, end users didn't appreciated it. They felt  data warehouse is too rigid. They can't make changes in data warehouse easily. It used to take 4-6 weeks to include any new business requirement change in data warehouse. They also felt that data warehouse was not giving any value add or insight which can help them in their day to day activity. After a year, data warehouse project was scrapped by that organization because the ROI generated from data warehouse was not enough to justify it's investment.


Today scenario has changed. Very recently, we had worked on two enterprise data warehouse RFPs wherein the end goal of implementing data warehouse was to support various business applications. Prospect had clearly stated objective of data warehouse in RFP. They wanted to built a data warehouse to support the following business applications

• Basel II Compliance
• Market Risk
• Credit Scoring
• Cross Sell/Up Sell
• Retention
• Campaign Management 

They wanted to ensure that all variables that are required to do say e.g cross sell/Up sell analysis are included in data warehouse model. There are some 750+ variables to do only cross sell/up sell analysis. Similarly, there are thousands of variables available to support other applications. Lot of time the data warehouse is built keeping in mind only MIS reporting requirements. Hence whenever business users want to do business analysis, they end up creating a seperate mart for data specific to that analysis. This results in data duplication and system overhead. Last week I met up with a senior executive of one of the large bank. Currently they have three data marts. One data mart caters to MIS reporting requirement, second data mart caters to Risk compliance requirements and  third data mart caters to PM requirements. Soon, they are coming up with a RFP to consolidate all three data marts into a single data warehouse.


In today's economic conditions, it is very critical to build "Analytics" friendly data warehouse. Typically, you require historical data to do analytics. Hence you need to capture data related to analytical variables right from day one when data warehouse is implemented. I have seen lot of organization making a mistake of building MIS reporting data warehouse. There are several disadvantages of this approach.

1. It takes significant amount of time & efforts to build such data warehouse. Your reporting requirements change by the time data warehouse is implemented.
2. ROI generated from such data warehouse is not significant enough to justify it's investment.
3. If right variables are not captured in the data model then it takes significant amount of time and efforts to incorporate them in data model at later stage. It involves change in data model, ETL & BI Strategies. Lot of time, it is not possible to incorporate such changes due to complexity of data model and ETL routines, and you end up creating a data mart to cater to Analytical requirements. This results in data de-duplication.

In today's world, it is not just sufficient to know who is buying what & when. You will need to know what they will buy next, & whether they are profitable customer for you or not. This requires analytical capabilities built into your data warehouse. Hence "Application Data warehouse" is way to go.