A oft-repeated benefit of data warehouses in general, and spend analysis systems specifically, is the promise of “a single version of truth.” The argument goes like this: in order to take action on any savings initiative, company stakeholders must first agree on the structure and organization of the data. Then and only then can real progress be made.
The problem, of course, is that truth is slippery when it comes to spend data. What, for example, is “tail spend”? Even pundits can’t agree. Should IT labor be mapped to Professional Services, HR, or Technology? For that matter, what should a Commodity structure look like in the first place? Can anyone agree on a Cost Center hierarchy, when there are different versions of the org chart due to acquisitions, dotted-line responsibilities, and other (necessary) inconsistencies?
What tends to happen is that the “single version of truth” ends up being driven by a set of committee decisions, resulting in generic spending data that is much less useful than it could be. Spend analysts uncover opportunities by creating new data relationships to drive insights, not by running displays or reports against static data. So, when the time comes to propose savings initiatives, the very system that’s supposed to support decision-making is less useful than it should be; or worst-case, not useful at all.
Questions and Answers: Metadata
Do we have preferred vendors? Do buyers and stakeholders agree on which vendors are preferred? What vendors are “untouchable” because of long-term contracts or other entanglements? For that matter, with which vendors do we actually have contracts, and what do we mean by “contract”? Are there policies that mandate against a particular savings initiative, such as lack of centralized control over laser printer procurement, or the absence of a policy on buying service contracts? Can we identify and annotate opportunities and non-opportunities, by vendor or by Commodity?
The answers to these (and many other) questions produce “metadata” that needs to be combined with spend data in order to inform the next steps in a savings program. The nature of this metadata is that it’s almost certainly inaccurate when first entered. We’ll need to modify it, pretty much continually, as we learn more; for example, finding out that although John may have dealt with Vendor X and has correctly indicated that he’s dealt with them, it’s actually Carol who owns the relationship. We may also determine that the Commodity mapping isn’t helpful; network wiring, for example, might need to belong with IT, not Facilities.
As we add more and more metadata to the system — information that is critical to driving a savings program — we encounter the need to refine and reorganize data to reflect new insights and new information. Data organization is often quite purpose-specific, so multiple different versions of the data must be able to be spawned quickly and coexist without issues. This requires an agile system with completely different characteristics than a centralized system with an inflexible structure and a large audience. In essence, one must learn to become comfortable with alternative truths, because they are essential to the analysis process.
So what happens to the centralized spend analysis system, proudly trotted out to multiple users, with its “single version of truth?” Well, it chugs along in the background, making its committee members happy. Meanwhile, the real work of spend analysis must be (and is) done elsewhere.