The accounting or ERP system is not the only source of useful spending data in the enterprise. There are many other datasets with stories to tell. Here are just a few:
- Insurance claims systems
- Purchasing card feeds
- T&E data
- Fleet vehicle records
- Cell phone usage records
- Invoice-level detail by vendor, by commodity
And that’s just on the cost side – why should analysis systems restrict themselves to spend data? How about:
- Sales information
- A/R data (should we beat up a vendor who is also our best customer?)
- Credit and collections data
- Subscriber billing information
- Call center analysis
How can all these disparate and rich datasets be brought into one over-arching “spend analysis” dataset? Often they can’t; and that means we need multiple datasets, and the flexibility to create them as needed. Which brings us to the first two guiding principles of Web 2.0 Spend Analysis:
- New analysis datasets should be easy and fast to build, by ordinary business users, at no incremental cost;
- Spend analysis systems should support multiple datasets simultaneously, enabling multiple users to investigate arbitrary and unrelated topics, also at no incremental cost.
Why at no incremental cost? Because if there’s cost associated with the project, the project won’t get done. The “what if” analysis that could have found a jackpot of savings won’t get done. The cleanup of a messy ancillary dataset will never happen. And so on.
Why do ordinary business users need to be able to build new datasets? Because if they have to ask someone else to do it (IT, or specially-trained internal resources, or the spend analysis vendor), it won’t get done, or it will get done incorrectly. And, if someone else has to do the work, then there is incremental cost, and we’re back to square one — trying to justify an expensive initiative to higher-ups.
Of course, enterprises often grow by acquisition, and may have a number of active accounting systems under the same corporate umbrella. Achieving a coherent view of spending across these disparate systems can lead to impressive savings – not just the incremental savings that result from achieving higher discount levels with vendors, but shifting of spending onto existing contracts that may be far superior at one division than at another. Such disparities are apparent when spend data are consolidated, and the savings are both zero-effort and immediate.
So, of course it is useful to have a overarching view of spend, which may involve millions or tens of millions of transactions. Which brings us to the next guiding principle of Web 2.0 Spend Analysis:
- Not only should the spend analysis system be agile enough to support multiple datasets, it must also be powerful enough to support single datasets as large as 50 or 100 million transactions, with acceptable performance.
Tomorrow: How clean is clean?