Friday, August 14, 2009

The Reasons Why 69 % Cube Based BI Project Fails And How QlikView Have Success Rate About 98 %

Dear Readers,
After long time I am interacting with you on my blog as I was quite busy with handling new accounts. But I was answering all queries which are coming to me by emails or on my phone. This time I am comparing the reasons why most of traditional cube based or data warehouse based BI projects fails and how QlikView can give you excellent success rate as compared to traditional BI architecture.

1. Lack of user involvement
Almost every time IT department start a BI project and fails to involve user as they found it very hard to involve in. Normally a user has the approach "Let me see something then only I can tell you what my requirements are". It is very difficult to control such cases if IT is doing so, it is not possible with every user or user group that they can able to speculate their need by seeing prototype only. I have seen lot of finance officers asking by seeing sales report "Oh so this tool is for sales analysis?", and sales guys asking after looking supplier analysis "Is it for logistics and my purchase department?" and if you are showing prototype for everyone on his own data, you may go over budget and it is not easy to handle change requests when you need to make changes in BI Cubes.

How QlikView can help
It is not possible to avoid change requests otherwise you are not giving right solution to end user and ultimately your users would be using MS excel down the line 6 months of implementation.
Better you accept maximum changes because you have QlikView in hand and USPs ease of use with no learning curve for IT as well as for end user result of this is rapid deployment. In QlikView one can handle change requests very easily and you can have a prototype ready for every user in average 2 hrs for each user. Once they can see the prototype for their own data set it is easy to involve them in BI project that is first step towards success. Answer is Create involvement by using such tool which can give you power to address any change request in 1/6 time than any other BI software take.

2. Building Enterprise data ware house Warehouse and data marts
Most of the companies start their BI projects by building data ware house. It involves high risk with very less guarantee of success. Companies keep adding more team-members that do not help much and data ware house projects doesn't achieve scalability. Data ware house have give very less ROI and project cost lot of money and projects end in disasters. Some companies start with data marts and try to create enterprise data ware house step by step. it is again a time consuming process and require several iterations.

How QlikView can help
To implement QlikView you don't require creating any data ware house. What it does is it pulls data from transaction system (i.e. ERP, CRM etc) and stores it in to a file that has ".qvd" extension. This file is actually an associative data model and search being made (Subsequently Query is being processed) by using patented Technology "AQL" (Associative Query Logic.)
As GUI is also written on the same file so there is no back end in QlikView when it is processing the data during run time. It takes around 1/6 time to create associative data model than creating a data ware house. Also you do not require to use any third part ETL tool QlikView have its own integration layer that call edit script to load data in ".qvw" file. It also takes care of data cleansing part so you can identify noisy data and its source very quickly and subsequently can take necessary steps.

3- Budgetary Constraints
To start a tradition BI project it requires a big budget. And people normally don't care of expenses of hardware, training and maintenance cost. Having cubes is another issue as whenever requirements change after implementation/or during implementation, changing cubes or building entirely new cube have its own cost and finally project goes out of budget.

How QlikView can help
If we look at overall budget of QlikView or if we talk about total cost of ownership (TCO) including cost of software, hardware, training, implementation services, and maintenance the total cost would be around 1/6 of traditional BI architecture for initial investment and overall it would coat around ½ than traditional BI projects.
As QlikView implementation doesn't required big hardware infrastructure, a implementation time is also around 1/10 of traditional BI projects (Average implementation time of a QlikView project is 10 days) also it do not require highly skilled IT professionals and can be deployed/maintained by in house team budgetary constraints are not in the way of having Business Answer.

4- Corporate Politics
Once the organization start a BI project the first step is fixing the requirements and since the primary user group of a BI project is top guys in any company and they all have different work are and have different thought process, they started feeling that their requirement are not getting covered in this projects ( It is obvious as traditional BI projects are based on cubes and they are very rigid to adopt individual's thought process) so they start playing power game or stop using what they have given by IT department.

How QlikView can help
The best part I have seen in QlikView is it is personalized for individual's need it is easy to deliver a particular user what he is expecting from the BI project. Even in same department an individual head of a particular KPI have his own requirements and that is to be catered individually for him, it is his business requirement, and QlikView is like rubber it can be molded for an individual's need.

5- Wrong Choice of KPI's ( OR KPI's chosen are hypothetical and not solving Business problems)
A finance cube is useless when we are looking at AR report and when we have to see the sales rep detail associated with a particular default account. It happens extensively that while finalizing dimensions for cube IT people are not sure what they are delivering is really the business need and when they deliver it to end user after 5 months (Usually a traditional BI project takes 5 months to show first analytical report ready) they found what they have delivered was not their need or the need has changed during last months. (End users keep asking for something new it is not possible to control demand)

How QlikView can help

The USP of QlikView is "Its easy" it is easy for end users to use and it is easy to deploy by IT team. Since "End users keep asking for something new it is not possible to control demand" but we can have a tool that can quickly deliver what they want now. It is the best tool for ad-hock needs it can cater those requirements where end user want answer on phone , like what is my sales as compared to last year what is my production as compare to Q2 in this year. What this particular product is doing in that reason where I had 80 % margin in last three years.
KPIs cannot be fixed they keep changing according to business needs only we can do is, we can have a tool that can give answer quickly than any other tool. "QlikView gives you answer in 1/10 time as compared to traditional BI software".

6- Complex Cubes with limited dimensions
Normally a cube can handle maximum 8 dimensions efficiently putting more dimensions in cube make it slow, but problem here is it hard to decide what are the exact dimensions required for business answer by the time we know it has been too late. Also every one do not require dashboard, or analysis or reporting.

How QlikView can help
QlikView do not work on traditional BI architecture it use tow technology "AQL" and in-memory technology. That make it different that traditional cube based BI software. QlikView can give you information with "n" dimensions.
Also it can be customized for individual's need. One can have Dash board or analysis or reposts or combination of these. In case of change in requirement internal IT team can handle in 1/10 time as compared to traditional BI software. It gives you less than 5% vendor dependency.

Next Step
I can write "n" number of pages on QlikView but it is suggested that don't believe without seeing. I recommend "Seeing is believing" or "SiB" ask your QlikView vendor to create some analytics, dashboards and reports on your data at your premises and play with it ask you end users to use those dashboard for some time before going with it.

For "Seeing is believing" or "SiB" please feel free to write me at my email id sudhir@iconresources.com you can call me at
+91-9312667720

6 comments:

  1. Good article. I am presently working on a business case for BI project. How do you compare Ms BI tool with Qlikview?
    I case of an Enterprise wide BI project which hass to buil information from multiple applicationss...how does this approach w/o data mart work? How will be the performance?

    ReplyDelete
  2. Dear Kaladevi,
    I have tried to answer your question at my latest post "QlikView Vs OLAP – Comparison based on resource required and “Time, Cost & Value” "

    Find the link bellow.
    I will appreciate your comments
    http://qlikviewvsolap.blogspot.com/2009/08/qlikview-vs-olap-comparison-based-on.html

    Regards
    Sudhir Kumar Singh

    ReplyDelete
  3. Hi,
    I am new to QlikView ....I have two doubts regarding the solution:

    1. Refresh time( How much time it takes to refresh lets say 1 million record from source to memory)???

    2. For what amount of source data( how many millions or billions can this be done cost and resource effective) is this solution feasible???


    It would be great if u help me regarding this....

    ReplyDelete
  4. Have you seen what happens when you hit the memory barrier...?

    Lovely in those small, single user, test environments... but watch those disks dance when you spill over with Enterprise scale data sets. Unless of course you aggregate data, but then you fall foul of your own benefits.

    From a Qlikview fan, but for the right purpose...

    ReplyDelete
  5. mmmm been told 2 days to develop ended up with 2 weeks - faster in cognos

    ReplyDelete

Search more on BI on Web

Know the Blogger