Chapter 8 Common Mistakes Companies Make on Business Intelligence Initiatives
“The structure that a mature enterprise takes on at any point in time essentially represents the accumulation of a long series of prior resource allocation decisions…. If these decisions are made without a coherent guiding philosophy or strategy, the organization that results will be like a stalagmite: shapeless, inefficient, and of little usefulness.”
—Robert Hayes, Steven Wheelwright, and Kim Clark, Dynamic Manufacturing
It can be argued that the emergence of the term “business intelligence” (BI) within the data warehousing (DW) industry was spawned largely as a result of the many mistakes that organizations unwittingly made as they pursued DW initiatives. Those mistakes were often costly, resulting in the implementation of large unused data warehouses that represented significant wasted investments.
With the arrival of the new BI buzz, the discussion turned away from how to build large data warehouses toward the acknowledgement that the data warehouse was only a means to an end. What was really needed was BI: the ability to identify and deliver actionable information that could be used within the organization to improve bottom-line business performance. Data warehouses would be repositioned as the technical means to achieve BI.
Once management’s eyes turned toward BI, their interest in identifying return on investment (ROI) associated with BI/ DW investments also resurfaced. Unfortunately, much of the BI discussion is still relegated to buzz and has not been truly embraced and adopted by organizations. With new BI vendor offerings in the areas of analytical applications, scorecards, and dashboards, many organizations are faced with even more choices, which heightens the potential for chaos.
This problem is illustrated by a recent discussion we had with a student of ours. As an exercise, the student had been assigned to determine which key process indicators (KPIs) from the plethora of choices offered within his company’s new BI vendor tool should be used by their organization to measure business performance. The tool had clearly been purchased to address information requirements that had not yet been defined, Without a sound framework to sift through all the possibilities that are offered in the BI/DW arena, there is a very real risk that organizations will repeat history and make more costly mistakes. Instead of improving the informational capabilities of an organization, BI initiatives, just like DW initiatives, can have the opposite effect. Several years ago one of our clients, a vice president of marketing, said it well: the problem used to be that there was too little information; now the problem is that there is too much information. It’s like being a child in the F.A.O. Schwarz toy store in Manhattan: you don’t know which way to turn.
Back to what we are trying to achieve. The BI ideal would be to make optimal use of information within the organization to achieve measurable improvement in business performance. It would be to have exactly the right information at the right time to make the business decision and take the actions needed to achieve optimal business performance. Although this is the ideal, very few organizations have come close to achieving it. Advances in technology offer the promise of BI, but achieving incremental improvements in information usage within organizations has proven to be difficult. The following section outlines the most common and damaging mistakes that managers make within the context of critical BI success factors. The BI Pathway approach was developed to address these critical success factors and to avoid those mistakes. Although much of this information is covered obliquely in other sections of this book, this section is meant to distill the most common mistakes we’ve seen that have thwarted BI success.
8.1 Critical Success Factor: Establishing the Value Proposition
The first step to BI success is to establish a clear understanding of how business performance can be improved by investing in a BI program and to define the scope of the BI initiative. You can define scope as enterprise-wide, limited to a single line of business, limited to a single function, or limited to a group of users. Define scope any way that makes sense, but define it you must. Until you know what you’re not going to do, it’s very hard to speak with confidence about what you are going to do. Establishing the scope of the BI initiative is a vital first step and prerequisite for defining the value proposition. These activities set the foundation for everything to follow.
Once you’ve set the scope, focusing on how a BI program can improve business performance explicitly addresses the ROI issue: Why should we embark upon a BI initiative? What business problems exist and how will a BI program address these problems? What will a BI investment give us that we can’t already get? Is the investment worth the potential business value? How will having this information translate into bottom-line results? Why should we fund the BI initiative instead of another potential IT capital investment? Why should organizational stakeholders support the BI initiative?
8.1.1 Mistake #1: No Explicit Alignment Between Business Intelligence Strategy and Business Strategy
In their quoted statement at the beginning of this chapter, Hayes et al. (1988) were concerned about manufacturing strategy and competitiveness. It is clear that aligning resource allocation decisions with business strategy is just as important for BI competitiveness. In our experience, one of the most common and critical mistakes is the lack of explicit alignment between BI strategy and business strategy (Figure 8.1). Accordingly, BI investments are made without a coherent guiding philosophy, and the organizational result is an inability to fully leverage BI as a profit-improvement tool.
Clearly, organizations would never develop business processes such as order processing and inventory management without knowing the purpose of the processes and how they contribute to achieving business results. It is common, however, that organizations invest in BI/DW initiatives without having a clear understanding of what informational capabilities they are building, why they need those capabilities, and how they will contribute to achieving business goals and objectives.
This problem is illustrated by a conversation we had recently with a company in the midst of a major undertaking to integrate customer information across all lines of business. When asked why the company needed this capability and how this information would be used to support business goals and improve business performance, managers had no answer. Clearly, this linkage had not been explicitly discussed and communicated within the organization. If BI capabilities are to be optimized, the business needs a clear understanding of the opportunities that exist to deliver and use information in support of the business strategy. It provides the critical foundation for all that is to follow. Companies that think about how they use information to improve strategic results will be ahead of companies that don’t.
8.1.2 Mistake #2: Not Knowing How to Define Information Requirements
Once you have a well-reasoned understanding of the relationship between BI strategy and business strategy, it is critical to understand the details of the information requirements and how they relate back to supporting the business. Because business users have been trained over the years by information technology (IT) departments to provide reporting specifications for operational system reporting, these business users reasonably think that information requirements should be defined as reporting requirements. IT departments also tend to resort to this seemingly logical approach. As a result, it’s common for all concerned to specify requirements as data elements rather than as true information needs associated with a clear business purpose. Accustomed to not having information, business users often request the ability to have lots of data so that they can do ad hoc reporting. This approach has typically lead to expensive, monster-sized databases that are not designed for a specific purpose and do not perform well. Because they tend to be large, unwieldy, and confusing, containing “everything and the kitchen sink,” they often end up not being used by the business.
FIGURE 8-1 Connecting business strategy to BI strategy.
Because of this approach to defining requirements, it is very common for information requirements to exist with little if any business context. Why particular information is needed, how it will be used, and how the intended use would contribute to improved business performance are not clearly understood or articulated. Based on conversations with many people from many organizations over the past years, we’ve concluded that this problem has been a major contributor to many failed DW efforts. A recurring theme that we have heard from IT staff is that “we built what they asked for and they aren’t using it.” Companies that both align BI strategy with business strategy and explicitly link how information can be used for competitive advantage by enabling and/or supporting business strategies will be ahead of companies that don’t. By putting analytical rigor into “connecting the dots” to clearly understand what information is needed by the business, why it is needed, and how it will be used to improve performance, they are providing a solid foundation for achieving both business and technical BI program success.
8.1.3 Mistake #3: Not Marketing the Vision to Obtain Organizational Support
Many organizations are surprised to discover that it’s not good enough merely to develop a BI/DW application and train business users—not if they want to ensure that the application will be used. This approach, which is common for operational systems, does not always work. One reason for its failure is that many organizations consider BI/DW applications to be optional. Unlike most other IT operational applications that replace existing applications and have to be used by the business, BI/DW applications often exist in parallel with old reporting capabilities. As a result, business users who are uncomfortable with the new BI/DW capabilities can frequently fall back on using their old reports to get their jobs done. This makes it harder to ensure that business users will use the new BI/DW capability and that the benefit of this investment will be realized.
By definition, embarking on a BI initiative changes how the organization accesses and uses information. For that reason, it is important that the organizational stakeholders are “on board” with the vision. This should not be a daunting task if
Providing a clear articulation of the “current state” of information availability and usage, as well as the vision for the “future state” and how it is better, sets the stage for organizational buy-in and support. Organizations that explicitly embark on a marketing program to obtain organizational buy-in for their BI initiative actively communicate the value proposition to key organizational stakeholders, thereby setting the stage for BI success.
Tip
Establishing the BI value proposition is critical to BI success. It includes using a sound BI requirements framework that explicitly links BI requirements to business need. It also includes promoting the BI value proposition within the organization.
8.2 Critical Success Factor: Establishing and Managing a Business Intelligence Program
Many organizations get started with a single BI project. If it’s successful, they realize that there is business demand for more BI capability. Unlike operational IT projects that develop stand-alone systems, such as order entry systems, procurement systems, and human resources (HR) systems, BI applications are interdependent and need to be managed within a program context. This interdependency includes BI projects sharing such things as tools and technologies, data architecture, standards, methodologies, and ETL (extract, transformation, and loading) processes. Many BI mistakes result from not fully appreciating the need to manage a BI initiative as a series of projects managed within a unified program.
All BI project opportunities within the stated scope of a BI initiative are not created equal: the relative cost/benefit of each potential BI investment varies. Organizations must consider what opportunities exist and how each opportunity sizes up relative to other opportunities. For example, within the scope of an enterprise DW program, there are numerous opportunities for getting started:
To ensure that BI capital investments are made wisely, organizations must ensure that there is a way to sift through all of the possibilities and evaluate them and fund them based on relative cost/benefit considerations.
8.2.1 Mistake #4: Using Ad Hoc Practices to Select and Fund Business Intelligence Projects
It is always interesting to talk with organizations about their BI projects and the considerations that led the organizations to choose these projects instead of others.
Unfortunately, it’s common to hear about (1) a key business individual who unilaterally decided to fund a project, (2) an IT manager who decided to build a BI proof of concept in hopes that it would be funded, or (3) a key individual in management who saw a demonstration of a vendor scorecard and decided to purchase it. It is rare that organizations use a framework for analyzing the merits of the potential BI projects to determine which ones are more worthy of funding based on their potential business value. Organizations that use a structured approach to evaluate and determine the relative cost/benefit of competing BI project efforts are more likely to make optimal use of their BI investments.
8.2.2 Mistake #5: Providing Inadequate Governance for the Business Intelligence Program Management
In most organizations, the job of IT is to run projects that build individual, stand-alone IT applications. By use of this IT paradigm, many organizations mistakenly conclude that BI simply requires an IT project that will result in a BI application. As a result, organizational expectations, business resources, technical resources, and funding often focus on individual project efforts and are insufficient to support the needs of a successful BI program. Although an initial BI project may be needed to spark the interest of the business organization in the possibilities of using information to support business goals, it is important for organizations to understand that a BI initiative ideally goes well beyond any single project. If positioned correctly, it is a long-term program undertaking to leverage information assets to support business success. As such, it requires a long-term commitment, a program perspective, and a governance structure.
To get the most out of a BI initiative, organizations must strategically position them as programs made up of individual BI project efforts, each of which furthers the organization’s ability to use information for competitive advantage. If there are organizational impediments to achieving BI program success—such as insufficient funding, resources, and management of BI program activities that cut across individual project activities—then these impediments need to be resolved. Companies set a course for success when they understand the goals and opportunities of a BI initiative and provide adequate resources for both a BI program governance structure and BI project level activities. It’s more costly up front to fund BI program governance activities, but this investment is needed to ensure that the right projects get funded; that supporting tools and technologies, data architecture, and ETL processes are rationalized across project efforts; and that sound standards are put in place for use by all projects.
Many of the “problems” we hear about are symptoms of the same mistake: the lack of coherent BI program governance. These problems include the following:
Organizations that invest in formal BI program governance in support of all BI projects make a wise investment and avoid expensive future problems associated with a project-centric approach to BI.
8.2.3 Mistake #6: Establishing De Facto Program Governance Based on the Initial Business Intelligence Project
We often have conversations with individuals who are responsible for their organization’s “first BI project.” Typically, these individuals are overwhelmed by all of the activities they must do to get started. The problem is that in addition to performing all of the activities needed for their individual BI project, they have also become the de facto program managers. Decisions related to tools and technologies, data architecture, technical standards, meta-data management, methodology, and other program-level activities are made by them. They are optimizing their decisions for their current project. As a result, it is common that these decisions sometimes fail to work for future project efforts. Organizations that use the initial BI project to make long-ranging decisions that will affect future projects are risking expensive mistakes.
8.2.4 Mistake #7: Not Strategically Positioning the Business Intelligence in the Business Organization
BI initiatives are often positioned organizationally as an improvement on “reporting” and are viewed as something done by IT. This frequently explains why there is little, if any, advancement of information usage in many organizations. Organizations are on the right track when they appreciate that BI is far more than reporting and can serve as an important tool to advance their competitive position in the marketplace. These organizations tend to view BI as a new strategic tool that has great potential if applied properly. They clearly understand that to make the most of this potential, senior-level business resources need to be actively involved to exploit it. If companies position BI as an important business initiative to be led by senior members of the business organization and supported by IT resources, then they’re ahead of companies that don’t.
8.2.5 Mistake #8: Not Providing Adequate Resources and Funding for Supporting Efforts Needed for a Successful Business Intelligence Initiative
As part of a BI program effort, it is necessary to provide resources and funding for new supporting functions such as data management and meta-data management. Data management requirements can range from defining enterprise-level naming conventions, definitions, and business rules to ensuring standards of data quality. Meta-data management efforts provide for the management and traceability of all components of the BI environment. Meta-data needs range from ensuring that definitions and business rules associated with BI applications are made available to business users to providing source data mapping information to manage the environment or answer questions regarding the sources of information in a BI application. These efforts can often be significant, but they are needed to ensure the success of the BI initiative. Organizations that recognize the need for and provide the resources and funding for supporting efforts needed to support a BI program will be laying the groundwork for success.
Tip
Establishing and funding a BI program are critical to ensuring a solid foundation for BI initiatives. The BI program provides a business, technical, and organizational framework to guide BI projects.
8.3 Critical Success Factor: Optimizing Information Technology Infrastructure for Business Intelligence
In many organizations, management information and reporting systems are relegated to the status of second-class citizens. Operational systems that take orders, replenish inventory, pay bills, and process paychecks have always been considered the lifeblood of the organization and have always been given priority over systems that deliver information.
In combination with the fact that the technical underpinnings and requirements of these different classes of systems differ greatly, this results in BI technical environments that are optimized for operational systems and don’t serve the needs of BI technical environments well. Most business users believe that IT is just IT; they don’t understand that there can be distinctly different needs for different classes of systems. If BI is truly being positioned in the company as a strategic tool to improve bottom-line performance, then it needs to be considered by itself and given equal consideration to be successful.
8.3.1 Mistake #9: Using a Technical Infrastructure That Does Not Adequately Support Business Intelligence
Operational systems are designed and optimized to capture individual business transactions (usually current year) as they occur. Those systems also update these business events, as needed, to run the business. Reporting needs are considered secondary when designing these types of systems.
In contrast, a DW environment, typically used to support a BI program, receives high volumes of data, including historical data, from many different systems. The DW environment must be optimized both to load this data efficiently and to provide high-performance information access. Because the underlying purpose and focus of these classes of systems are vastly different, considerations regarding storage, processing, network needs, and tool/technology requirements are vastly different. Unfortunately, it is common to hear about DW environments that don’t perform. A major contributing factor to this problem is often an inadequate technical infrastructure. Organizations that recognize the need to invest in a technical infrastructure optimized to support BI requirements will avoid technical risks that lead to performance problems.
8.3.2 Mistake #10: Using Operational System Information Technology Design and Development Approaches
Many organizations do not recognize the inherently different nature of DW. They try to use operational system design and development approaches to get the job done. Although some of these approaches might be useful to address “real-time” DW approaches, many of these approaches do not support other DW needs and result in design, performance, and time-to-delivery problems.
For example, analysis techniques used to identify and document requirements that work well for operational systems do not do a very good job of capturing BI application requirements. Approaches used to specify report design are also not adequate at all. Design techniques used for operational systems, such as data modeling approaches, also are inadequate to support DW needs.
New types of testing to ensure adequate load and query performance are not needed for operational systems, but they are critical for DW environments. Organizations frequently do not appreciate these differences. Without knowing it, they use the wrong approaches to design and develop their DW environments, which results in mistakes that compromise quality and performance. Organizations that recognize that different design and development approaches are needed to support BI requirements will avoid quality and performance problems.
8.3.3 Mistake #11: Using Information Technology Standards and Policies Designed for Operational Systems
In most organizations, IT standards and policies have evolved over time and have been adjusted when problems have occurred. Many of these standards and policies have their roots in the days of mainframe system design, when time was measured in years rather than months. As a result, many of these standards and policies are not conducive to rapid application development: a stated goal for BI applications.
Several years ago, we were working with a client who had a very cumbersome project planning policy. It had been developed in response to sloppy project management practices that had caused problems in the past. This process included developing a very detailed project plan and incorporated several review cycles. If followed properly, it would take more than two months to complete before any project activities began.
The problem was that the BI project on which we were assisting was slated to be completed in four months. Doing the math, we pointed out that 50% of the time slated for the project would be consumed in planning the project. Although this process might be appropriate for a large-scale, multi-year system, it was not appropriate for this organization’s BI project.
Tip
BI has its own development and infrastructure needs that often differ from the needs of operational systems. You can save money and time at the beginning by using operational resources and methods for BI, but you end up in the long run with less effective BI systems that deliver less value to the organization. It’s wiser to recognize and address the unique requirements and potential of BI at the outset.
Another client had a charge-back system that was in place for business users who requested ad hoc reports. The purpose was to provide a disincentive for users to make ad hoc report requests that affected the performance of their operational systems. This policy, when it was applied to BI applications, made using the DW environment cost-prohibitive. Organizations that review and revise existing IT standards and policies to ensure that the policies adequately support BI program needs will be more successful in developing and deploying BI applications.
8.4 Critical Success Factor: Managing Organizational Change Needed to Capture Value
It is one thing to build a BI asset. It is another thing to ensure that the potential value of that asset is realized. Managing organizational change is critical to ensuring that the BI asset, once built, is put to good use to deliver bottom-line results. Typically, organizations grossly underestimate the effort required to institutionalize and optimize the use of the BI asset. Because business users can often avoid using BI applications, they often do. Training alone is not usually adequate to ensure that business users will get on board with the BI program. Organizational incentives may need to be put in place to ensure that business users will make the changes needed to leverage the new BI asset.
Organizations also are often unwilling to make changes needed to operational systems to ensure that the information they need to run the business is available and of high quality. Because of the organizational challenges associated with change, it is also common that the potential for the use of BI to improve business performance is not optimized.
8.4.1 Mistake #12: Not Utilizing Business Process Reengineering Approaches to Optimize the Use of New Business Intelligence Capabilities
Old IT paradigms usually persist when BI deployment activities are developed. Because acceptance testing and user training have usually signaled the end of a project, most BI efforts stop at this point. The problem with this approach is that business users are often confused about how to do their jobs “the new way” now that they have a new BI application. In some cases, the effect of the new BI capability is minor; in others, the effect is dramatic, completely changing the way that a job has been done in the past.
For example, we worked with a client several years ago who was used to generating a campaign mailing list from valid names in a database. To improve the response rate and reduce the marketing costs associated with obtaining a response, a BI application was developed to support customer segmentation analysis and to generate a targeted list of high-probability prospects. This new capability fundamentally changed the way that the identification of campaign targets was to be performed.
Training alone would have been inadequate to ensure that this new “to be” business process was put in place and used as intended. If business users are not helped along with understanding and adjusting to changes in underlying business processes needed to optimize the use of a new BI application, odds are that the application will not be used as intended. As a result, the potential business value will be compromised.
In addition, the IT department is not the organizational unit that should be charged with this activity. The business organization must work in conjunction with IT staff during the requirements phase to fully articulate both the “as is” business process and information capability and the desired “to be” business process and information capability. As the BI application is implemented, the business organization is responsible for ensuring that business process changes needed to realize the potential value of the new BI application are put in place. Organizations that manage organizational and business process changes needed to capture the value of the BI asset are more likely to achieve a good return on their investment.
8.4.2 Mistake #13: Unwillingness to Make the Organizational Changes Needed to Obtain Data Needed to Deliver Business Intelligence
By definition, BI is about change. In addition to business users needing to adjust to new informational capabilities, changes are also often required so that the organization can capture new types of data needed to provide a BI capability and to ensure the quality of that data. This change usually affects owners of the operational systems who are charged with designing the systems needed to capture business data and set standards for data quality. It also affects business-side people who are charged with inputting the data into the systems. A BI program can be limited by the organizational will to make these changes. Often, the need for more and better data collides with the organizational desire to speed up and reduce the cost of operational processing.
One client several years ago had a need for richer demographic data in order to better profile and understand customer behavior. Rather than putting in place efforts to add to the data currently available about customers, an effort was underway to reduce the amount of available customer data to shorten the length of time and cost required to take customer orders. Because the client’s BI strategy was not explicitly aligned with its business strategy, the impact of this change was not visible to key business decision makers. As a result, they had no vote and the operational needs to reduce the time and cost of taking customer orders won out.
8.4.3 Mistake #14: Not Creating Organizational Incentives
Most people in organizations do not like change, even if they understand logically why change may be beneficial to the business. Even when given a BI application that can help them do their job better, and provided with the necessary training and support, resistance is often met. It is common that people may want to resort to what they know and have done for years. To ensure that the people who are needed to capture the value of the BI asset are using it in the way that is intended, it is important to create organizational incentives for “doing the right thing.”
One organization built in management objectives affecting bonuses for actively using the BI application. Other organizations send strong signals that senior management will be using new BI application capabilities to manage the business and expects that the rest of the business will use them as well. Organizations that recognize the need to institutionalize the use of BI assets through creating organizational incentives are more likely to capture the potential ROI of their BI asset.
8.4.4 Mistake #15: Not Exploiting the Full Potential of Information
Many organizations have a hard time moving away from the status quo. Accustomed to having little to work with, they have a hard time thinking about the full range of possibilities of how they could use information for competitive advantage. Some organizations, by nature, resist change and will only embrace it when forced to. Other organizations are so focused on the present that they don’t seem to have the organizational bandwidth to fully exploit the possibilities.
Tip
To get the most value from BI, you must change your processes from those based on not having information to those based on having information. Identifying the need for change, and proactively managing it, will increase the odds of success.
There are organizations, however, that are capturing the potential of BI for competitive advantage. These organizations will be the leaders in defining new ways of competing, and will reap the rewards of exploiting this new capability.
8.5 Key Points to Remember
8.6 Think Tank
8.6.1 Seven Questions to Ask About Business Intelligence Mistakes
3. Have we actively marketed the value of BI to get management support and user buy-in?