Hitachi Vantara Pentaho Community Wiki
Child pages
  • 1.2 The Problem with Traditional Business Intelligence Projects
Skip to end of metadata
Go to start of metadata

Problem 1: Unfamiliar Territory for Users

This creates a problem that might be unique to the Business Intelligence field. The problem is that the end-users or consumers of a Business Intelligence solution are not familiar with those terminology, tools, and technologies. This situation does not exist in other fields. For example the consumers of a customer relationship management (CRM) system are familiar with the concepts of leads, opportunities, customers, and accounts that the CRM system manages.

The problem surfaces right at the start of a Business Intelligence project. How do you discuss the requirements of the system when the consumers don't understand the terminology? The answer is that you cannot effectively present and evolve the requirements in document form: you need to show them, and ideally let them use, a prototype or pilot of the system.

The consumers of a Business Intelligence system have to be actively involved in the definition of the system and can only do so effectively if they have a something that works and is based on real data. If more users have access to the pilot system better feedback on the requirements can be gathered. This introduces a second problem.

Problem 2: Cost of Prototypes

In order to alleviate the first problem many Business Intelligence practitioners recommend using 5-10% of the project's budget (or proposed budget) to create a prototype or pilot.

These prototypes or pilot need to be created very early on during the project: in many cases before the project has been given budget approval. This is because the benefits of a Business Intelligence solution are often hard to quantify. A particular solution might help managers make more informed, and therefore supposedly better, decisions. How much money will those better decisions save the organization in the first year? It is frequently hard to estimate.

Prototypes are often built during feasibility or return-on-investment (ROI) studies to help alleviate this situation. However if the estimated cost of estimating the ROI is too high the feasibility study might not ever be undertaken. The problem is that to get good feedback on the expected ROI you need to gather feedback from as many users as possible, however if there is a per-user license cost to do this the cost of gathering the feedback can become prohibitive. If it costs $20,000 to do the prototype the project budget needs to at least be in the $100,000-200,000 range.

The good news is that open source Business Intelligence tools let you do this with no license fee for the Business Intelligence functionality. In conjunction with open source operating systems, databases, and application servers a pilot using open source BI tools can be executed without any software license fees.

Problem 3: Expensive Infrastructure

A third problem with Business Intelligence implementations is that the infrastructure of a Business Intelligence solution is expensive. This means that there can be a high cost, in both software (unless open source is used) and effort, in creating even a simple Business Intelligence solution. What is worst in most cases the users get no value from the system until the end of the project. You can compare it to building a house: it takes a lot of resources and time to construct the house but none of the value can be realized before the end. If the house design has 10 rooms and you are half way through the construction of the house do you have 5 usable rooms? No, you have no usable rooms, and you continue to have no usable rooms until the last day of the project.

Problem 4: Rigid Project Methodologies

The fourth problem with traditional Business Intelligence projects is that the methodology used can compound the problems above and make them worse. Traditional development methodologies have phases with rigid transitions between them. In addition there are different people working on the different phases with 'hand-offs' between them. This makes adapting to change difficult and the later in the process that the change surfaces the harder it is to handle. This causes problems for the development of all software systems. Business Intelligence's unique 'unfamiliar user' problem makes it hard to concretely define the requirements. Combining a requirements definition that cannot be reliably confirmed with a process that does not handle change well is a recipe for problems.

Problem 5: Inertia

A combination of the problems above means that it is not a trivial exercise to create an Business Intelligence solution. This makes Business Intelligence unsuitable for projects where a quick answer is needed to a one-time problem. For example let us assume that an organization is under a new competitive pressure and wants to adjust its pricing scheme for all of its many products in all of its markets. The new pricing scheme needs to be decided upon within 10 days. If it takes two or three months to assemble a Business Intelligence solution to analyze the sales trends within each market there is no point even starting. Even if it only takes two weeks to create the solution it will be available too late.

Is there an alternative way to approach Business Intelligence projects that helps alleviate these problems? Why, yes. The alternative is to use an agile approach.

  • No labels