the doctor has asked “Has the time for one vision arrived?” The point of his post is contained in the last paragraph1, and boils down to whether “Best of Breed” solutions in the supply chain space are “good” or “bad” from an “integrated data” perspective.
It is certainly the case that there are a lot of software solutions that boil down to nothing more than a custom database fronted by a UI and a report writer. Such systems are rather easy to build; in theory, they can be built (as the doctor has pointed out in jest previously) using a VBA programmer and a Microsoft Access database. Jesting aside, home-brew solutions can exceed both the functionality and usability of so-called “enterprise” solutions. For example, Access-based 1990’s-era spend analysis leave-behinds from consulting organizations such as the old Mitchell Madison Group are still running in some large companies today, and, I daresay, are still superior to many current solutions.
Since there’s a pretty low technical bar to producing YAS (Yet Another Solution), there are grounds for hand-wringing when trying to keep track of them all, and of all the disparate data they are managing.But it really doesn’t matter whether a software product is built by in-house resources using Access and VBA, or by an international team of professional programmers using J2EE/Flex/Silverlight/Ajax/etc. and delivered via the browser, because the answer to the doctor’s question is simple:
Until there is a major, earthshaking change in the technology of database systems, the notion of an “integrated” enterprise-wide data store is pure fantasy.
Why? Because, as the post points out, “each data source [is using] a different coding and indexing scheme, [and] there is no common framework that connects the applications.” And that’s all she wrote, folks. You can’t store egg nogg in a fruit basket. It’s just not going to work.
Now, kudos to Coupa and others for “opening their API” (meaningful for programmers, not so much for ordinary humans) and so forth, but there is at present no way to integrate disparate, unrelated data into some centralized data store, without losing all the detail in the process. I don’t care if it’s all “spend” data, either. Slapping a label on something doesn’t make it homogeneous. I’m a bit of an expert on spend data, and I can assure you that spend data comes in all shapes and sizes and is certainly not homogeneous, whether you run an e-procurement system or you do not.2
And, of course, both old and new database vendors have been claiming for years to be able to integrate disparate data sources across the enterprise. Sure, if you want to join a few records across disparate databases that share common keys, there’s demo-ware that they can show you. It works great. But try a multi-way join across millions of records across disparate databases, and I’ll join you for a beer in the year 2025 when the query finishes.
So, I’ll steal the thunder from the “future post” mentioned by the doctor and jump right to the conclusion:
- Don’t worry about “integrating” data, because it’s not going to work the way you hope it will. At best, you will end up with inadequate compromises and uselessly generic data, like a design-by-committee spend cube that is shelf-ware after six months.
- Do worry about being able to move data easily in and out of the systems that you have. Don’t allow vendors to “lock up” your data; you should be able to change platforms easily, whenever you want to.
- Do worry about flexibility and adaptability in your analysis system. You should be able to operate it yourself, for example. If your data is locked up behind some SQL database that only IT drones can access, it isn’t doing you any good at all.
- Do worry about being able to move data from [anywhere] to your analysis system, quickly and easily.3
Let’s see what the doctor thinks, when he gets around to it.
1Apparently the doctor has never taken Journalism 101. But we can forgive him, since he doesn’t pretend to be a journalist.
2There are new ideas like “semantic database systems”; but a quick glance at recent history will show how well that works out in practice (Jason Busch over at Spend Matters, for example, made the mistake of drinking the semantic search Kool Aid with the now-defunct Spend Matters Navigator).
3Also, it’s important to clarify the notion that “real time” access to data is required for procurement decisions. No procurement decision needs to be made in real time. Is this a Hollywood science fiction movie where we need to dodge laser blasts from Tie fighters zooming in from all angles? No, it’s the real world, and decisions can and should be made thoughtfully and carefully. When the doctor says “real time,” I would hope that he means that there should be access to the data and answers to questions without waiting a week or a month for some analyst to write software.