Business Intelligence (BI) is Not a Technology – Here’s 5 Reasons Why

Individuals and organizations have developed a perspective over time that BI, reporting, and dashboards are technologies provided by MicroStrategy™, Cognos™, and others. When searching for resource capabilities for example, recruiters or managers often head straight to dice.com or similar sites to find the right people to support the effort.

The reality is the technical skill sets required are probably the last, and lowest level skill needed in order to make BI/reporting efforts successful.  The traditional tech-first approach ignores many ground truths of these types of efforts - which is why so many organizations derive little to no value from multi-year, multi-million dollar data warehouse and dashboard initiatives that when complete, only offer the foundational ability to start creating useful reporting. There are far more important ingredients organizations need to think about in order to drive real value from enterprise reporting. Here are 5:

1. Knowing what Questions to ask.
One of the most important skill sets required for BI success is business/organizational acumen and experience. What are you trying to accomplish? What are the relevant patterns of business? What is the domain of the areas of focus? The ability to form answers to these types of questions is far more important than how to map data to a chart widget or how to join database tables. Example: grants portfolio reporting illustrating grants by stage, org type, and focus area VERSUS all those dimensions relative to performance in order to drive changes in the portfolio to increase award impact and mission value.

2. Knowing what each data element means from a business/mission perspective.
Another important ingredient is the ability to rapidly assess different data elements, not just in terms of translating what they mean from a simple functional perspective, but the value and position of each element relative to the organization. Example: is the data an input or output relative to a particular business area or opportunity? Is it a categorizing dimension and if so, how important is it relative to similar dimensions in creating insight. Without an understanding of the data elements relative to the business, many report developers generate substantial ‘ok, so what?’ reports that actually increase the signal to noise ratio reporting is supposed to reduce.

3. Knowing how to visualize information at the right level for each audience.
The presentation of traditional reporting is often binary; table of data or pie/bar chart. That’s it. Little thought is put into structuring reporting to provide the right summary relative to the audience’s level, span of control, or interest within the organization. Also frequently missing is how information is presented together and in what order to tell the right story in a sequence that’s mentally consumable for the audience. Additionally, reporting is often left in whatever format the tool spits out instead of what best conveys the right information – how about an infographic of shrinking people shadows to illustrate reductions in manpower across years instead of a bar chart?

4. Knowing how to analyze the information and reporting.
An amazingly large number of reporting and dashboard efforts fail to include or embed any kind of analysis in the reports - pie chart is a pie chart; look at it and decide for yourself if these wedges are good or bad. Good BI/reporting embeds the analysis – “This trend is negative, if it continues this way X will happen”. Or even better, also embeds business rules that tell individuals automatically when thresholds are reached in the underlying data.

5. Knowing truly great reporting is iterative.
The most valuable reports and visual models are highly iterative. Not iterative for several weeks or months. Iterative forever. Good reports should evolve with the organization and if the reports are adding value, then different/deeper insight should be necessary for the reporting to continue to move the needle. Example: Budget versus execution reports to better manage contract burn rates VERSUS the next iteration that shows forecasted burn as well based on historic trending, and so on.

Summary
None of these 5 elements is truly technical, but they frequently represent the missing ingredients that weaken or ruin BI/reporting initiatives. Only after these non-technical elements of success are present, are the requisite technical skills even required. What do you think?