Excel is pervasive in businesses, with a probably very low estimate of a couple of hundred million users around the world. Countless companies run some part of their reporting, analytics or planning systems using spreadsheets. For this good reason Excel is regarded as the most commonly used Business Intelligence tool, even if it’s single workbook workup. Still, horror stories abound about error-ridden spreadsheet data, from the “London whale” debacle to an influential paper by two Yale economists about debt-to-GDP ratios.
But this post is not about Excel’s failures, whether in stray spreadsheet mode or as a component within a Business Intelligence implementation. Because by now, with the right framework in place—for example, with Microsoft’s SharePoint Server 2013 or with an analytical database like PowerOLAP—there’s no reason not to use the everyday spreadsheet as an essential component in a B.I. rollout. That’s especially the case if Excel is the preferred front end for an intended user group, like the Finance team.
The subject here might better be described as making a complementary B.I. front end choice, and not becoming a victim to Excel’s many successes as a solution! After all, if spreadsheets are so commonly used, and can be utilized to great (and secure) effect, why not always default to Excel as a front end? Excel can make impressive charts and graphs; there’s the ability to capture data in Excel; and users can even perform “surface-layer calculations” using the product’s limitless bag of tools and tricks.
See Related: What is A ‘Depreciated’ Value in Excel
And then there’s the refrain, “everyone already uses Excel!” So why doesn’t everyone just get with the program and accept the spreadsheet as a default front end to a cracklin’ B.I. solution?
Well, the simplest answer is: because many users just don’t want to use Excel. And given the laudable objective of “self-service” BI, there’s really no reason why a firm should foist a User Interface upon users if it turns them off—or, worse, intimidates them. (For some people, Excel is like a foreign language: in the face of fluent “speakers” it can be scary to say “buenos días”.)
There are reasons—less emotional ones, we might say—for not using Excel. Arguably, specialized dashboard products are better at conveying quick and impressive visualizations of KPIs; and though it is a matter of opinion, such products may provide an easier way to create graphical representations of data than by operating Excel’s charting and graphing tools. Perceptions matter, and if dashboard product is perceived to be easier and more impactful, users will prefer it. As well, with more and more people expecting to manage their own charts and graphs via mobile devices, an Excel-only strategy seems far less likely to satisfy a wide user group.
Assume that your firm wants to satisfy both the Excel-centric and the worksheet-phobic: Does that condemn you to a less-than-optimal (or, worse, self-defeating) multi-vendor approach to Business Intelligence? Not at all! It should be possible to satisfy all your objectives and users—provided you have a strategy in place that can “make Business Intelligence better” by using technologies you may already own—like Excel, almost certainly, but also Tableau, QlikView, along with SQL Server, SAP HANA and other relational databases.
The key thing to determine is whether your platform can serve as a “connector” or “nexus” technology, to accommodate Excel and other B.I. front ends. You will want to be sure that what you select will be totally secure, i.e., ensure one version of the truth—no separate silos holding data for different uses or front end; and, that it can exceed address current Business Intelligence needs, as well as prepare you for next-phase requirements (maybe, beyond current KPI needs, you’re targeting an inventory forecasting application in future).
And most of all, your selection should keep all your users happy and very, very productive—whether they’re Excel jockeys, or faint at the thought of File, Open, XLSX.