Do BI vendors know what they are talking about?

(Spoiler alert – Bill Gates does.)

Anyone with children or clients knows that the simplest questions can be hardest to answer. A couple of weeks ago an executive asked me to explain the difference between business intelligence and reports.

Her very words were … I thought business intelligence was just reports. The team want me to use more dashboards – and they want the budget to build them. But on the vendor’s website they are still talking about reports. What’s going on?

I’ll walk you through a sort of answer but I am not trying to package up market segments, or define clear categories of products and features. The world is messier than that, and I am tired of taxonomies. These are just rough guides that I use day-to-day in the field.

Let’s start with reports.


A report is really just a formatted retelling of the data related to a given subject. More often than not, the scope of that subject is defined by the data available in a single system. Thus, applications like Salesforce or Microsoft Dynamics will offer a ton of reports on different topics within Salesforce or Dynamics. Yet, however nicely or badly formatted, they remain just statements of the appropriate data, with little or no reframing. The Campaign Leads Report lists the leads for a campaign. Much reporting is as straightforward as that, and no less useful for it. In fact, it’s astonishing – and disgraceful – how many managers still lack basic operational reporting.

Meanwhile, some report users and vendors get their knickers in a twist about reports being “pixel-perfect.” Why? Oh who knows, but it’s often because they want to print out the results and keep them in a binder as a kind of mid-century symbol of a job well done. Or because they have spent so much time getting that tabulation just right that they can’t bear for the reporting software not to support their efforts. I am sure TPS reports were pixel-perfect.

From reports to BI

Business Intelligence tools evolved to do more than just restate the data in your application with a fancier format. Most importantly, BI tools enable users to build composite, interactive front-ends which may include visualizations, tabular views and a wide range of filtering and browsing options. At this point, you can start to explore data; the user experience of the tool – in so far as the designers have done their job – should be optimized for this, with navigation and analytic features.

Behind the interface, we typically build BI applications over data which has been integrated and aggregated in quite sophisticated ways. As a result, BI affords a more thoughtful understanding of the state of your business – more intelligence as the military would say – that can be very valuable.

I’ll blog more in the future about what I look for in a BI tool, in particular the framework I use for assessing their support for exploring, browsing, or as it may be called, information foraging.

Confusing the user

Do remember that I am not drawing clear lines here. Some reports are more interactive than others. Some would-be BI applications offer sadly limited opportunities for exploration. Don’t fret about it. If we visit some vendor websites, they will helpfully make it clear for us. If only …

In Microsoft PowerBI, a dashboard is a page often called a canvas (that’s three names for the same thing) that uses visualizations also called visuals which are called tiles (another three names) when in used in a dashboard-page-canvas. These visualizations-visuals-tiles are pinned from reports, which can be created from scratch or imported from a dashboard-page-canvas.

I hope that’s clear because it gets a little confusing when you realize that by reports they don’t mean Reports. At least they don’t mean reports built using Reporting Services. That would be silly.

Actually, I am being unfair to my former team. You can pin some things from a Reporting Services report to a PowerBI dashboard-page-canvas: you can pin a report item. Report items, for the record, are parts of a report. But not all parts of a report. And they are not Report Parts which are report items which have been published to a Report Server where they can become parts of other reports.

Reporting to Bill Gates

I never did. Report to Bill Gates, that is. I wasn’t that smart. But I did take part in product and business reviews where we ran through prototypes with him. Bill always wanted more interactive insights than Microsoft tools of the day offered and he was frustrated that we had so many reporting tools and different access points to the technologies. During one meeting he asked the meeting to enumerate the different ways of building a report in the Microsoft stack – bringing the inconsistencies home to us.

First in our minds (I worked in SQL Server) was Reporting Services, we had reports in Access, and there a Business Scorecard Manager at that point, as I remember. After we had listed 5 or 6 different technologies, Bill asked, “But what about when I build a report in Excel?”

We were well aware that Excel is used for everything from storing data to drawing computer art, so even the Excel product managers in the room pushed that one aside. People do anything in Excel, so it’s not really reporting, users just call it that. Bill insisted that Reports were a feature in Excel. So we had to open the application on a handy machine. How do I make a pivot table? Go to the menu, create a new one and there it is …


Spreading the blame

To be fair, other vendors have the same problem of trying to describe a range of business use cases addressed by their platforms. Microsoft has numerous products, developed over many years, and names and labels evolve and change sometimes faster than the technologies. Other megavendors – Oracle, IBM and SAP are no better. Tableau objects are visualizations-vizzes-dashboards-reports depending on what you are reading.

At Qlik, when I worked there after Microsoft, we in the product team were clear that the artifacts users created in Qlik Sense Desktop are apps. but according to marketing, you can use Qlik Sense to create personalized, interactive data visualizations, reports and dashboards. And Qlik has a separate reporting application called NPrinting. The secret is in the name – it’s all about printing and, yes, it’s pixel-perfect. You can imagine my enthusiasm.

Some bright notes

Many of the issues I have described here are the result of the very flexibility that BI vendors often reach for in their products. But the confusion also arises because BI developers and analysts tend to use their application of choice for many different use cases.

Newer vendors – or vendors who radically redesign their applications – have an opportunity to do things differently, at first. We were clear at Qlik that users build apps.

Vendors such as Domo and YellowFin sometimes have a similar confusion of terms, but their user experiences have carefully differentiated workflows for various use cases. ClearStory are appropriately very clear that they build stories as their analytic artifact.

As I said I will blog soon about the user behaviors in analytics. I think these behaviors are more important than market categories or vendors’ own labels when distinguishing products.

For now, I hope you realize why I am not trying to draw clear boundaries between tools!


  1. Fred Kaffenberger - Reply

    Overdetermined terms. It reminds me of getting an anonymous rose on Valentine’s day one year, with an invitation to discuss Milton. I was taking a Milton class and teaching Milton at the same time. Turns out, it was someone from the computer lab with whom I had commiserated. App is another overdetermined term. What’s an app in Power BI?

  2. Scott D Epter - Reply

    Nice, entertaining (as always) and meaningful piece. Looking forward to your piece on user behaviors. No matter what we vendors say and do the only thing that matters is whether we are making our user’s lives better…easier, more productive, more efficient…whatever it is they need to be successful.

  3. Robert Rose - Reply

    Great article. I have found that many BI vendors have deliberately kept their definitions er, fuzzy to fit more buying and selling situations than they are ideally suited for. Much of it might be that buyers could be anywhere along thew maturity curve for using analytical technologies and many are still at the earliest stages.

  4. Onno van Knotsenburg - Reply

    Even though the vendor calls it a spreadsheet, a visualization, an app, a dashboard or whatever…. if at the end the day the customer wants “a report”, a vendor at some point will just give up and (also) call it a report. Later in the process the vendor might consider trying to convince the customer to call it what the vendor had in mind… if it is really worth the trouble.

Leave a Reply