To survive in today’s business a company has to continuously improve productivity and efficiency, while management and executives have to make decisions almost immediately to ensure competitiveness [3]. As we can use information to enable improved decision making and efficiency [2, 7], we use the possibilities provided by Business Intelligence (BI) to enable those activities [1]. However, inappropriate use or implementation of BI environment or strategies can lead to productivity and efficiency loss.
To avoid productivity and efficiency loss with your company, at least in BI field, I present several biggest mistakes companies and IT management make when applying or implementing Data Warehouse (DW) or BI solutions. This article is based on the communication with dozens of DW and BI domain experts from various European countries working for some the biggest companies.
The biggest mistake of them all: Modifying the source system architecture or structure to enable additional functionalities in DW or BI environment
Never change or modify the source systems application architecture for the purpose of making your Data Warehouse (DW) or Business Intelligence (BI) environment less changeable or invariable. This statement is supported by seminal figures and fathers of DW and BI as well, namely Bill Inmon [4] and Ralf Kimball [5]. BI environment, especially DW is the place and the tool which main purpose is to extract, clean, transform, load and deliver the data from source systems in wanted format for reporting purposes. Remember, this is not the purpose of the source systems. Source systems are there to support everyday business and NOT to support IT strategy of the company or immutability of DW.
Most of the less informed DW developers say that Inmon himself said a DW should be unchangeable, which is of course not true. Inmon says that the data, initially extracted from source systems in DW should be the same as in source system, not the DW architecture itself. DW architecture should be extendible and changeable according to the requirements of business systems and not vice versa, but only to be able to store historical data with all its properties. Those data should be than modified further for the purpose of reporting via data marts. Neither Inmon nor Kimball supports the idea to design, model or modify source systems according to the needs of reporting applications.
To illustrate the levity of such solution, we use real life example: You would never ask a milk production company to change their milk package properties (size and proportions) to be compatible with the shelf in your store or in your warehouse. Would you?!
The second one: Align BI or DW strategy on specific software
Never align IT or company strategy on the specific software. This is especially important when speaking about Business Intelligence or Data Warehousing. I’ve spoken with many BI / DW developers and architects from various European companies and many of them identified this as the biggest obstacle to deliver most optimal reporting solutions to their clients. As we all know, DW and BI tools can be very expensive and complex, and because of that, less informed management thinks they can do anything or the best path for their IT departments is to follow the strategy of the software itself. This is the one of the biggest mistakes the management can make.
Software, DW and BI focused as well, should be used as add-ons to achieve your company goals and to support everyday business, and not the actual strategy itself. IT department management very often forgets that the main reason of their existence is to support everyday business by applying technology and they should convey to business needs – not vice versa.
Several BI and DW domain experts, working for the biggest international companies, said that the after their management decided to follow the strategy of the software, their BI and DW teams grew to more than 100 people, while at the same time increasing the slowness of service delivery and incident responding time. Those situation lead to frustrations and dissatisfactions of the customers and key-users, including the people leaving the company as well.
To illustrate the problem: Would you build the roads in your country according to the specific requirements of only one car type, or would you prefer that cars are built conveying the general road standards?
The third: Negligent, unkempt and foul Business Intelligence Competency Centre (BICC)
BICC is a part of the company, which main aim is to leverage the BI investment and provide continuous improvement in performance management [6]. Gartner Research define it as a team of people, focused on BI, with specific tasks, roles and responsibilities working together established to promote collaboration across the organization. Almost every large corporation using BI or DW solutions has its own BICC. This is extremely positive practice; however, large number of domain experts working in BI or DW field think that the BICC at their company is negligent, unkempt and foul. Moreover, most of them think that BICC causes more frustration and takes too much time than it helps. The reasons are frivolous approach in centre coordination, inadequate or not relevant members, complex documenting requirements including those without specific purpose and not clearly identified contact or leading person. Some of the colleagues said it would be more optimal and more effective to work without such BICC – which is devastating fact. So, if you don’t intend to apply BICC at your organization seriously, it is better not to have it all, as it will consume resources and cause additional frustration without any real purpose.
Have a nice working week!
References:
[1.] Dedić, N. and Stanier C., 2016., “An Evaluation of the Challenges of Multilingualism in Data Warehouse Development” in 18th International Conference on Enterprise Information Systems – ICEIS 2016, p. 196.
[2.] Hannula, M. & Pirttimäki, V., 2003. Business intelligence empirical study on the top 50 Finnish companies. Journal of American Academy of Business, 2, pp.593–599.
[3.] Huff, A., 2013. Big Data II: Business Intelligence – Fleets Analyze Information from several sources to improve overall performance. Commercial Carrier Journal, (April), p.53.
[4.] Inmon, B.W., 2005. Building the Data Warehouse 4th ed., Indianapolis: John Wiley & Sons.
[5.] Kimball, R. et al., 2008. The Data Warehouse Lifecycle Toolkit 2nd ed., Indianapolis: John Wiley & Sons.
[6.] Oracle, 2012. Enabling Continuous Improvement in Performance Management. Publisher: Oracle Corporation, p. 4.
[7.] Yrjö-Koskinen, P., 1973. Johto – Tiedontarve – Tiedonhankinta. Miten informaatiopalvelu voi palvel la yrityksen johtoa? Publications of Insinöörijärjestö, No.77 – 73.