Do You Need Master Data Management?
Page Contents
Master data management (MDM) is quickly becoming the driving force behind organizing data that is shared across the enterprise. Most applications in use today share data with each other in one form or another. Keeping that data under control, while still available for other processes and future needs, is critical for business intelligence and analytics initiatives.
Master Data Defined
The typical software portfolio leverages lists of data, which are shared and used by line-of-business applications. For example, an ERP system will normally interact with data sets made up of master data, such as a Customer Master, an Item Master and an Account Master. The master data is a key element of an enterprise's intellectual property.
Master data's value proves tantamount for business operations and can be a viable indicator for judging an enterprise's overall value in the world of mergers and acquisitions. Countless businesses have been acquired by larger entities, simply because of the value of the data offered.
Master Data: A Practical Definition
How data is identified, categorized and defined determines the best course of action when it comes to managing master data.
Identifying what should be considered master data starts with understanding the different data types used in an enterprise. Typically, most enterprises deal with five different types of data:
- Unstructured: Normally consists of data found in email, white papers, articles, corporate intranet portals, product and marketing collateral and PDF files.
- Transactional: Data that is related to sales, deliveries, invoices, claims and other interactions.
- Metadata: Repository data, sometimes contained in XML documents, report definitions, column descriptions in a database, log files, connections and configuration files.
- Hierarchical: A type of data that is used to store the relationships between other data. Often found in systems that stress the interrelationship of elements, such as a financial system, or stored separately to illustrate real‐world relationships, such as company organizational structures or product lines. Hierarchical data can at times be considered a superset of an MDM domain, since it can be used to discover the relationships between master data.
- Master: Master data generally falls into four groups: people, places, things and concepts. Those groups are further categorized using subject areas, domain areas or entity types. Subject areas further define the data; for example, the data group “people” can be further broken down into subjects such as customer, employee or salesperson. Some domain areas can be further divided. For example, customer can be segmented based on incentives and history. The granularity of master data domains is fundamentally determined by the extent of variances between the characteristics of the objects within them.
Getting Started with Master Data Management
Defining what constitutes master data is only the first step in the management process. After identifying critical master data elements, it becomes imperative to determine if the actual data should fall under the auspices of a master data management platform.
Without further identification, the concept of master data can wrongfully transform into one of all data in the enterprise, which in essence should never be managed as if it was master data. Avoiding that conundrum means taking appropriate action, driven by understanding the criteria that make up actionable master data.
That criteria includes:
Behavior
Data interaction gives a solid clue to what should be classified as master data. For example, a transactional system always involves master data. That transaction may be a customer purchasing a product or a vendor selling a part, with a partner delivering a crate of materials to a specific location. Other identifiers include concepts where an employee is hierarchically related to their manager, who reports to another employee, who happens to be another manager. A product may be a part of multiple hierarchies, which may describe where the product is stored and who has access to it.
The behavior of the relationship between master data and transactional data can be thought of as a noun/verb relationship. Transactional data captures the verbs, such as sale, delivery, purchase, email and revocation; master data is the nouns.
Life Cycle
Master data can also be defined by the way it is created, read, updated, deleted and searched. Often referred to as the CRUD cycle, businesses normally establish rules which dictate how the data life cycle is executed.
For example, creating a customer record may be bound by a company's business rules. What's more, there may be multiple rule sets based upon customer type, location, industry segment and so on. Each element of the CRUD cycle can have different meanings for different master data types. For example, creating a vendor may have many different rules than for creating an employee.
Cardinality
The number of elements in a set directly impacts whether or not the criteria is met for considering whether or not data should be considered master data. For example, if a company only sells a dozen different products, Master data management may be overkill for managing the related data. Expand that product count to thousands, though, and MDM becomes beneficial to the operational cycle. The importance of having a master data management solution increases as the cardinality increases.
Generation
Master data is less volatile than transactional data, and can be further categorized by the lifespan of the data. Volatility impacts how the data should be managed. For example, a contract for a single executable action will be considered transaction data rather than master data. But a multi-year contract that consists of several actions, locations, events and actors for an ongoing or long-term process may be considered master data and should be managed as such.
Complexity
Simple data entities are relatively easy to manage and do not require the change management offered by master data management. Those simple data entities usually consist of inventory items that are normally collected and tallied, then stored for later use. For example, the number of gallons of gasoline stored at a distribution center may be significant, but each gallon does not need to be tracked or managed individually.
Value
The more value the data has to the organization, the more likely it will be considered a master data element. Value and complexity go hand in hand when it comes to identifying master data.
Reusability
The ability to reuse data is one of the primary drivers behind master data. For example, customer information may be shared across multiple applications, ranging from CRM to invoicing to contracts. If access to that data is limited to any one of the applications using it, operators may be forced to create local data stores and usurp the ability to share that data.
A Master Data Management Challenge
For many organizations, it proves rather simple to enumerate the various master data entity types. However, the challenge lies with how to decide which data items should be treated as master data and how that data should be made available across the enterprise.
To further complicate matters, there are numerous situations where data does not meet the usual criteria for master data, yet should still be managed as such, creating a kind of data “identity crisis.” A rule of thumb: When deciding on what entity types should be treated as master data, it is often better to categorize that data by behavior and attributes within the context of the business needs.
Frank Ohlhorst is an award-winning technology journalist, professional speaker and IT business consultant. He has written for leading technology publications including ComputerWorld, TechTarget, PCWorld, ExtremeTech and Tom's Hardware and business publications including Entrepreneur, Forbes and BNET. He was also the executive technology editor for Ziff Davis Enterprise's eWeek and the former director of the CRN Test Center.
