Business intelligence projects have historically produced remarkable results for countless companies. Properly implemented, BI projects give business analysts and management access to timelier, more accurate information to enable them to make better decisions. However, successful implementation of any business intelligence – or IT – project requires one other BI component: business involvement.
It is crucial that a company’s business user community be involved with the design of any BI solution and the underlying enterprise data warehouse. Building an EDW without the business community’s involvement is akin to constructing a building development project without a blueprint. In fact, a lack of involvement from businesspeople is perhaps the single most prevalent reason for failure of an EDW/BI solution.
For starters, business involvement within a company requires the business community’s active participation in requirements-gathering sessions to convey the key business questions that must be answered in order to effectively manage and monitor their business. This participation can help the EDW development team better understand the business leadership’s vision for the future. Only then can an effective, business-oriented solution result.
This is especially true for EDWs. An EDW is a repository that aggregates data from disparate systems throughout the company and integrates it into a single version of the truth across the enterprise. Successfully implementing an EDW requires that all business functional divisions across geographies collaborate and reach consensus on the names and definitions of data objects in the enterprise.
The level of business involvement required to achieve this may sound impractical at first, but consider just one example: the definition of “Product.” The finance, marketing and manufacturing business units may each have a different, conflicting definition of the “Product” object. These types of conflicts must be addressed during EDW implementation so that standard object definitions can be reached and agreed upon. Otherwise, it will be a nearly impossible task to accurately compare and build reports with data from different business units once the data is integrated in the EDW.
The Business Value of a Successful EDW
True business intelligence comes from the analytical search and reporting capabilities that are available to a company’s business community as a result of the data rationalization and integration process that takes place during the construction of an EDW. The EDW is the source of information for queries and reports that provide the business community with an enterprise view to facilitate more insightful management and better decisions.
Consider the example of a large financial institution (FI) that is considering a merger/acquisition strategy. The FI’s EDW would be an invaluable resource in decision-making. First, the financial information in the EDW would give the FI’s executives a handle on their financial strengths and weaknesses – thereby assisting in their decision to choose a merger/acquisition target that would complement their financial and market position. Second, the customer information available in the EDW would enable them to compare customer lists with the acquisition target in order to perform cross-marketing of the newly combined FI’s products if the customer lists were similar. If the lists were different – due to geography or historical market – the customer information would help the acquiring FI in trying to maximize the retention of the target FI’s customers as they develop new marketing strategies to meet those customers’ needs.
Leveraging Business Involvement for a Successful EDW Implementation
A huge factor in the success of any IT project, especially an EDW, is for the development team to make a concerted effort to understand the needs and concerns of the business community. Statements such as, “If only we could do this,” as well as the business users’ descriptions of the barriers to aggregating data for an enterprise view, are clues to understanding a company’s needs. These clues often hold the secret of leveraging business involvement to achieve success in implementing an EDW. To successfully leverage the knowledge and expertise of the business community, there are three critical success factors: listen to and learn from the business community, analyze and understand the business needs, and engage and advise the business community on the fundamental building blocks of the EDW.
Listen and Learn
One clear path to an enriched, viable and useful EDW is for the development team on the project to listen to the company’s business community and make a determined effort to learn about the company’s business. Truly understanding the business means more than identifying the data used and created by the business. It means understanding the business logic, as well as the processes that are performed to initially create and maintain the data. Without this knowledge and understanding – of both the current state and the desired future state – the project can devolve into simply shifting the data from one environment to another and replicating that data with no clear enrichment. This will increase the cost of managing that data and most likely will not result in accomplishing the goal of the EDW implementation, which is providing improved information for business decision-making.
Analyze and Understand
Once the EDW team has secured the input of the company’s business community and learned about the business processes and operations, the next step is to analyze and understand those operations to gain a more in-depth knowledge of how the business functions on a day-do-day basis. From the standpoint of the development team, the responsibility of analyzing and understanding the business community’s needs primarily rests with the data architect and the development team leadership.
This task is accomplished through the EDW development team working with the business community to design the logical data model for the EDW. The LDM is the foundation of any EDW project and largely determines the success or failure of the project. If the business community is not properly involved and their needs are not appropriately communicated in the development and design of the LDM, it’s a safe bet that the EDW project will not be able to accomplish its goals.
The LDM not only visually represents the data needed to run the business in its current state; it represents the company’s vision of its future state. Thus, the LDM should account for any future plans that the business community has for key business activities such as acquisitions, incorporation of external information, process changes – in essence, any key enterprise-level activity that would affect future information needs.
The result of the development team’s effort to analyze and understand how the business operates is an LDM that serves as the blueprint of the EDW and clearly shows how critical data is related, as well as how that data helps the company do business. Additionally, the LDM provides a vehicle by which both the business and technology teams can achieve a better understanding of the business, and can work together to design practical solutions for providing timely and important information to the company’s leadership.
Engage and Advise
One key to meeting the two critical success factors above is relationship building. The relationship-building process begins with the engagement of the EDW team with business subject matter experts from fundamental business areas such as finance, marketing and operations. The SMEs provide the development team with critical knowledge of the day-to-day operations of the business and how the business processes flow to create and manage the information that the business community needs to function and help grow the business.
Another relationship of critical importance to the success of any EDW project is the one between the data architect and the business community. First, the data architect should become the trusted adviser to the business champion of the EDW. The data architect should work directly with the business champion of the EDW to learn and understand all aspects of the data and business environment. Armed with this knowledge, the data architect can then spearhead the source-to-target data mapping initiative and drive this process to capture the current state of the business. This current state information is necessary to create the specifications for the implementation of the EDW. Fundamentally, the data architect has three responsibilities: learn the company’s business, design the EDW and transfer the knowledge of the EDW design to the business and implementation teams.
The development of these relationships is absolutely imperative in order to achieve a high-quality EDW design. Without the direct interaction and cooperation between the development team and the business community, the needs of the business may not be taken into account properly, and the EDW may not provide the user community with the information they need to do their jobs properly. It’s that important.
Engage, Engage, Engage – the Mantra for Success
It cannot be said strongly or often enough: the business community must be engaged in the EDW design and development process. The business community will be the ultimate end users of any EDW, and without their input and decisions to critical business questions, more than likely, any EDW that is developed will not meet all of their business needs. Such an EDW could not provide a good return on the company’s investment simply because it would not be used enough to justify the investment. Unfortunately, the most common result of the implementation of an EDW with limited or no involvement of the business community is a replication of the current environment, not an improvement that provides business users with the information they need to make more timely, better-informed decisions.
Further, when the business community is not involved from the beginning of the EDW design, any subsequent enhancements to the design of the EDW are usually time-consuming and potentially difficult. This can be somewhat mitigated, depending on the level of expertise of the data architect. If the data architect has a high level of expertise, the implemented EDW design may possibly accommodate a few enhancements. However, the issue of the lack of knowledge of the business expectations and requirements as well as vision for the future remains a problem.
More likely is a worst-case scenario in which the EDW implementation becomes a hodgepodge of patches and fixes that convolutes the overall design of the EDW. The probable result in this case is the costly task of processing the same data multiple times and performing manual manipulations that could have been avoided with the engagement of the business community.
Using the Other “BI” to Align Business and Technology
However, when the business community is involved from the inception of an EDW project, the implementation process is typically smooth in that business and technology goals and needs are usually aligned. When the business is involved from the beginning, the EDW design is much more likely to be practical, efficient and usable. However, when business involvement is not a part of the EDW implementation, the most likely result is that the current state is replicated – perhaps with slight variations including a little more flexibility toward the vision of where they want to take the enterprise, but not much more.
The most critical success factor for the implementation of any technology is the other BI, business involvement. This is true whether the project is for an EDW, an enterprise resource planning solution or a custom-designed application implementation.
The author would like to acknowledge and thank Sandee Walia, senior consultant, Deloitte Consulting LLP, for her insights on this topic.
This publication contains general information only and is based on the experiences and research of Deloitte practitioners. Deloitte is not, by means of this publication, rendering business, financial, investment, or other professional advice or services. This publication is not a substitute for such professional advice or services, nor should it be used as a basis for any decision or action that may affect your business. Before making any decision or taking any action that may affect your business, you should consult a qualified professional advisor. Deloitte, its affiliates, and related entities shall not be responsible for any loss sustained by any person who relies on this publication.
As used in this document, “Deloitte” means Deloitte Consulting LLP, a subsidiary of Deloitte LLP. Please see www.deloitte.com/us/about for a detailed description of the legal structure of Deloitte LLP and its subsidiaries.