Master Data Management has been getting a decent amount of play recently and I figure that I’ll chime in with my opinion on it. First, a definition from Wikipedia is in order:
In computing, master data management (MDM) comprises a set of processes and tools that consistently defines and manages the non-transactional data entities of an organization (also called reference data). MDM has the objective of providing processes for collecting, aggregating, matching, consolidating, quality-assuring, persisting, and distributing such data throughout an organization to ensure consistency and control in the ongoing maintenance and application use of this information.
That’s a mouthful, eh? As I am wont to do, let’s personalize this a bit. I will use an example of a situation that may benefit from the introduction of an MDM tool.
YYZ Enterprises is a standard moving company with its own enterprise systems. It is looking to carve out a niche for itself. To that end, it purchases Limelight, Inc., a small moving company that specializes in transporting high-priced art. Like YYZ, Limelight has its own back office systems–different than those of YYZ. The new company, Moving Pictures, is poised for . …
Master Data Management has been getting a decent amount of play recently and I figure that I’ll chime in with my opinion on it. First, a definition from Wikipedia is in order:
In computing, master data management (MDM) comprises a set of processes and tools that consistently defines and manages the non-transactional data entities of an organization (also called reference data). MDM has the objective of providing processes for collecting, aggregating, matching, consolidating, quality-assuring, persisting, and distributing such data throughout an organization to ensure consistency and control in the ongoing maintenance and application use of this information.
That’s a mouthful, eh? As I am wont to do, let’s personalize this a bit. I will use an example of a situation that may benefit from the introduction of an MDM tool.
YYZ Enterprises is a standard moving company with its own enterprise systems. It is looking to carve out a niche for itself. To that end, it purchases Limelight, Inc., a small moving company that specializes in transporting high-priced art. Like YYZ, Limelight has its own back office systems–different than those of YYZ. The new company, Moving Pictures, is poised for growth but has to deal with regular M&A issues. Here’s where the prospect of MDM comes in.
Because both YYZ and Limelight have disparate systems (with considerable overlap in terms of customer bases and vendors), complete data and system integration at Moving Pictures would be wise. Maintaining two different systems is ill-advised for a number of reasons:
- dual maintenance costs
- lack of a central data repository
- data overlap and inconsistency
- complicated reporting
- increased demands placed on IT for system maintenance
I could go on, but the fundamental point is this: Moving Pictures should clean up all data and bring it into one place. Doing so would allow the new company to realize a number of considerable benefits:
- minimize administrative costs
- provide its employees with a simple, consolidated view of its operations
- give the new company every opportunity to succeed
The last thing that Moving Pictures wants is spaghetti architecture.
Economic Pressures and System/Data Realities
Merging systems takes time. So does cleaning up data. Converting data from Limelight’s system into YYZ’s is not a simple export and load process. Data needs to be mapped, analyzed, and transformed into a format that Limelight’s system can accept. Duplicate vendor, employee, and customer records should be consolidated. What’s more, beyond mere data work, Limelight end-users need to be trained in how to operate YYZ’s system. Finally, on the hardware front, perhaps Moving Pictures need to purchase more powerful servers and a new database to support the business.
Moving Pictures’ management may not provide the time or resources to allow this essential consolidation and system integration to take place. To that end, an MDM tool may provide a ‘band-aid’ solution to the new organization’s underlying issue: disparate data sources and inconsistent data in each. An MDM application can read vendor or customer information from both systems and possibly prevent it from getting worse. Such a tool may be a good stopgap. For example, it may prevent the following scenario from happening: Geddy–a sales rep–enters a sale for a sale to Dreamline Inc., a customer that (behind the scenes) is linked to the ‘old’ CUSTOMERID field on the CUSOTMER table. As a result, he does not get credit for his sale. Consider a related consequence: Dreamline does not receive its order because Moving Pictures ships it to Dreamline’s old address. Dreamline’s CEO (Neil) is so upset that he takes his business elsewhere.
Conclusion
MDM is a relatively new technology and I’d be lying if I claimed to have used it. From what I understand of it, however, MDM is quite a bit like a business intelligence (BI) tool, at least in concept. MDM allows organizations to do some things that they otherwise would not be able to do, such as checking for errors and transforming data elements.
That’s all fine and dandy. However, let’s not forget the underlying premise of these tools: they exist to account for-and ultimately deal with-data discrepancies or redundancies in multiple systems. It’s probably easiest to go ‘old school’ and simply clean up and map enterprise data when an organization mergers with–or acquires–another.
