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é
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
What’s the biggest BI problem companies keep running into? Overloading data at the expense of functionality, says an expert. Find out how to avoid ... Continue Reading
There’s a lot of confusion about agile business intelligence (BI). Get an expert’s take on what agile BI really is and if it’s a valid BI development... Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.