Business intelligence (BI) projects have the goal to implement suitable tools for decision support and to integrate them with existing data sources in a company. They have therefore been on CIOs agendas for several years and there are still a lot of BI projects to come. Despite this fact, however, still the majority of BI projects fail to deliver the full benefit for the business that was expected. One factor why such projects are likely to fail is the lack of communication and common understanding of the project by the BI project team and the business departments. In this research, a modelling technique has been implemented that allows to model both the BI project elements as well as the business model in one comprehensive and easily understandable model, which can help to facilitate the communication between the stakeholders of a BI project. The modelling notation has been evaluated against real-world case studies by conducting interviews, which have shown that the implemented modelling technique could indeed improve the project results. An extended version of this paper is available under [1].
In recent years, the area of Business Intelligence (BI) has become a crucial part in the decision making process for companies in order to increase the value of the company. The expansion of existing or the introduction of new BI systems is still an important point on many CIOs’ agendas. A recent study, however, has unveiled that not even 30% of the BI projects conducted have completely delivered the expected benefit for the business, even though the discipline of BI has been around for nearly two decades [2]. Among other reasons, one of the most important success factors when creating a BI system is the alignment of the project with the company’s business strategy, goals and objectives [2], [3]. In order to provide valuable insights into the company’s performance and to create a benefit for the business it is of great importance to understand e.g. which key performance indicators (KPIs) are relevant for the business in pursuit of the company’s goals. Defining these KPIs and their underlying measures without a holistic view on the business strategy may result in missing answers to crucial business questions and, in the worst case, might lead to a decrease of business value due to missed opportunities or wrong decisions. The alignment of a BI project with the company’s strategy has already been named as an inevitable prerequisite for project success by several authors [2], [4], [5].
Modelling techniques and frameworks which allow the modelling of certain aspects of the business strategy, objectives or goals as well as the architecture of a BI system exist and provide tools to create models of their respective topics, for example the Business Motivation Model (BMM) from OMG. However, the modelling techniques that have been identified and analyzed are all limited to their respective areas. No modelling technique could be identified which provides the possibilities to model both the technical as well as the business aspects of a BI project which would greatly support the alignment of the BI project and the business strategy by graphical means. The goal of this study is to identify which elements are necessary for the mentioned alignment and to develop a modelling notation that allows the people involved in the project to facilitate communication and understanding and thus to support them in designing BI solutions that truly create a business value.
The term “Business Intelligence” (BI) was initially shaped by the Gartner Group in the 1990s. It is a technique to access and analyse information by the means of information technology which supports the management of a company to take business decisions based on quantitative business information coming from a variety of sources [6]. The Data Warehouse Institute defines the term as “The processes, technologies, and tools needed to turn data into information, information into knowledge, and knowledge into plans that drive profitable business actions.” [7, p. 7], which is the definition used throughout this research paper.
A BI system not only consists of one tool or software, instead it contains several systems, which are connected over several layers. The base of all BI systems are the data sources, which supply the data. This data is gathered from the different sources and integrated into a single database called data warehouse (DWH). Based on the DWH, one or several data marts are fed with data and store it in a structure optimized for analytical queries. The most commonly used structure is the dimensional modelling technique, introduced by Ralph Kimball in the 1990s. The idea behind the dimensional data model is to separate the measured data from the context. The measurements, also called facts, usually yield values (called fact measures) which are captured during the execution of a business process [8]. This whole structure can be modelled using a bus-matrix, which logically connects business processes with analytics dimensions. On top of these data marts, reports are created which contain relevant information for business users.
Avanade identified that 91% of all companies are using BI tools for analysing and managing their data [9]. According to a Gartner report, BI will continue to be an important topic with most company’s CIOs until 2017 and the adoption of BI tools within companies will continue to grow [3]. Despite the high awareness of BI, still less than 30% of all BI projects deliver the intended value for the business. Focusing on metrics which are not relevant for the operational or strategic control of the business is one of the major fail factors in BI projects [2]. This makes it necessary that the BI initiative is driven by the business in order to create a benefit [5]
Gartner Inc. [10] defines an Enterprise Architecture (EA) as a “discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analysing the execution of change toward desired business vision and outcomes”. Lankhorst [11, p. 10] adds that the alignment of business and IT leads to lower costs and other benefits and that a good enterprise architecture helps to translate the corporate strategy to daily operations which is one of the key points in achieving business success [11, p. 3]. To support Enterprise Architecture design, several frameworks have been developed by different authors with different purposes, like the Zachman Enterprise Architecture Framework or The Open Group Architecture Framework (TOGAF). Existing tools allow the modelling of relations between business goals, KPIs and processes, however, no tool has been found which provides a holistic view on the company and bridges the gap between enterprise architecture and BI.
In the last 15 years business people are becoming increasingly aware of the importance of a model and start to create models of their processes, goals, strategies, rules or policies. One of the drivers why business modelling became popular is the changing economics of corporate information technology and the need to better align IT activities with business needs. However, there are several kinds of business modelling techniques, each supporting its specific purpose [12, pp. 1–4]. Creating a model of the business and aligning it with IT or BI initiatives can facilitate the communication between these worlds and thus lead to better understanding and more sustainable results. Orr et al. [13] add that business modelling is a very important task and can bring a huge benefit on communicating the strategy as well as strategy definition and allow a more thorough analysis of the business. An example for a modelling notation that allows business modelling is BMM, which provides a metamodel for developing, communicating and managing business plans in an organised and systematic way. We performed case analyses of BI projects to understand how an alignment of the projects with the enterprise architecture was done and how the quality of that alignment impacted the success of the projects. We analyzed two real-world BI projects, a successful one and one that can be regarded as failed, based on project documentation, follow-up documents as well as interviews with involved people.
The goal is to identify which artefacts were generated during the projects and how well they supported the communication between the project’s stakeholders and hence the generation of business value.
The first case focuses on the development of a new BI system for multiple departments of a Swiss health insurance company. The scope of the project was to replace the existing manual reporting process with a flexible and easy-to-maintain BI system, thus minimizing the effort and at the same time the quality of reporting. In the initial phase, the relevant core processes were analysed and measurements were defined. Then, the company’s balanced scorecard was reviewed and KPIs were defined and specified, including the data sources, dimensions and periodicity. A busmatrix was defined as a documentation and guide for the subsequent implementation. Several changes to the initial requirements were necessary during the project, however, due to the close involvement of the senior management and their understanding of the technical implications, the impact of the changes could always be made visible to the sponsors. The system was accepted without restrictions and was made available to the users. Besides the initially defined project goals, the company experienced further advantages that were enabled by the use of the system.
The second case is about a rather big BI project carried out for the financial department of a transportation company. Since years, the company was relying on dozens of different reports, based on data gathered from various sources across departments, to steer its business activities and track its financials. The goal was to implement a standardised/harmonised, yet flexible and easy-to-use solution that would increase the transparency, efficiency and reporting functionality. After the requirements engineering phase, the solution architecture was defined and the project team started to work on the project according to the initial specification. Eventually, after two years, a completely new BI system was introduced that was implemented according to the initial specification. However, within weeks the newly developed system was withdrawn since the business strategy had changed and the previously defined KPIs and reports were no longer relevant.
Although both cases were initially aligned to the company’s goals by the use of balanced scorecards and KPI mapping tables, the way these tools were used was very different. While in the second case, the senior management was only involved during the initial phase of the requirements engineering, the involvement of the senior management in the first case was much closer, including a certain understanding of how the technical solutions supported the project goals.
In the second case, however, the senior management had no understanding of the technical relationships as they were not involved during the system’s design phase. Obviously, becoming familiar with the artefacts produced by the project team (bus matrix, KPI definitions) was too cumbersome for the management in this case. We hypothesise that artefacts with a significantly lower complexity might have increased the management’s commitment by reducing the communication barrier. Possibly, that would also have made it possible to understand the effect of potentially small changes in requirements to the overall BI.
The BI Project Model (BIPM) extends the already existing BMM with aspects relevant for modelling and aligning BI projects. This extension was implemented using the ADOxx meta-modelling platform1, but it should be easily transferable to other modelling environments. Figure 1 shows an extract of the BMM class diagram with the most relevant BMM classes colored in blue and the BIPM extensions colored in orange as well as the proposed relations between these classes. These additional classes were identified based on both the elements relevant for a BI system as well as the commonly used structure within a BI system suggested by the literature [14]. The class “Source System” represents a transactional system like a cash system or a production control system which are the systems that generate the data used for analysis. The “Fact” class represents the fact table where the relevant transactions of the executed business process are stored, based on Kimball’s dimensional design model [14].
The class “Dimension” represents a dimension in a BI data model which is necessary to provide a meaning for the analyses of the measures captured in the fact table and allow the measure to be put into a specific context. The “Metric” class represents a numerical value, which is stored in the fact table and can be used for 1 http://www.adoxx.org/live/home measurements. The “KPI” class represents a numerical value that is calculated based on one or several metrics and is used for measuring the achievement of an objective. Therefore, a KPI is very closely related to the “Objective” concept as well as the “Metric” concept and cannot only store a specific value but also target values or thresholds. The class “Report” could be used to visualize in which report which KPIs are used and can therefore be of help especially in follow-on projects to identify which reports are impacted when a KPI is changed. All these classes contain one or multiple attributes, like the name of the element or the containing data fields, which can be used to specify the purpose and the content of a class in more detail.
Since a major goal of the BIPM is the facilitation of the communication between stakeholders, especially between IT and business, a graphical representation of the meta-model was developed, which is easily understandable by both parties.
In order to facilitate the readability and clarity of the model, each class has its dedicated graphical representation, which makes it easier to understand, especially for people not familiar with BI projects, which elements are part of the BI project and how they are related to one another as well as to the company’s business model. Possible relations between the elements are visible in Figure 1 and examples of the relations can be found in Figure 3. The following table shows the different graphical representations as well as their meaning.
The modelling procedure for BIPM is visualized in Figure 2 by showing the steps necessary to create a BIPM from scratch.
According to Karagiannis & Kühn [15, p. 2] a modelling technique consists of two main components, the modelling language and the modelling procedure. They define the modelling procedure as a description of the necessary steps for applying the modelling language in order to create a result. The steps and their order of execution are based on both the logical order for creating a BIPM model as well as Kimball’s four-step dimensional design process [14, pp. 246–248] in a slightly adapted way.
The upper part of the picture shows the business motivation containing the company’s vision, strategy and goals. The lower part contains the BI project using the BIPM extension. Both parts are connected via the relation between the BMM’s “Objective” class and BIPM’s “KPI” class. This relation allows the modeler to specify, which objective of the company’s business model is supported by which KPI – the starting point of a top-down modelled BI project. By following the relations between the class instances, the data lineage can clearly be identified, from the KPI down to the involved source systems or vice-versa.
The goal of the evaluation was to evaluate whether the use of the BI project model as a modelling notation for BI projects would be helpful and whether it provides a significant benefit over the use of already existing and applied tools like the dimensional design model or the bus-matrix with regards to the communication aspect. This evaluation was done by remodeling a real-world case and conducting sets of interviews with several pairs of persons who are unfamiliar with the specific case. Each interview set contains two individual interviews with people having a similar educational and professional background, Table 2 presents a summary of the interview results: Questions Interview set 1 Interview set 2
Number of correct namings of metrics Steps performed to name the metrics Time needed to identify the table to add attributes to the insurant Correctly identified source systems Correctly named business processes relevant for the project Time needed for identifying the source system for comparing premium calculation data Total time needed to answer all the questions approx. 36 min without
BIPM approx. 13 min 0 of 2 0 of 5
2 min with
BIPM approx. 4 min 2 of 2 5 of 5 1 Less than 1 min 9 of 9 1 of 2 approx. 1 min approx. 22 min without
BIPM approx. 15 min 0 of 2 0 of 5 approx. 5 min 9 of 9 0 of 2 approx. 42 min with BIPM approx. 3 min 2 of 2 5 of 5 1 approx. 2 min 9 of 9 2 of 2 approx. 1 min approx. 19 min
Both interviewees had to answer several questions about the project – short versions of these questions are presented in the leftmost column of Table 2. These questions were chosen to cover important aspects from various layers – from strategic goals down to source systems – of a BI project. To help them find the answers, one of the interviewees was provided with the BI project model of the case and the other one with the traditional documentation. A total of two interview sets – four individual interviews - were conducted. From the summary of the interviews in Table 2, it becomes clear that the interviewees who answered the interview questions only with the help of a BIPM model were able to answer the questions in about half the time compared to the interviewees with the traditional information. Further, the answers were more accurate and they could identify several elements which were not identifiable at all using the traditional documentation. The interview partners with BIPM both agreed that such a model could be of great help as it is more easily understandable and is especially helpful when trying to identify the interdependencies between the elements. However, they suggested that the visual representation of the objects could still be enhanced.
The result of our research is a holistic modelling technique consisting of both a modelling notation as well as a modelling procedure to create graphical models of BI projects. A meta-model library was implemented using the ADOxx meta-modelling platform (www.adoxx.org) which allows the creation of specific BIPM models.
The evaluation, described in section 6, has shown that the BIPM models were clearly preferred by the interviewees and they were able to provide better answers to the questions in less time. Although the existing project documentation provided a more detailed insight into the project than the BIPM models did, the latter allowed the interviewees to get a clear and holistic picture of the project in a much shorter time and gain a better understanding of the main project elements. What they particularly liked in the BIPM models were the visible relations between the elements of the BI project as well as the relation to specific business objectives.
One can therefore conclude that in these cases the BIPM models provide a representation of the BI project which is easier and quicker to understand for people who are not closely involved in the project or who have little to time to get familiar with it. Given these results, and looking back at the findings about the failed BI project in Section 4, it is reasonable to assume that BIPM would be an important step in facilitating management understanding of BI projects and hence increase their commitment. This, in turn, will make it possible to avoid project failures as the one described in Section 4. In a further research step, the modelling technique should be evaluated during real BI projects.
Since the modelling-technique is neither industry nor technology specific, it can be assumed that it can also be applied in BI projects conducted in different industry sectors. This proof, however, has to be done in a subsequent research project.