Do you have detailed criteria for evaluating master data management (MDM) tools?
Hey, wait a cotton pickin' minute! Are you asking for our proprietary MDM vendor evaluation methodology? Well, okay then. Here it is.
We evaluate six areas when we do MDM vendor evaluation for clients. They are:
|Data content||The data values reflect the host application system. Any data element name or value is based on the application's rigor.|
|Data quality||Reflects the data quality metrics associated with the master application. There's likely to be duplicates or data idiosyncrasies to support the operational functions of the application.|
Data content changes in meaning and/or value (e.g. phone #1 is home; phone #2 is business) requires manual intervention. A separate communications and tracking process will be necessary. The system wasn't built with data sharing and movement in mind.
Any changes to values based on business processes (updating phone number) may not be tracked or archived. It is based on the application's needs.
Data manipulation occurs as part of the application process. Any updates or modifications will be based on application-based rules.
Data value matching and comparison will be limited to the application's needs and isn't likely to be subject area oriented. (e.g. matching will be limited to keys or exact match instead
Any value conflicts or inconsistencies may require special processing or manual resolution unless that logic has been built into the data collection process.
The rules and policy details are built within the code inside the application. Rule updates and changes are infrequent but feasible (and usually time consuming and/or expensive). The rules are business process- and application function- oriented, not enterprise oriented (think ERP or packaged application).
|Data access and navigation||Data access occurs within the application. It is only available via extracts. External online data manipulation (create, update, delete) is not feasible. Only the application's developers are able to navigate the underlying data structure.|
If you know your functional requirements for these categories, you'll be able to map your requirements to the functions and features offered by key MDM vendors. This is a rigorous and fool-proof way of selecting an MDM tool. It lets you defend your selection based on the given solution's ability to meet your company's business needs, and gets you off the hook for choosing your enterprise-app-vendor-du-jour just because it's the shortest distance between two points.
The white paper titled, "The Baseline on MDM: 5 Levels of Maturity for Master Data Management" is helpful. It details five different functional levels for MDM. The better you can understand what your company needs and the level of complexity involved, the more deliberately you can begin to choose your MDM tool.
Dig Deeper on MDM best practices
Related Q&A from Jill Dyché
Do you need to gather business requirements for an MDM project? Find out and learn how functional requirements are the key difference between the MDM... Continue Reading
Learn about the most common master data management (MDM) project pitfalls that companies run into. Get a list of the major problems that can hold ... Continue Reading
Is it better for companies to go with an enterprise-wide master data management (MDM) implementation or deploy MDM departmentally? Find out which ... Continue Reading