Tag Archive for Master Data Management

Formulate Essential Data Governance Practices

The creation of a  Data Governance function at your organization is a critical success factor in implementing Master Data Management.  Just like any machine on a factory floor, Master Data is an Asset.  An Asset implies ownership, maintenance and value creation: so too with Master Data.  To borrow an analogy from the Manufacturing world, Transactional data is the Widget, and Master data is one of the machines that makes the Widget.  It is part of your organization’s Value Chain.

Unfortunately, firms starting on the road to MDM fall peril to one of two pitfalls on either extreme of the Data Governance mandate.  The first pitfall is to treat MDM as a one-time project, not a program.  Projects have an end-date, Programs are continual.  Have you ever heard of an Asset Maintenance Project?  That’s a recipe for crisis.  Firms which maintain their assets as a Program do far better.

The second pitfall is ask the Data Governance team to do too much, too fast.  Governance cannot do much without some asset to govern.  Have you ever heard of a Machinery Maintenance Program instituted before you figured out what type of machinery you needed, what the output requirements were, or before you made the capital purchase?  I haven’t either.  First, you acquire the capital.  You do so with the expectation that you will maintain it.  Then you put it into production. Then you formulate the maintenance schedule and execute that plan.

In order to successfully stand up a Data Governance function for your Master Data Program, you’ll need to understand these essential roles in Data Governance: Executive Steering, Data Owners, Data Stewards. 

Follow these Do’s and Don’ts:

Do establish an Executive Steering Committee for all Master Data practices in your enterprise, focused upon strategic requirements, metrics and accountability.

Do establish Data Quality Metrics.   Tie them to strategic drivers of the business. Review them regularly.  Your MDM toolset should provide analytics or dashboards to provide this view.

Don’t ask the Steering Committee to own the data model or processes – that is the Data Ownership role.

Do establish a Data Ownership group for each domain of Master Data.  Ownership teams are typically cross-functional, not simply the AR manager for Customer Master Data, or the HR manager for Employee Master Data.  As you evolve down the maturity path, you will find that master data has a broad set of stakeholders – Do be ready to be inclusive.

Do establish regular status meetings where Data Ownership meets with the Executive Steering Committee to review priorities and issues.

Don’t require that Data Owners “handle the data”.  That is the Data Stewardship role.

Do formalize a Data Stewardship team for each domain of Master Data.  Data Stewards are “data people” – business people who live in the data, but with no technical skills required, per se (though technology people can contribute to a Data Stewardship team).

Don’t restrict Data Stewards to just  the people who report to the Data Owner – think cross-functional!

Do anticipate conflicts – Data Owners should have some political skills.  The reality is that Master Data is valuable to a broad set of constituencies within an enterprise.  Be practical as it relates to one faction’s “Wish List” and keep moving the ball forward.

Without a Data Governance function, MDM tends to be a one-time project (“Clean it Once”) and fails to deliver real value.  Without a clear vision of how Data Governance support MDM, it can hold things up. A rational Data Governance function does not need to hold up the execution of a Master Data project – it supports it. Keep Data Governance strategic, cross functional, and flexible. Then, let the MDM technology team deliver the tools.

First Accommodate Master Data, Then Clean It

In this blog post, I want to challenge a deeply held notion of Data Quality and Master Data Management.

I have had many, many conversations with technology professionals seeking to implement MDM in their organization. In those first conversations, among the first questions asked is a complex one, disguised as a simple one – How can I start with clean data?

Listen: if you try to start your Master Data implementation with clean master data – you will never get started!

Instead you need to embrace two fundamental realities of Master Data Management. First, there is no clear authoritative source for your master data (if there were, you wouldn’t have a problem). Second: Data Quality is “Front of House” work. The IT department may have data integration, data profiling, third party reference data and matching algorithms in their toolbox, but they can only do so much. IT tools are Back Office Tools and the IT data cleanups happen in the shadows. When they get it wrong, they get it very wrong and comprehensively wrong (and the explanation is hard to understand).

This sequence of events is straightforward, enables the business to take ownership and provides a clear path to getting started.

  • Accommodate your Data – in order for business people to steward and govern their own data – they need to see it with their own eyes, and they need to see all of it, even the data they don’t like. In order to do this, you must:
    • Maintain a clear relationship between data in the MDM hub and its source – don’t attempt to reduce the volume of records. The Federated approach to MDM does this best.
    • Keep rationalization/mapping to a minimum – avoid cleaning the data as you load it. Its wasteful to do it in ETL code when your MDM toolset is ready to do it for you much more easily.
    • Take a “Come as You Are” approach – avoid placing restrictions on the data at this stage of the project, because this only serves to keep data out of your system. We want the data in.
  • Establish Governance of your Data – once you have all of the data loaded into a Federated data model, you have the opportunity to start addressing the gaps
    • First, take some baseline measurements. How incomplete is your data?
    • Next, begin developing rules which can be enforced in the MDM Hub. These rules should be comprehensible to a business user. Ideally, your toolset integrates the rules into the stewardship experience, so that rules declared in the hub are readily available to them. Once you have a healthy body of rules, validate the data and take another baseline measurement
    • Now your data stewardship team can get to work, and you’ll have real metrics to share with the business with regards to the progress you are making towards data compliance.
  • Improve your Data – MDM toolsets automate the process of improving master data sourced from different systems. They do this in three ways:
    • Standardize your Data – MDM tools help data stewards establish standards and check data against those standards
    • Match your Data – MDM tools help data stewards find similar records from multiple systems and establish a grouping of clusters of records. The Group becomes the “Golden Record” – none of the sources get to be the boss!
    • Harmonize your Data – MDM tools help data stewards make decisions about which sources are most authoritative and can automate the harmonization of data within a grouping

Organizations whose starting approach with MDM is “Get the data clean and Keep the data clean” often fail to even get started. Or worse, they spend a lot of time and money requiring IT to clean the data, and then abandon the project after 6 months with nothing to show for it. Clean, then Load is the wrong order: Flip the Script and stick to these principles.

  1. Design a Federated MDM Data model which simplifies identity management for the master data.
  2. Identify where your master data lives and understand the attributes you want to govern initially.
  3. Bring the master data in as it exists in the source systems.
  4. Remove restrictions to loading your data.
  5. Establish some baseline measurements.
  6. Devise your initial rules set.
  7. Use MDM Stewardship tools to automate standardizing, matching and harmonizing.

5 Reasons to Keep CRM and MDM Separate

In previous articles, I have identified 5 Critical Success Factors for Initiating Master Data Management at your organization, and delved more deeply into the first of these: the creation of a new system which intentionally avoids creating another silo of information.  The second critical success factor is to recognize that MDM tools work best when kept separate from the sources of master data.  A prime example of this is CRM.  Customer Relationship Management (CRM) solutions are often a key topic in my discussions with clients, chiefly with respect to a proposed Customer MDM solution.   I’m going to use CRM to demonstrate why organizations fail to implement Data Governance when they elect to integrate MDM processing into an existing operational system.

It can be enticing to think of CRM as a good place to “do” Customer MDM.   Modern CRM systems are built from the ground up to promote data quality.  Modern CRM solutions have an extensible data model, making it easy to add data from other systems.    Customer data often starts in CRM: following the “Garbage In, Garbage Out” maxim, it seems important to get it right there first.  Finally, software vendors often claim to have an integrated MDM component, for Customers, Products, Vendors and others.

But here are the problems this approach creates:

  1. More than Data Quality – if an operational system like CRM can offer address standardization, third party verification of publicly available data, or de-duplication of records then you should leverage these services.  But keep in mind – these services are to help you achieve quality data for the purposes of making operations in that system work smoothly.  If you have only one operational system, then you probably have no need for MDM.  If you have more than one, and you pick one as the winner, you’ll tie the two systems together very closely, making future integrations extremely daunting.
  2. Data Stewardship Matters – Data Stewardship refers to a role in the organization responsible for maintenance and quality of data required throughout the organization.  In a well-designed Data Governance Framework, data stewards report to the governance team.  It’s not always possible for an organization to have dedicated data stewards; more often,  “Data Steward” is one role added to operational responsibilities.  Now, I would love to tell you that CRM users care about data quality; many of them do.  But sales professionals are often focused on the data they need to close a deal, not the myriad other pieces of information needed to truly drive customer engagement.  Asking them to be responsible for doing so sets the organization up for failure.
  3. Governors Don’t Play Favorites – an MDM system should have the ability to store and represent data as it actually exists and is used in ANY source of master data.  Without this, your data stewardship team cannot really see the data.  If you insist on making CRM the source for master data, your technology team will spend all of their time mapping and normalizing data to match what CRM needs and wants.  This is a waste of time.  The Federation MDM model is designed to move data in quickly and show data stewards how things really look.  Then, and only then, can decisions be made (and automated) about which systems adhere most closely to Enterprise Standards for quality.
  4. Information Silo or Reference Data Set – CRM meets the definition of an Information Silo: it has its own database, and it invents its own identities for Customers, Accounts, Leads, etc.  What happens when an account must be deactivated or merged with another account in order to streamline operational processes.  Well, if any systems are using CRM as their Reference Data Set, you will have massive problems.
  5. Present at Creation – you probably realize that there are lots of sources of Customer Data, some the business likes to talk about, and some they don’t.  I like to separate the two into Sanctioned and Unsanctioned Master Data.  Unlike Sanctioned Master Data, which lives in CRM and ERP and other operational systems managed by IT, Unsanctioned Master Data lives in spreadsheets and small user databases (ex. Microsoft Access) or even websites.  This may surprise you – unsanctioned master data is often the most valuable data in the governance process!  This is where your analysts and knowledge workers are storing important attributes and relationships about your customers, and the source of real customer engagement.  MDM needs to make room for it.

One of the most common misconceptions about how to build an MDM system is the idea that Master Data Management can be best achieved by maintaining a Golden Record in one of many pre-existing operational systems.  This can be a costly mistake and sink your prospects for achieving Data Governance in the long term.  A well implemented Master Data Management system has no operational process aim other than high quality master data.  It must take this stance in order to accept representations of Master Data from all relevant sources.  When this is accomplished, it creates a process agnostic place for stewardship, governance and quality to thrive.

Avoid Creating Another Information Silo with MDM

In my last article, I discussed the five most critical success factors when implementing a Master Data Management solution. At the top of the list was a warning: “Don’t Create Another Information Silo”. What does that mean? Why is that important? What is different about this new system we are calling “MDM”?

I define “Information Silo” as an application which has the following characteristics:

1. The application has its own database.

2. The database is highly normalized, because the designer of the data model has made an effort to reduce duplication of data.

3. Identity is invented in the database, because things like Customer, Product, User all need primary keys to identify the record within the system.

4. Domain Logic controls most, if not all, of the data quality requirements, because encapsulating business logic outside a database promotes re-use.

Each of these principles makes perfect sense for a custom application. But if you use them in your Master Data Management solution, you will make another Information Silo, and you’ll be right back where you started.

Certainly, our Master Data Management solution will include a database, the “MDM Hub”, which will be the central place for data in our system to reside. But we need to design a different kind of database model, unlike many other systems we have designed for the enterprise. What should this data model look like? There are 3 modeling approaches to consider. I’ll explain each, and then tell you which is the best and why.

A Registry approach is the lightweight model whereby only the pointers to source data are stored in the Master Data Hub. We are capturing only minimal attributes in the hub with this pattern, and consumers of data will be required to seek out an authoritative data source elsewhere. Essentially, this MDM pattern is designed to store nothing, only to tell consumers where to get the data. This does not work well when it comes time to implement Data Governance, because the MDM system has not defined a Jurisdiction for the Data Governance team to work in.

A Transaction approach represents the opposite end of the spectrum from Registry, and it helps to address the common fear of “Garbage In, Garbage Out” which so many first-timers experience. The idea with Transaction is that Master Data should be created in a tightly controlled environment which imposes rigor on the master data creation process and ensures that ALL data is collected up front. This approach sounds worthwhile, until you consider what it will take to build such a system: you may as well build a new ERP system. This is the classic trap leading directly to another silo of information!

A Federated approach represents a middle ground between Registry and Transaction. Think of this as the “come as you are” alternative, because we are going to pull the master data from the sources with as little translation as needed, and we are going to leverage the source identity in MDM, combining the name of the source system with the source system’s identifier. The Federated approach recognizes that in order for the data governance team to effectively govern, it needs enough master data attributes to discern critical differences in the MDM hub, but not all of it.

Here is an example of how the Federated model works. Let’s say that we have 5 sources of Customer Master data: 3 ERP (JD Edwards Enterprise One, SAP and Dynamics AX), 1 CRM (SalesForce) and 1 Custom SQL solution used by a Web site. A Federated design would dictate:

  • An Entity named “Source System” whose members would define the sources of data (i.e. JDE, SAP, AX, SFDC, SQL)
  • An Entity named “Customer” whose members would have an identity which would be the combination of the Actual Id value from the source system, prefixed by the Source System code itself (i.e. “JDE-100054”, “SAP-000005478”, “SQL-1”). If the Actual Source System Id is used, then these MDM Identifiers will be unique in the Federated model.
  • Some number of additional attributes which help the stewards of the master data understand if these records represent a common customer. This needs to be defined by the business stakeholders, not the database administrators.
  • A solution for creating a Golden Record in the MDM solution. This solution should match members based upon matching rules and group them together as proposed units. The common grouping for these records is a reference to the Golden Record. For example, the solution should present hierarchy with the Golden Records as parents of the sources.
  • MDM-100 : “BlumShapiro”
  • JDE-100054 : “Blum Shapiro & Co”
  • SAP-0000005478 : “BlumShapiro”
  • SQL-1 : “Bloom Shapiro”

Advantages to this way of working include:

A. Because we are bringing source data in “as is”, data can be loaded quickly into the MDM hub

B. A Federated MDM solution can produce reports which tie out to legacy reports, because they use the same Master Data.

C. Your Data Stewardship team works with the data as it is, without translation or normalization, and has enough data to begin defining data quality rules

D. The solution is positioned nicely for source system synchronization, because a one-to-one relationship exists between the Authoritative record in MDM and the target

A Federated MDM Data Model for your Master Data Management program is the best approach for getting started. It is simple to design, easy for business users to grasp, and avoids creating another data silo. In fact, it is only aggregating from silos and grouping for matching, harmonization and coherence. Most importantly, this approach gets you something fast. It gets your governance team something they can touch and feel. An MDM initiative must deliver value to the business quickly, and to do this it must be relevant as soon as possible.

Next time, I’ll talk about how an MDM differs from CRM, and why you should treat your CRM(s) as “just another source of master data”.