Over the last 35 years, business users and IT professionals have struggled with requesting and delivering computer-based solutions that support all kinds of decision-making processes. In spite of all the developments and efforts, the general situation is a lack of user satisfaction and a disconnect between business decision-making and the IT worlds. After all, the majority of decision support still relies on spreadsheets developed by users.
What can be done to improve this relationship? Before answering this question it is important determine which factors are decisive for user satisfaction in the first place. The following four factors are essential:
- The pace at which users receive answers to questions.
- The degree of relevance between the answer and the question asked. (An answer with little or no relevance to the users question is as good as no information at all.)
- The (perception of) reliability of the answer. (Do I trust the answer enough to use it?)
- The cost of information compared to its value. (Users are not interested in answers where the cost exceeds the value of the information.)
According to Gartner, 46 percent of the drivers to invest in business intelligence (BI) have to do with time, 29 percent with quality, 11 percent with costs and 14 percent with alternative methods of sharing and distributing information.1
Improving an unsatisfactory relationship that has been developed over a long period of time is a complicated process and there are no simple solutions. So, making improvements, such as the following recommendations, is a complicated process in itself.
1. Concentrate all functional and technical expertise necessary to design, build, deploy, support and maintain the information logistics infrastructure and the BI applications in one logical organizational unit, such as the business intelligence competency center (BICC).
The back end of BI (the data warehouse) is its infrastructure, which has to be designed - at the architectural level - independently from the actual BI applications. Nevertheless, BI applications are the reason to exist for the data warehouse. You dont need a data warehouse if you dont have BI applications; but you can have BI applications without a data warehouse. BI applications without the warehouse or a number of independent data warehouses each with their own cluster of BI applications are all too often the case. Although this can be explained by history, it becomes a burden to maintain timely delivery of relevant and reliable information at acceptable costs while integrating information across multiple data warehouses. If its not a problem now, sooner or later it will be.
This is not a recommendation to build one super data warehouse for the whole organization, it is merely a plea to concentrate expertise in order to design an overall information logistic architecture and process with all the optimal decoupling points for any given situation.
Although the architecture itself is largely independent of the actual applications, the combination of data warehouse and BI expertise in one BICC is necessary to ensure that the priorities, pace and requirements are dictated by the business requirements. Ownership and management of a BICC cannot be dominated by IT. Depending on the business governance it should be one centralized BICC or a number of closely cooperating BICCs.
2. Break through the concept that the user pays and that projects can only be started when money is made available by the business.
An information logistics infrastructure - the enterprise data warehouse (EDW) - is an infrastructure that neither the individual owners of source systems nor the individual owners of the BI applications have any direct interest in. The investment only gives return on projects started after the initial investment is made.
Where the back end requires funding beforehand, independent from individual BI applications, the BI applications themselves should be fully funded by the business owner of the application. The costs of data warehouse activities necessary for the individual application can be included in the project costs. The costs of using the generic infrastructure should be included in the operational costs of the application on a pay-per-use basis. The cost of developing the application should be based on competitive market compliant tariffs. When external consultants are brought in, the hourly rate of these consultants should not be raised with a surcharge to make up for overhead costs of the BICC. Planning should be based on priorities set by the business. Never turn down a request for a project based on capacity or - even worse - budget constraints of the BICC. Doing so will force the business to look elsewhere and undermine the success of the BICC.
3. Use an architecture that is resistant for a variety business governance models for the design of an EDW.
An EDW is often seen as one large, centralized and all-embracing data warehouse where all source systems deliver their data and from which all data marts (or BI applications) are fed. Such a concept is often in contrast with the way in which the business governance is arranged by most large organizations or defined and executed/delegated across different business units. Instead, most large business units have substantial freedom to design a strategy to execute their part of the business. This local strategy is - hopefully - in line with an overall strategy. This power is assigned based on geography, countries or regions. There are even organizations with a matrix where ownership is divided across both axes. In such organizations it is not only unfeasible but also undesirable to have one large centralized physically implementation of the data warehouse. It is much better to implement an architecture in which a network or federation of logically coupled, but physically separated data warehouses exist. This logical coupling takes place based on an information model where each underlying organization can couple with the information model of the upper lying organization and expand it with its own model. Over time, these information models themselves and the level they are coupled with will change.
4. Use tools and technology based as much as possible on the (re)generation of structures and automatic population for implementing your information logistic infrastructure methods, and stop constructing and maintaining the data warehouse with traditional database-oriented methods, tools and technology.
By definition, an EDW is never ready. The application landscape of a large organization is always a work in progress. More importantly, there is continuous change in organizational and reporting structures. These changes in the information model have a tremendous impact on the logical data model. Changes in the logical data model are probably the main reason for intensive and thus time-consuming maintenance of the data warehouse. Technology that generates the data warehouse based on an information model will reduce lead times by large percentages. Some tools can automatically capture the changes in all attributes of all dimensions. In this way it is possible to generate analysis and reports on all facts in any arbitrary historical context of the master data. This is something that is not possible or requires very intensive maintenance in a lot of data warehouses.
5. Adopt prototyping as well as an evolutionary and incremental way of working as the primary methods for the BICC, especially with respect to the front-end applications.
It is essential to use an interactive and short-cyclic way of working and communicating with the actual users. This needs to take place based on moving screens and not on PowerPoint or Word. BI users only know what they want at the moment they see the first screens rolling. Where you can measure lead time for development or changes of an operational application in months, weeks or days, you should measure lead time for BI applications in weeks, days or even hours. Developers of BI applications need to understand the pace of the business, which does not imply they need to be part of the business organization. One important condition should be met: the BICC must operate as a profit center and not as a cost center with a limited budget and all kinds of planning restraints.
6. Limit the role of an enterprise resource planning (ERP) package BI add-on as an operational data store (ODS) or for one-to-one reporting.
As long as the implementation of the underlying package is reasonably standard, the business context of such an add-on is excellent for one-to-one reporting. Most of this reporting will be used for operational reporting purposes. At the same time, it can be an excellent source for the real EDW. However, dont use such an add-on data warehouse as the EDW when the organization has standardized on the package(s) of one specific vendor. In practice, such a standardization will never be 100 percent. Integrating information from multiple components of the package of one vendor is just as difficult and cumbersome as integrating the content of tailor-made applications or a number of different packages from different vendors. Also, the technology and underlying architecture of these applications are not (fully) compliant with the recommendations above.
7. Initiate pilot projects in the fields of master data management (MDM) and data quality from within the BICC.
In spite of the implementation of these suggestions; if MDM and data quality are not structurally sound, it will prove to be virtually impossible in the end to obtain reliable and consistent management reporting. We know that it is a condition of success that the business is in the lead in addressing these issues; however, at the same time we see that the business - in general - is reluctant to do so. The solution is to start within the BICC limited pilot projects, which are aimed at digging up examples of shortcomings and building a clear business case. Financing of these pilot projects should come from a general budget. Supporting technology is expensive, but it is worthwhile to investigate the opportunities available when using the services and infrastructure of an information logistics service provider.
These suggestions we have not even touched on the impact of the inflow of a new generation of managers - men and women who have grown up using computers and the Internet as common practice. Imagine what that will mean for requirements with respect to content, format and the timeliness of information. Maybe we will witness a move from spreadsheet management to browser management.
Implementing these recommendations will not necessarily be simple. But, you owe it to your users.
- Neil McMurchy. Survey of BI Purchase Drivers Shows Need for New Approach to Business Intelligence. Gartner, July 4, 2008.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access