MDM

Balancing the Business Partner / Party Concept

Henrik Gabs Liliendahl2 Comments

Since the birth of this blog one of the key concepts that has been repeatedly visited is the business partner / party concept in Master Data Management (MDM). This concept is about unifying the handling of data about customers, vendors, contacts, employees and other real-world objects that are all legal entities. One of the first posts from 16 years back was called 360° Business Partner View.

Since then, the uptake for this idea has been greatly helped by all the major ERP vendors over the years, as they have adopted this concept in their newer data models.

This is true for SAP, where the business partner concept was introduced as an option in the old ECC system and now has become the overarching concept is the new S4 system. The concept in S4 is explained by SAP here.

Also, Microsoft has adopted a party concept in their D365 solution. This is explained here.

The Technical Balancing Act

While the data models have been twisted to reflect the business partner / party concept in principle, there are still some halfway solutions in force.

For SAP some examples I have come across are:

  • The hierarchy management is for some purposes better suited for the business partner layer and for other purposes better suited for the underlaying customer or vendor layers, which are still there.
  • A real-world employee has at least two business partner records to work properly. This became the standard in the newest versions of S4 as the unified option had multiple challenges.
  • The main SAP MDM add on (MDG) still has a customer workflow side (MDG-C) and a vendor workflow side (MDG-V).

The Business Balancing Act

Though the technical uptake is there, the business uptake is slower.

In all the SAP and D365 renewal projects I have been involved in, there were concerns from parts of the business side about aligning sell-side customer-facing processes and buy-side vendor-facing processes and thus harvesting any business benefits around a unified handling of the two most prominent entities in the business partner / party concept.

The main reasons for the unified approach are:

  • You will always find that many real-world entities have a vendor role as well as a customer role to you.
  • The basic master data has the same structure (identification, names, addresses and contact data.
  • You need the same third-party validation and enrichment capabilities for customer roles and vendor roles.

The main arguments against, as I have heard them, are:

  • I don’t care.
  • So what?
  • Well, yes, but that is a thin business case against all the needed change management.

What are the pros and cons that you have experienced?

The Intersection of Data Observability, MDM and Data Quality

Henrik Gabs Liliendahl2 Comments

Data observability is a new discipline on the rise within data management. As with many new disciplines everything is not new, though. There are several capabilities that come with a data observability solution that have been known for decades within Master Data Management (MDM) and not at least Data Quality Management (DQM).

The brief reason of being for data observability is to prevent data issues at scale. Compared to MDM and DQM you will usually utilize a data observability solution more upstream and have more data sources in scope. The emphasis of data observability is to early and continuously identify data issues. MDM and DQM is geared towards resolving the issues.

Below is a short walkthrough of the common capabilities you can deploy as part of the triangle of data observability, MDM and data quality.

Data Matching

Implementing a data observability solution will usually not extend to data matching capabilities. These capabilities will still reside in the intersection of MDM and data quality.

Data Discovery

Data discovery has been an adjacent part of many MDM solutions as touched on in the post How Data Discovery Makes a Data Hub More Valuable.

You will probably find a better home for data discovery in a data observability solution as this is better deployed for multiple upstream data flows.

Data Profiling

In Data Quality Management (DQM) solutions data profiling has often been seen as a one-off exercise that precedes data quality improvement and data matching, data migration and other data management initiatives.

With a data observability solution, you will be able to implement continuous data profiling and related monitoring.

Metadata Management

Metadata management is essential for data observability, MDM and data quality respectively and over essential for getting the full return of investment in a triangle of data observability, MDM and data quality solutions.

Product vs Material vs Article vs Item

Henrik Gabs LiliendahlLeave a comment

One problem with having English as the lingua franca on this planet is that English have a lot of different words meaning (almost) the same. One example is product, material, article, and item. This entity is the core entity within the master data domain we usually call the product domain.

I have experienced numerous occasions where these words are used to describe different perspectives across lifecycles or granularity in different ways within the same organization operating in manufacturing, distribution, retail, construction or comparable industry.

Product

The word product is part of the product domain in Master Data Management (MDM). It is also part of the adjacent discipline called Product Information Management (PIM). Also, it is part of the upcoming Digital Product Passport (DPP).

Furthermore, the word product is part of the term Universal Product Code (UPC) which is the North American version of the Global Trade Identification Number (GTIN).

We also have the word product as part of the term finished product.

If product is not the overarching term for material, article, and item it is often seen as either:

  • The sellable thing that comes out of a manufacturing process.
  • A higher level in a product hierarchy where there are varying articles/items on a lower level.

Material

In SAP, the predominant ERP application on this planet, the core product entity is called material.

We also have the word material as part of the term raw material.

Material is often seen as a thing that goes into a manufacturing or construction process.

Article

The word article is part of the term International Article Number previously known as European Article Number (EAN) which is the European version of the Global Trade Identification Number (GTIN).

An article is often seen as the level in a product hierarchy where you can assign a GTIN, meaning that the articles with the same GTIN have the same dimensions, color, other specifications, and packing.

This is equivalent to the term Stock Keeping Unit (SKU).

Item

Item is often used as an alternative or neutral term for product, material and/or article. Item is widely used as a column header for the sold products/materials/articles on an sales order and invoice or the requested products/materials/articles on a purchase order.

Proper use

As with so many other similar terms there is no generic proper use that your organization can stick to. There may be a trend or standard in your industry you can adhere to. Anyway, your data governance framework should be able to state the proper use within your organization as part of a business glossary.

Have you formed a business glossary or similar construct that defines how the words product/material/article/item/whatever (in your official language) should be used?

Data Matching Efficiency

Henrik Gabs Liliendahl3 Comments

Data Matching is the discipline within data quality management where you deal with the probably most frequent data quality issue that you meet in almost every organization, which is duplicates in master data. This is duplicates in customer master data, duplicates in supplier master data, duplicates in combined / other business partner master data, duplicates in product master data and duplicates in other master data repositories.

A duplicate (or duplicate group) is where two (or more) records in a system or across multiple systems represent the same real-world entity.

Typically, you can use a tool to identify these duplicates. It can be as inexpensive as using Excel, it can be a module in a CRM or other application, it can be a capability in a Master Data Management (MDM) platform, or it can be a dedicated Data Quality Management (DQM) solution.

Over the years there have been developed numerous tools and embedded capabilities to tackle the data matching challenge. Some solutions focus on party (customer/supplier) master data and some solutions focus on product master data. Within party master data many solutions focus on person master data. Many solutions are optimized for a given geography or a few major geographies.

In my experience you can classify available tools / capabilities into the below 5 levels of efficiency:

The efficiency percentage here is an empirical measure of the percentage of actual duplicates the solution can identify automatically.

In more detail, the levels are:

1: Simple deterministic

Here you compare exact values between two duplicate candidate records or use simple transformed values as upper-case conversion or simple phonetic codes as for example soundex.

Don’t expect to catch every duplicate using this approach. If you have good, standardized master data 50 % is achievable. However, with a normal cleanliness, it will be lower.

Surprisingly many organizations still start here as a first step of reinventing the wheel in a Do-It-Yourself (DIY) approach.

2: Synonyms / standardization

In this more comprehensive approach you can replace, substitute, or remove values or words in values based on synonym lists. Examples are replacing person nicknames with guessed formal names, replacing common abbreviations in street names with a standardized term and removing legal forms in company names.

Enrichment / verification with external data can also be used, for example by standardizing addresses or classifying products.

3: Algorithms

Here you will use an algorithm as part of the comparison. Edit distance algorithms, as we know from autocorrection, are popular here. One frequently used one is the Levenshtein distance algorithm. But there are plenty out there to choose from each with their pros and cons.

Many data matching tools simply let you choose from using one of these algorithms in each scenario.

4: Combined traditional

If your DIY approach didn’t stop when encompassing more and
more synonyms it will probably be here where you realize that further quest for
raising efficiency includes combining several methodologies and doing dynamic
combined algorithm utilization.

A minor selection of commercial data matching tools and
embedded capabilities can do that for you so you avoid reinventing the wheel
one more time.

This will yield high efficiency, but not perfection.

5: AI Enabled

Using Artificial Intelligence (AI) in data matching has been practiced for decades as told in the post The Art in Data Matching. With the general rise of AI in recent years there is renewed interest both at tool vendors and at users of data matching to industrialize this.

The results are still sparse out there. With limited training of models, it can be less efficient than traditional methodology. However, it can for sure also limit the gap between traditional efficiency and perfection.

More on Data Matching

There is of course much more to data matching than comparing duplicate candidates. Learn some more about The Art of Data Matching.

And, what to do when a duplicate is identified is a new story. This is examined in the post Three Master Data Survivorship Approaches.






The Intersection Between MDM, PIM and ESG

Henrik Gabs LiliendahlLeave a comment

As touched on in the post Three Essential Trends in Data Management for 2024, the Environmental, Social and Governance (ESG) theme is high on the data management agenda in most companies. Lately I have worked intensively with the intersection of ESG and Master Data Management (MDM) / Product Information Management (PIM).

In this post I will go through some of the learnings from this.

Digital Product Passport

The European Union concept called the Digital Product Passport (DPP) is on its way, and it will affect several industries, including textile, apparel, and consumer electronics. The first product category that will need to comply with the regulation is batteries. Read more about that in the article from PSQR on the Important Takeaways from CIRPASS’ Final Event on DPP.

I have noticed that the MDM and PIM solution providers are composing a lot of their environmental sustainability support message around the DPP. This topic is indeed valid. However, we do not know many details about the upcoming DPP at this moment.

EPD, the Existing DPP Like Concept

There is currently a concept called Environmental Product Declaration (EPD) in force for building materials. It is currently not known to what degree the DPP concept will overlap the EPD at some point in the future. The EPD is governed by national bodies, but there are quite a lot of similarities between the requirements across countries. The EPD only covers environmental data whereas the DPP is expected to cover wider ESG aspects.

Despite the minor differences between DPP and EPD, there is already a lot to learn from the data management requirements for EPD in the preparation for the DPP when that concept materializes – so to speak.

Environmental Data Management

The typical touchpoint between the EPD and PIM today is that the published EPD document is a digital asset captured, stored, tagged, and propagated by the PIM solution along with other traditional digital assets as product sheets, installation guides, line drawings and more.

The data gathering for the EPD is a typical manual process today. However, as more countries are embracing the EPD, more buyers are looking for the EPD and the requirements for product granularity for the EPD are increasing, companies in the building material industry are looking for automation of the process.

The foundation for the EPD is a Life Cycle Assessment (LCA). That scope includes a lot of master data that reaches far beyond the finished product for which the EPD is created. This includes:

  • The raw materials that go into the Bill of Materials.
  • The ancillary materials that are consumed during production.
  • The supplier’s location from where the above materials are shipped.
  • The customer’s location to where the finished product is shipped.
  • The end user location from where recycling products is shipped.
  • The recycled product that goes back into the Bill of Materials.

All-in-all a clear case of Multi-Domain Master Data Management.

It is easy to imagine that the same will apply to products such as textile, apparel and electronics which are on the radar for the DPP.

Examples of Environmental Data

CO2 (or equivalent) emission is probably the most well known and quoted environmental data element as this has a global warming potential impact.

However, the EPD covers more than twenty other data elements relating to potential environmental impact including as for example:

  • Ozone layer depletion potential – measured as CFC (or equivalent) emission.
  • Natural resource (abiotic) depletion potential – measured as antimony (or equivalent) consumption.
  • Use of fresh water – measured as H2O volume consumption.

Can I help You?

If you are in a company where environmental sustainability and data management is an emerging topic, I can help you set the scene for this. If you are at an MDM/PIM solution provider and need to enhance your offering around supporting environmental sustainability, I can help you set the scene for this. Book a short introduction meeting with me here.

From Platforms to Ecosystems

Henrik Gabs Liliendahl2 Comments

Earlier this year Gartner published a report with the title Top Trends in Data and Analytics, 2023. The report is currently available on the Parsionate site here.

The report names three opportunities within this theme:

  • Think Like a Business,
  • From Platforms to Ecosystems and
  • Don’t Forget the Humans

While thinking like a business and don’t forget the humans are universal opportunities that have always been here and will always be, the move from platforms to ecosystems is a current opportunity worth a closer look.

Here data sharing, according to Gartner, is essential. Some recommended actions are to

  • Consider adopting data fabric design to enable a single architecture for data sharing across heterogeneous internal and external data sources.
  • Brand data reusability and resharing as a positive for business value, including ESG (Environmental, Social and Governance) efforts.

Data Fabric is the Gartner buzzword that resembles the competing non-Gartner buzzword Data Mesh. According to Gartner, organizations use data fabrics to capture data assets, infer new relationships in datasets and automate actions on data.

Data sharing can be internal and external.

In my mind there are two pillars in internal data sharing:

  • MDM (Master Data Management) with the aim of sharing harmonized core data assets as for example business partner records and product records across multiple lines of business, geographies, and organizational disciplines.
  • Knowledge graph approaches where MDM is supplemented by modern capabilities in detecting many more relationships (and entities) than before as explained in the post MDM and Knowledge Graph.

In external data sharing we see solutions for:

External data sharing is on the rise, however at a much slower pace than I had anticipated. The main obstacle seems to be that the internal data sharing is still not mature in many organizations and that external data sharing require interaction between at least two data mature organizations.

MDM For the Finance Domain

Henrik Gabs LiliendahlLeave a comment

Most Master Data Management implementations revolve around the business partner (customer/supplier) domain and/or the product domain. But there is a growing appetite for also including the finance domain in MDM implementations. Note that the finance domain here is about finance related master data that every organization has and not the specific master data challenges that organizations in the financial service sector have. The latter topic was covered on this blog in a post called “Master Data Management in Financial Services”.

In this post I will examine some high-level considerations for implementing an MDM platform that (also) covers finance master data.

Finance master data can roughly be divided into these three main object types:

  • Chart of accounts
  • Profit and cost centers
  • Accounts receivable and accounts payable

Chart of Accounts

The master data challenge for the chart of accounts is mainly about handling multiple charts of accounts as it appears in enterprises operating in multiple countries, with multiple lines of business and/or having grown through mergers and acquisitions.

For that reason, solutions like Hyperion have been used for decades to consolidate finance performance data for multiple charts of accounts possibly held in multiple different applications.

Where MDM platforms may improve the data management here is first and foremost related to the processes that take place when new accounts are added, or accounts are changed. Here the MDM platform capabilities within workflow management, permission rights and approval can be utilized.

Profit and Cost Centers

The master data challenge for profit and cost centers relates to an extended business partner concept in master data management where external parties as customers and suppliers/vendors are handled together with internal parties as profit and cost centers who are internal business units.

Here silo thinking still rules in my experience. We still have a long way to go within data literacy in order to consolidate financial perspectives with HR perspectives, sales perspectives and procurement perspectives within the organization.

Accounts Receivable and Accounts Payable

The accounts receivable data has an overlap and usually share master data with customer master data that are mastered from a sales and service perspective and accounts payable data has an overlap and usually share master data with supplier/vendor master data that are mastered from a procurement perspective.

But there are differences in the selection of parties covered as touched on in the post “Direct Customers and Indirect Customers”. There are also differences in the time span of when the overlapping parties are handled. Finally, the ownership of overlapping attributes is always a hard nut to crack.

A classic source of mess in this area is when you have to pay money to a customer and when you get money from a supplier. This most often leads to creation of duplicate business partner records.

MDM Platforms and Finance Master Data

Many large enterprises use SAP as their ERP platform and the place of handling finance master data. Therefore, the SAP MDG-F offer for MDM is a likely candidate for an MDM platform here with the considerations explored in the post “SAP and Master Data Management”.

However, if the MDM capabilities in general are better handled with a non-SAP MDM platform as examined in the above-mentioned post, or the ERP platform is not (only) SAP, then other MDM platforms can be used for finance master data as well.

Informatica and Stibo STEP are two examples that I have worked with. My experience so far is though that compared to the business partner domain and the product domain these platforms at the current stage do not have much to offer for the finance domain in terms of capabilities and methodology.

SAP and Master Data Management

Henrik Gabs Liliendahl4 Comments

SAP is the predominant ERP solution for large companies, and it seems to continue that way as nearly all these organizations are currently on the path of updating and migrating from the old SAP version to the new SAP S/4 HANA solution.

During this process there is a welcomed focus on master data and the surrounding data governance. For the technical foundation for that we see 4 main scenarios:

  • Handling the master data management within the SAP ERP solution
  • Adding a plugin for master data management
  • Adding the SAP MDG offering to the SAP application stack
  • Adding a non-SAP MDM offering to the IT landscape

Let’s have a brief look into these alternative options:

MDM within SAP ERP

In this option you govern the master data as it is represented in the SAP ERP data model.

When going from the old R/3 solution to the new S/4 solution there are some improvements in the data model. This includes:

  • All business partners are in the same structure instead of having separate structures for customers and suppliers/vendors as in the old solutions.
  • The structure for material master objects is also consolidated.
  • For the finance domain accounts now also covers the old cost elements.

The advantage of doing MDM within SAP ERP is avoiding the cost of ownership of additional software. The governance though becomes quite manual typically with heavy use of supplementary spreadsheets.

Plugins

There are various forms of third-party plugins that help with data governance and ensuring the data quality for master data within SAP ERP. One of those I have worked with is it.master data simplified (it.mds).

Here the extra cost of ownership is limited while the manual tasks in question are better automated.

SAP MDG

MDG is the master data management offering from SAP. As such, this solution is very well suited for handling the master data that sits in the SAP ERP solution as it provides better capabilities around data governance, data quality and workflow management.

MDG comes with an extra cost of ownership compared to pure SAP ERP. An often-mentioned downside of MDG compared to other MDM platforms is that handling master data that sits outside SAP is cumbersome in SAP MDG.

Other MDM platforms

Most companies have master data outside SAP as well. Combined with that other MDM platforms may have capabilities better suited for them than SAP MDG and/or have a lower cost of ownership than SAP MDG. Therefore, we see that some organizations choose to handle also SAP master data in such platforms.

Examples of such platforms I have worked with are Informatica, Stibo STEP, Semarchy, Reltio and MDO (Master Data Online from Prospecta Software).

While MDO is quite close to SAP other MDM platforms, for example Informatica and Stibo STEP, have surprisingly very little ready-made capability and methodology for co-existing with SAP ERP.

Master Data Management in Financial Services

Henrik Gabs LiliendahlLeave a comment

Master Data Management (MDM) has a lot of common considerations regardless of the industry where MDM will be blueprinted and implemented and then there are some key aspects to consider specifically for a given industry.

A recent blog post here on the blog examined the specialties of doing Master Data Management (MDM) in the manufacturing sector. The post was called 4 Key Aspects of Master Data Management in Manufacturing.

In this post two specialties of doing MDM in the financial service sector will be examined. These are:

  • The impact of regulations
  • Data domains in focus

The Impact of Regulations

Doing business in the financial service sector is heavily impacted by the various regulations enforced by authorities across the globe. These regulations aim at improving market confidence, financial stability, and consumer protection and stretch across concepts as Know Your Customer (KYC), Anti Money Laundering (AML) and many more. Doing data management in the financial service sector revolves a lot around adhering to these regulations and the embedded concepts.

When implementing a Master Data Management (MDM) solution in the financial sector you will need a broad set of capabilities that both cover the traditional goals of managing master data as for example getting a Single Customer View (SCV) and then also the specifics of what is entailed in and demanded for Knowing Your Customer (KYC).  

Data Domains in Focus

In master data management we often focus on three major data domains: Customer master data, supplier master data and product master data. These domains are also relevant for master data management in financial services however often with some other meaning, naming, and additions.

The customer is king in any business. In financial services a customer is though more often being regarded as one of several different party roles that are involved in business processes. The customer in various roles is one of more counterparties being involved in transactions taking place. Therefore, we for example see the party domain being more naturally accepted by business stakeholders in the financial service sectors than we until now see in other industries.

From Master Data Management to Data Hub Strategy

The requirements for master data management in the financial service sector will quite early in the journey lead to that solutions must be able to encompass Extended Master Data Management. This can also be seen as a data hub strategy where data quality and data governance play a crucial role.

You can learn more about these considerations in a webinar co-hosted by Semarchy with participants from Sumitomo, HSBC and Bloomberg discussing How to establish data quality and data governance for analytics in financial services.

Extended MDM Revisited

Henrik Gabs LiliendahlLeave a comment

Master Data Management (MDM) continues to scale as explored in the post about how MDM inflates.

One inflating trend can be named Extended MDM, which is about taking other data domains than the traditional customer, supplier, and product domains under the MDM umbrella and thus creating a governed data hub.

Which entities that will be is industry specific. Examples from retail are warehouses, stores, and the equipment within those. Examples from pharma are own and affiliated plants, hospitals and other served medical facilities. Examples from manufacturing are plants, warehouses as well as the products, equipment and facilities where the produced products are used within.

Extended MDM can be seen as a twin discipline to a data hub strategy with the twist that the MDM approach adds governance to reflecting, integrating, and meshing critical application in a centralized fashion. This trend was touched in the post MDM Terms on the Move in the Gartner Hype Cycle with reference to the latest Hype Cycle for Data and Analytics Governance and Master Data Management.

The digital twin concept is another trend that, so to speak, is a twin of the Extended MDM trend. You can view all the traditional objects (domains) in MDM and the new to come as digital twins as explained in the post 4 Concepts in the Gartner Hype Cycle for Digital Business Capabilities that will Shape MDM.