By Miguel López, BI Practice Manager at Fusionworks
For some time now I have been thinking that I should write something about the Business Intelligence practice or BI, after working in it for 22 years and more than 12 years as a consultant providing service to many of the most important businesses in Puerto Rico in a diversity of industries. In all this time I have been able to understand well what BI is, or better yet, I have been able to really understand what it is not. Although many think otherwise, BI in its essence has not changed much since its origins. The definition of BI from the functional perspective continues to refer to “a variety of technologies and practices that help you transform and store information of business processes to monitor business strategies and decision making” (Some references: //searchbusinessanalytics.techtarget.com/, //en.wikipedia.org/wiki/Business_intelligence). The success of BI in companies will depend on how close the initiatives related to this definition are. I would say that we are not close to the definition if we remain using BI tools to solve transactional and/ or process deficiencies that should be resolved with other solutions. On the other hand, if we use the information to measure and analyze strategies that lead to business growth, then BI will be of great benefit and will add value to the company. For this reason, experience has led me to identify situations that are not real in BI and therefore are not good practices in its implementation.
Let’s say, some myths within Business Intelligence:
The first myth is to think that IT or the systems area owns BI. One of the keys to success for a BI strategy is that the business areas are responsible for them. The business is the one that provides the measure of the initiatives that impact a strategic plan. Technology divisions should be information facilitators. They should remain updated in the best practice as to how to store information and have it ready for the business’ needs. Typically, the technology area thinks about making available to the functional user the best BI technical tool for them to develop their own reports. And this has to be done, but it is not what drives a good BI practice. It all starts with the business strategies that need to be measured to make decisions. Then come the tools to manage the information linked to these strategies. For BI, what comes first data or strategy? The correct response should be strategy.
The definition of “project” refers to a set of tasks that have a beginning and an end to achieve an objective. Many businesses see BI as a “reporting” or “dashboard” project that begins with knowing what data reports have and ends when they are developed and delivered. I agree with having a plan for a BI strategy, but it should not be guided by the creation of reports but by the ability to make decisions and take action based on the results of the reports. The truth is that creating reports is the least complicated part and should not take a lot of time if everyone knows the business strategy that has to be measured. Definitely, thinking about BI as a project is another myth, it should be seen as a culture or a way of life. A concept that adapts as companies grow.
For the last years, we have been hearing the concept of self-service within the BI practice. This assumes that business users can have access to any data structure to create their own reports and analysis without a lot of knowledge in programming and very little intervention form technical staff. It is in this assumption that lies the problem. For many businesses that sell software this is the way they market it, but in the functional reality, this is one of the biggest myths. I dare say that in 99.9% of the cases that we give BI tools to functional users, they become experts in all the tricks the tool provides to create reports, but they are not able to have that same information available in a reliable and recurrent manner so that those responsible for business strategies can make assertive decisions. The above is a typical example where the systems area creates a data bank without following functional requirements, then the business connects to them to solve data transformation, integration and relation problems before creating reports. Another classic situation is to use 80% of the time to develop a report and 20 % to analyze it and make decisions.
“One size fits all”
We have seen pieces of clothing that in their size say “one size fits all”. That is not entirely true, (on some it will be too big and on others, it may not fit at all) there is always someone on who it will be too big or too small. Well, that is another myth about BI. There is no single solution for all information needs. In fact, information coming from the same operational process can be viewed from different optics of the business. For example, sales information can be viewed from the financial perspective, customer service, purchase process, inventory among others. In most businesses, the reality is that there is one single table to solve all business perspectives. My recommendation is to know the requirement of each process or strategy that needs to be measured and then develop data structures according to need. There is nothing wrong about creating different versions of the same information. This should be the norm in the development of Data Warehouses-DW. DW cannot be seen as a “One size fits all” solution, but as the sum of the parts that cover the business processes on which strategic decisions are made. Many expressions that are said related to this are: “We have more than enough data”, “set all the fields”, “can I have a button that shows all?”, “can we use Excel?”, this last one is a LOL.
Having historical information not only refers to how far back we have data stored and available for analysis, but also to the version of the information at different points in time. Maybe during time, a process has changed the classification of products, clients, and business segments among others. What happens if we want to see the information classified according to the historical moment in which the transactions happened and not the current classification? Current data is the present state of the classification of events, while historical data is like saving photos at the time of the classification of events. That’s the real difference between actual vs. historical data. This definition of historical data is one of the main characteristics that define data warehouse under the best practices. To turn the myth of historical data into something real you need to have the concept clear and know the techniques of how to create historical data to take them to a data warehouse.
There are other articles about the myths of BI based on personal experiences. This is my experience and I am sure that many can identify with this. But I am also sure that a good BI practice adds value to companies because it transforms them into strategic companies where what can be measured is done, otherwise it is not done. At Fusionworks we can help you implement Business Intelligence in your business. Contact us!