Thursday, July 17, 2008

Enterprise Level Attributes and Data Governance

Lately I’ve been seeing a lot of discussion throughout the MDM community regarding the topic of building data governance around master data and whether or not MDM can be used as a tool to aid this process because of its ability to rapidly develop a governance process using the native workflow engine. The big question seems to be whether or not MDM should be recommended as a workflow tool for companies facing governance problems with master data. Unfortunately it’s not the easiest question to answer because the two options depend heavily on the scenario.

It's been my experience that a common misunderstanding of the "central master data management" scenario is that there is one system of truth for all of the master data in your landscape. As we know, that doesn't provide any real business benefit. The only people that benefit from that are the end-users (data stewards) because they only have one tool they need to worry about. The real business benefit of a central master data management scenario is the ability to identify what pieces of data in your landscape are truly important to your business. What are the attributes that you really care about providing data integrity, governance, and standards around? Separating those and putting them in a tool like MDM can provide a huge benefit to a business because they can easily adapt standards and provide oversight around your "enterprise level attributes" which can help keep your data clean and free of duplicates which ultimately affects the business processes that use the master data.

Now, a lot of customers want to do this, but a lot of them aren't ready for the organizational change that is associated with an implementation like this. If you are going to do a central master data management scenario then the business should form an organization (EDM group?) that focuses on enterprise data, and all they care about is the attributes that have a direct impact to the quality of the business processes affected downstream. I believe the right thing to do here is to try to get the business to adapt a new procedure for governance if they want to go down the "central master data management" path. However, I don’t think it's a good idea to pitch a central master data management scenario if they are simply trying to build a workflow for master data. So one important question is what is the driver here? Are they interested in building a workflow for master data, and you are curious as to how MDM could play a role? Or are they interested in doing a central create scenario and want to figure out how to build workflow around that? If it's the latter of the two I would suggest you try to get them to adopt a new procedure. If it's the first, then I would say leave MDM out of the picture because plenty of clients build workflow around master data without MDM and it works just fine. It's hard to force an organizational change if the business if not expecting it.

The best scenarios I have seen are where there is a team of data stewards that are involved with the governance process of creating the enterprise level record, then that gets sent out to the partner systems (ECC perhaps) where a separate workflow process occurs for the local attributes, and is performed by a different group of users. Putting all of the attributes in MDM can lead to some complex issues, especially if there are multiple partner systems involved, because people can get confused as to which attributes should be maintained for each partner system and ultimately end up decreasing the overall data quality.