With the advent of the Internet not only have companies been able to conduct business at the speed of light, but they have also been accumulating information at no lesser speed. The technologies to store and distribute information have progressed significantly. Yet, companies who have made significant investments in information management with technologies and infrastructure for enterprise business intelligence, enterprise information integration, real-time BI, etc. Still haven’t been able to deliver on the promise of getting the right information to the right people at the right time. At the root of this problem is the fact that we haven’t established an effective way to deal with delivering the right information. 
Even after significant investments and multiple iterations of data warehouses companies end up with the problems of a lack of a common vocabulary, lack of credibility in the information and a lack of understanding of how information is produced. The reasons for this typically are stated as:

  • The business is too complex to standardize.
  • Multiple stakeholders have unique preferences for definitions.
  • Information and data is an IT responsibility.
  • Definitions for nonstandard results are not available.

One of the first questions asked is, what is the reason to standardize data definitions? When most companies strive to develop competitive advantage by developing variety in the product set or in features, why, then, do we try to force standardization when it comes to information assets? In order to conduct operations efficiently, whether on the shop floor in a manufacturing plant or an exchange between finance and marketing functions, a common vocabulary is essential to communicate efficiently. The challenge doesn’t seem to be with having multiple definitions as much as it is with calling things with different definitions by the same name. When most companies launch a “standardization” initiative (or MDM project) they get stuck trying to arriving at a single definition for each commonly used terms. 
There has to be a rationalization process for reviewing the definitions, cataloging them and then adopting them. The focus of this is to understand the variations, asking tough questions as to reasons for variability and then retaining sometimes more than one definition (more on this later). But the answer to our “why” question really varies from company to company. Asking the question “Why standardize?” brings more people to the table than asking “Why not standardize?” Most standardization efforts have an assumption going in of coming up with a standard (read single) definition of commonly used metrics, which conveys the message that eventually only one point of view will be accommodated. Out of many perspective wins. Hence it is common to see a very defensive attitude of participants in such an exercise. 
Instead, the organization needs to focus on the learning aspect so as to convert a lot of useful but tacit knowledge into a more explicit knowledge base. 
Information we can be basically classified as fundamental and derived. For example, at a health insurance company a claim is a very fundamental transaction. Typically, there isn’t much of an argument on the definition of a claim. Most of the variations would be around notions like “health episode” or a “visit,” which are concepts derived from fundamental clinical or financial transactions. There can be very detailed definitions of what constitutes a visit. A clinical perspective might factor in procedures, clinical pathways, level of care etc and a financial perspective might look at the facility, dates of service, etc. 
We can find countless examples like this in every industry. Most variations at the fundamental level are more around sourcing of the information as opposed to the definition. The sourcing problem could be because of multiple versions of the truth housed in multiple systems. Whether its customer information, vendor information or product/service information,   organizations eventually try to consolidate information from multiple systems in order to arrive at the “standard.” We don’t have that luxury for derived information because there are multiple derivations that might be useful. The focus of this article is on the latter i.e. managing derived definitions. This is equally applicable in a business-to-business scenario. Every business partner or customer may have a unique business model, and conducting business with them might require adapting to each of those variations. In this case, trying to standardize would be detrimental to the business relationship and in fact, adapting to and managing the variations would be a source of competitive advantage.
The organization first has to learn about various definitions, use cases and stakeholder analysis as part of the process to convert some of the tacit knowledge about definitions into a more explicit understanding across the enterprise.

The learning from this process can be made available to the whole organization via a two-stage process. It is not just enough to build a system with the requisite metadata; it is even more important to have a process in place in how the business community can use this new information. If there are new definitions and ways of looking at things, then individuals need to be taught about the various use cases and potential upsides of a new point of view. This typically requires training and coaching that is very business-centric (not IT-centric). Typically, by having a coalition of business analysts, power users who have been part of the learning process can be the guiding force for the deployment and adoption works best this way because as they are able to articulate the business imperatives better and it is not seen as an IT effort.
How can such a rich multilevel information layer be developed and implemented within our traditional data warehousing constructs?
Stage 1:

  • Develop the enterprise data warehouse with fundamental transactions and definitions.
  • Develop departmental data marts/applications with enterprise definitions pulled down and accommodating departmental variations.
  • Get all data, business rules and metadata onto a single platform.

Outcomes/benefits:

  • The organization understands variability in definitions, and
  • Everyone is on a common platform and can exchange information based on shared understanding.

Stage 2:

  • Enrich the enterprise data warehouse with new departmental definitions.
  • Augment data marts with enriched EDW definitions.

Outcomes/benefits:

  • The EDW, not only has fundamental definitions but is enriched by new insights available to everyone across the enterprise, i.e., departmental insight becomes part of an organizational repository. 
  • The organization understands variability in definitions.


Critical success factors for both steps are:

  • Business ownership of the initiatives,
  • Strong executive support,
  • A steering committee that can provide the necessary oversight and guidance,
  • Solution development aligned with business goals outlines,
  • A solution stack that allows for exchange of metadata across the enterprise and
  • Establishing the analytics COE.

This two-stage approach is a more collaborative approach to moving the organization forward. It takes the organization on a journey where there is enough progress to get operational efficiencies first with everyone on a common platform and then eventually benefitting from a shared learning and moving towards common and well understood definitions with well outlined use cases.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access