by Julie Hunt

It’s always great to get a briefing from a very knowledgeable and flexible founder of a young company: tapping into original vision that has been tempered by the experience of customer implementations can be a rich experience. Recently the MDM Think Tank chatted with Martin Turvey, CEO of Loqate, about location intelligence and data quality. Loqate may be a young company, but in many ways, it is not a “start-up” due to the extensive expertise of founders Turvey and Paul Flew, in the areas of address quality practices and location intelligence — and the technologies that support them. Flew’s strong NLP (natural language processing) background is also an important asset for Loqate.

For most businesses, accurate address data is essential; poor address quality costs companies tons of money and lost customers. Not only is missing address information a problem, but inconsistent address data across repositories impedes data synchronization and calls into question the accuracy of all of the data. Turvey provided an interesting point: over 80% of data has a location element (source: PBBI). This means that verifying and cleansing address data, and then adding geocoding, can greatly enhance the usability of this data.

Use cases for location intelligence include: fraud detection, insurance risk assessments, improving mailing and shipping operations, real time mapping of web content and news feeds. Loqate maintains a repository of reference data comprised of address, geocodes, languages and other data covering 242 countries and territories.

Loqate is one of the few independent software vendors for address quality / location intelligence services, since most of the other vendors have been acquired by the usual suspects. Traditional data management stacks from the large infrastructure vendors are not an option for many companies, especially in emerging markets and the larger international arenas for address quality needs.

So Loqate is positioning its independence as a competitive differentiator that allows it to target solution niches not usually covered by the big infrastructure vendors.  This positioning is strengthened by Loqate solution innovation and future direction, including an upcoming Cloud / SaaS offering. Turvey commented that most MDM solutions fail at what Loqate does well for address quality and location intelligence. As to sales model, the Loqate solution is only available through Loqate partner companies that OEM or sub-license the technology.

The components of Loqate are broken down into:  Verify, Geocode, Register, and Identify. Additional technology includes the Geo-Data Quality Engine and the Global Knowledge Repository.

In Verify, where validation and clean up are performed, powerful differentiation exists in the parsing methodology. Based on lexicon and context, parsing algorithms understand what the data should be, based on context parameters. Loqate parsing capabilities analyze and remediate data in situ, and do the hard work on single strings without breaking the string into components first. In fact, the string’s structural context provides cues for Loqate’s parsing / validation. Most other data quality tools require users to do quite a bit of hands-on mapping and other tedious work as preparation for remediation. This isn’t the case for Loqate Verify. Parsing is also trans-global for processing records and strings with mixed international character and language sets. Data can also be transliterated from one character set to another character set (e.g. Roman to Katakana in Japan)

Turvey cited a use case for Fraud Detection: cheats will use fake addresses made up of components that are valid on an individual basis (real street address, real city), but in combination the components do not add up to a valid address. Most other address quality and data quality solutions will vet the individual components but not the composite, which means they may validate a fraudulent address.

Loqate provides real value by trapping errors at data entry time when remediation is at the cheapest point. It’s also essential to trap inconsistencies at data entry to prevent fraud and block bad data from infecting processes such as shipping that can greatly impact costs.

Geocoding is available for every address data element “out of the box”. The geocode assignment results from high granularity generation of a latitude-longitude coordinate for any address worldwide. From the geocode a map visualization can be created, accurate to delivery point / rooftop levels.

Register provides smart data entry to reduce errors and speed up operational processes. This is particularly useful when working with customers, whether it’s a call center employee talking to a customer or a self-service interface for eCommerce.

Identify:  The Loqate Entity Extraction module enables location, additional geographic and contact information to be identEified and extracted from web content and other unstructured information sources. LocationV extractions enable content to be localized, driving location-based services and geographically targeted advertising.

Loqate has included the ability to quantify address data quality through its Accuracy Code analysis. A verification accuracy match score portrays the similarity between input data and the closest reference data match as a percentage between 0 and 100, with 100 as best match, as well as detailing what changes have been made to each key component during processing and determining validity of those components.

Right now, user tweaking is limited and is mainly accomplished through processing rules. There is no means as yet to tweak algorithms. Loqate is taking a slow approach here, being careful not to lead users astray, since algorithm changes can end in unexpected and harmful consequences.

Next up for Loqate is an impending Cloud / SaaS offering that should be available Spring 2012. Loqate is touting their Cloud services as “developer source for anything location”. It is also a great opportunity for further innovation since the Cloud can take software vendors in some very interesting directions.

About the author: Julie Hunt is a software industry strategist and analyst, providing market and competitive insights. Her 25+ years as a software professional range from the very technical side to customer-centric work in solutions consulting, sales and marketing.  Julie shares her takes on the software industry via her blog Highly Competitive and on Twitter at @juliebhunt   For more information, please visit Julie Hunt Consulting – Strategic Product & Market Intelligence Services. 

The event is sponsored by Trillium Software. Here are the invitation details:

Is your data governance program delivering?

Having a center of excellence to govern and manage your corporate data is no easy task. Yet, a solid data governance program is critical to making your data work for your organization.

In Part 4 of our Data Governance Series: Impact You Can See, you have the chance to hear from a panel of experts who explain how to make your data governance efforts help you achieve your organizations goals by aligning data to your business.

Have a question for our experts? We’d like to hear from you. Submit your question when you register and get the chance to have one of our experts answer it!

The featured speakers are:

• Dan Power, President, Hub Solution Designs
• Jon Asprey, VP of Strategic Consulting , Trillium Software
• Lovan Chetty, Senior Manager (Product Management), Kalido
• Patrick Beatty, Director of Information Management, PwC

Please click here to register.  It should be a very interesting session!

If it were so, I could redefine an entire industry with this article. The gray area between DG and MDM is real and (artificially) exists due to a lack of definition, maturity, or understanding within an organization. Considering that methodologies for MDM and DG have many variances, it would be a challenge to hit on every possible permutation of DG and MDM to define the dividing lines. Doing so would make for a long and painful read and probably be published under a self-help genre for curing insomnia. Instead, let’s generalize on the goals of each and try to find that utopian business model where there is complete harmony.

To do so, I have broken the discussion into three topics: DG, MDM, and that gray matter in between.

Governance

Data Governance organizations are business entities that define and manage the most vital corporate asset, business information. Governance organizations may vary in participation and influence, but they share common goals of corporate data policy definition, policy enforcement, and communication. DG initiatives arise from self-awareness amongst the business leadership that they create and own information and that IT serves as its librarian. Throughout the business are pockets of information, some self-contained within a single business process and some shared across many.

The self-contained “departmental” information can be manipulated, manufactured, and retired with little concern over consequences to external business processes and are of lesser concern to Governance organizations. But when information created by one business process is integral to other business processes, it becomes apparent that a lack of control introduces organizational risk. DG strives to define the structure within the organization to manage the complete information lifecycle of information deemed to be of business importance in order to mitigate risk.

The “best” or “most effective” methods to accomplish successful Data Governance can be the subject of numerous heated debates. I submit that such debates detract from the true mission of identifying what information is important, how to manage it, how to communicate about it, and most importantly, how to measure the effectiveness of your Governance efforts. If the business already realizes a need for Governance, half the effort is done. As long as there is a desire to institute and improve a process, most any dialog is a step in the right direction.

One aspect of Governance that is rarely in dispute is the identification of data owners and data stewards. Data Owners are responsible for the accuracy and completeness of the information and Data Stewards are entrusted to maintain this accuracy.  Also common is the Governance Council which defines the standards and processes to be followed by the Owners, Stewards, and Librarians. These standards and processes are company assets that become the ‘rules of law’ for all things data.  Like rules that govern acceptable behavior in our society, these rules are in place for the good of the business.

MDM

MDM is an information-centric business process to consolidate and manage specific enterprise data that just happens to use technology to assemble, merge, and distribute the data in question.  MDM arose from a need to ensure consistency of strategic shared information to improve data quality, accessibility, and security.

MDM is unique in that it is limited to specific shared information that is not transactional in nature such as: common reference codes, persons, products, or locations.  Value realized from an MDM solution occurs when information is made consistent across the organization, duplicate records are identified and resolved, and the quality of the information is markedly improved.

Achieving data consistency and quality generally requires a thorough understanding of the information at hand, how and where it is created or modified, and what roles and rules are needed to manage its data life cycle.

Methods for MDM, like DG, vary by business and business need.  Long before any MDM solution can be implemented, extensive process and information re-engineering must be planned for. Organizations that do not integrate information across departments effectively have a much harder time getting consensus during this planning process.  Despite the MDM data subject, methods, or tools used, a common practice of the planning process is to identify those responsible for the data in question and those responsible for its daily management (similar to the data owners and stewards above). For the select information within its domain, MDM should consider management from data inception through retirement and all uses between.  Roles of an MDM project include Business Analysts, Data Architects, Data Owners, Data Stewards, data providers, and data consumers.

Gray Matter

Unless my hints were not blunt enough or I’ve put you to sleep already, it should be apparent that there is significant overlap in the purpose, roles, and assets between Governance and MDM. Both processes define data elements and rules around their creation, management, and retirement.  They also both identify owners and stewards of information and place a structure around the process for ensuring data quality, security, and interaction.  So it seems simple that these overlapping roles would be one and the same, right?  Right?

In a utopian business world, the DG organization would be in place before an MDM initiative begins.  Such a DG organization would be structured with the foresight to handle an MDM initiative. In fact, in Utopia, the DG organization would be the driving force for identifying the business need and performing the cost-benefit analysis to justify such an MDM project.

Without tight coupling between MDM and DG, each initiative will see voids in their processes and fill them in order to be successful in their own right.  If DG has not instituted data standards prior to the MDM envisioning stage (or they are not followed), MDM may limit itself to what is needed to satisfy the current phase or one system. For example, “MDM in a vacuum” may have no reason to validate the business definition, domain, or business name of an attribute or list of values does not conflict with an already-established business data element.  A source system may use NULLs to indicate yes or no conditions or have other non-documented defaults that flow into the Best Version of Truth.

Without a global view of how Yes/No indicators should be handled, an MDM project could proliferate ambiguous data to all its consumers.

Another area of consideration is the logging and reporting of data errors and exceptions. In Utopia, I’m told, it is a law that each data element is assigned a data owner, a data steward, a domain of allowed values, restrictions, and a distinct definition. When data is introduced that break these laws, the violation is recorded and the owner or stewards are notified to rectify the situation. A clearly defined policy to automatically identify and report such violations along with a policy to address these issues in a timely manner ideally springs from a strong DG presence rather than an MDM afterthought.

It is expected that DG will evolve to handle new technologies regardless of whether the technology is new to the organization.  In the case of MDM, a DG organization needs to be able to address MDM concepts like trust and survivorship as well as create and expand policies around data dictionaries and canonical modeling. With tight coupling, an MDM project will look heavily to a DG organization for guidance and resources, and MDM will become another data standardization model to demonstrate the value of DG.

Summary

MDM should be considered an extension of DG.  Without proper controls and standardization of data, the worst case for an MDM project is that is becomes a waste of budget. The best case under the same lack of vision is that the project becomes a waste of potential.  Strong DG methods are undeniably needed when defining and standardizing information within an MDM solution. Without an Enterprise-wide focus on DG, an MDM solution will eventually arrive at a solution that meets the myopic needs of its immediate source/target systems, but little else. When an MDM expansion opportunity arises, the original lack of global vision will result in either a re-evaluation of the entire MDM solution or a limiting of the new audience to the initial design goals.

When considering a new or expanded MDM initiative, the first step should focus on your DG program. DG Stewards and Sponsors are the driving force for MDM justification and definition and are the true customer for MDM. Defined global controls should be finalized and introduced early into the process. Only then will you be considered a citizen of Information Utopia.

Rob DuMoulin is an information architect with more than 26 years of IT experience, specializing in master data management, database administration and design, and business intelligence.

“MDM should be a business driven program” is the mantra we hear time and time again. And while that is the right prevailing wisdom, doesn’t it seem that there is far more articulation about the technical elements of MDM than about the business elements?

So often I have seen MDM publications and presentations start with the “should be business driven” perspective but then quickly shift to covering the technical elements of MDM, topics related to architecture, data models, data integration, metadata management, match logic, consolidation, synchronization, application services, and so on.

Yes, those all are important elements in the MDM equation, but this over-abundance of technical insight can be frustrating for those seeking practical knowledge and guidance for the business planning of an MDM program. After all, without a strong business presence, MDM can’t develop into a core competency throughout the company. So why, in comparison, is so little insight provided about the business side of the equation?

Actually, it’s easy to understand this situation. The plethora of technical insight is a byproduct of the influence that IT and vendors have on the MDM market. And that’s not suggesting that business organizations don’t care to promote their MDM practices, it’s just that there is much more uniqueness and latency involved with getting these business components established, and these dynamics are harder to articulate.

Let’s take a closer look at these influences and dynamics.

The call for MDM

The initial need and sponsorship for an MDM initiative often emerges from the IT and/or analytical groups in a company. These groups usually exist separately or on the periphery of the business. The IT and analytical areas responsible for activities such as system integration, data migration, information management, data warehousing, business intelligence and reporting will typically be the first to expose where poor data quality and lack of data governance is creating project delivery delays, data management problems, integration issues, distrust of the data, and reporting problems.

Therefore, it’s understandable that these groups become initial proponents of MDM solutions. And while the root cause for many of these data problems lies in front-end business practices and data entry points, the IT and analytical groups are most directly impacted and naturally tend to implement their own back-end corrective actions.

At some point these ongoing problems and workarounds become a tangled mess, and that situation becomes a catalyst for seeking an MDM solution. Current state issues, improvement opportunities, and cost/benefit projections cited in MDM proposals are usually centered on correcting these legacy issues, improving data governance and information management practices, and eliminating the workaround overhead. In other cases, MDM programs often emerge when legacy applications are being replaced with more integrated platforms such as business application suites, data hubs, and enterprise warehouses where IT planning and activity is already underway.

Product vendor and consulting influence

Because of the large market opportunity and competition among MDM product vendors and consulting firms, it is expected that they will have a significant influence on the MDM information being presented. Technology and consulting help should always be factored into an MDM assessment and implementation plan. Although the overall impact and practical use of both can often be overstated, good technology and consulting help applied in the right places can definitely advance MDM capability and reach.

But many other aspects of implementing MDM involve new and unique business practices, business context, and process management where technology and consulting help will only have limited application, if any.

MDM is as much about people and process as it is about technology, which is why product vendors are increasingly looking at improving their business consulting practices or consulting partnerships as a competitive advantage. Over time this trend should help bring a better balance of information and practical insight for the planning and implementation of MDM.

Discovery and Analysis

At the onset of an MDM initiative, a “Discovery and Analysis” phase is conducted to fully detail the issues, root causes, business and system impacts, and opportunities for improvement. This discovery and analytical phase is often led by IT or an analytical team, if not a consulting group. Business leads should be actively involved in this phase, but specifically how and where business groups will be needed to drive and support MDM plans will largely depend on what priorities and direction come out of this discovery and analysis work. And where the business engagement needs are identified, the business groups will often need time to plan, budget, and prepare for these activities.

Implementing process improvements and driving data governance activity can be new or disruptive territory for business organizations. Many MDM programs do not have sufficient budgets to cover these business area needs, therefore the implementation of these business elements can take some time.

MDM job roles

IT groups already have most of the necessary job roles and skill sets needed (e.g. analysts, architects, project managers, programmers, data miners, database administrators) to initiate and support the technical aspects of MDM. The business roles needed within a MDM program (e.g. data governance leads, data stewards, process analysts, quality managers, data access gatekeepers) often do not already exist as formal job roles. Consequently these roles either have to be assigned to existing resources that have other job responsibilities and/or created through new hires, job transfers, or contracted positions which can require budget allocation and also take time to fulfill. Therefore it’s common to see IT and analytical related activity initiated early on while the business roles and needs are being addressed.

Maturity models

In MDM and data governance maturity models, we typically see the advanced levels of maturity defined using terms such as Managed, Optimized, Proactive, Advanced, or Transformational. But in many of these models, those levels are characterized by more system and analytical orientated achievements, related to systems integration, establishing a system of record, business process automation, using SOA/SaaS, quality monitoring, delivering trusted analytics and KPIs, and so on.

The business area maturity needs and milestones — associated with data governance, data life cycle management, and quality control — are much less apparent in these maturity models.

Granted, much of the program development and maturity on the business side of a MDM program is going to be tied to unique business practices that are harder to generalize in a high-level maturity model. Therefore it often takes some digging in MDM and data governance forums or finding business case studies to gain good insight on how and where the business events and the maturity of business practices have occurred in a MDM implementation.

A developing dynamic

So even though it is critical for business to be involved and provide leadership in an MDM program, defining, articulating, and achieving that is likely to be a developing dynamic that spawns from IT and analytical underpinnings where product vendors and consulting firms are also well entrenched. As more companies launch MDM initiatives and develop their MDM core competencies across their business model, we can expect to see increasing amounts of business insight and best practice information made available that will express how and where business roles and business practices evolved in MDM programs. I look forward to that.

Mark Allen is co-author of the book “Master Data Management in Practice: Achieving True Customer MDM”. Mark has over 20 years of data management and project management experience including extensive planning and deployment experience with customer master initiatives, data governance programs, and with leading data quality management practices. Mark is a senior consultant and enterprise data governance lead at WellPoint, Inc. Prior to WellPoint, Mark was a senior program manager in customer operations groups at both Sun Microsystems and Oracle Corporation. At Sun Microsystems, Mark served as the lead data steward for the customer data domain throughout the planning and implementation of Sun’s enterprise customer data hub.

A Sample Organizational Model

A three level model like this can work well at a lot of companies:

1. Data Governance Steering Committee: a cross-functional, executive level group that makes policy decisions, provides funding, resolves escalated issues, and provides strategic direction.
2. The Data Governance Office (DGO) is charged with coordinating data governance (strategic) and stewardship (tactical) activities. It manages communications from the Steering Committee to all stakeholders.
3. One or more tactical groups (Data Stewardship Teams) in each functional area and geography (if needed), which provide guidance to individuals with data stewardship responsibilities.

However, what’s most important is to have the organizational structure that will work in your company.

Data Governance Steering Committee

The Data Governance Steering Committee serves a function similar to the U.S. Supreme Court. Issues escalated by the Data Governance Office are resolved by the Steering Committee.

The Steering Committee probably won’t directly make much policy (except on an exception basis), except where the issues are serious or the dollar amounts are large. For example, where a new policy may be compliance-related and involve large penalties, the Steering Committee would at least review (and probably sign-off on) the new policy.

Similarly, establishing the overall Data Governance organization and its place in the company, as well as its Year 1 funding and its renewal, is probably a matter that will be settled by the Steering Committee.

The ultimate power in the corporation to make sure Data Governance policies are being followed, and to resolve issues escalated from lower levels, resides in the DG Steering Committee. But that group will, to a large extent, rely on the Data Governance Office to make it aware of when policies are not being followed, and when escalated issues need to be resolved.

This group will usually include senior level business owners and the overall executive sponsor(s) for data governance, and operates strictly at strategic level.

The key things at this level are: getting the right executives involved, and that once it starts meeting, it accomplishes some useful things. Otherwise, the executives will feel like they’re wasting their time when they do meet, and the group will quickly disband.

Data Governance Office

The Data Governance Office is similar to the Executive Branch of the Federal Government. It’s heavily involved in making data policy. It oversees the business data stewards and the IT stewards. The DG office is similar to a Program Management Office (PMO) and usually includes the global process owners (from the business) and the global solution owner from IT.

The DG Office operates at the tactical level but needs to be comfortable managing up (to the strategic level) and down (to the operational level).

The DG Office is critical to having a successful Data Governance initiative. Creating the right Data Governance Office can make or break your entire effort.

The policy making that transcends different line of business interests would typically be done in the Data Governance Office, since the DGO would have representation from the various lines of business through the global process owners.

Who’ll Head Up the Data Governance Office (DGO)?

There’s a tendency in these job descriptions to be a little “over the top”. Some companies are looking for people who can in effect walk on water, leap tall buildings in a single bound, etc.

Data Quality Pro had a great article recently: “Data Quality Director Required – Must Possess Powers of Invincibility”. Vincent McBurney wrote an interesting article titled “Data Governance is Career Suicide”.

Hub Designs Magazine responded with an article titled “Data Governance: The People Make It Real”, explaining how to support data governance leaders in their new roles.

This person does need a strong leadership style and the delegated authority of the executives on the Data Governance Steering Committee.

Data Stewardship Teams

The third level of the Data Governance Organization is similar to the Legislative Branch of the Federal Government.  It works with the Data Governance Office in making data policy, and in carrying it out.

These teams need to be from the business side in order to know the “ins and outs” of the data, but the teams should include IT stewards as well, to assist with the technology aspects of the data governance processes.

There are usually data stewardship teams from various functional areas and geographies. They work at the operational level but selected people may be representatives to the Data Governance Office (i.e. they’ll primarily be data stewards but they may attend meetings of the Data Governance Office, even if they’re not formally members of the DGO).

This is so they can adequately represent the stewardship level on issues they are bringing to the Data Governance Office for resolution.

These people spend time responding to issues raised by others; monitoring data quality and developing new data quality and business rules; but their real skill set is collaboration with multiple organizations at multiple levels.

Summary

Don’t get the impression that data governance means a big bureaucracy.

Every company will find its own balanced approach, with a business-driven, IT-supported group that makes decisions about information and governs master data like any other critical asset in the enterprise – with diligence, formal processes and metrics.

But people can fill multiple roles at first, and especially during the initial phases, you can take a pretty lean approach. It’s more important to start doing data governance than to wait for the perfect organizational structure and staffing.

Why is this stuff so hard?

Companies aren’t used to governing data across the entire enterprise. It goes against their well honed instincts, to break things up into smaller units or silos to make them more manageable. Where they do have data governance in place, it’s usually done at an application or business unit level.

And it can be tough to show ROI for data governance.

But companies with effective governance processes in place generate up to 40% higher ROI on their IT investments than their competitors, according to Peter Weill and Jeanne Ross in “IT Governance: How Top Performers Manage IT Decision Rights for Superior Results” (Boston: Harvard Business School Press, 2004).

The bottom line is that managing things, when you have control over them yourself, is hard enough. Governing them, when you have to consult with others, gradually win them over, and lobby for things that matter deeply to you, is hard work!

How to get started

First, it’s important to avoid “analysis paralysis”. Since many organizations don’t know where to start, they do nothing at all.

Analyzing your current state and desired future state, using a maturity model as we discussed in the previous article, provides a framework for planning your activities and managing your expectations, enabling you to proceed.

Start by defining with some degree of precision (1) where the company is now, (2) where the company wants to be, and (3) over what period of time.

Then look at the critical elements such as MDM, data integration, data quality, data enrichment, data governance, business process management, BI, enterprise content management, and information lifecycle management over time. This should lead to a realistic plan and design. For more information on how to create a strategic roadmap, see James Parnitzke’s article on that topic.

Click to enlarge

Spend time on the design before launching

Don’t let yourself be rushed into getting organized too soon. Setting up a Data Governance Council too early is a classic failure mechanism!

Spend time on things like developing the data governance program’s overall vision and strategy, and its value statement – its reason for existing. Your stakeholders will want to know the answers to some basic questions like “where will the program live, and how will it be funded?”

Once you have the basics outlined, you can move on to the more detailed elements of the design. Who will be involved? How will the program be organized? Will it be centralized or de-centralized? Why are we doing this? What will the DG program do for the enterprise?

Before you launch a formal governance council, you need to have positioned the initiative to a key executive sponsor. Without them, the council will be just another meeting. Another point to keep in mind is that a global council can work cooperatively with local groups. Some companies think the global group is going to wind up being too big because it has to centrally govern all aspects of Customer, for example, instead of defining the 10 critical attributes across business processes and simply starting there.

Whatever you decide on these questions, working from a solid design is a lot easier than making it up as you go along.

When to start establishing Data Governance

Ideally, you would start about six months before starting any MDM initiative, so that your new DG group would have a chance to form itself, and then help drive the MDM initiative.

But don’t start before you’ve got your executive sponsorship and funding lined up. You’ll just end up with a failed data governance effort to explain away later. It’s better to wait until everything is lined up than start before you’re ready.

Then get ready for the ride of your life – corporate politics, new technology, organizational change, marketing communications, project management, you name it!

Using a Data Governance Maturity Model

Something that Hub Designs recommends early in a new Data Governance program is using a Data Governance Maturity Model to realistically assess how you currently govern data at the enterprise-wide level. This is helpful so that you’ll know where you’re starting from where the four dimensions of People, Process, Technology and Information are concerned, before embarking on your initiative.

Most Data Governance Maturity Models are based on the Software Engineering Institute’s Capability Maturity Model (CMM) for software development.

A Data Governance Maturity Model states what should occur at each level, not how to accomplish the activities. There are many different DG maturity models, but they share some common characteristics: they usually have 5 levels, and they’re just a tool to assess where you’re starting from, not something to get hung up on or on which to spend a lot of time.

The National Association of State CIOs (NASCIO) did a great study of the different Data Governance Maturity Models available from organizations such as IBM Data Governance Council, DataFlux, EWSolutions, Gartner, Knowledge Logistics, the MDM Institute, and Oracle Corporation, concluding that “data governance maturity models can be used as references in communication, awareness building, and the marketing of data governance”.

Where are most organizations today?

The important thing is to be realistic about where you’re starting from – most companies are starting at 0 or 1.

A lot of companies are doing governance, just not formally. People are managing data, they just need to figure out who’s doing it, and what and how they’re doing. Then group them and provide some central guidance to get them started.

Here are three things to think about:

• A recent survey of over 100 organizations found that only 10% have been able to move their DG programs beyond the lowest two levels of maturity. IT is still accountable for the data in 63% of organizations. Only 27% have established a data governance council with business representation and formal data stewardship. And 57% of organizations do not measure the performance of data management activities at all.
• Most companies with which Hub Designs has worked have not been successful making the types of organizational, cultural, process and technological changes necessary solely with internal resources.
• Most of the companies with which we’ve worked have a “research & analysis” period of up to two years under their belts before they start making serious progress on their MDM and governance programs.

The reality is that with cross-functional, multi-year programs such as MDM and data governance which involve multiple organizational, process, technology and information disciplines, it’s better to proceed deliberately and have a series of incremental “wins” that show business value, rather than go for a rapid implementation or a “big bang” approach.

Progress in this area is not linear – you make investments, you build competency, you do the hard work (and sometimes even get frustrated), and then by doing a relatively small amount of remaining work, you start to achieve your goals.

Like a baby learning to talk, or an adult learning a foreign language, there’s a steep learning curve that flattens out rapidly at the top. Companies will seem not to make progress for a long time (while they’re making the investment in growing their data governance capability), and then their abilities will come together rapidly, as people get a chance to put their new skills to work in a new Data Governance Organization.

The most important thing about data governance is to “start from where you are”. Most companies are just getting started on their data governance journey. It can be hard to admit that your company is at data governance maturity level 0 or 1. But the most critical step is the first one – getting started.

We live in interesting times. Poor information security practices led to the release of a huge number of secret diplomatic cables to WikiLeaks. The Federal Aviation Administration admitted that registration information for as many as one-third of all private aircraft is out-of-date and inaccurate, forcing the FAA to cancel and re-register all civil aircraft.

And the private sector isn’t immune. TUI Travel, Europe’s largest tour operator, accepted the resignation of its CFO after restating its 2009 results to the tune of $191.8 million, blaming problems in integrating computer systems following a 2007 merger.

Sound familiar? Hopefully, your company doesn’t have any data governance “skeletons in the closet” like these. But if you hunt around a bit, you’ll undoubtedly find people in your business who’ll tell you about:

• decisions that were made based on reports with wrong or missing information,
• the real costs of duplicate data in your customer master database,
• cash flow being impacted because invoices were being sent to the wrong addresses,
• supplier master issues causing millions in avoidable costs in lost volume discounts
• the penalties for not complying with industry and government regulations on customer data and privacy,
• failure to comply with tax laws because of inaccurate billing information,
• information-heavy projects that run over time, or require length rework after go-live,
• decommissioning systems is nearly impossible because clear retention and destruction policies have not been defined,
• manual correction and alignment of content and documents takes time away from resources because these items aren’t singularly governed,
• IT staff spending a lot of time re-integrating data and dealing with data fire-drills because data service level agreements and fit-for-use levels have not been established and tracked.

If you talk to business owners across functional areas like R&D, Marketing & Sales, Finance, Operations, Human Resources, and Customer Service, you’ll fill up a small notebook with the stories about what not having a data governance organization in place is costing your company.

What exactly is “master data”?

Good question. Master data is the lifeblood of your company. It’s information that’s critical to the enterprise, including entities such as customers, products, employees, suppliers, and locations. It’s shared (or it should be) across applications, systems and databases, and across multiple business processes, functional areas, organizations, geographies and channels. It’s generally not anything that happens at a particular time, but instead a person, place or thing that changes slowly over time. Master data is not transactional, but it’s used by and linked to transactions.

And what is “data governance”?

Master data needs to be governed as you would any other critical asset in the enterprise – with diligence, formal processes and metrics. I’ve often said that if companies treated their cash and their inventory the way they treat their customer and product data, a lot of people in corporate America would be going to jail.

Jill Dyché, in Ten Mistakes to Avoid when Launching Your Data Governance Program, defined data governance as “the decision rights and policymaking for corporate data”.

Whenever you see the word “decision rights” and “policymaking” next to the words “corporate data”, you know that you’re dealing with an area that is more political than technological. But technology can be an enabler.

One of my favorite quotes is by Dean Kamen, the inventor and entrepreneur:

The technology is the easy part. Understanding what drives people – individuals, societies, what makes cultures clash – all of those questions are way, way harder to answer than how to solve any particular technical problem.

Simplifying today’s enterprise architectures

Today, most companies larger than $500 million – $1 billion in revenue:

• have grown through merger & acquisition activity,
• have a mixture of front office and back office suites and “best of breed” applications
• have some acquisitions and applications that are integrated and some that aren’t
• have created shadow IT organizations in individual Lines of Business in an effort to speed up results
• have created more complex processes for dealing with data issues, causing individual groups to creatively work around the processes
• have more diverse groups of workers with diverse experience (and preferences) for enabling software tools, like Excel

As a result, most companies suffer from significant data silos and data fragmentation – what I call the “Islands of Data” problem.

These data silos increase costs, hurt business and IT agility, and result in bad decisions being made throughout the enterprise (because of low quality, inaccurate, inconsistent data).

Master Data Management can solve the “Islands of Data” problem

Master Data Management (MDM) technology brings master data together in an MDM hub. In addition to the MDM hub itself, you’ll usually need:

• Data Integration (usually using Service-Oriented Architecture)
• Data Profiling and Data Quality
• Business Process and Business Rules Management
• Third Party Data Enrichment
• Technology to facilitate Data Governance

The MDM Hub centralizes master data, providing the much desired “Single Source of Truth”, streamlining business processes (which reduces costs and increases productivity and agility), and increasing revenue (through ability to support more targeted marketing and cross sell / up sell initiatives) and improving compliance.

But committing to MDM technology isn’t enough, unfortunately. Nor is it the first thing you need to figure out. In order to make the entire exercise work, we also need data governance.

So Why Do It? Why Govern Master Data?

The alternative – not governing it – is information chaos and anarchy. “A disaster of biblical proportions. Human sacrifice, dogs and cats living together… mass hysteria!” (from one of my favorite movies, Ghostbusters).

Seriously, why would we bring together master data from all over the enterprise, cleanse it, build golden records of customers, products, suppliers, etc. and not govern the decision-making process, result, and resulting analytics? That would be a value destruction exercise worthy of the Guinness Book of World Records.

Data governance is a critical success factor for master data management. MDM isn’t a “lights out operation”. Don’t try to do master data management without a data governance organization in place or under construction. You’ll wind up looking like this guy!

In the May 30th, 2011 edition of Hub Designs Magazine, you may recall the article The System of Record in MDM by Dalton Cervo (who is also the co-author of our new book Master Data Management in Practice: Achieving True Customer MDM).

In the article, Dalton aptly pointed out the underlying importance and challenges associated with defining a system of record (SOR) approach needed to enable a single version of the truth in a master data hub environment.

Expanding from that SOR aspect, MDM as a whole is an ongoing set of processes and disciplines aimed at achieving and maintaining a single version of the truth within one or more master data domains. Companies will typically begin their MDM focus in one master data domain area and expand to more domains with implementation of a multi-domain program model.

In some cases there may be a multi-domain plan from the start, but usually a single domain like Customer or Product will still be the starting point and set the program tone for subsequent domains. When taking this multi-domain leap, it is critical to determine what aspects of MDM planning and execution can be repeatable and scalable across the domains, as well as what are the domain specific elements. With that in mind, here are some perspectives and questions that are important to consider when pursing a multi-domain model.

Defining domains in a multi-domain model

There are a number of commonly identified MDM domains that are often referenced in MDM literature and business case examples such as Customer, Product, Locations, Materials, Employee, Supplier, and a few others that represent master data areas common to most business practices.

Depending on the business model, industry orientation, and application platforms involved, the actual master domains or domain names that a company defines may deviate somewhat from those common domain types. In fact, it would not be unusual in a multi-domain implementation to see a mix of domain types where the leading domains are some of the common MDM domains, followed by other data domains that may not necessarily fit a true MDM definition — such as a more transactionally oriented data set — but where MDM type disciplines can still be applied to achieve a desired level of improvement, consistency, and value with that data.

In such cases, this may appear to be an unconventional approach, but in practice it is reasonable to expect that regardless of the original intent and context, good data management practices and disciplines such as MDM will usually find their way into more general usage over time. A multi-domain model can often become a vehicle where good MDM practices become more generally applied across a company’s data sets. This is actually goodness, so keep in mind that the multi-domain makeup does not always have to be limited to just the master data context.

Prioritizing in a multi-domain model

As is often the case, starting an MDM initiative with a focus on the Customer or Product domain certainly makes sense since the viability and sustainability of most companies rests on customer and product dynamics. Most all sales, marketing, financial, service, and analytical functions in a company are tied to these customer and product dynamics, so this can be a natural starting point for MDM before venturing further.

Once the most critical domains area addressed, it will usually be easier for other data domain programs to get started and aligned within the overall MDM plan. However, there can be many strategic, operational, and technical reasons that can influence domain implementation order.

The MDM business case and investment decisions should be driving the overall MDM roadmap based on priorities that are typically associated with risk mitigation, revenue growth, cost reduction, or business efficiency. The MDM priorities are also going to be influenced by things like executive sponsorship, available resources, business process impacts, new technology, BI needs, and budget forecasts.

When planning a multi-domain program, sufficient time is needed to work out the right implementation approach, examine business impacts, determine critical path dependencies, and to define the ongoing program management model. Not fully addressing these items will likely lead to various program impacts and priority adjustments.

It is the business functions and transactional areas who are the primary creators and consumers of the master data, and since most transactional areas will interact with master data from multiple domains, the domain implementation plan and order can have significant impact on business operations. So be sure to plan and prioritize wisely.

Distinguishing the Program Management Office role from the data domain role

Implementing MDM across multiple domains naturally creates the need to examine how to best coordinate and prioritize multi-domain activity and focus, particularly in regards to technology needs, quality improvement priorities, and demand for budget and IT resources.

A multi-domain MDM plan needs to start by creating a distinct enterprise level Program Management Office (PMO) charter and core team to establish the program foundation needed to move forward.  In some cases, this charter may be assigned to an enterprise data governance group. However established, this is the program office that will need to provide the cross-domain program leadership, policies, standards, services, and core resources to help facilitate and support the multi-domain model. Each domain should still have its own domain specific program scope, responsibilities, and resources, but this should be in alignment with the multi-domain model and policies that the PMO puts forth.

Depending on an organization’s model and approach, the role and responsibility mix between the PMO and domain charters can vary, but generally there should be a clear separation of duties conducive to a collaborative and supportive relationship. Because many aspects of quality management, governance, and stewardship focus are unique within each domain, this should not be impeded by excessive PMO control.

If the PMO charter is too broad, overly controlling, and attempts to create too much of a homogeneous multi-domain model, it can start overshooting its value if it takes away authority and empowerment from the domain specific teams.

A multi-domain MDM program should not be a cookie-cutter process or a follow the bouncing ball type of affair. Rather, it is very much the orchestration of unique programs that have common threads and are on a common enterprise MDM mission but with different domain specific objectives and priorities. A well-conceived PMO should always be cognizant of how to continually coordinate and enable the various domain programs and avoid over-managing where control and conformance is not necessary, otherwise this can become a path toward a stifling model that is not conducive to overall MDM growth and maturity.

A PMO needs to cultivate an environment where a maturing MDM domain team can lead by example with developing best practices which other domain teams can leverage to accelerate their maturity. The leading domain implementation needs extra attention so that the business foundation it creates for data governance, stewardship, quality management, and technology usage, can create repeatable models to help prime the start up of the other domain implementations. This is critical for driving sustainability across the overall MDM model. Leveraging the knowledge, practices, and experience from a leading MDM practice should be a key strategy in a multi-domain plan.

There are also many IT-oriented services needed in MDM such as metadata management, data analysis, data integration, data cleanup, or development of metrics and reports where competing demand is likely to occur across multiple MDM programs. The PMO needs to ensure that these services are as extensible and scalable as possible in order to manage the demand as economically and efficiently as possible.

Launching too many MDM initiatives side by side and each with common dependencies and demand on IT can quickly lead to overload and bottleneck scenarios, causing deliverables to be delayed which can negatively impact the progress and expected deliverables across all the MDM initiatives.

Also, when planning your multi-domain program be careful not to create too many critical path dependencies on new technology because, as we all painfully know, these implementations will often be subject to delays and functionality issues. There are many business project areas of MDM programs (e.g. data governance, data steward setup, business analysis, process improvement, and many program management tasks) that don’t depend on technology, so be sure these type project areas and tasks are sufficiently identified in the program plan and can still move forward while other technology issues are being addressed.

Additional things to consider

Beyond what I have already covered about planning and implementing a multi-domain model, here are some other important questions and perspectives that should be considered:

• Can your IT models and practices sufficiently adjust to provide more flexibility and collaborative support across business-driven MDM programs?
• How much capacity will business and IT organizations have to support requirements and demands from a multi-domain plan?
• Will new technology actually help enable more MDM efficiency and accelerate ROI?
• Will any anticipated organizational change be a disruptive factor, enough to preclude a multi-domain MDM initiative from succeeding?

Simply stated, when planning and implementing a multi-domain model, expect a lot of variables and do the math. Complete necessary business analysis to fully identify what MDM and data governance oriented needs, benefits, and impacts can be expected; what will apply across the domains; and what will be associated to a specific domain. Gear your PMO office to help successfully facilitate the common and unique elements while also driving the domain programs to stay in scope of the overall enterprise MDM model and objectives.

A multi-domain plan can easily be a 3-5 year journey, but if persistently and successfully pursued, this should result in highly consistent and unified data management practices across the enterprise that can greatly benefit a company’s operational and analytical foundation.

I truly believe that MDM has the ability to drive more operational efficiency through continued application and maturity of its core disciplines in a multi-domain model. And while MDM oriented technology continues to be introduced that can greatly assist multi-domain implementations, fundamentally it is the due diligence done in the MDM planning stages and the ability to implement a flexible MDM program foundation that enables the efficient and cost effective application of the technology.

Mark Allen has over 20 years of data management and project management experience including extensive planning and deployment experience with customer master initiatives, data governance programs, and leading data quality management practices. Mark is a senior consultant and enterprise data governance lead at WellPoint, Inc. Prior to WellPoint, Mark was a senior program manager in customer operations groups at both Sun Microsystems and Oracle Corporation. At Sun Microsystems, Mark served as the lead data steward for the customer data domain throughout the planning and implementation of Sun’s enterprise customer data hub.

A three level model like this can work well at a lot of companies:

1. Data Governance Steering Committee: a cross-functional, executive level group that makes policy decisions, provides funding, resolves escalated issues, and provides strategic direction.
2. The Data Governance Office (DGO) is charged with coordinating data governance (strategic) and stewardship (tactical) activities. It manages communications from the Steering Committee to all stakeholders.
3. One or more tactical groups (Data Stewardship Teams) in each functional area and geography (if needed), which provide guidance to individuals with data stewardship responsibilities.

However, what’s most important is to have the organizational structure that will work in your company.

Data Governance Steering Committee

The Data Governance Steering Committee serves a function similar to the U.S. Supreme Court. Issues escalated by the Data Governance Office are resolved by the Steering Committee.

The Steering Committee probably won’t directly make much policy (except on an exception basis), except where the issues are serious or the dollar amounts are large. For example, where a new policy may be compliance-related and involve large penalties, the Steering Committee would at least review (and probably sign-off on) the new policy.

Similarly, establishing the overall Data Governance organization and its place in the company, as well as its Year 1 funding and its renewal, is probably a matter that will be settled by the Steering Committee.

The ultimate power in the corporation to make sure Data Governance policies are being followed, and to resolve issues escalated from lower levels, resides in the DG Steering Committee. But that group will, to a large extent, rely on the Data Governance Office to make it aware of when policies are not being followed, and when escalated issues need to be resolved.

This group will usually include senior level business owners and the overall executive sponsor(s) for data governance, and operates strictly at strategic level.

The key things at this level are: getting the right executives involved, and that once it starts meeting, it accomplishes some useful things. Otherwise, the executives will feel like they’re wasting their time when they do meet, and the group will quickly disband.

Data Governance Office

The Data Governance Office is similar to the Executive Branch of the Federal Government. It’s heavily involved in making data policy. It oversees the business data stewards and the IT stewards. The DG office is similar to a Program Management Office (PMO) and usually includes the global process owners (from the business) and the global solution owner from IT.

The DG Office operates at the tactical level but needs to be comfortable managing up (to the strategic level) and down (to the operational level).

The DG Office is critical to having a successful Data Governance initiative. Creating the right Data Governance Office can make or break your entire effort.

The policy making that transcends different line of business interests would typically be done in the Data Governance Office, since the DGO would have representation from the various lines of business through the global process owners.

Who’ll Head Up the Data Governance Office (DGO)?

There’s a tendency in these job descriptions to be a little “over the top”. Some companies are looking for people who can in effect walk on water, leap tall buildings in a single bound, etc.

Data Quality Pro had a great article recently: “Data Quality Director Required – Must Possess Powers of Invincibility”. Vincent McBurney wrote an interesting article titled “Data Governance is Career Suicide”.

Hub Designs Magazine responded with an article titled “Data Governance: The People Make It Real”, explaining how to support data governance leaders in their new roles.

This person does need a strong leadership style and the delegated authority of the executives on the Data Governance Steering Committee.

Data Stewardship Teams

The third level of the Data Governance Organization is similar to the Legislative Branch of the Federal Government.  It works with the Data Governance Office in making data policy, and in carrying it out.

These teams need to be from the business side in order to know the “ins and outs” of the data, but the teams should include IT stewards as well, to assist with the technology aspects of the data governance processes.

There are usually data stewardship teams from various functional areas and geographies. They work at the operational level but selected people may be representatives to the Data Governance Office (i.e. they’ll primarily be data stewards but they may attend meetings of the Data Governance Office, even if they’re not formally members of the DGO).

This is so they can adequately represent the stewardship level on issues they are bringing to the Data Governance Office for resolution.

These people spend time responding to issues raised by others; monitoring data quality and developing new data quality and business rules; but their real skill set is collaboration with multiple organizations at multiple levels.

Summary

Don’t get the impression that data governance means a big bureaucracy.

Every company will find its own balanced approach, with a business-driven, IT-supported group that makes decisions about information and governs master data like any other critical asset in the enterprise – with diligence, formal processes and metrics.

But people can fill multiple roles at first, and especially during the initial phases, you can take a pretty lean approach. It’s more important to start doing data governance than to wait for the perfect organizational structure and staffing.

Our experience, however, is that sticking to the truism of the need for “business & IT alignment” is an oversimplification at best and utterly misleading at worst. The chasm to bridge is often really not between “business” and “IT”.  It is also very much within business and within IT:

• Different business units / processes / functions refuse to see Master Data from the perspective of others: a salesman and a delivery person have different views on customer data; purchasing organization and manufacturing look at material data from very different perspectives;

• Professionals from different IT areas have varying viewpoints on Master Data Management: people with data warehousing and Extract/Transform/Load background do not talk the same language as Data Quality and MDM tool professionals.

The fundamental challenge in Master Data Management and Data Governance lies in the above situations, in real boundary-spanning cooperation between different parts of the organization.

Of course such cooperation is also needed when implementing enterprise systems like ERP as well, but in the case of MDM, an extra twist of difficulty is added. It is not just about making interfaces between processes and the organization work. It is about more profound boundary-spanning. It is about practicing true systems thinking.

Approach

So, what to do? The central tenet of Data Governance and Master Data Management, managing data as a critical asset across the entire organization, often doesn’t happen for the above discussed reasons.  Elegant jumps over the gaps are rarely possible. Turf wars abound, within business and within IT.

The answer is that a serious practitioner should learn from how boundary-spanning leadership is done and reflect them in his or her approach to overcoming Data Governance and MDM challenges. Quoting the Drucker Exchange:

“Our world is more interconnected than ever before, but what sorts of boundaries still keeps an organization divided within, thereby undercutting its chances for success?” the Drucker Exchange

In our next article, we’ll discuss how these boundaries can be recognized and managed in MDM and Data Governance programs.

Kimmo Kontra and Pertti Karhu are co-founders of a Finnish Data Management consulting company, Datpro. Both Kimmo and Pertti can be reached via their company’s web site, http://www.datpro.fi.  Kimmo tweets as @kimmokontra and occasionally blogs about topics that interest him in http://datalifeuniverse.blogspot.com. 

Why is this stuff so hard?

Companies aren’t used to governing data across the entire enterprise. It goes against their well honed instincts, to break things up into smaller units or silos to make them more manageable. Where they do have data governance in place, it’s usually done at an application or business unit level.

And it can be tough to show ROI for data governance.

But companies with effective governance processes in place generate up to 40% higher ROI on their IT investments than their competitors, according to Peter Weill and Jeanne Ross in “IT Governance: How Top Performers Manage IT Decision Rights for Superior Results” (Boston: Harvard Business School Press, 2004).

The bottom line is that managing things, when you have control over them yourself, is hard enough. Governing them, when you have to consult with others, gradually win them over, and lobby for things that matter deeply to you, is hard work!

How to get started

First, it’s important to avoid “analysis paralysis”. Since many organizations don’t know where to start, they do nothing at all.

Analyzing your current state and desired future state, using a maturity model as we discussed in the previous article, provides a framework for planning your activities and managing your expectations, enabling you to proceed.

Start by defining with some degree of precision (1) where the company is now, (2) where the company wants to be, and (3) over what period of time.

Then look at the critical elements such as MDM, data integration, data quality, data enrichment, data governance, business process management, BI, enterprise content management, and information lifecycle management over time. This should lead to a realistic plan and design. For more information on how to create a strategic roadmap, see James Parnitzke’s article on that topic.

Click to enlarge

Spend time on the design before launching

Don’t let yourself be rushed into getting organized too soon. Setting up a Data Governance Council too early is a classic failure mechanism!

Spend time on things like developing the data governance program’s overall vision and strategy, and its value statement – its reason for existing. Your stakeholders will want to know the answers to some basic questions like “where will the program live, and how will it be funded?”

Once you have the basics outlined, you can move on to the more detailed elements of the design. Who will be involved? How will the program be organized? Will it be centralized or de-centralized? Why are we doing this? What will the DG program do for the enterprise?

Before you launch a formal governance council, you need to have positioned the initiative to a key executive sponsor. Without them, the council will be just another meeting. Another point to keep in mind is that a global council can work cooperatively with local groups. Some companies think the global group is going to wind up being too big because it has to centrally govern all aspects of Customer, for example, instead of defining the 10 critical attributes across business processes and simply starting there.

Whatever you decide on these questions, working from a solid design is a lot easier than making it up as you go along.

When to start establishing Data Governance

Ideally, you would start about six months before starting any MDM initiative, so that your new DG group would have a chance to form itself, and then help drive the MDM initiative.

But don’t start before you’ve got your executive sponsorship and funding lined up. You’ll just end up with a failed data governance effort to explain away later. It’s better to wait until everything is lined up than start before you’re ready.

Then get ready for the ride of your life – corporate politics, new technology, organizational change, marketing communications, project management, you name it!

Using a Data Governance Maturity Model

Something that Hub Designs recommends early in a new Data Governance program is using a Data Governance Maturity Model to realistically assess how you currently govern data at the enterprise-wide level. This is helpful so that you’ll know where you’re starting from where the four dimensions of People, Process, Technology and Information are concerned, before embarking on your initiative.

Most Data Governance Maturity Models are based on the Software Engineering Institute’s Capability Maturity Model (CMM) for software development.

A Data Governance Maturity Model states what should occur at each level, not how to accomplish the activities. There are many different DG maturity models, but they share some common characteristics: they usually have 5 levels, and they’re just a tool to assess where you’re starting from, not something to get hung up on or on which to spend a lot of time.

The National Association of State CIOs (NASCIO) did a great study of the different Data Governance Maturity Models available from organizations such as IBM Data Governance Council, DataFlux, EWSolutions, Gartner, Knowledge Logistics, the MDM Institute, and Oracle Corporation, concluding that “data governance maturity models can be used as references in communication, awareness building, and the marketing of data governance”.

Where are most organizations today?

The important thing is to be realistic about where you’re starting from – most companies are starting at 0 or 1.

A lot of companies are doing governance, just not formally. People are managing data, they just need to figure out who’s doing it, and what and how they’re doing. Then group them and provide some central guidance to get them started.

Here are three things to think about:

• A recent survey of over 100 organizations found that only 10% have been able to move their DG programs beyond the lowest two levels of maturity. IT is still accountable for the data in 63% of organizations. Only 27% have established a data governance council with business representation and formal data stewardship. And 57% of organizations do not measure the performance of data management activities at all.
• Most companies with which Hub Designs has worked have not been successful making the types of organizational, cultural, process and technological changes necessary solely with internal resources.
• Most of the companies with which we’ve worked have a “research & analysis” period of up to two years under their belts before they start making serious progress on their MDM and governance programs.

The reality is that with cross-functional, multi-year programs such as MDM and data governance which involve multiple organizational, process, technology and information disciplines, it’s better to proceed deliberately and have a series of incremental “wins” that show business value, rather than go for a rapid implementation or a “big bang” approach.

Progress in this area is not linear – you make investments, you build competency, you do the hard work (and sometimes even get frustrated), and then by doing a relatively small amount of remaining work, you start to achieve your goals.

Like a baby learning to talk, or an adult learning a foreign language, there’s a steep learning curve that flattens out rapidly at the top. Companies will seem not to make progress for a long time (while they’re making the investment in growing their data governance capability), and then their abilities will come together rapidly, as people get a chance to put their new skills to work in a new Data Governance Organization.

Google Search Results Heat Map

I was doing some research recently on the search terms that bring people to the Hub Designs Blog. So I took a few minutes and found that for the most frequently used 40 search terms over the past year that I looked at, the Hub Designs Blog was in the Top 10 search results on Google for every single one, with an average position of Google’s search results page of third. That, to me, is amazing.

The single article on Ten Best Practices for Master Data Management (we also have a ten-part series on the same topic, which starts here) does very well on Google, placing in the Top Ten for the following search terms:

• “customer data integration best practices” (#1)
• “master data best practices” (#1)
• “customer data management best practices” (#1)
• “master data management best practice” (#1)
• “master data management best practices” (#3)
• “data integration best practices” (#7)

The most important thing about data governance is to “start from where you are”. Most companies are just getting started on their data governance journeys. It can be hard to admit that your company is at data governance maturity level 0 or 1. But the most critical step is the first one – getting started.

We live in interesting times. Poor information security practices led to the release of a huge number of secret diplomatic cables to WikiLeaks. The Federal Aviation Administration admitted that registration information for as many as one-third of all private aircraft is out-of-date and inaccurate, forcing the FAA to cancel and re-register all civil aircraft.

And the private sector isn’t immune. TUI Travel, Europe’s largest tour operator, accepted the resignation of its CFO after restating its 2009 results to the tune of $185 million, blaming problems in integrating computer systems following a 2007 merger.

Sound familiar? Hopefully, your company doesn’t have any data governance “skeletons in the closet” like these. But if you hunt around a bit, you’ll undoubtedly find people in your business who’ll tell you about:

• decisions that were made based on reports with wrong or missing information,
• the real costs of duplicate data in your customer master database,
• cash flow being impacted because invoices were being sent to the wrong addresses,
• supplier master issues causing millions in avoidable costs in lost volume discounts
• the penalties for not complying with industry and government regulations on customer data and privacy,
• failure to comply with tax laws because of inaccurate billing information,
• information-heavy projects that run over time, or require length rework after go-live,
• decommissioning systems is nearly impossible because clear retention and destruction policies have not been defined,
• manual correction and alignment of content and documents takes time away from resources because these items aren’t singularly governed,
• IT staff spending a lot of time re-integrating data and dealing with data fire-drills because data service level agreements and fit-for-use levels have not been established and tracked.

If you talk to business owners across functional areas like R&D, Marketing & Sales, Finance, Operations, Human Resources, and Customer Service, you’ll fill up a small notebook with the stories about what not having a data governance organization in place is costing your company.

What exactly is “master data”?

Good question. Master data is the lifeblood of your company. It’s information that’s critical to the enterprise, including entities such as customers, products, employees, suppliers, and locations. It’s shared (or it should be) across applications, systems and databases, and across multiple business processes, functional areas, organizations, geographies and channels. It’s generally not anything that happens at a particular time, but instead a person, place or thing that changes slowly over time. Master data is not transactional, but it’s used by and linked to transactions.

And what is “data governance”?

Master data needs to be governed as you would any other critical asset in the enterprise – with diligence, formal processes and metrics. I’ve often said that if companies treated their cash and their inventory the way they treat their customer and product data, a lot of people in corporate America would be going to jail.

Jill Dyché, in Ten Mistakes to Avoid when Launching Your Data Governance Program, defined data governance as “the decision rights and policymaking for corporate data”.

Whenever you see the word “decision rights” and “policymaking” next to the words “corporate data”, you know that you’re dealing with an area that is more political than technological. But technology can be an enabler.

One of my favorite quotes is by Dean Kamen, the inventor and entrepreneur:

The technology is the easy part. Understanding what drives people – individuals, societies, what makes cultures clash – all of those questions are way, way harder to answer than how to solve any particular technical problem.

Simplifying today’s enterprise architectures

Today, most companies larger than $500 million – $1 billion in revenue:

• have grown through merger & acquisition activity,
• have a mixture of front office and back office suites and “best of breed” applications
• have some acquisitions and applications that are integrated and some that aren’t
• have created shadow IT organizations in individual Lines of Business in an effort to speed up results
• have created more complex processes for dealing with data issues, causing individual groups to creatively work around the processes
• have more diverse groups of workers with diverse experience (and preferences) for enabling software tools, like Excel

As a result, most companies suffer from significant data silos and data fragmentation – what I call the “Islands of Data” problem.

These data silos increase costs, hurt business and IT agility, and result in bad decisions being made throughout the enterprise (because of low quality, inaccurate, inconsistent data).

Master Data Management can solve the “Islands of Data” problem

Master Data Management (MDM) technology brings master data together in an MDM hub. In addition to the MDM hub itself, you’ll usually need:

• Data Integration (usually using Service-Oriented Architecture)
• Data Profiling and Data Quality
• Business Process and Business Rules Management
• Third Party Data Enrichment
• Technology to facilitate Data Governance

The MDM Hub centralizes master data, providing the much desired “Single Source of Truth”, streamlining business processes (which reduces costs and increases productivity and agility), and increasing revenue (through ability to support more targeted marketing and cross sell / up sell initiatives) and improving compliance.

But committing to MDM technology isn’t enough, unfortunately. Nor is it the first thing you need to figure out. In order to make the entire exercise work, we also need data governance.

So Why Do It? Why Govern Master Data?

The alternative – not governing it – is information chaos and anarchy. “A disaster of biblical proportions. Human sacrifice, dogs and cats living together… mass hysteria!” (from one of my favorite movies, Ghostbusters).

Seriously, why would we bring together master data from all over the enterprise, cleanse it, build golden records of customers, products, suppliers, etc. and not govern the decision-making process, result, and resulting analytics? That would be a value destruction exercise worthy of the Guinness Book of World Records.

Data governance is a critical success factor for master data management. MDM isn’t a “lights out operation”. Don’t try to do master data management without a data governance organization in place or under construction. You’ll wind up looking like this guy!

Inspired by Crysta Anderson from Initiate, who put together IBM’s Mastering Data Management blog Top 10 Posts of 2010, I decided to put together a similar “Top Ten Posts of 2010″ for the Hub Designs Blog.

In our holiday greetings article, Thank You To Our Readers, we covered some of the top articles from the beginning of this blog in July 2007, and included some readership statistics, which we won’t bore you with today.

Our reports on MDM vendors like Oracle, IBM Initiate, Informatica (formerly Siperian), Kalido, and Orchestra Networks were very popular in 2010.  And our series on MDM best practices, practicing enterprise architecture within MDM (by Jim Parnitzke) and on data profiling (by Rob DuMoulin) were also big hits.

Without further ado, here’s the Hub Designs Blog “Top 10 for 2010″.

1. Oracle’s MDM Strategy and Roadmap – A look at Oracle’s MDM strategy and roadmap, from the Oracle Applications Users Group (OAUG) COLLABORATE conference in April 2010.
2. Building MDM-Powered Solutions with Initiate Composer – A description of Initiate’s new Composer product, which is a framework for building solutions on top of IBM’s Initiate Master Data Service hub.
3. Master Data Management Best Practice Series, by Dan Power – A ten part series on MDM and data governance best practices, based on my presentation at Oracle OpenWorld 2010.
4. Modeling the MDM Blueprint, by James Parnitzke – A six part series on applying important enterprise architecture concepts to MDM projects.
5. Data Profiling For All The Right Reasons, by Rob DuMoulin – A five part series on data profiling and its role within MDM and data governance initiatives.
6. Siperian Acquired By Informatica – My analysis of Siperian’s acquisition by Informatica, written on the day the news broke.
7. Informatica Analyst Briefing – Hub Designs is regularly briefed by the major MDM vendors; this one by Informatica was about 2 months after the acquisition. A later briefing from October 2010 can be found here.
8. Kalido MDM and AB InBev – I live blogged this at the Gartner MDM Summit during a session by Kalido’s President and CEO Bill Hewitt and Jonathan Starkey, the Director of Business Intelligence at AB InBev North America.
9. Intersection of MDM, CRM and ERP – My article on Why Product Information Management in Information Management magazine sparked a short blog article by Andrew White of Gartner. The “Intersection of MDM, CRM and ERP” article is in response to Andrew’s.
10. Orchestra Networks Enters Gartner Magic Quadrant – We thought it was newsworthy that Orchestra Networks, a specialized MDM vendor, was included in Gartner’s “Magic Quadrant for Master Data Management of Product Data” for the first time. Also, Orchestra Networks sponsored a white paper titled A Real Multidomain MDM Solution or a Wannabe? by Hub Designs that was published in September.

It’s been a busy 2010.  I recently read the 2009 Year in Review from this time last year, and was exhausted just reading it, but this year has been the same – several conferences (Gartner MDM Summit, OAUG COLLABORATE, Oracle OpenWorld, Kalido), webinars (with eLearning Curve, TechTarget and Oracle Applications Users Group) and some exciting things to look forward to and update you on in 2011.

I’d like to to thank my wife and two boys for their unwavering support throughout 2010 – and my heartfelt thanks to the folks on the Hub Designs team - I couldn’t do it without you!

And thank you – as always – for your readership and support.  Happy New Year!

Well, another year has nearly passed, and I’d like to say “thank you” to everyone who has read and supported this blog over the past three and a half years.

Only one thing has made this blog possible: you. Whether you came here to learn about master data management (MDM) and data governance, or to follow the development of the consulting firm Hub Solution Designs, your support is what has kept us writing, with 265 articles to date.

We’ve had some great guest authors over the years, whose work you can see on the Top Series page.  They’ve helped to bring great insights and ideas to the blog; I hope you take the time to check out their work.

Our MDM Best Practice series was very popular this October, with the series as a whole receiving more than 2,100 page views in the past two months. The shorter article on Ten Best Practices for Master Data Management, which led to the ten part series, has received 5,100 views so far.

Five Essential Elements of MDM and CDI remains one of our most popular articles, and Joan Lawson’s MDM and SOA, a Strong Partnership is in the “Top Ten” as well.

A couple of the articles we’ve written about Oracle have proven popular as well: Oracle’s MDM Strategy and Roadmap, and the First Look at Oracle Fusion MDM Hub. Jim Parnitzke’s series on Modeling the Blueprint for MDM proved so popular, we re-ran it this summer, as did Rob DuMoulin’s series on Data Profiling for All The Right Reasons.

Our article on the Hidden Costs of Duplicate Customer Data has received 1,175 total views over the past year, and How Master Data Management is Similar to ERP has been averaging 200-300 views per year for more than three years now. MDM and Enterprise Architecture (also by Joan Lawson) is a good reminder of the central role that MDM plays in the practice of Enterprise Architecture.

I hope you enjoy reading the blog as much as I enjoy writing for you. And I hope your holiday season is filled with family, love and happiness, and that you have a safe, healthy and prosperous New Year!

The results were not surprising, but I found them very interesting nonetheless. Keep in mind that this was a self-selecting group; that is, people who were interested enough in data governance to have taken the survey. That suggests that the general population would be even less mature.

The biggest finding was that only 10% of organizations have been able to move their data governance programs beyond the first two levels of data governance maturity. That matches well with our experience at Hub Designs – most companies are just getting started with data governance.

Despite the commonly expressed belief that data should be owned by the business, traditional IT organizations are accountable for data in nearly two-thirds (63 percent) of organizations.  At Hub Designs, we believe that the business should be accountable for the data – but sometimes, that’s a “bridge too far”. You’ve got to start where you are, and evolve over time to higher levels of maturity. If the center of gravity right now is in the IT organization, that that’s where you start. But over time, have a strategy for moving data governance into the business.

Nearly half (45 percent) of organizations taking the survey said they have a formal data governance council in place, but only 27 percent have established a data governance council with business representation and formal data stewardship. That tells me that even in places where they’re doing some type of (immature) data governance, there are still lots of opportunities for improvement, by increasing the level of business involvement, stewardship and data quality.

This finding I found stunning: more than half (57 percent) of organizations do not measure the performance of data management activities at all. That leads me to believe that those organizations won’t be doing data management for much longer, because lack of measurement tends to lead to lack of funding, because of a perceived lack of documented results.

Clearly, we have a long way to go in the corporate world in becoming more mature from a data governance perspective. I really liked Kalido’s survey, and you can find Winston Chen, Kalido’s VP of strategy and business development, discussing it on his blog at http://bit.ly/cbckxD.

Speaking of Kalido, Hub Designs is sponsoring their upcoming Virtual User Conference on December 7, 2010. The Kalido Connect virtual conference provides attendees with a cutting-edge platform for networking, exhibition, collaboration and learning. Attendees can watch a presentation in a packed auditorium, network with peers in the Kalido Connect Lounge, or visit fully interactive sponsor booths on the exhibit floor. From group chats to one-on-one discussions, the virtual platform allows for a live conference and exhibition floor with real-time user interaction. To register, just click http://bit.ly/kalido-register.

Kalido Connect offers:

• Real-world examples of Kalido’s business value as told by their customers
• Keynote sessions on BI, MDM and data governance trends and how to keep ahead of the curve
• Technical breakout sessions to maximize your investment in the Kalido Information Engine™ and expand your skill set
• Exhibit hall showcasing complementary products and services from Kalido partners and sponsors
• Opportunities to network with colleagues, industry leaders and executives

Last year, more than 300 people attended the Kalido Connect Virtual User Conference, and Kalido expects to double that this year.

Dan Power: Informatica MDM Tweet Jam like playing “stump Dan” – see if you can perplex, mystify and amaze me!

Dan Power: Actually, just kidding – want to have a good dialogue with everyone – would love to have a good MDM discussion.

Informatica Corp.: Right now! Join the #MDM TweetJam with @dan_power. 9am PT.

Dan Power: OK, the Tweet Jam is officially open!

Jakki Geiger: Dan, what are the most common concerns you hear about MDM?

Dan Power: IT people still seem concerned about how to involve the business and sell it to senior management.

Jakki Geiger: what advice do you give them?

Dan Power: IT seems to know that MDM is needed but sometimes can’t seem to get the business on board, and it can be hard to pitch to the C-Suite.

Dan Power: We advise building a compelling business case – getting outside help if needed – and recruiting internal business champions.

Jakki Geiger: What strategies to get the business on board have you seen work?

Dan Power: I wrote an article about that in a recent Information Management magazine and a blog article on Hub Designs Blog that accompanied it.

Jakki Geiger: We’ve seen IT successfully tie MDM to key strategic imperatives like improving cross-sell and up-sell=getting sales on board.

Ravi Shankar: One thing we have done to help IT is to quantify how much DQ issues can cut costs or increase revenue.

Dan Power: Getting the business on board means STARTING in the business – find out their pain points and recruit them to drive from Day 1.

Jakki Geiger: Others include onboarding channel partners onboard faster, which appeals to sales and channel operations.

Jakki Geiger: A huge driver has been regulatory compliance = appealing to those who gather data across the enterprise and create reports.

Ravi Shankar: I like what Charles Bloodworth of J&J said at Informatica World 2010 – “MDM is not just a project; it’s a discipline – a way of doing bus for us”.

Dan Power: Good points Jakki & Ravi – those are the pain points I’m talking about: increasing revenue / onboarding channel partners faster.

Jakki Geiger: One area I think is really going to take off is improving business processes = improve data to improve the process.

Jakki Geiger: One exec got buy in from exec team with “we need to manage our product supply chain and info supply chain equally efficiently”.

Ravi Shankar: Agreed – bus needs to be involved in MDM. Charles of J&J said bus involvement drove their MDM and data governance success.

Dan Power: That’s right – becomes a way of life – new discipline for the business – to have a golden copy of the data that they can trust.

Jakki Geiger: I agree with u. IT needs to understand what the business pains and strategic imperatives are, then evaluate “can MDM help?”

Dan Power: Product management and supply chain are just as fertile for most companies as customer data – so MDM is just getting started.

Dan Power: I’ve been talking to a lot of companies lately that have already done customer MDM and are now looking at doing product MDM.

Ravi Shankar: Product MDM: I see lot of demand for this from manufacturing companies. Just came from S. Korea – product MDM is hot.

Dan Power: Or even supplier MDM – in order to get global strategic sourcing initiatives off the ground, which can save millions of $.

Ravi Shankar: Customer MDM to product MDM – we’ve seen that with our own early customers – They leveraged the same Informatica platform.

Julie Hunt: How do you see MDM implementations evolving to take advantage of newer tech such as ‘cloud’?

Julie Hunt: And what advantages does the cloud offer to MDM solutions?

Dan Power: Good question, Julie – definitely see a movement towards the cloud – people don’t want to create tomorrow’s “legacy systems”.

Dan Power: So they increasingly are asking their vendors about cloud deployment options, even if they don’t rush to take advantage of them.

Dan Power: They want to know they’re available

Dan Power: To Julie’s Q about cloud, I think eventually we’ll see cloud deployments at lower cost than on-premise (particularly hardware).

Ravi Shankar: Let me outline 2 use cases we’ve seen @ InformaticaCorp.

Ravi Shankar: Use case 1: During peak times like holiday seasons, retailers can burst into cloud for additional capacity.

Ravi Shankar: Use case 2: Mktg mgrs can use self service tools to upload attendee list from event w/o having to bother IT.

Dan Power: The promise of cloud for me, is more flexibility as my business grows and if we have seasonal peaks and valleys of demand.

ocdqblog (Jim Harris): What do you say to companies that expected that from their data warehouse? How is MDM different from conformed dims?

Ravi Shankar: ocdqblog – welcome. Looking forward to a lively MDM discussion.

Dan Power: Good question, Jim. Most companies had unrealistic expectations from data warehouses, which ended up being expensive, read-only,

Dan Power: and updated infrequently. MDM gives them the capability to modify the data, publish to a DW, and manage complex hierarchies.

Dan Power: So to finish answering your question Jim, I think MDM offers more flexibility than the typical DW.

Dan Power: That’s why BI on top of MDM (or more likely, BI on top of a DW that draws data from an MDM) is so popular.

Ravi Shankar: MDM for DW – 90% of Informatica MDM customers use it for analytical use (in addition to operational).

ocdqblog (Jim Harris): Thanks Dan – Follow-up is do you see MDM as compliment or replacement for DW?

Dan Power: Definitely a compliment – fills void in the middle between trx systems and the DW – does things that neither can do to data.

Jakki Geiger: are you seeing this trend? Evolving beyond single customer view= visibility into 360 customer view w/products and channels, etc.

Dan Power: Yes, Jakki – people want more than a single view – they want multiple views on top of the single view.

Ravi Shankar: Siperian customers – We’re having a lively chat on MDM and data governance. Join in!

Ravi Shankar: Dan, what do you tell DW admins that DW provides their single view for enterprise?

Dan Power: I tell DW admins that most people in the enterprise aren’t completely happy with DW – that’s why there’s pain leading to MDM.

Jakki Geiger: Since the driver of MDM is the business, how are we getting master data into the hands of the business?

Dan Power: Good Q, Jakki – getting MDM data back into hands of the business should be built into the project – and the software platform.

Ravi Shankar: Compliance is driven out of DW – you need MDM for accurate compliance reports – Do you agree?

Dan Power: Yes, Ravi – Garbage in, Garbage out – you need quality data from the MDM system to feed into the data warehouse.

Julie Hunt: So we must advocate value of data governance as well as value of MDM with business, senior management?

Dan Power: I tell people to think of their initiative as a data governance project that happens to involve #MDM technology.

Dan Power: Not an #MDM technology project that requires data governance.

Dan Power: And to start the data governance piece about 6 months before the technology piece, if possible.

Julie Hunt: The importance of data quality = another layer to be advocated to the business and to management – show them the impact on outcomes.

Jakki Geiger: MDM is like a Ferrari. If you don’t use DQ with MDM, it’s like putting regular gas in Ferrari=sub optimal performance.

Dan Power: I’ve seen people try to do MDM without data quality – and it’s a disaster, like trying to run a submarine on dry land!

Dan Power: The fact is that #MDM and data quality are linked, just as #MDM and data governance are linked.

Ravi Shankar: Should data quality be integrated within #MDM?

Dan Power: Good question, Ravi – I’ve seen it both ways – a data quality engine integrated with the MDM platform or separate, both can work as long as the data quality tool is robust and the integration is solid, shouldn’t matter.

Dan Power: Most MDM platform vendors are not equally good at developing data quality tools – Informatica is one of the few that is.

Julie Hunt: How much does corporate culture impact success/failure of projects for #MDM, data governance etc.?

Dan Power: Great Q – corporate culture is a huge impact on success because data governance drives MDM and requires a lot of change mgt. So spend a lot of time on org. change in the data governance side of the #MDM initiative in order to be successful.

Ravi Shankar: Heard a customer say – “Don’t overdo data governance – do just what’s necessary” Do you agree?

Dan Power: I’d agree not to go overboard on data governance – balanced approach that’s right for your co. just enough to get the job done. Too much data governance can be worse than not enough – can be bureaucratic – the “data governance police”.

Ravi Shankar: Data governance applies to all data, but I hear that in MDM context a lot. Do you hear “master data governance” for MDM?

Jakki Geiger: Some argue shouldn’t call it data governance because the -ve connotation of “governance” thoughts?

Dan Power: I actually like that phrase – master data governance – makes it more clear and precise what we’re talking about

Dan Power: Because otherwise, data governance organization can get drawn into all kinds of weird things not related to master data

Dan Power: We need to recognized that data governance is (a) political, (b) controversial, (c) going to have an enforcement side.

Ravi Shankar: Now, do orgs do data governance first before implementing MDM or after they select an MDM product?

Dan Power: So in some ways, I actually like the term “data government” better – makes it more explicit what we’re talking about.

Dan Power: And it reminds people that we’re talking about governing the enterprise’s core master data – just like we govern other key assets.

Jakki Geiger: I think the challenge is that we’re still in the process of understanding that data is a strategic asset.

Dan Power: It’s ideal if they can start data governance before even selecting a product – so that the data governance org. can help w/ the selection process.

Ravi Shankar: Dan wrote an excellent whitepaper – “When Data Governance Turns Bureaucratic” – you can download it from http://bit.ly/ck2Gw8.

Dan Power: Truly competitive 21st century companies not only understand that data is a strategic asset, it’s how they run their business.

Dan Power: Forward looking businesses like Google, Amazon, Century 21, eBay, etc. realize that the data IS their business!

Jakki Geiger: “Data as strategic asset” is a fairly new concept. Visionaries recognize need 4 scale and intelligence=harnessing & analyzing data.

Dan Power: That was a fun white paper to write – looking forward to doing another one with the great folks at Informatica again soon!

Jakki Geiger: What I liked about Dan’s WP was the discussion around stopping the problem of data quality at the source.

Seth Grimes: Is data governance also (d) useful on balance and (e) capable of delivering ROI?

Dan Power: Yes, of course – or people wouldn’t be doing it. You can’t bring together massive amounts of data in an MDM hub and not have some type of governance framework in place. And if there was no ROI, it wouldn’t be happening.

Dan Power: I’m pretty familiar with Oracle’s data governance program, and for a huge company, it’s not real expensive.

Ravi Shankar: Welcome to #INFATJ – good data governance question.

Ravi Shankar: Successful Informatica MDM customers like J&J, Merrill, and numerous others have had strong global data governance orgs.

Ravi Shankar: Data is a key asset that many firms make a lot of money out of it – Bloomberg for e.g.

Ray Wang: RT @Ravi_Shankar_: Data is a key asset that many firms make a lot of money out of it – Bloomberg for e.g.

Dan Power: Good example with Bloomberg – welcome Ray!

Ravi Shankar: @rwang0 thx for the RT

Jakki Geiger: Can you create a career out of MDM? Many of our customers have extended MDM to address more and more issues in their orgs.

Dan Power: Good Q, Jakki – u can create a career out of it, I have for the last 6 years, but you’ve got to really have this in your blood

Ravi Shankar: Within Informatica customers, we’ve seen careers of several people take off b/c of successful #MDM data governance.

Julie Hunt: Thanks for great tweet jam!

Jakki Geiger: Thank you for participating! Looking forward to next time. Good luck to you all!

Dan Power: Thanks for joining us today – hope you enjoyed it! Check out the Hub Designs Blog at http://blog.hubdesigns.com.

Ravi Shankar: Thx for your insightful discussion and advice on #MDM data governance. Hope you all enjoyed it. Until next time!

Dan Power: This is Dan Power, signing off – have a great day everyone!

MAG is a not-for-profit community, founded by Pierre Bonnet, of users, software vendors, consultants and systems integrators who jointly invest their time and intellectual property in the development of a common best practice and procedure approach for the successful and sustainable implementation of Master Data Management projects.  Pierre is also author of the excellent book “Enterprise Data Governance“.

Hub Designs believes in the community driven approach that the MDM Alliance Group is pursuing, and we’ve been following their progress for quite a while. Their web site, www.mdmalliancegroup.com, has a lot of good information and downloadable assets on modeling procedures, prebuilt data models, webinar replays, and more.

Hub Designs sponsors The MDM Community, but so far that has been more of a forum for people to ask one another questions, to write blog articles, to discuss topics and post upcoming events. Perhaps at some point, The MDM Community will become a way for MDM practitioners to share digital assets with one another. But in the meantime, the MDM Alliance Group is doing great work, and Hub Designs is proud to be a member of it.

Also, a section of our white paper which was released on Sept. 14th, 2010 has been published on the MDM Alliance Group web site. This section deals with the importance of a model-driven approach and proactive data governance to delivering multidomain MDM. You can read that section of the white paper here.  You can also download the entire white paper.

Contact Hub Designs for advice on your MDM or data governance initiative.

A shorter, more targeted project (vs. the “ultimate” whiz-bang project with all the technology bells and whistles) pays off better in two important ways:

1. Generally, the costs are lower, because you’re incurring them for a shorter time. That’s obviously not always strictly true (some crash projects can end up being very expensive) but a 6-9 month project usually tends to be less expensive than a 12-24 month project.
2. You’re delivering the expected benefits that much sooner. So whatever value the business is going to gain from your MDM initiative, it will get that value roughly twice as fast if you can go with the targeted 6-9 month project instead of the 12-24 month “mega project”.

If you think back to our recent article on MDM Best Practice #1 – Start with the Need, Pain or Problem (Not “The Solution”), what the business really wants is for their problem to be solved. They don’t want the most elegant solution with the latest ‘whiz bang’ technology.

They’d like to be able to recognize their customer at all touch points; to be able to add new customers easily without accidentally creating a lot of duplicates; to be able to manage customer creditworthiness and risk in an efficient manner; to roll up sales by the customers’ corporate hierarchy; to be able to efficiently identify the untapped prospects in a corporate family, geography or vertical market; to be able to tie all interactions with a customer back to a single view of that customer; and so on.

Not a lot to ask, they’d probably tell you. They’ll probably ask, why can’t we do that now? After all the investments in all the ERP and CRM systems, in all the data warehouses, data marts and business intelligence solutions, we come along with MDM platforms and (gulp) data governance.

We tell the business users that with MDM, on the one hand, we can help them with their burning problems that never seem to get solved any other way. But on the other hand, it’s going to take their direct involvement in a way they’ve probably never had to do before: data governance.

So it’s matter of “to whom much is given, much is expected”. The business will have a new capability that will solve some important business problems, but the business owners and users will have to step up in a way they may not have had to before, by taking ownership of the data, setting policies around data quality, accuracy, completeness, timeliness and consistency, and then agreeing to enforcement of those policies.

Data government is primarily a political endeavor, and as a result, MDM projects have an explicitly political side to them. Be prepared for that, and remember, faster is better.

Contact Hub Designs for advice on your MDM or data governance initiative.

Start with the people, politics and culture, and then move on to the data governance and stewardship processes, then the technology.

The recent Gartner “Magic Quadrant for MDM of Customer Data” by John Radcliffe had a great statement: “To succeed, you should put together a balanced MDM program that creates a shared vision and strategy, addresses governance and organizational issues, leverages the appropriate technology and architecture, and creates the necessary processes and metrics.”

Another illustration of the need to balance the technology with the people and process is a quote by the inventor and entrepreneur, Dean Kamen: “The technology is the easy part. Understanding what drives people – individuals, societies, what makes cultures clash – all of those questions are way, way harder to answer than how to solve any particular technical problem.”

This Best Practices series is based on a talk that I’ve given at the Oracle Applications Users Group COLLABORATE and Oracle OpenWorld conferences a few times. The talk has evolved each time I’ve given it, but one consistent theme has been “being an MDM evangelist”. I believe in the nature of master data management and data governance to fundamentally change the IT architectures, business processes and organizational cultures (how we think of the core data that we use to run our businesses). And I think corporate America is overdue for these changes.

We’re all consumers who’ve had frustrating experiences with companies trying to do simple things like changing our addresses, stop receiving extra copies of catalogs, fixing errors on credit reports, etc. And we’ve all had the opposite experience, when a quick phone call or self service Web portal took care of everything. What a difference in the customer service experience!

And in the business-to-business world, there are a lot of companies out there that would like to make decisions more quickly, based on reliable data, that would like to reduce their supply chain spend, consolidate their enterprise applications, increase their revenue by up-selling customers, get paid more quickly by making sure invoices go to the right address every time, manage credit risk for new customers, understand customers’ corporate hierarchies, cut their new product introduction life cycle in half, and so on.

These are the types of innovations that our companies desperately need to be competitive in the next decade. The economy is improving – but slowly. As an MDM evangelist, what improvements and innovations can you bring to your company? And can you use the balanced, holistic approach to make sure that the shiny, new technology doesn’t outweigh the people, process and information sides of the picture?

You’ll succeed if you recruit the right executive sponsors; invest in creating a data governance team; design your data governance processes, and communicate how the MDM initiative is helping the company to achieve its strategic objectives. And above all, be persistent. Don’t take no for an answer. The company didn’t get into its current situation overnight, and fixing it won’t happen overnight either.

Please let us know – in the comments here or in the forums on the MDM Community – whether you’ve taken on the role of MDM evangelist in your organization, and if you need any help with it, please let us know.

This is very true in master data management (MDM) – where you’ll inevitably come under pressure to oversimplify. It’s not uncommon to have 20-30 source systems (or more) that have to be integrated with the MDM hub. And tackling other initiatives in the enterprise at the same time (like service-oriented architecture or major ERP or CRM upgrades) can increase the pressure. MDM can help with those other initiatives but doing several things at once may increase the overall degree of difficulty.

Remember, if you oversimplify or underestimate, you’ll be under pressure to cut functionality later. Satisfying important requirements will be postponed to later phases, and the business will be disappointed.

So watch out for the temptation to oversimplify. I had a client once who was setting up a customer hub with about five very complex mainframe-based source systems. They were oversimplifying by making the integration from the source systems to the hub one-way only. So new customer records would flow to the hub, but any updates or data quality improvements made in the hub would not flow back to the source systems.

I asked them what the plan was for those updates, and their answer was “manual integration” (which, of course, is no integration at all – just data stewards manually entering the changes a second time back into the source systems). We all know how that turns out – a great opportunity to synchronize updates and data quality improvements from the hub back to the source systems goes untapped.

Another thing I’ve noticed is that data governance can be disruptive to the business unless the business itself is driving the data governance program and it has been well-planned. Then, any disruption seems to be overlooked, much as you’d be willing to overlook a bit of mess from a home renovation when you were living in the house, as long as you got your dream house at the end of the process. But if someone else (IT, for example) tries to impose governance on the business, that’s a different story. Then, any disruption tends to be bitterly resented, since it’s being imposed from the outside.

Please let us know – in the comments here or in the forums on the MDM Community – what you think of this tendency to underestimate the complexity of MDM projects. And I mean it this time – let’s have your comments and “war stories”!

The next article in the series is: MDM Best Practice #10 – Use a Balanced, Holistic Approach

MDM Best Practice #8 – Resist the Urge to Customize

As the various MDM hubs mature, it’s getting easier to resist the temptation to customize. When I first started working with Customer Data Integration (CDI) hubs in 2004, they were a little “rough around the edges”, and sometimes customization was unavoidable.

But we’re six years further into this now, and the major vendors’ platforms are light years ahead of where they were in 2004. At this point, working with the vendor to improve their product in future releases is a better strategy than customization.

And most products allow you to modify the underlying data model – and the various flavors of the user interface – without touching the source code. This is a big improvement, because most of the times, the changes needed by the business are relatively minor – a few new fields here and there, some new reports of course.

One important thing to include in your evaluation of vendors’ platforms is how easy it is to “settle into” the platform – to make those minor changes and to adapt the platform to the way your organization does business. If the platform seems like it would difficult to adapt in this way, consider that a warning sign.

If you do have to customize, do it carefully; make sure your changes will survive an upgrade gracefully and are well documented.

One of the biggest risks is getting “rev locked”. The MDM vendors are still revving their products once or twice a year, so you don’t want to get stuck on an older version. I had one client that was told by their vendor that their technical problems were fixed in the latest release. Unfortunately, they were told by their internal team that the earliest they’d be able to upgrade to that release would be in about 18 months!

One way to avoid this is to build what I call “upgrade competency” into your project and your team during your initial implementation – so you already have one upgrade under your belt during your implementation life cycle. That way, the upgrade process isn’t quite so daunting.

Please let us know – in the comments here or in the forums on the MDM Community – how your organization is dealing with the issue of customizing your MDM platform.

The next article in the series is: MDM Best Practice #9 – Don’t Underestimate the Complexity

There’s not much point in doing master data management if you’re not going to govern the data.

I remember attending an MDM Summit conference a few years ago, and hearing a pharmaceutical company admitting that they had spent 6 months implementing their MDM technology before they realized that they needed to have a data governance component – an organization with the accompanying processes to manage the quality and accuracy of the company’s critical master data. They essentially had to start their project over again after putting that data governance program in place.

The ironic part was that their system integrator partner ended up sponsoring the Data Governance track at the next conference.

Make sure you convince management of the need for a data governance team as part of your MDM implementation, because trying to do master data management without data governance is like trying to fly a plane with only one wing.

Please let us know – in the comments here or in the forums on the MDM Community – how your organization is handing the intertwined nature of MDM and data governance.

The next article in the series is: MDM Best Practice #8 – Resist the Urge to Customize

Today, we’re going to resume our series on Master Data Management Best Practices. Here are the earlier articles in the series:

1. Start with the Need, Pain or Problem (Not “The Solution”)
2. Active, Involved Executive Sponsorship
3. Emphasize the Organizational Change Management Aspects
4. The Business Has To Own MDM and Data Governance
5. Use Your Best Project Managers and People

MDM Best Practice #6 is to think of MDM and data governance as long term programs, not a short term projects.

Start by understanding and describing your current state – where you’re starting from. Then define your “to be” or future state, and analyze the gaps between the current and future states, and how to close them.

Work with the business owners to break the project to close those gaps up into a series of discrete, manageable phases, much as a software company will have a series of releases of functionality in their successive versions of their software over a period of years.

Spend some quality time planning – the time you invest will be repaid many times over. I recommend spending up to 15% – 25% of the total initiative in planning. Don’t forget, you’ll be breaking down silos and coordinating across multiple lines of business, functional areas, channels, geographies, and so on – and sometimes, these areas you’ll be coordinating won’t like one another very much. So you’ll want to allow for plenty of time to plan what will probably end up being a complex, multi-year effort involving a balanced initiative composed of both data governance organization and process and MDM technology implementation.

The other thing to keep in mind is that MDM is never truly “over” – you may reach a plateau or “steady state”, but there will always be master data coming into the company that will have to be cleansed, matched, merged, synchronized, published, analyzed and utilized. And there will always be more you can do – higher levels on the MDM maturity model scale that you can help your organization achieve.

So plan for an MDM “way of life” that continues on, much like Finance or Sales continue on, not a project that “goes live” and then is over.

Please let us know – in the comments here or in the forums on the MDM Community – how your organization deals with the long term nature of MDM and data governance.

The next article in the series is: MDM Best Practice #7 – Create a Data Governance Organization and Processes

Make sure you can’t be derailed by opponents pointing to avoidable project management or organizational issues. You cannot afford to have this type of project fail, so focus on controlling scope, getting the requirements right, managing risks, and communicating effectively and often.

I’ve seen situations where clients have had simultaneous projects going on: MDM, data governance, CRM and ERP. Even though the MDM and data governance projects were the most crucial, foundational efforts, upon which both the CRM and ERP projects depended, the MDM and DG projects seemed to suffer from “brain drain” – where the stronger resources were getting reallocated to the ERP project.

This “brain drain” syndrome is a mistake – the technical complexity of MDM, breaking down the organizational silos, the cultural changes and other “soft stuff”, putting data governance processes in place across the enterprise, all of these factors argue for putting your best people on these transformational programs.

It may be “project management 101″ but don’t put your “B” and “C” players on your most important programs.

Please let us know – in the comments here or in the forums on the MDM Community – what you think of prioritizing your MDM and data governance programs and putting your best people on them.

The next article in the series is: MDM Best Practice #6 – A Long Term Program, Not a Short Term Project

One model that I’ve seen work very well is for the business to lead the data governance initiative, with senior management being involved through a Data Governance Council (which makes policy for enterprise data), with Global Process Owners handling day to day activities in their own functional areas such as marketing, sales, channels, customer support, and finance, and with tactical aspects handled by business data stewards and IT stewards, under the direction of the Global Process Owners and the IT Global Solution Owner.

This three level model (Data Governance Council, Global Process Owners, Data / IT Stewardship) allows the business to set direction at the highest level and coordinate across the enterprise, while still letting the process owners manage activities within their own functional areas. It’s important to break down the silos which are so common in most of today’s corporations, because silos breed the “islands of data” problem. Reuniting and reconciling those “islands of data” is one of the major reasons companies are doing master data management initiatives in the first place.

When MDM is driven solely by IT, the business may not understand it or buy in. In some cases, the business may not even realize MDM is there, if it’s buried too deeply in the “infrastructure”.

The hard truth is that MDM’s nature as an ongoing program means that even if the initial project is funded by IT, the business may not pick it up in Year 2 & beyond – unless the business owns it.

I’ve seen many instances of MDM programs whose first iteration (driven solely by IT) failed, until they started over, recruited sponsors in the business, transferred ownership of the program to them, and took a more business-oriented approach to the initiative.

Please let us know – in the comments here, in the forums on the MDM Community or using the #MDM hashtag on Twitter – what you think of the need for business to own the MDM and data governance initiative.

The next article in the series is: MDM Best Practice #5 – Use Your Best Project Managers and People

Outside perspective can be very helpful here. As I discussed in a recent article, “Org. Change and Data Governance”, organizational change management – as an applied discipline – is used far too rarely on MDM projects. They’re big enough to justify it, and they certainly involve enough corporate politics and cultural change to benefit from a structured approach to organizational change management. My firm, Hub Designs, applies org. change and communications strategy techniques to every project we do.

Most of what I know about organizational change management I learned from my friend, Dr. Burt Reynolds, who is now an Assistant Professor at Southern NH University. We first worked together on an Oracle ERP project at a software company in Massachusetts. One of the reasons that project was successful was the project leadership included a strong org. change component.

In MDM projects, a clear communications strategy that addresses all of the various stakeholders of the initiative, and communicates your messages to them using their preferred methods of communication, over the right time frame, will have a huge impact – particularly if you can tell those stakeholders how MDM and data governance are making a difference and helping the organization realize its strategic goals. Find every occurrence of increased revenue, reduced costs, and easier compliance and risk management, and pass those success stories on to the organization at large.

Please let us know – in the comments here, in the forums on the MDM Community or using the #MDM hashtag on Twitter – what you think of the need for organizational change management in MDM and data governance initiatives.

The next article in the series is: MDM Best Practice #4 – The Business Has To Own MDM and Data Governance

To champion a change (towards managing master data as a true corporate asset) is going to mean significant cultural disruption. In most companies, that type of change is best driven “top down”.

Don’t try to start until this is in place. Work on your elevator pitch, reach out to senior management and educate them on master data management, and work on recruiting your executive sponsors.

MDM and data governance programs are typically not very successful from the “bottom up”. They may start that way, and even show a few small wins, but you’ve got to get the “C suite” interested and engaged at some point in order to get the budget money and the political “juice” you’ll need.

Don’t forget that data governance is largely a political function. I’ve always liked Jill Dyche’s definition of data governance: “Data governance is the decision-rights and policymaking for corporate data, while data management is the tactical execution of those policies.”

When you see the word “decision rights” and “policymaking” next to the words “corporate data”, you know that you’re dealing with an area that is more political than technological. But we need to embrace that, for that is the reality of data governance (or as my friends at Evaxyx in the UK like to call it, “data government”).

And if you think that anything in the enterprise can succeed that is so strongly political without the explicit and continuing support of senior management, I’ve got a bridge in Brooklyn that I’m dying to sell you.

Please let us know – in the comments here or in the forums on the MDM Community – what you think of the political nature of data governance and the need for active, involved executive sponsorship of MDM projects.

The next article in the series is: MDM Best Practice #3 – Emphasize the Organizational Change Management Aspects

I wrote an earlier article on this in October 2007, and it’s proven to be one of the most popular articles on this blog, with more than 4,500 views to date. I’ve spoken on this topic several times at the Oracle Applications Users Group COLLABORATE conference, and at Oracle OpenWorld in 2009 and 2010.

My thoughts on MDM and data governance best practices have changed a bit over the years. At the recent Oracle OpenWorld conference, I co-presented with a couple of great people from Oracle, so I only had about 30 minutes, which forced me to focus and be more concise.

For those of you who couldn’t get to San Francisco for OpenWorld, I’m going to do a series here on this blog, looking at my recent Oracle OpenWorld presentation one best practice at a time.

MDM Best Practice #1 – Start with the Need, Pain or Problem (Not “The Solution”) – the “build it and they will come” approach really doesn’t work for MDM. I had one client where the IT group built a working customer hub, but couldn’t get the business interested in adopting it, and as a result, couldn’t get the funding to continue project beyond Year 1.

To avoid their mistake, make sure MDM solves some key business problems. Find out what your company’s overall corporate strategy is, and figure out how to tie MDM to delivering on that corporate strategy.

In particular, look at the data-related components of your planned and in-flight projects, then see how a centralized data hub can save money. I had one client where the “data components” of their ten planned and in-flight projects totaled about $10 million, and they calculated that by implementing a customer hub, they could achieve those same business goals for $6 million. After their implementation, which lasted 12 months, their actual costs were only $4 million. So they delivered savings of $6 million vs. the data-related costs embedded in the ten separate projects.

This may sound like an IT-driven initiative, but saving $6 million while still achieving the same business goals was a win-win that made the business team and the IT team look good.

Please let us know – in the comments here or in the forums on the MDM Community – what you think of business-driven rather than IT-driven MDM and data governance initiatives.

The next article in the series is: MDM Best Practice #2 – Active, Involved Executive Sponsorship

Let me start out by saying that Hub Designs is vendor agnostic – we partner with all of the leading MDM vendors, including Oracle, Informatica / Siperian, Initiate Systems / IBM, SAP, D&B / Purisma, and Kalido, and are having partnership discussions with others like Orchestra Networks and Stibo Systems.

But my roots in the Oracle community go back to 1995, and my knowledge investment in Oracle’s CRM, ERP and MDM products is considerable. So I feel very comfortable at OpenWorld, and have about 250 Oracle people in my address book.

So although we are vendor agnostic, it’s only natural that we’ve developed a strong relationship with some partners, and are still working on developing that level of partnership with others. It’s hard to have equally deep partnerships with ten or so different companies.

My schedule prevented me from arriving until Tuesday, and when I did get there, I didn’t feel too well. But I did get to some sessions on Wednesday, and I was particularly impressed by “MDM Customer Panel: Implementation Challenges and Best Practices with the MDM Institute, Credit Suisse, Royal Caribbean Cruise Lines, Cricket Communications, and Wind River Systems”.

The session was a very practical Q&A, with different Oracle customers from different industries talking about their experiences, difficulties, and successes over the past four years or so. Several of them had implemented Oracle’s Customer Hub (formerly Siebel Universal Customer Master or UCM), with Wind River having implemented the Customer Data Hub (CDH) product.

The session also included Aaron Zornes, a prominent thought leader and Chief Research Officer of the MDM Institute. It was great to see him and to chat briefly after the session. If you’re able to, you should definitely register for the upcoming MDM and Data Governance Summit in New York City on October 3-5. I’ve been attending these for several years and always find them helpful in order to stay in touch with the pulse of what’s going on in the MDM and data governance space.

The session that I did with Bill Miller and Vanessa Hsu from Oracle was well attended, despite being in the very last time slot of the conference (Thursday at 3:00 pm). We had 101 people in the room, and even though we went a few minutes past the top of the hour, almost everyone stayed to the end. I talked about the need for change in today’s corporations, and the power of being an MDM evangelist in bringing innovation and change back to your company, as well as about the Top Ten best practices that I’ve observed over the past nine years of working in the fields of Data Governance and Master Data Management, across both the customer and product domains.

Bill Miller talked about how Oracle has applied these concepts to its own MDM needs, and its own six year journey from data quality chaos to finely tuned governance machine. It was great to hear, because I’ve known Bill for almost that entire time, and watched him go through some incredible projects, and grow into an important role as Global Solution Owner for Data Quality Management with Oracle’s IT function. He works closely with the business people (the Global Process Owners) in marketing, sales, finance, customer service, and so on. That virtual team is Oracle’s data governance board, and is responsible for some huge improvements in Oracle’s data quality picture over the last few years. Oracle implemented Oracle Customer Hub internally, and made some great process and cultural changes.

Vanessa Hsu is a Senior Product Strategy Manager at Oracle, and is responsible for a new product called Oracle Data Governance Manager. That product is an extension to Oracle Customer Hub, and provides a centralized administration tool for data stewards, giving easy access to key MDM operations, to increase data steward productivity and highlight enterprise-wide data quality metrics at a glance. It’s an important capability that Oracle will extend to its other hub products over its next release cycle.

The “feel on the street” in the MDM track at Oracle OpenWorld this year was that it was “full speed ahead” at Oracle. Gartner recognizes Oracle as one of the leaders in its “Magic Quadrant” for MDM, and deservedly so. There are a lot of smaller vendors with great technology too, but Oracle has done a lot to advance the state of the MDM art, and it was a pleasure to be in San Francisco this week to see their customers talk about their success. It will be interesting to see what happens over the next few years as Oracle introduces Fusion MDM to the market.

For almost ten years, with a few years off during the “Dot Com” era, I implemented Oracle’s CRM and ERP products. One of the things I came to appreciate during that time was the huge difference that including organizational change management makes between a successful implementation and a “less than successful” one.

That’s why I include emphasizing the organizational change management aspects as one of the “Ten Best Practices in Master Data Management and Data Governance” when I speak at conference like the Oracle Applications Users Group COLLABORATE 10 or Oracle OpenWorld.

That’s because big transformational programs like MDM and data governance are not that different from CRM and ERP. Any time you want the organization to embrace new processes and new technology, and more importantly to modify its DNA (that is, its culture), you’ve got to embrace “org. change”.

I’ve got a friend who is a professor in this stuff at Southern New Hampshire University, with a distinctive name – Dr. Burt Reynolds. I first met him on a 12 month ERP project at a $1 billion software company, where he helped define the org. change strategy. I studied what he did very carefully, and I’ve tried to weave it into every project I’ve done since then.

One of the biggest elements is the communications strategy. First, learn about your audience. How do they like to learn about things? Do they like e-mail newsletters, internal web sites, one-on-one meetings with their supervisors, town hall meetings with company leaders, lunch and learn sessions with project team leadership, small training sessions, etc.

Second, think about your message. Some things lend themselves to certain media better than others. Short, snappy messages are probably better suited for town hall meetings. Technical material is better handled in hands-on training sessions. Anything involving changes to individual positions is best suited for individual meetings with supervisors.

What you’ll wind up with is a grid of messages on the left and media across the top. Then you add in the time element (when to deliver these messages), and you’ll have your internal communications campaign.

Steve mentions in his article the ADKAR model for organizational change developed by Prosci: Awareness, Desire, Knowledge, Ability, and Reinforcement.

What this will produce is a well-coordinated internal communications strategy, that when you deliver it, will result in every stakeholder and business constituent being aware of your data governance program, why it’s necessary, and how it links to the overall business strategy of the company.

As for desire to participate in the change, you want to reach as many people as possible, recruit some to be champions of the program, educate others so they’re at least neutral towards it, and keep the number of active opponents as small as possible.

Your communications plan must include a healthy amount of knowledge transfer, because data governance, although not solely a technology driven activity, includes enough technology that the people actively involved in it need to be completely comfortable with it.

You’ll also be raising the bar for the ability and skill of many of the individuals in the company, as well as redesigning some of the processes for entering, updating and consuming master data. Be prepared for the amount of time this is going to take, as well as the force of the political pushback you’ll encounter. People and organizations have a lot of inertia and tend to resist change at first. That’s why reinforcement is so important, by repeating important messages several times and weaving them into different media.

Steve’s article was great, and brought back to me the importance of introducing organizational change management into MDM and data governance programs. It can literally make the difference between success and failure. Please let us know – here in the comments or on in the forums on the MDM Community – what you think of applying org. change to MDM and data governance.