-
-
Marketplace
-
Channel Resources
Articles from this Site
-
One brand, one Web site! DM Review is now the home of all the content you're used to at BIReview.com and much more. If you are registered at BIReview.com, you're already registered at DM Review. If not, take just a moment to sign up for all the free services we have for you at the new DMReview.com.
Single Truth, Multiple Versions
"We want one version of the truth." It sounds like an obvious and reasonable request, one that anyone involved in business intelligence hears often. In order to understand and manage their businesses, managers want one answer to the key questions about business attributes and performance indicators. Yet it's confusing and even dispiriting when an executive asks seemingly simple questions such as, "Exactly how many employees do we have now?" or "What were sales through our distributors last quarter?" and receives different answers to those questions from each person asked. It can be maddening to managers to have such a straightforward desire frustrated for so many years.
The difficulty of making "one version of the truth" happen in large organizations might suggest that there are some complexities behind the request, and indeed, there are. The appealing notion of common information elements being measured in the same way is both difficult and not always positive. There are valid reasons why different parts of organizations create their own versions of the truth, which should be understood before one version can be achieved-assuming that it's still a desirable goal.
To explain this phenomenon, let's start with what I call "Davenport's Law of Common Information." This profound observation, which I am sure will win me the Nobel Prize in information management as soon as that category of prize is established, goes like this:
The more an organization knows or cares about a particular information entity in its business, the less likely it is to agree on a common term and meaning for it.
I discovered this law several years ago, when someone at American Airlines told me she had found 11 different internal meanings of the term "airport." Maintenance people thought that any place you could fix an airplane was an airport; cargo people thought that any place you could pick up or drop off cargo was an airport, and so forth. Each use was valid, but if someone asked, "How many airports are there?" it would be difficult to get one version of the truth.
I have since found a number of confirmations of Davenport's Law. A few weeks after my American experience I visited Union Pacific, where the railroad people told me they had difficulty agreeing on what constitutes a train. For some, it is an abstract scheduling entity; others say it is the locomotive. Still others believe it is the locomotive with all the cars that happened to be attached at the time.
You can imagine the number of domains in which versions of truth can multiply. In fact, a corollary of Davenport's Law suggests that if an organization doesn't have arguments about what constitutes, for example, a customer, then it really doesn't care about customers very much. Most organizations do have such arguments, and they are certainly valid. Some organizations view individuals as customers, some think only about organizations. Some organizations view prospects as customers, some don't. There's no right or wrong answer.
It often makes sense for different parts of the organization to have different versions of key information entities. A high-tech firm with which I once worked had one division that sold directly to customers and another that sold through distributors. The direct-to-customer business defined a "sale" as when a customer took delivery, and the indirect sales organization declared "sold" when the distributor took possession - even though sometimes the product came back from distributors. When more sales were going direct, that division's definition tended to prevail at the enterprise level, and vice versa when indirect sales were the lion's share. But there was almost always confusion and at least two versions of the truth.
Creating one version is problematic, too. If there is only one meaning for key information entities, some people in the organization are going to lack information about key aspects of their business. At the high-tech firm, either the direct or indirect business would not be able to measure what they were doing in the way they liked. "Common" information often means "lowest common denominator" information.
So what should organizations do about this conundrum? The nature of the problem suggests aspects of a solution. First, don't insist on one version of the truth everywhere. Since it's difficult to create such a situation, and since there are negative aspects to it, firms should only aspire to "one version" where it's absolutely necessary to have common enterprise information. This is likely to be true for externally reported entities, such as "revenues" or "profits" if you work for a publicly-held company and your senior executives want to stay out of jail. Common information around customers, at least for those who buy across the enterprise, is also a good bet. What this amounts to is a "federalist" information model, in which some information is controlled by the enterprise, and most is left to the "states" or business functions and units.
Companies have traditionally dealt with the creation of common information through data architecture, in which a group of technical specialists decide which information should be common and how data and applications should interact to create it. Yet the key constituents of common information are not technologists, they are businesspeople. They are the ones who suffer and prosper based on the information entities they can use in their business, so they should be involved. If the key information issues aren't totally obfuscated by technical detail, managers are likely to engage with passion. Instead of data architecture, "data arguing" is the desired approach.
The goal of these discussions should be to create a set of principles for how information will be managed across the organization, rather than a detailed technical architecture. One principle around commonality might state, "All information entities are controlled by individual business units except those involving enterprise financials [revenues, profits, cost of goods sold, etc.] and enterprise customers." Of course, more centralized principles would also be viable in an organization that wanted and needed a higher degree of information commonality. Creating and enforcing one version of the truth across many different information elements, however, will be both difficult to establish in the first place and difficult to maintain over time.
Tom Davenport is Professor and director of research, Babson Executive Education, Babson College. He can be contacted at tdavenport@babson.edu.
For more information on related topics, visit the following channels:
