BUSINESS INTELLIGENCE: A PROCESS, NOT A PROJECT
By Sonny Childs, business intelligence practice lead, IronEdge
Reality check: Business intelligence initiatives fail most of the time. Whether that’s back-end infrastructure or front-end visualizations, industry analysts show bleak stats on whether or not your project will be valuable and integrated into a company’s processes. Our practice focuses on offering Business Intelligence-as-a-Service (BIaaS), and we are often asked why we do this rather than the traditional professional services single-project model. The following story speaks to a would-be business intelligence creator and illustrates why BI projects frankly shouldn’t be projects at all. Successful business intelligence initiatives are an ongoing process that become intimately integrated with clear channels of communication and consistently cultivated to prune noisy fluff and grow actionable insights. Let’s walk through the beginning of a hypothetical story of how one project turned into a process out of necessity.
The executives submitted a request for the report. The business analyst starts with some preliminary questions about what information the report will show and what calculations and source data are needed to show it. The data analysts dig through databases and spreadsheets. They put together some huge blocks of SQL and write a fair amount of DAX and maybe even some M. The business analyst probably has multiple meetings with executives and management in order to understand fully what they want to see. The visualization team spends time tweaking fonts and colors and deciding whether to use that new visualization or feature. The business analyst meets with the executive team to show them the report. The executives are shown how they can click here, see this, click there, see that. The executives give praise and ask for clarification on some things, giving the analysts the chance to show off their knowledge on how the report works. The executives say things such as, “This is extremely useful!” Then everyone leaves that meeting and goes back to working on that other thing, whatever it is.
One Month Later
If the analysts have report usage metrics in place, they might check on how popular the report is. They find that one or two executives are accessing it once or twice a week. Good enough, they might say. At least someone is getting some value out of it. If they don’t have report usage metrics, the business analyst might ask a manager who seemed particularly enthusiastic only to receive a lukewarm response asserting that it’s useful, and they’re definitely going to use it … eventually.
Three Months Later
The report usage metrics show executives and managers rarely access the report. The data analysts see that the scheduled refresh stopped three weeks ago because of a data type error. The business analyst asks the VP of sales what “sales hit ratio” means. Unfortunately, the VP describes a calculation that is wildly different from what is being shown in the report. The analysts check the report, and everything at least seems to be working, except the map illustrating regional supply chain heatmaps is completely broken and displays a blinking exclamation point, waiting for someone who cares to address the issue.
Business intelligence initiatives fail most of the time. Whether that’s back-end infrastructure or front-end visualizations, industry analysts show bleak stats on whether or not your project will be valuable and integrated into a company’s processes.”
What Went Wrong?
The business analysts asked the executive team what they wanted to see on the report. The data analysts found exactly where all the data lives and identified every table and document required to answer the business questions. The SQL is clean, well formatted, and even includes some handy comments for in-line documentation in case someone else wants to contribute. The report shows exactly what the executive team asked for, too. Unfortunately, that might actually be why no one is using it. At this point, there is a potent combination of stale, shallow ideas, as well as a lack of maintenance on the data and infrastructure used for the report. These problems alone are “report killers,” so let’s take a look at how to identify and guard against these issues.
I Am On A Crusade Against Vanity Metrics
Business intelligence is about turning data into prescriptive, actionable, and valuable information. The process of creating this actionable information typically takes many learning cycles and starts with what I refer to as “vanity metrics.” Vanity metrics are usually technically correct and might make you feel good when you look at them but unfortunately only serve that purpose. At the beginning of a business intelligence initiative, you might create many of these metrics in order to verify your data quality and accuracy of measures; however, once those measures are shown to be accurate, these metrics should immediately become part of a more interesting story. For example, you might have a chart showing revenue by client for this fiscal year. You might be able to prescribe some actions based on this, such as how often you should communicate with that client, but looking at total revenue doesn’t really tell the whole story. From there, you might start calculating cost of goods sold and other ancillary costs associated with supporting and doing business with that client and apply margin estimates. Some business owners are surprised to find that their clients doing the most revenue can have razor-thin margins that put them below other smaller clients from a profitability standpoint. You might start looking at the seasonality of that revenue and understand that a particular client or clients do the vast majority of their business in the summer, which can allow you to schedule business reviews at a time where they’re starting their yearly budgeting, so you can be first on the list of considerations. Learning cycles are the most important concept in a business intelligence initiative, and you must turn what you’ve learned into new, more valuable insights that you can immediately expose to the people who have the power — and responsibility — to take action on those insights. Once you’ve determined that you can accurately measure key business facts across various business dimensions, you have to start creating and evaluating business measures. Business facts are your basic event or occurrence, such as an invoice, support ticket, or server log. Business dimensions describe these facts:
- Who created that invoice
- When was it paid
- Which client was invoiced
- Who was the salesman that generated the initial quote?
“The SQL is clean, well formatted, and even includes some handy comments for in-line documentation in case someone else wants to contribute. The report shows exactly what the executive team asked for, too. Unfortunately, that might actually be why no one is using it.”
Business measures are derived from qualitative and quantitative data across these concepts. Good examples of basic business measures are margins, SLAs, and hardware/machinery durability and performance ratings. Once you start to define and agree on basic measures, construct more complex measures that take into account multiple simple measures. For example, your company might create a rating scale for your clients that takes into account their average monthly revenue and costs, how complex they are, and their risk of defection, among other considerations. These ratings must be integrated into your processes to make them prescriptive. For example, a particular client rating might warrant a set amount of scheduled business reviews, phone calls, or other account management actions within a calendar year to combat potential attrition. You can then measure whether your processes are being followed and adjust accordingly. Once you begin to roll these measures up into easy-to- understand and actionable information, you have to reapply this new information to your business processes and ensure everyone who is consuming this information is aware of how to interpret and take action from the information.
Let’s go back to our hypothetical project and see what it looks like when it is treated as an ongoing process.
BI is a Process
The analysts now continually strive to keep data and infrastructure stable, clean, and accurate. The business analysts are learning from the executive team and interrogating them to determine which visualizations are intuitive and actionable, and they are pruning everything else. When VPs see that a particular company is below projected revenue for the quarter, they understand that they are required to get a business review scheduled with their point of contact to go over some recommended infrastructure updates. Executives and management understand that anything in bright red is actionable, and they’ve integrated these prescriptive KPIs into critical business processes. The analysts will then analyze the results of these actions and further refine the data to drive real, tangible business value to the executive team.
Business intelligence should be a focused lens showing the executive team where to take their next steps. Business intelligence lenses will start out blurry, and the process of getting it — and keeping it — in focus is continuous. Many executives are running blind, relying more on intuition than data. If someone is handed blurry glasses, they might reject those and go back to what was adequate before: feeling carefully around in the dark. Process-based business intelligence continually focuses that lens in order for the company to take on a culture of making confident decisions based not on instinct, but actionable analytics.
“Many executives are running blind, relying more on intuition than data. If someone is handed blurry glasses, they might reject those and go back to what was adequate before: feeling carefully around in the dark.”
TakeawaysTreat business intelligence initiatives as an ongoing process, not a single project.
Data, infrastructure, and definitions of metrics and KPIs change. Empower your team to adapt to this.
Work with your business analysts to get to the essence of the questions you’re asking.
Always be willing to prescribe an action that must be taken when specific KPIs are breached.