Why Spend Analysis Frustrates Those Who Need It Most

Within most organizations there are three groups of consumers for spend analysis data:

• Group I: those interested primarily in reports;
• Group II: those who drill around a spend dataset, occasionally, to explore specific areas of interest, or to track down individual payments;
• Group III: power users who are using the spend data to locate, drive, and monitor the next level of savings initiatives — initiatives that are aimed past low-hanging fruit that has already been harvested.

Satisfying all three of these groups is beyond the reach of most of the current generation of spend analysis products. The essential problem is that they can't decide whether they're a data warehouse or a data analytics product. It's not possible for them to be both, and putting the word "analysis" in the product name doesn't make it so. A data analytics product has to be able to change data, hierarchies, and rules, instantly and easily, on the fly, to support whatever analysis is required right now. Contrariwise, a data warehouse cannot change frequently. It has to remain static for weeks, if not months. Data warehouse-based analyses therefore have to be done with whatever data structure was in place when the warehouse was published. Most of the time, that structure is either useless (a committee decision, for example), inappropriate for the analysis at hand, or obsolete. That's why the concept of using a data warehouse to do data analytics is flawed. Imagine a spreadsheet whose structure cannot be changed — how is this helpful?

Which is why the target user for spend analysis vendors has always been the Group II user. It's relatively easy to construct a data warehouse that can be used to answer questions that don't deviate from a pre-defined structure. But what about the other consumers of spend data, and all the other questions? Attempts have been made to build suites of static reports to satisfy the Group I users, but static reports are flawed from the beginning, simply because they are static. Everyone is acquainted with a report that doesn't do "quite" what one wants, or a report that rolls up the wrong way, or provides totals that have to be imported into another tool (perhaps manually transcribed, even) in order to derive meaningful numbers. It's not possible to point a standard reporting package at an OLAP database and expect anything but hours-long delays, because relational reporting systems simply don't work on voluminous datasets. A reporting facility has to be adaptable to dataset changes and requirements changes, and it also must leverage OLAP power to generate its results -- without requiring its users to be IT experts. Custom reports from the vendor are typically the only "solution" — an expensive and frustrating one, to be sure.

Of course, Group III power users are usually the first to realize that the spend analysis system hasn't provided much value. It becomes apparent within days that fixed hierarchies and fixed dimensions are of little use for ad hoc analysis. This group's response, because they are more proficient with data manipulation than other consumers, is to work around the tool by downloading raw transactions from the warehouse directly onto their desktops. Then they hack at those transactions with Access and Excel in the same way that they've always done. The value of the spend analysis package to them is minimal -- it is merely a cleansed transaction store.

At the end of the day, then, what is the look-back on a spend analysis project? Typically an enormous expenditure has been undertaken; a spend dataset has been made generally available, with great effort; but the static reports generated from the system are considered only marginally useful, and power users ignore the system completely. True, a handful of Group II users access the system from time to time, to answer specific questions -- but most of those questions could probably have been answered without it.

The result is deep frustration across the organization, and a continued dependence on inadequate and painful manual processes for locating and tracking spend initiatives.

We think BIQ solves this frustration elegantly and inexpensively, and we invite you to explore the rest of this site for some of the reasons why. BIQ can be both a warehouse and an analysis platform, and it can be deployed on individual PC's, or on servers -- at the same low price.