Business intelligence (BI) software, which emerged in response to the need for accurate and timely information to support informed business decisions, has evolved into a complex market comprising tools and platforms.
Many of today’s BI platforms only target large enterprises with vast resources and large budgets. Yet even with this technology, companies repeat common mistakes based on poor reporting and analysis practices.
In tracking mediocre results in the implementation of BI software, and even failures, worst practices are found. The top four include:
* Assuming the average business user has the know-how or the time to use BI tools;
* Allowing Excel to become the default BI “platform”;
* Assuming a data warehouse will solve all information access and delivery requirements; and
* Selecting a BI tool without a specific business need.
These worst practices set companies on a path to BI failure. The mistakes have been repeated by some of the best and smartest organisations in the world. Typically, worst practices occur when companies seek to use the latest technology, yet fail to balance the hype with practical knowledge and experience.
Assuming user know-how
Often, the first (not to mention the most damaging) mistake when assessing a BI solution is failure to include non-technical business users on the selection committee. This seems counter-intuitive because these will be the predominant users of the solution.
Most crucial is the ability to make BI content easily accessible, easy to use, flexible and widely distributable. To ensure adoption, the resulting data, reports, dashboards, documents and BI portal itself must allow nontechnical users to easily get what they need.
More often than not, it is the participants on the tool selection committee who are at the source of BI failure, not the users. If the assumption is that all business users need a BI tool, then the committee is more likely made up of mainly advanced users who are focusing on the features of the development environment. On the contrary, the common business user is more concerned with the resulting BI portal.
When business users are excluded from the solution selection process, their need for simplicity is overlooked. This is why many of the tools purchased for the entire user population end up as shelfware.
Allowing Excel to become a BI “platform”
Excel is arguably the most widely used BI tool in the world – for businesses of all sizes. While many consider it to be just a spreadsheet, Excel houses many organisations’ financial reports. Excel thrives in the absence of a true BI application.
The beauty of Excel is that it provides a simple interface for common functions such as calculating, presenting and displaying numerical data. Although Excel provides much utility for business users, it wreaks havoc on the quality and consistency of information. This is especially damaging in heavily regulated industries that need to adhere to strict compliance legislation. Consider the following, all-too-common scenario:
Business analysts develop Excel spreadsheets to assist with the day-to-day operational decisions. Pleased with the autonomy and sophisticated analysis that Excel provides, they share their innovations with colleagues who then modify the spreadsheet logic and manually add data from their own information silos.
Over time, rogue spreadsheets with data from multiple, dubious spreadsheets are created throughout the organisation, and executives find themselves making decisions based on untraceable, questionable data.
It is not Excel that is at fault; it was never intended to be a BI tool. Much of what is found in Excel spreadsheets is put there through a manual, error-prone process, which should never be the case with BI. Business intelligence applications should only use data from reliable, trustworthy sources.
The impact of having bad data in Excel spreadsheets has been brought to light recently in many widely publicised instances where Excel errors have cost companies millions of dollars.
The European Spreadsheet Risks Interest Group, a group that analyses and quantifies the cost of spreadsheet errors worldwide, has reported various situations, including:
* Incorrect estimates, caused by spreadsheet calculation errors, will cost the municipality of West Baraboo an additional $400 000 in interest over the life of its most recent 10-year borrowing plan.
* The Knox County Trustee’s Office experienced a $6-million discrepancy in reported cash-on-hand as a result of a bad spreadsheet link – an accounting mistake that led to more than $12 000 in audit fees.
* A consultant for the Arizona Portland Cement Company submitted a spreadsheet to the Environmental Protection Agency (EPA) containing a maths error that wrongfully indicated noncompliance with emissions guidelines. Though the problem did not actually exist, the EPA fined the company more than $350 000 and still lists it as a “high-priority violator”.
Assuming a data warehouse will solve problems
Data warehouses are an important part of information technology and, in particular, are a critical component of many analytical systems. So it is not the data warehouse that is the problem. The worst practice arises when a data warehouse is viewed as the solution to all information problems or when it is expected that the availability of the data warehouse will drive business users to the information.
The truth is that not all BI applications require a data warehouse. Many BI applications are better served with integration and portal technology that allows data to reside where it currently exists and pulls it on an as-needed basis. Unfortunately, many organisations fail to assess whether or not a data warehouse is the right solution before creating a data warehouse.
So often companies begin a data warehouse project before they have a BI solution, or even before an information need has been identified, only to find that they have incurred another expense and have not solved a single problem.
Organisations often rush into the creation of data warehouses for reasons that are not entirely valid, such as:
* The company’s BI solution required it, not because it made sense as a business solution;
* The company needed to get data from more than one application, so a data warehouse was necessary; and
* The company needed a data warehouse because all information systems require it.
According to leading industry analysts, integration and movement of data (data warehousing) can consume as much as 80 percent of the cost of a BI implementation. Simply put, data warehouses should not be implemented without a clear understanding of the business challenges. Decisions around data warehouses should be well researched.
Selecting a BI tool without a specific business need
The most illogical of the four worst practices is the purchase of BI software without a solid strategy and meaningful objective. In fact, the largest expense, and the smallest ROI, will result from the purchase.
Companies generally recognise the need for business analysis and embark on a project to evaluate and purchase a BI solution. Without a specific purpose, that BI environment is unlikely to impact the business. The starting point for creating a BI solution should be the identification of a specific problem, which can be solved by improving access to timely, relevant information.
For example, enhanced information access may help to accelerate a slow-running process, eliminate a bottleneck, reduce the cost of doing business, attract new customers, or even serve as a new revenue source.
When information requirements such as these are identified up front and used as the business driver behind the BI implementation, the BI system has a much greater likelihood of success.
The lesson here is that the motivation for pursuing and purchasing BI software, or building a data warehouse for that matter, should never be general purpose. True success comes when there is an understanding of the business problem at hand, and an expectation of the results when information is injected into the process.
While some of the concepts may seem common sense, organisations stumble across at least one of these worst practices during the course of their business intelligence projects. Who can blame them, when industry trade journals, vendors and consultants promote the latest technologies and promise all sorts of benefits? It is easy to get caught up in the hype.
Consider the following:
* Do not start your next project for a general purpose – determine how timely information delivered in the right context can accelerate a process, reduce costs or improve productivity.
* Do not limit your options – identify which data integration method will allow you to prepare the data for your application in the most timely and least cost manner. You may discover that a data warehouse is appropriate or you may find that it is unnecessary.
* Maximise end-user flexibility – build a BI application that leverages web-based, parameter-driven forms; personal end-user scheduling for regular e-mail delivery; and alternate output options (i.e., HTML, Excel, or PDF).
* Include business users on the selection committee – Implement a solution that will be embraced by all. For most users, this means an easy-to-use BI portal that doesn’t require too much time or effort. But don’t neglect the preferences of your technical users either. BI tools, although complex, are a great way to provide technical business analysts with a way to contribute new insight to an evolving BI portal.
Evaluate how many technically savvy analysts you really have, and build these tools into the final solution. Be sure that their work can easily be shared with other, less technical business users, so everyone benefits.
