The bad news is information-management (IM) types, strategic IT thinkers, et al. still really stink at explaining what this stuff is to business people. I believe the basic root of this problem is that we are too hung up on parables and metaphors as a technique to explain the value proposition of information management.
For example, "information is an asset" is an extremely common statement, and probably the most common information principle published. The subsequent explanation is that assets are managed, so information has to be managed. While this makes eminent sense, it does not sell or get IM efforts funded. The metaphor certainly starts the explanation process, but does not complete it.
In addition, when we (the IM types) explain how to develop the strategy, or define the architecture, we still insist on terms like "meta data." All apologies to my fellow proponents of meta data, but while the concept is great, it is not a deliverable of any business relevance, and the words make no sense to a businessperson. And please don't say we have to educate them. They do not have time, and we can just use another word (or two). And now we are bringing ontology and taxonomy into the lingua franca.
Fortunately, there is a basic series of building blocks that can be used to:
- Illustrate what information management is;
- Describe the value proposition;
- Show what it looks like; and
- Maintain perspective.
Definition, Please
Information management/data strategy (or some combination thereof) can usually be defined along the following lines:
IM is a program that manages the people, processes and technology in an enterprise towards the goal of maximizing the leverage, value and investment in data and knowledge, while avoiding increased risk and cost due to data and knowledge misuse, poor handling or exposure to regulatory scrutiny.
This definition avoids the "asset" metaphor. While information certainly is an asset, this is an abstract concept, and abstractions just do not sell well.
Another key word is "program." This implies that IM is ongoing, and must be sustainable. Projects have beginnings and ends. Programs are forever.
Value Proposition, Please
Any savvy executive will hear the definition, and then follow up with some elegant question along the line of, "So what?" This is not a discouraging sign, merely an indication of interest. Therefore, the next step is to have a very clear two-level statement of value for your organization.
The first level of value comes from alignment with pragmatic business initiatives. For example, many CRM projects of the past 10 years have ended up becoming, "Oh shoot, we don't really know who a customer is" projects. The governance and semantic management that accompanies IM certainly supports projects such as this. Another practical initiative that has worked for many of our clients is the cost of data quality and dis-integration. It is relatively easy to calculate, and usually presents some serious numbers for consideration. Lastly, the aforementioned risk considerations are easily associated with IM practices. A good actuary can place a financial model on risk inherent in an information portfolio.
The second level is the elevator speech. This consists of 50 to 100 words that drive home the value proposition. Anyone associated with IM, business and IT efforts should commit this to memory. Therefore, anyone involved with the program should say something along the lines of:
The IM program will directly increase cash flow by supporting customer retention and cross-selling, while reducing the overhead and risk associated with spreading too much data around the enterprise over a 20-year period.
The key words here are "cash flow" and "overhead." If the IM effort cannot supply support for a positive change in business value, then the IM effort is not structured correctly, and is not sustainable.
What Does It Look Like?
An effective IM program must produce deliverables that address some of the abstract concepts required when doing architecture (like visions and concepts) but avoid obfuscating technical jargon and use business terms.
The tangible results of information management take the form of measurable changes in infrastructure, data usage patterns, data quality and redundancy. Therefore, business personnel should approve deliverables that depict business rules, data quality characteristics, business performance metrics, and metrics to measure the success of IM.
All of the other deliverables that result from developing an IM program are for the IM team, e.g., the models, tool installations and so forth. Where there is an intersection of IM jargon and business user, use friendlier terms. The previous example of meta data is a good example - meta data is a blanket term that encompasses all the data required to manage data. The business side need only see what affects their interaction with the information.
Therefore, after the architecture and policies and such are developed, and a sensible, pragmatic road map is produced to incrementally implement the various pieces of IM, a set of metrics must be put into place to reinforce the benefits, usage and adherence to the IM programs and governance.
Maintain Perspective
The reason you have a plan is so someone can change it. The IM program provides an effective platform for creating flexibility. However, it is often easy to get caught up in the tool or package selection and implementation, or the philosophical examination on, "What is a customer?" The bottom line for an IM program, which must be reinforced from time to time, is supporting the business with clear, documented and effective data and information. The business user wants this as badly as anyone in information technology. Only through focusing steadily on solid governance, business alignment and an effective, practical road map will IM succeed. The software, the repositories and the models are all tools to achieve what should be a well-documented and measurable program.
Be the first to comment on this post using the section below.