Overview of Services Advisory Services
ASSESSMENTS Readiness Assessment for BI, DW, and CPM Assessment of Current BI & DW Environments Data Shadow System Assessment ARCHITECTURE & TECHNICAL Architecture Design & Project Planning Technology Strategy & Tool Evaluations MANAGEMENT & BUSINESS INITIATIVES Data Management & Governance Strategy Organizational, Resource & Skill Review Business Planning & Justification Internal Marketing RETAINERS Retainer-Based AdvisorImplementation Services Education Services
BI/DW TrainingSoftware Vendor Services
Data Warehousing and Business Intelligence Data Modeling BI & DW Concepts & Fundementals BI & DW Architecture BI & DW Project Management Business Overview of DW Data & Process Modeling Data Management Concepts Data Naming WorkshopEducational Assessments
Four Flawed Business Intelligence Assumptions
Originally published in Information Management
In The Trial-and-Error Method for Data Integration, I discussed some common data integration mistakes. In this article I point out where companies tend to go wrong in business intelligence (BI) implementations.
1. Assuming your BI projects are pervasive and successful. BI is used successfully in all industries and continues to gain momentum. Thousands of business users are using BI reports and analytical applications to conduct analysis and make decisions.
Despite the success, there are two dirty secrets in the industry. First, BI isn't pervasive. Only a small percentage of an enterprise's employees, customers and partners are actually using these reports. Second, and more serious, it's not that successful. Business users rely on countless data shadow systems to get their information.
A survey by TDWI estimated that an average enterprise had 28.5 data shadow systems.1 Why so many? Because business users have no choice. Despite the "official" tools and data warehouses, we still aren't providing what they need.
I often work with enterprises with supposedly successful BI implementations. They ask for a BI review or assessment, and what do I find? Alongside the pockets of happy users are frustrated businesspeople who have built data shadow systems because what IT delivered doesn't meet their needs. What these enterprises need is an intervention - the business sitting IT down to convince them that their BI job is not working.
2. Assuming the power users speak for the business users. Often a BI team's primary contacts are the business's power users. Although it's normal for them be your first and primary contact, it is a mistake to rely solely on them for requirements and feedback. The power users are the "geeks" of the business. I like geeks (I'm one myself), but they don't represent "normal" business users. Power users like toys such as slice-and-dice tools and spend a lot of their time building data shadow systems.
Normal business users, on the other hand, do their jobs and use BI tools as enablers. Their job isn't to play with the toys like the power users; it's to make business decisions. If you ignore their requirements, the resulting BI application won't get used, no matter how great it seemed in the proof-of-concept stage.
3. Assuming that business users want what they initially ask for. With traditional software development you get requirements, develop specifications, code it, test it and then deploy it. That's okay for traditional applications, but it misses the mark for BI analytics. In fact, BI projects often fall into two camps. Either the BI usage is much lower than expected when deployed (and users build data shadow systems) or the project team is surprised during the testing phase that the business users are suddenly expanding their requirements and priorities. This usually makes BI projects late and over budget. In either scenario, the failure to meet business expectations is common.
Why don't users explain what they need right from the start? Why do they change their minds and add requirements? It's simple: they think they know what they need at the beginning. Thinking it's the right choice, they initially ask to replace what they currently have. But then when the project is underway, they see what is possible and get a clearer picture of where their data shadow systems fit into the overall scheme. You can head off these issues using an iterative development approach with heavy business-user involvement.
4. Assuming Microsoft Excel is evil. IT folks generally view Microsoft Excel as an inferior competitor to BI tools and try to thwart the business's natural tendency to use it. IT's desire to replace Excel hampers effective communication between IT and the business, leading to blind spots. Not acknowledging Excel's role leads to nasty surprises once a project is underway.
IT needs to accept Excel as part of their BI tool portfolio, just as the BI vendors have embraced Microsoft Office integration in their BI product suites. This integration goes far beyond the tepid interaction that existed in the past when integration was limited to extracting data into an Excel-readable format. A lot of business analysis begins with flat file exports (and subsequent data shadow systems).
The benefits of Excel are that it is already pervasive, people understand it, it is inexpensive and it has tremendous analytical capabilities, especially when the data accessed comes from the data integration services that IT has created. The problem with data shadow systems isn't that Excel is the BI tool, but rather that it (and Microsoft Access) is being used for data integration and transformation.
It's easy for an enterprise to make any of these assumptions during a BI project. But BI success and its pervasive use rely on meeting and exceeding business expectations, not relying on easy assumptions or treating it like any other IT project. And, the success of every BI project depends on healthy communication between IT and business users during every phase of the project.
Wayne Eckerson. "In Search of a Single Version of the Truth." TDWI, November 2004.
|Data warehouse & Business Intelligence consulting|