Brotherhood of Master Data - The MDM Cult Series Part 1
Dears,
The reason why the title has the world “cult” is to know that MDM is still not fully explored technology and successful execution of the MDM projects remains the authority of little knowledgeable brotherhood who indeed keep this secret very close to the professional network. This is an attempt to unleash the knowledge of MDM to wide group of audience whom I feel would make the best use of this information in their MDM Initiatives.
This article is designed to give a business-centric view of the master data management (MDM) concept and what challenges will be faced by organizations of various sizes. Business stakeholders within an organization will gain an understanding of the needs of their organization and will be empowered to define the initial MDM vision for their organization. This vision will facilitate the initial decision necessary to implement a master data management solution within their organization.
Different Challenges based on size of Organization
As any business grows, the management of this data is a critical driver to their success. Every acquisition brings in new sets of master data to be merged with the existing business. Although MDM is important to organizations of all sizes, the size of an organization plays a crucial role in how to approach the implementation of MDM.
Many small businesses do not consider their master data a problem to be concerned with. After all, the spreadsheets they currently use to manage their Product List work great and the accounting system is the only location that the chart of accounts needs to exist in. In my experience this is the easiest and cheapest time to handle the master data management problems. The number of stakeholders for each dataset is small. The number of systems that rely on each dataset is very small. This is the time to implement a master data management strategy that can grow with the business. Each new system implementation will benefit from the single source of all of master data.
Mid-size organizations have a number of dependent systems for each set of master data, so system integration starts to become important. The number of stakeholders for each silo of master data is relatively small. These groups may still work in small teams efficiently. Effective master data controls and an owner for each of the master data entities must be defined. These owners, usually called data stewards, are responsible for managing their domains as new systems are integrated into the organization.
Large organizations have a number of challenges when implementing a comprehensive MDM solution. They are large enough that there are several stakeholders for each silo of master data. Many systems rely on these same models of master data. At this size, coordination of data is a central concern and requires the input of many different stakeholders.
Conglomerates are the most complex MDM challenges. While they may be smaller in overall size in term of employees, assets, or revenue than their large organization brethren, the distinguishing characteristic of these organizations is the breadth of their products offerings or the diversity of their businesses. Typically these organizations have a diverse offering that makes tracking their master data very challenging. With a significantly diverse product offering, being mindful of how the different businesses interact is extremely important. Also, many industries have specific regulatory hurdles with regards to customers and products that may not be readily known by the organization as a whole.
Why current systems are ineffective master data Apps
In many applications, especially ERP systems, master data is created and stored as a requirement of these process systems. Some companies may even call the teams that manage the central data for the ERP systems the master data management group. Although this group is a great place to start to source the new roles of true master data management, these systems do not provide many of the features required to properly manage master data for the entire organization.
Some common limitations of these MDM strategies are:
Limited ability to version this master data
Inefficient methods of exporting this data into other applications
Master data is specific to the functions of the system that manages it and doesn’t readily satisfy the requirements of other applications that need to consume it
Inability to properly store hierarchies or change hierarchies as business requirements change
Limited or no ability to model relationships between different data groups
Limited ability to version this master data
Functional systems require master data to run their specific operations for the organization. Their chief consideration is the most current general ledger, cost centers, organizational entities, and products. Companies spend thousands of hours and hundreds of thousands of dollars to re-organize their sales team. Invariably, a large portion of this time and money is spent mapping the old business units to the new structure.
Inefficient methods of exporting data to other applications
Large, business-wide applications are heavily customized for each organization. These systems provide limited ability to transfer data out of the master data systems. Most systems have some export mechanism that resembles a query language with output of text files. The ability to transform this data with system tools during the export process is very limited if it exists at all. It is also very difficult to export changes within a specified period of time. Due to the lack of versioning, it is very unlikely that master data transactions will be available.
Master data is skewed to the functions of the system it is in
These systems have been customized to provide tailored processes to the organization. In the process of customizing these systems, many of the strategies used to customize these processes revolve around making modifications to the master data stored. These changes may work well for their intended function, but as we will see ,storing data in a function-dependent manner makes it less usable to the rest of the organization’s systems.
Inability to properly store hierarchies
Some ERP/CRM solutions tout the ability to store master data hierarchically. In actuality this is usually managed by placing multiple identifiers into an attached attribute. By giving each character in this attribute special meaning, a surrogate-derived hierarchy can be formed in any subscribing reporting engines. This is a messy solution that tends to scale poorly. As a company grows, each of these character sets can become overextended, creating complex interim solutions. Changing the hierarchy requires changing the identifiers of all records, which can be prohibitively expensive.Proper hierarchy storage should allow for both derived-data hierarchy relationships and arbitrary parent-child relationships.
Limited or no ability to model relationships between different data groups
Many solutions are not designed to allow relationships to be made between two disparate data groups. Managing products per customer or products per salesperson can be difficult, if not impossible, as the systems may be working with a small subset of the overall corporate data set.
Watch this space for the second part of this Series
Loving P&C
DC*
Dears,
The reason why the title has the world “cult” is to know that MDM is still not fully explored technology and successful execution of the MDM projects remains the authority of little knowledgeable brotherhood who indeed keep this secret very close to the professional network. This is an attempt to unleash the knowledge of MDM to wide group of audience whom I feel would make the best use of this information in their MDM Initiatives.
This article is designed to give a business-centric view of the master data management (MDM) concept and what challenges will be faced by organizations of various sizes. Business stakeholders within an organization will gain an understanding of the needs of their organization and will be empowered to define the initial MDM vision for their organization. This vision will facilitate the initial decision necessary to implement a master data management solution within their organization.
Different Challenges based on size of Organization
As any business grows, the management of this data is a critical driver to their success. Every acquisition brings in new sets of master data to be merged with the existing business. Although MDM is important to organizations of all sizes, the size of an organization plays a crucial role in how to approach the implementation of MDM.
Many small businesses do not consider their master data a problem to be concerned with. After all, the spreadsheets they currently use to manage their Product List work great and the accounting system is the only location that the chart of accounts needs to exist in. In my experience this is the easiest and cheapest time to handle the master data management problems. The number of stakeholders for each dataset is small. The number of systems that rely on each dataset is very small. This is the time to implement a master data management strategy that can grow with the business. Each new system implementation will benefit from the single source of all of master data.
Mid-size organizations have a number of dependent systems for each set of master data, so system integration starts to become important. The number of stakeholders for each silo of master data is relatively small. These groups may still work in small teams efficiently. Effective master data controls and an owner for each of the master data entities must be defined. These owners, usually called data stewards, are responsible for managing their domains as new systems are integrated into the organization.
Large organizations have a number of challenges when implementing a comprehensive MDM solution. They are large enough that there are several stakeholders for each silo of master data. Many systems rely on these same models of master data. At this size, coordination of data is a central concern and requires the input of many different stakeholders.
Conglomerates are the most complex MDM challenges. While they may be smaller in overall size in term of employees, assets, or revenue than their large organization brethren, the distinguishing characteristic of these organizations is the breadth of their products offerings or the diversity of their businesses. Typically these organizations have a diverse offering that makes tracking their master data very challenging. With a significantly diverse product offering, being mindful of how the different businesses interact is extremely important. Also, many industries have specific regulatory hurdles with regards to customers and products that may not be readily known by the organization as a whole.
Why current systems are ineffective master data Apps
In many applications, especially ERP systems, master data is created and stored as a requirement of these process systems. Some companies may even call the teams that manage the central data for the ERP systems the master data management group. Although this group is a great place to start to source the new roles of true master data management, these systems do not provide many of the features required to properly manage master data for the entire organization.
Some common limitations of these MDM strategies are:
Limited ability to version this master data
Inefficient methods of exporting this data into other applications
Master data is specific to the functions of the system that manages it and doesn’t readily satisfy the requirements of other applications that need to consume it
Inability to properly store hierarchies or change hierarchies as business requirements change
Limited or no ability to model relationships between different data groups
Limited ability to version this master data
Functional systems require master data to run their specific operations for the organization. Their chief consideration is the most current general ledger, cost centers, organizational entities, and products. Companies spend thousands of hours and hundreds of thousands of dollars to re-organize their sales team. Invariably, a large portion of this time and money is spent mapping the old business units to the new structure.
Inefficient methods of exporting data to other applications
Large, business-wide applications are heavily customized for each organization. These systems provide limited ability to transfer data out of the master data systems. Most systems have some export mechanism that resembles a query language with output of text files. The ability to transform this data with system tools during the export process is very limited if it exists at all. It is also very difficult to export changes within a specified period of time. Due to the lack of versioning, it is very unlikely that master data transactions will be available.
Master data is skewed to the functions of the system it is in
These systems have been customized to provide tailored processes to the organization. In the process of customizing these systems, many of the strategies used to customize these processes revolve around making modifications to the master data stored. These changes may work well for their intended function, but as we will see ,storing data in a function-dependent manner makes it less usable to the rest of the organization’s systems.
Inability to properly store hierarchies
Some ERP/CRM solutions tout the ability to store master data hierarchically. In actuality this is usually managed by placing multiple identifiers into an attached attribute. By giving each character in this attribute special meaning, a surrogate-derived hierarchy can be formed in any subscribing reporting engines. This is a messy solution that tends to scale poorly. As a company grows, each of these character sets can become overextended, creating complex interim solutions. Changing the hierarchy requires changing the identifiers of all records, which can be prohibitively expensive.Proper hierarchy storage should allow for both derived-data hierarchy relationships and arbitrary parent-child relationships.
Limited or no ability to model relationships between different data groups
Many solutions are not designed to allow relationships to be made between two disparate data groups. Managing products per customer or products per salesperson can be difficult, if not impossible, as the systems may be working with a small subset of the overall corporate data set.
Watch this space for the second part of this Series
Loving P&C
DC*
No comments:
Post a Comment