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