MOM–MDM CRUDS Matter More than Politics of Ownership

The MOM-MDM Paradox

Share Print Related RSS

Manufacturers are experiencing real pain around 1) accurate reporting (KPIs and financial), 2) regulatory compliance and 3) implementing service-oriented architecture (SOA) and software as a service (SaaS). This pain has prompted a great interest in master data management (MDM) at the enterprise level. However, MDM pain is increased dramatically with the application and integration of manufacturing operations management (MOM) systems into the enterprise to support globalization—and it’s not just trying to keep track of the alphabet soup that’s the problem.

Rudimentary MDM Definitions

There are some very well-understood and easily identified classical enterprise master data items, such as “customer” and “product.” In fact, many define master data by simply reciting a commonly agreed upon enterprise master data item list containing such all-purpose general terms as “customer,” “product,” “location,” “employee” and “asset.”

However, identifying the data elements managed by a MOM-MDM system is much more complex and defies such rudimentary definitions. In fact, a lot of confusion and debate swirls around what master data is in the make-to-order SOA  environment of 21st-century manufacturing and how it is qualified, necessitating a much more comprehensive treatment of the subject.

There are essentially five data types:

  • Master: Critical nouns of business and operations generally fall into four groupings: people, things, places and concepts. Further categorizations are called subject areas, domain areas or entity types. For example, within “people” fall the categories of  “customer,” “employee” and “salesperson.” Within “things” fall: “product,” “part,” “store” and “asset.” Within “concepts” fall: “contract,” “warranty” and “licenses.” Finally, within “places” fall the subcategories of “office locations,” “geographic divisions,” “plants” and “work cells.” 
         Domain areas may be further divided. Customers are segmented by incentives and history. A company has normal customers, as well as “premiere” and “executive” customers. Products are segmented by “sector,” “industry” and “plant.” For example, master data requirements, the life cycle, and the CRUDS (created, read, updated, deleted and searched) cycle for a product in the consumer packaged goods (CPG) sector is very different from those in the automotive industry. The granularity of domains is essentially determined by the magnitude of differences between the attributes of domain entities and between the complexity of operations processes and product/market changes.  

Master data is a special type of reference data shared over a number of systems. Debate exists on the term “master data,” since master data is also used for original data, like an original recording. I dispute the advice to avoid using the term “master data.” Original data in the context of an original recording is more correctly referred to as “master copy.”

Classical Master Data. Most enterprise systems have data lists that are shared and used by several applications. For example, a typical ERP system as a minimum has a Customer Master, an Item Master, and an Account Master. This master data is a key company asset. It’s not unusual for a company to be acquired primarily for access to its Customer Master data.

MOM Master Data. MOM Master Data typically are composed of, but not limited to, product recipes/routes, bills of materials (engineering and manufacturing), bills of resources and hierarchies (equipment, materials—raw, intermediate, consumed, and finished goods—and personnel—engineers, operators, mechanics, technicians, etc.— production rules set, quality test specifications and physical assets descriptions. MOM master data sets change dramatically by manufacturing type, product type, SKU count and work order mix/ type.

  • Hierarchical: Hierarchical data stores the relationships between data across systems (ERP, design, MOM, supply chain, etc., as descriptions of real-world relationships, such as company organization structures or product lines. Hierarchical data is sometimes considered a super MDM domain because it is critical to understanding and discovering data relationships. 
  • Transactional: Data related to sales, deliveries, invoices, trouble tickets, claims and other monetary and non-monetary interactions. 
  • Metadata: Master data residing in a formal repository or in various other structured forms, such as XML documents, report definitions, column descriptions in a database, log files, connections and configuration files. 
  • Unstructured: Data found in email, white papers, magazine articles, corporate intranet portals, product specifications, marketing collateral and PDF files.

At a basic level, MDM seeks to ensure an organization does not use multiple and potentially inconsistent versions of the same master data in different parts of its operations. Other data problems include issues with data quality for KPI analytics and financial metrics, consistent classification and identification of data and data-reconciliation issues.

MDM processes include source identification, data collection, data transformation, normalization, rule administration, error detection and correction, data consolidation, data storage, data distribution and data governance. Tools include data networks, file systems, a data warehouse, data marts, an operational data store, data mining, data analysis, data federation and data visualization.

The MOM-MDM Paradox

Manufacturers experience massive issues with MOM-MDM during mergers or acquisitions. Two merging organizations typically create an entity to duplicate master data at the enterprise, product design, financial and production levels. In practice, reconciling several MOM master data sets (production, quality, plant inventory and maintenance operations) and systems present complex difficulties due to existing system dependencies of operations processes, transaction, applications and metrics. As a result, architectures do not merge fully with a “special reconciliation” process to ensure consistency between the data stored across MOM and enterprise systems. Consequently, aggregated financial metrics become real barriers to change, optimization, adaptability and, finally, profitability of the plant work processes. Furthermore, over time as further mergers and acquisitions occur, problems and losses multiply as more master databases appear and data-reconciliation processes become extremely complex and consequently unmanageable and unreliable. Ultimately, over 100 separate, poorly integrated master databases evolve to cause serious operational problems in customer satisfaction, market agility, operational efficiency, decision-support and regulatory compliance.

MDM entities depend on the nature of manufacturers and their markets. MDM processes identify MOM and enterprise sources to collect entity descriptions. During governance, transformation and normalization processes, administrators adapt descriptions to standard formats and data domains to remove duplicate instances of any entity. A separate organizational MDM repository for each MOM and enterprise process is recommended due to the high MOM change rate. MOM and Enterprise MDM must be reconciled in real time so all requests produce the same description, irrespective of the originating sources and the requesting destinations. Otherwise, inaccurate data produces poor decisions. 

Share Print Reprints Permissions

What are your comments?

You cannot post comments until you have logged in. Login Here.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments