Why do BI fail?
Why do BI Implementations Fail?
Posted 3/29/2006 by Ferenc Mantfeld (CTO)
Today's entry addresses the reasons why so many Business intelligence deployments are flawed and why a lot of BI projects are eventually abandoned or taken up very slowly.
Lack of upfront planning
The most common assumption in Business Intelligence Projects is that "If we build it, they will come".
Inconsistent implementations, lack of executive sponsorship, lack of cooperation and intra-departmental conflicts cause slow adoption and abandonment of BI projects. The success of a BI Project is directly related to consideration of business, user & training requirements, because the value of a BI deployment is NOT that obvious that all users would be lining up to learn to use the system, despite the sales pitch that BI vendors make.
Organizations should start with a solid business case for why they want BI, carefully considering requirements and strategically aligning BI with business problems. Too often, BI systems are built for the power user and thus only a handful of employees use it. Instead the BI systems should appeal to the mass majority of users and once these users have what they are looking for to make their lives simpler, the power user capabilities should be considered.
Pass the RACT test before you touch a keyboard
The RACT test asks: Is this product
• Relevant?
• Accurate?
• Consistent?
• Timely?
If your BI implementation does not pass and continue to pass this test, forget it: it is a failure.
Data Quality issues
The GIGO equation fits well here. Garbage In = Garbage Out. Bad Data leads to bad decisions. Too many bad decisions or just one crucial one will cause immediate distrust and abandonment.
Where a data warehouse is used, it is important to filter out bad data at the ETL (Extract, Transform & Load) stage. Good data governance is a separate but linked project to ensure a good data warehouse with clean, high-quality data.
Not Anticipating change
Most of the requirements that drove the implementation of the BI project will change within a year. BI systems evolve and as users adopt it more readily, new requirements will surface.
Ensure that your organization is prepared for (is flexible enough to handle) evolutionary change and choose a product that will allow you the flexibility of rapidly changing what has been delivered and ensure that your BI project budgets reflect these allowances.
Differences in Perceived Need
We must have a single version of the truth !
Some people don't really want a single version of the truth, thus the proliferation of "spread marts" in an organization. Some people are happy to work with common assumptions and manipulate the numbers in meetings. Ignoring the cultural challenges in on organization can threaten the success of a BI deployment.
The "single version of the truth" mantra must be embraced and propagated throughout the organization from the CEO on down.
One-Stop shopping
There is no such thing as a standard BI implementation. Too often, organizations are led to believe that the best solution for BI would be to purchase their existing ERP, CRM or other vendor's BI / Analytics product.
The incumbent vendor has a strategic advantage against the competition because they can offer price incentives and leverage existing relationship and existing investments, not to mention raising the FUD (Fear, Uncertainty, Doubt) factor over their competitors. Almost 100% of these organizations find much further down the track that having to integrate the rest of their organization into the BI solution from the ERP / CRM vendor is a very costly exercise, much more so than if they performed a thorough evaluation of the available solutions and matched these up against their real requirements before they got started.
Dashboards as a generic cure
Pretty graphical dashboards, as appealing as they are, need the same amount of planning and careful consideration for what goes into them as any other project would.
Dashboards that show inconsistent figures or that don't flow easily into the rest of the organization's data run the risk of diminishing confidence in the solution, leading to abandonment.
The data behind the dashboard needs to verified and checked for consistency and accuracy, otherwise it is just a pretty picture without any value. Dashboard implementation needs to be part of the strategic plan.
Outsourcing
The most crucial factor to the success of any BI (or any other software project for that matter) is the knowledge of how the company works and what is stored where. Business Analysts and Data Analysts who understand these aspects of the organization are worth their weight in gold, as they are the ones who will validate or refute the success of the BI implementation. Thus an intimate knowledge of the organization's policies, business practices, history, user demographics, customer demographics are the things that can never be outsourced and yet these are the crucial elements that ensure success of a BI project.
BI vendors or SI (Systems Integrators) services can complement an immediate skills shortage and provide re-usable methodologies and objects but they can never replace the valuable insight of knowledgeable employees. Many organizations that have decided to outsource their entire BI implementation have ended up bringing the project back in house. No consultant is going to learn your complex business in a few days or weeks. Consultants should be used to provide skills that the organization does NOT have, with a view to transferring as much of that knowledge to the organization's employees. This also leads to better knowledge worker morale in the organization, better adoption and willing ownership of the processes and deliverables.
Performance Considerations
The typical engagement starts off with a demonstration of the product running against some data that might be up to a few hundred thousand records in size from the main source system.
Roll on to production implementation where there are hundreds of million or even billions of records. Suddenly the scalability considerations become very evident. Refer to the last point of the RACT test.
Ensure that the choice of product will scale to support data volumes, user volumes and concurrency.
If you are drawing the data to be reported on in real-time from an OLTP datasource, the last thing you want is a product that runs DSS (Decision Support System) OLAP type queries on an OLTP mission critical database, otherwise you could find that daily revenue generating activities are being hampered. Ensure that the BI product you have chosen has safeguards to arrest runaway queries since not every organization has the luxury of a dedicated DBA monitoring the production database looking to kill abusive query threads.
Ferenc Mantfeld
Posted 3/29/2006 by Ferenc Mantfeld (CTO)
Today's entry addresses the reasons why so many Business intelligence deployments are flawed and why a lot of BI projects are eventually abandoned or taken up very slowly.
Lack of upfront planning
The most common assumption in Business Intelligence Projects is that "If we build it, they will come".
Inconsistent implementations, lack of executive sponsorship, lack of cooperation and intra-departmental conflicts cause slow adoption and abandonment of BI projects. The success of a BI Project is directly related to consideration of business, user & training requirements, because the value of a BI deployment is NOT that obvious that all users would be lining up to learn to use the system, despite the sales pitch that BI vendors make.
Organizations should start with a solid business case for why they want BI, carefully considering requirements and strategically aligning BI with business problems. Too often, BI systems are built for the power user and thus only a handful of employees use it. Instead the BI systems should appeal to the mass majority of users and once these users have what they are looking for to make their lives simpler, the power user capabilities should be considered.
Pass the RACT test before you touch a keyboard
The RACT test asks: Is this product
• Relevant?
• Accurate?
• Consistent?
• Timely?
If your BI implementation does not pass and continue to pass this test, forget it: it is a failure.
Data Quality issues
The GIGO equation fits well here. Garbage In = Garbage Out. Bad Data leads to bad decisions. Too many bad decisions or just one crucial one will cause immediate distrust and abandonment.
Where a data warehouse is used, it is important to filter out bad data at the ETL (Extract, Transform & Load) stage. Good data governance is a separate but linked project to ensure a good data warehouse with clean, high-quality data.
Not Anticipating change
Most of the requirements that drove the implementation of the BI project will change within a year. BI systems evolve and as users adopt it more readily, new requirements will surface.
Ensure that your organization is prepared for (is flexible enough to handle) evolutionary change and choose a product that will allow you the flexibility of rapidly changing what has been delivered and ensure that your BI project budgets reflect these allowances.
Differences in Perceived Need
We must have a single version of the truth !
Some people don't really want a single version of the truth, thus the proliferation of "spread marts" in an organization. Some people are happy to work with common assumptions and manipulate the numbers in meetings. Ignoring the cultural challenges in on organization can threaten the success of a BI deployment.
The "single version of the truth" mantra must be embraced and propagated throughout the organization from the CEO on down.
One-Stop shopping
There is no such thing as a standard BI implementation. Too often, organizations are led to believe that the best solution for BI would be to purchase their existing ERP, CRM or other vendor's BI / Analytics product.
The incumbent vendor has a strategic advantage against the competition because they can offer price incentives and leverage existing relationship and existing investments, not to mention raising the FUD (Fear, Uncertainty, Doubt) factor over their competitors. Almost 100% of these organizations find much further down the track that having to integrate the rest of their organization into the BI solution from the ERP / CRM vendor is a very costly exercise, much more so than if they performed a thorough evaluation of the available solutions and matched these up against their real requirements before they got started.
Dashboards as a generic cure
Pretty graphical dashboards, as appealing as they are, need the same amount of planning and careful consideration for what goes into them as any other project would.
Dashboards that show inconsistent figures or that don't flow easily into the rest of the organization's data run the risk of diminishing confidence in the solution, leading to abandonment.
The data behind the dashboard needs to verified and checked for consistency and accuracy, otherwise it is just a pretty picture without any value. Dashboard implementation needs to be part of the strategic plan.
Outsourcing
The most crucial factor to the success of any BI (or any other software project for that matter) is the knowledge of how the company works and what is stored where. Business Analysts and Data Analysts who understand these aspects of the organization are worth their weight in gold, as they are the ones who will validate or refute the success of the BI implementation. Thus an intimate knowledge of the organization's policies, business practices, history, user demographics, customer demographics are the things that can never be outsourced and yet these are the crucial elements that ensure success of a BI project.
BI vendors or SI (Systems Integrators) services can complement an immediate skills shortage and provide re-usable methodologies and objects but they can never replace the valuable insight of knowledgeable employees. Many organizations that have decided to outsource their entire BI implementation have ended up bringing the project back in house. No consultant is going to learn your complex business in a few days or weeks. Consultants should be used to provide skills that the organization does NOT have, with a view to transferring as much of that knowledge to the organization's employees. This also leads to better knowledge worker morale in the organization, better adoption and willing ownership of the processes and deliverables.
Performance Considerations
The typical engagement starts off with a demonstration of the product running against some data that might be up to a few hundred thousand records in size from the main source system.
Roll on to production implementation where there are hundreds of million or even billions of records. Suddenly the scalability considerations become very evident. Refer to the last point of the RACT test.
Ensure that the choice of product will scale to support data volumes, user volumes and concurrency.
If you are drawing the data to be reported on in real-time from an OLTP datasource, the last thing you want is a product that runs DSS (Decision Support System) OLAP type queries on an OLTP mission critical database, otherwise you could find that daily revenue generating activities are being hampered. Ensure that the BI product you have chosen has safeguards to arrest runaway queries since not every organization has the luxury of a dedicated DBA monitoring the production database looking to kill abusive query threads.
Ferenc Mantfeld
posted by Blog 4 Discussion at 11:36 AM
0 comments
