I’m always amused when I run across new marketing-speak for old ideas, but the “Web 2.0″ meme has some interesting applicability to spend analysis. Web 2.0 refers to the evolution of the Web from a static content-delivery mechanism into a higher-value interactive medium – and spend analysis needs to make the same transition.
But, more on this later. As with any story, we begin at the beginning.
I. Spend Analysis Today
Spend Analysis (SA) starts with the aggregation of error-corrected and enhanced spend data into a useful data display framework. This entails:
- Collecting data from multiple accounting systems or other sources (such as pcard systems, PO systems, insurance claims systems, and T&E systems).
- Correcting the data through a process of classifying spend by sourceable commodity. Besides direct materials, sourceable commodities might include categories such as contract labor, office supplies, computing equipment, commercial print, and so on.
- Loading the data into a useful data display framework. Such frameworks should be based on advanced database systems capable of OLAP (On Line Analytical Processing), as opposed to ordinary relational database systems. Although functional SA systems have been created with relational databases, there are basic technical reasons why they cannot scale to multiple millions of transactions and maintain acceptable response times. Many “home grown” SA systems have failed because the early promise of relational processing and relational reporting bogs down exponentially as datasets expand.
SA systems are not “Business Intelligence” systems. For SA, it’s necessary to re-classify spending data, and to build data dimensions that support purchasing and sourcing, as opposed to the very different data organizations that support corporate accounting. SA systems must also consider data feeds that are separate from and/or additive to the accounting or ERP system. For these two reasons, spend analysis systems don’t tie directly into accounting or ERP systems as BI systems usually do; in fact, such a connection would be a mistake. And, as a corollary, ERP systems are not capable of spend analysis, either.
Simplistically, an SA system might consist of a commercial OLAP system (such as Hyperion’s Essbase, Microsoft’s SQL Server, or SAP’s Business Warehouse) together with expertise sufficient to (1) collect and aggregate data from multiple sources, (2) classify the data into sourceable commodities, and (3) load the data into the OLAP system such that it can be viewed. This simplistic view, in fact, accurately characterizes many of the SA systems currently on the market today.
Unfortunately, the concrete nature of a commercial OLAP system and viewer does not usually extend to the “soft” processes of loading and classifying data. Those processes are typically handled with external manual resources (offshore resources in many cases), augmented by whatever automation can be brought to bear. Typical SA systems have therefore become an amalgam of “product” and “service,” where the SA supplier is retained on a long-term basis to update data and change dimensions and mappings on behalf of the customer. The SA “system” is therefore an odd mix of software and consulting services, with a built-in dependence on the vendor to make changes. Ironically, this means most spend analysis systems are the literal definition of “Software as a Service” – they are mostly Service, not Software.
Equally unfortunately, the typical SA system tends to suffer from Stephen Potter’s “so what” diathesis – i.e., once the data have been loaded into a drillable OLAP viewer, and the obvious low-hanging fruit has been picked, it is not obvious how to use the system to drive long-term and consistent value – for example, to track the progress of initiatives, contracts, and compliance, or to drive generic business models of more significant scope. It’s therefore not uncommon for SA customers to derive steeply diminishing returns from their original SA investment, rather than leveraging that investment to maintain focus and control, and to uncover additional savings.
Tomorrow: Data, Data, Everywhere