Six criteria for master data management (MDM) tool evaluation

Digg This!     StumbleUpon     Del.icio.us

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

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.
Change management	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.
Processing	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
Rules/policy	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.