Tag Archives: MDM

Six AI and ML Use Cases Within MDM

Posted on by
Reply

One of the hottest trends in the Master Data Management (MDM) world today is how to exploit Artificial Intelligence (AI) and ignite that with Machine Learning (ML).

This aspiration is not new. It has been something that have been going on for years and you may argue about when computerized decision support and automation goes from being applying advanced algorithms to being AI. However, the AI and ML theme is getting traction today as part of digital transformation and whatever we call it, there are substantial business outcomes to pursue.

As told in the post Machine Learning, Artificial Intelligence and Data Quality perhaps all use cases for applying AI is dependent on data quality and MDM is playing a crucial role in sustaining data quality efforts.

Here are six use cases that are commonly being addressed by AI and ML capabilities:

AI MDM DQ Use Cases

  • Translating between taxonomies: As reported in the post Artificial Intelligence (AI) and Multienterprise MDM emerging technologies can help in translating between the taxonomies in use when digital transformation sets a new bar for utilizing master data in business ecosystems.
  • Transforming unstructured to structured: A lot of data is kept in an unstructured way and to in order to systematically exploit these data in AI supported business process we need make data more structured. AI and ML can help with that too.
  • Data quality issue prevention: Simple rules for checking integrity and validating data is good – but unfortunately not good enough for ensuring data quality. AI is a way to exploit statistical methods and complex relationships.
  • Categorizing data: Digital transformation, spiced up with increasing compliance requirements, has made data categorization a must and AI and ML can be an effective way to solve this task that usually is not possible for humans to cover across an enterprise.
  • Data matching: Establishing a link between multiple descriptions of the same real-world entity across an enterprise and out to third party reference data has always been a pain. AI and ML can help as examined in the post The Art in Data Matching.
  • Improving insight: The scope of MDM can be enlarged to Extended MDM Platforms where other data as transactions and big data is used to build a 360-degree view of the master data entities. AI and ML is a prerequisite to do that.

Data Fabric vs MDM

Posted on by
Reply

New terms are constantly emerging in the data management space. One of these is “Data Fabric”.

According to Gartner, the analyst firm, data fabric “enables frictionless access and sharing of data in a distributed network environment.” Usually, one would associate data fabric with big data and edge computing. However, data fabric does embrace all kind of data and computing from the ones mentioned over multi-cloud to traditional on-premise computing and the data stores within.

Data fabric and Master Data Management (MDM) have the same aim, which is that all (master) data must be shared across the enterprise – and eventually also in business ecosystems. This is a prerequisite for successful digital transformation.

Lately, there has also been a development in the conception of MDM, where other data than master data are encompassed in some of the platforms offered as examined in the post Master Data, Product Information, Reference Data and Other Data.

So, there is clearly a union and an intersection of data fabric and MDM.

Data Fabric vs MDM

What ERP Applications Do and Don’t Do

Posted on by
Reply

The functionality of Master Data Management (MDM) and Product Information Management (PIM) solutions are in many organizations (yet) being taken care of by ERP applications.

However, there are some serious shortcomings in this approach.

If we look at party master data (customer roles and supplier roles) a classic system landscape can besides the ERP application also have a CRM application and a separate SRM (Supplier Relationship Management / Supplier Onboarding) application. The master data entities covered by these applications are not the same.

ERP do dont party

Party master data

On the sell side the CRM application will typically also hold a crowd of prospective customers that are not (yet) onboarded into the ERP application. In many cases the CRM application will also have records describing indirect customers that will never be in the ERP application. Only the existing direct customers are shared between the CRM and ERP application. Besides that, the ERP application may have accounts receivable records that have never been onboarded through the CRM application.

On the buy side a functionality of an SRM application is to track the onboarding process and thereby be the system of record for prospective suppliers. Only existing suppliers will be shared between the ERP application and the SRM application. Besides that, the ERP application will have accounts payable records that have never been onboarded through the SRM application.

A main reason of being for a Master Data Management (MDM) solution is to provide a shared registry of every real-world party entity now matter in what application they are described and thereby ensuring consistency, uniqueness and other data quality dimensions.

When looking at product data, ERP applications must often be supplemented by other applications in order to handle detailed and specific topics.

ERP do dont product

Product data

Product Lifecycle Management (PLM) applications are becoming popular when enterprise units as R&D, product management and others have to be supported in handling the series of detailed events that takes place from when a new product is thought of for the first time all through that it is retired and even after that in the period where complaints and other events may occur. ERP applications can only properly handle the main status events as when the product is ready for sale for the first time, when sale is blocked and when the last piece is taken away from the inventory.

Product Information Management (PIM) applications are becoming popular when enterprise units as sales and marketing need to provide specific product data that varies between different product groups. Not at least the rise of ecommerce has driven a demand for providing very detailed and specific product information to support self-service selling. ERP applications are not built to cater for this complexity and the surrounding functionality.

The information demand in this scenario does also encompass handling a variety of digital assets going from product images in many angles, line drawings, videos and more. Depending on the range of requirements this may be handled in a PIM application or separately in a DAM (Digital Asset Management) application.

Where there is no PIM and/or PLM solution in place, the fallback solution to cover the requirements not fulfilled by ERP is a bunch of spreadsheets.

The reason of being for multidomain MDM solutions is to cover the full spectrum of party entities, product entities together with other master data domains as locations and assets.

Check out the range of solutions to cover this space on this list.

Six MDMographic Stereotypes

Posted on by
Reply

In the Select your solution service here on the site there are some questions about the scope of the intended MDM / PIM / DQM solutions and the number of master data entity records. These are among others:

  • How many B2C customer (consumer, citizen) records are in scope for the solution?
  • How many B2B customer / supplier (company) records are in scope for the solution?
  • How many product (SKU) records are in scope for the solution?

When looking at what the needed disciplines, capabilities and eventually what solution is the best fit there are some stereotypes of organizations where we see the same requirements. Here are six such stereotypes:

MDMographic Stereotypes

In type A, B and C party master data management is in focus, as the number of products (or services) is limited. This is common for example in the financial services, telco and utility sectors.

Type A is where we have both B2C customers and B2B customers. Besides B2B customers we also have suppliers and some company master data entities act both in customer and supplier roles or in other business partner (BP) roles.

Type B is where the business model is having B2B customers. One will though always find some anomalies where the customers are private, with selling to employees as one example.

Type C is where the business model is having B2C customers. One will though often find some examples of having a small portion of B2B customers as well. We find type C organizations in for example healthcare, membership and education.

In type M, D and R product master data management is of equal or more importance as party master data management is. At these stereotypes, we therefore also see the need for Product Information Management (PIM).

Type M is found at manufacturers including within pharmaceuticals. Here the number of products, customers and suppliers are in the same level. Customers are typically B2B, but we see an increasing tendency of selling directly to consumers through webshops or marketplaces. Additionally, such organizations are embarking in caring about, and keeping track of, the end costumers as in B2B2C.

Type D is merchants being B2B dealers and distributors (wholesale). Though it is still common to separate customer roles and supplier roles, we see an increasing adoption of the business partner (BP) concept, as there can be a substantial overlap of customer and supplier roles. In addition, suppliers can have fictitious customer (accounts receivable) roles for example when receiving bonusses from suppliers.

Type R is merchants being retailers. With the rise of ecommerce, retailers have the opportunity of, within the regulations in place, keeping track of the B2C customers besides what traditionally have been done in loyalty programs and more.

All master data domains, also those besides parties and products, matters in some degree to all organizations. The stereotypes guide where to begin and solution providers have the opportunity of doing well with the first domain and, if covered, proceed with the engagement when other domains come into play.

Master Data, Product Information, Reference Data and Other Data

Posted on by
Reply

There is a trend on the data management market that the solutions are either going very niche (best-of-breed) in the data domain covered or they are encompassing a broader range of data types.

This can be seen in the spectrum of master data and product information as reported in the post MDM, PIM or Both.

We also see that governance and management of reference data is included in addition to managing master data as told in the post What is Reference Data Management (RDM)?

Some MDM (and RDM) solutions also extend the reach to cover aspects of transaction data and big data. The main scenarios covered are:

  • Matching of party entities in traditional systems of record with the parties referenced in social streams and weblogs (systems of engagement) as well as in sensor data. This can be used in creating a Customer Data Platform (CDP).
  • Extending data quality and data performance dashboards related to master data to cover aggregated transaction data and big data held in data warehouses and data lakes by using a shared set of reference data.

When product information is to be shared in business ecosystems through Product Data Syndication (PDS), this can be accelerated by using a data lake concept and new data stores as staging areas. This is due to that a main challenge here is that the data quality standards on the providing side most often are different from the data quality standards on the receiving side.

MDM PIM RDM and other data

The diagram is a variation of a diagram included in the whitepaper Intelligent Data Hub – Taking MDM to the Next Level. The original is developed together with Salah Kamel, CEO at Semarchy.