Over the past year, I've written several columns that focused in some way on master data management (MDM). I'm beginning to sound like a broken record, even to myself. The funny thing is, as much as I preach the importance of sound MDM to everyone I meet, the master data problem only seems to be getting worse.
Many of the executives I've talked with recently say their companies are thinking about - or are in the midst of - implementing MDM initiatives to help standardize their master data enterprise wide. However, I'm also hearing quite a few stories about how difficult it is to actually implement an MDM project. For that reason, and because I'm such an advocate of MDM and the potential benefits it can bring to any company, I'd like to address several common pitfalls you're likely to encounter in implementing an MDM project and suggest ways to help avoid them.
One of the most common pitfalls I've seen is when companies try to identify and standardize all their master data elements in a single initiative. This "big bang" approach usually doesn't work for any IT project, MDM initiatives included. It often simply causes confusion and makes master data problems seem intractable.
Instead of trying to resolve all your master data issues at once, begin small with a pilot project on a single master data element. I recommend beginning with the "customer" master data element. This is the most pervasive data element in many companies, and it is linked to most other master data elements. Thus, it is likely that once the customer data element is standardized, you'll have a leg up on standardizing other master data elements such as materials, vendor, product, etc. Also, once you've gotten your feet wet and better understand how the standardization process works, it should be easier to tackle more than one data element at a time.
Another pitfall to avoid - and this is related to the big-bang approach I discussed above - is scope creep. When you begin with a single master data element, such as customer, there will usually be someone who says something like, "Well, we can't understand 'customer' until we define 'material' or 'product.'"
That's simply untrue. Data elements are discrete entities; they can stand alone. They can be defined and standardized regardless of any other entities they're related to. If they can't, then perhaps they're not really data elements themselves but rather attributes of a data element. At any rate, it's extremely important - especially with regard to a pilot MDM project - that you clearly define the scope of the project before you begin and adhere to that scope as much as practicably possible.
A third common issue I've encountered is confusion over who actually "owns" master data elements and who has responsibility for managing the company's master data. You can help avoid this confusion by developing and implementing a data governance plan that clearly delineates data ownership and accountability structures before you begin an MDM initiative - even the pilot initiative.
A well-developed data governance program should employ a model that clearly defines roles and responsibilities as well as hierarchies and accountability structures. Common components of a data governance model include:
- A data management review board to provide strong leadership and oversight for the governance program, to set governance policies and to resolve critical issues;
- An enterprise data governance team responsible for the day-to-day coordination of data governance activities and maintenance of the corporate metadata repository; and
- A management and execution function that includes compliance and change officers, modeling resources and cross-functional representation from the company to execute compliance requirements and manage change.
Finally, perhaps the most critical pitfall to avoid is the failure to show the value of the MDM initiative to the company. If businesspeople think the MDM initiative is simply another IT project, they might not embrace it - and you may even encounter resistance to the project.
One way to avoid this pitfall is to form collaboration between the company and IT leaders of the MDM initiative to show the value of the project to the businesspeople within the company. The collaboration should strive to show how enterprise-wide standardized master data can help provide better access to accurate, consistent data that knowledge workers and decision-makers need to do their jobs. The collaboration should also stress the value of standardized master data in sustaining regulatory compliance and improving business performance.
Each MDM initiative is different because every company is different. Your project may encounter issues that are far different from these that I've outlined. However, if you begin small, stick to your project proposal, put an appropriate data governance plan in place and strive to continually show the value of the MDM initiative to the company, you'll have a good grounding to help identify and overcome issues that might arise.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access