Business Intelligence

Understanding the Value of Business Intelligence as a Service

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.

Day One

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.”

Takeaways

Treat 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.

Sonny Childs