Data Architecture

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.

4 Key Aspects of Master Data Management in Manufacturing

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.

For manufacturing I have found these 4 aspects as key areas when making the roadmap and deciding on Master Data Management architecture principles:

● The impact of Internet of Things (IoT) and Industrial Internet of Things (IIoT)
● Balancing global and local
● Mix of implementation styles
● Direct and indirect customers

The impact of Internet of Things (IoT) and Industrial Internet of Things (IIoT)

More and more produced products are smart devices. This goes for household appliances, power tools, cars and much more. Thus, they are part of the Internet of Things (IoT) meaning that each instance of the product (each produced thing) has its own identity, with a specific configuration, with specific ownership and caretaker-ship and each thing is producing streams of data. This will considerably extend the reach of Data Management and will require your Master Data Management to be open towards business partners.

For manufacturing the producing equipment is also smart devices with a lot of data involved and this can only be sustainable maintained and governed by a master data approach. This realm is sometimes called Industrial Internet of Things (IIoT) which is a facet of Industry 4.0.

Balancing global and local

In manufacturing you can only centralize master data management to a certain degree. There are manufacturing and adjacent processes that are best kept localized due to essential variances in product characteristics, geographic differences and other specializations in line of work.

Therefore, finding the right balance between global and local is a crucial point in blueprinting your manufacturing data management solution, reaching the best fit Master Data Management architecture and building the overarching data governance framework.

Mix of implementation styles

For the same reasons you will not be able to follow a full-blown centralized Master Data Management implementation style. You will need to go for a consolidation Master Data Management style but not necessarily for all data domains and subdomains. You can mix these two styles in what can be seen as a co-existence Master Data Management style.

Direct and indirect customers

In manufacturing your direct customers are typically distributors and retailers who have the end-user customers as their direct customers. However, it happens that you have a business scenario where the same end-users also become your direct customer as a manufacturer. Also, you as a manufacturer for many reasons will benefit from loyally share the end-user customer data with your business partners.

Your Master Data Management implementation should cater for providing a true 360-degree view on customers in this complex business setup.

Learn more

One good resource for a deeper dive into the Master Data Management Architecture considerations in manufacturing is a presentation by my long-time data management peer Magnus Wernersson and Pekka Tamminen of Solita. Find the YouTube video here provided by Semarchy: Volvo Cars – Data Centricity & Digital Innovations with MDM Architecture.

How MDM Inflates

Henrik Gabs LiliendahlLeave a comment

Since the emerge of Master Data Management (MDM) back in 00’s this discipline has taken on more and more parts of the also evolving data management space.

The past

It started with Customer Data Integration (CDI) being addressing the common problem among many enterprises of having multiple data stores for customer master data leading to providing an inconsistent face to the customer and lack of oversight of customer interactions and insights.

In parallel a similar topic for product master data was addressed by Product Information Management (PIM). Along with the pains of having multiple data stores for product data the rise of ecommerce lead to a demand for handling much more detailed product data in structural way than before.

While PIM still exist as an adjacent discipline to MDM, CDI mutated into customer MDM covering more aspects than the pure integration and consolidation of customer master data as for example data enrichment, data stewardship and workflows. PIM has thrived either within, besides – or without – product MDM while supplier MDM also emerged as the third main master data domain.   

The present

Today many organizations – and the solution providers – either grow their MDM capabilities into a multidomain MDM concept or start the MDM journey with a multidomain MDM approach. Multidomain Master Data Management is usually perceived as the union of Customer MDM, Supplier MDM and Product MDM. It is. And it is much more than that as explained in the post What is Multidomain MDM?

As part of a cross-domain thinking some organizations – and solution providers – are already preparing for the inevitable business partner domain as pondered in the post The Intersection of Supplier MDM and Customer MDM.

The PIM discipline has got a subdiscipline called Product Data Syndication (PDS). While PIM basically is about how to collect, enrich, store, and publish product information within a given organization, PDS is about how to share product information between manufacturers, merchants, and marketplaces.

The future

Interenterprise MDM will be the inflated next stage of the business partner MDM and Product Data Syndication (PDS) theme. This is about how organizations can collaborate by sharing master data with business partners in order to optimize own master data and create new data driven revenue models together with business partners.

It is in my eyes one of the most promising trends in the MDM world. However, it is not going to happen tomorrow. The quest of breaking down internal data and knowledge silos within organizations around is still not completed in most enterprises. Nevertheless, there is a huge business opportunity to pursue for the enterprises who will be in the first wave of interenterprise data sharing through interenterprise MDM.

Extended MDM is the inflated next scope of taking other data domains than customer, supplier, and product under the MDM umbrella.

Reference Data Management (RDM) is increasingly covered by or adjacent to MDM solutions.

Also, we will see handling of locations, assets, business essential objects and other digital twins being much more intensive within the MDM discipline. 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 their produced products are used within.

The handling of all these kind of master data on the radar of a given organization will require interenterprise MDM collaboration with the involved business partners.

Organizations who succeed in extending the coverage of MDM approaches will be on the forefront in digital transformation.

Augmented MDM is the inflated next level of capabilities utilized in MDM as touched in the post The Gartner MDM MQ of December 2021 and Augmented MDM. It is a compilation of utilizing several trending technologies as Machine Learning (ML), Artificial Intelligence (AI), graph approaches as knowledge graph with the aim of automating MDM related processes.

Metadata management will play a wider and more essential role here not at least when augmented MDM and extended MDM is combined.    

Mastering this will play a crucial role in the future ability to launch competitive new digital services.

MDM and Knowledge Graph

Henrik Gabs Liliendahl1 Comment

As examined in a previous post with the title Data Fabric and Master Data Management, the use of the knowledge graph approach is on the rise.

Utilizing a knowledge graph has an overlap with Master Data Management (MDM).

If we go back 10 years MDM and Data Quality Management had a small niche discipline that was called (among other things) entity resolution as explored in the post Non-Obvious Entity Relationship Awareness. The aim of this was the same that today can be delivered in a much larger scale using knowledge graph technology.

During the past decade there have been examples of using graph technology for MDM as for example mentioned in the post Takeaways from MDM Summit Europe 2016. However, most attempts to combine MDM and graph have been to visualize the relationships in MDM using a graph presentation.

When utilizing knowledge graph approaches you will be able to detect many more relationships than those that are currently managed in MDM. This fact is the foundation for a successful co-existence between MDM and knowledge graph with these synergies:

  • MDM hubs can enrich knowledge graph with proven descriptions of the entities that are the nodes (vertices) in the knowledge graph.
  • Additional detected relationships (edges) and entities (nodes) from the knowledge graph that are of operational and/or general analytic interest enterprise wide can be proven and managed in MDM.

In this way you can create new business benefits from both MDM and knowledge graph.

The Intersection of Supplier MDM and Customer MDM

Henrik Gabs LiliendahlLeave a comment

When blueprinting a Master Data Management (MDM) solution one aspect is if – or in what degree – you should combine supplier MDM and customer MDM. This has been a recurring topic on this blog as for example in the post How Bosch is Aiming for Unified Partner Master Data Management.

In theory, you should combine the concept for these two master domains in some degree. The reasons are:

  • There is always an overlap of the real-world entities that has both a customer and a supplier role to your organization. The overlap is often bigger than you think not at least if you include the overlap of company family trees that have members in one of these roles.
  • The basic master data for these master data domains are the same: Identification numbers, names, addresses, means of communication and more.
  • The third-party enrichment opportunities are the same. The most predominant possibilities are integration with business directories (as Dun & Bradstreet and national registries) and address validation (as Loqate and national postal services).

In practice, the problem is that the business case for customer MDM and supplier MDM may not be realized at the same time. So, one domain will typically be implemented before the other depending on your organization’s business model.

Solution Considerations

Most MDM solutions must coexist with an – or several – ERP solutions. All popular enterprise grade ERP solutions have adapted the business partner view with a common data model for basic supplier and customer data. This is the case with SAP S/4HANA and for example the address book in Microsoft Dynamics AX and Oracle JD Edwards.

MDM solutions themselves does also provide for a common structure. If you model one domain before the other, it is imperative that you consider all business partner roles in that model.

Data Governance Considerations

A data governance framework may typically be rolled out one master data domain at the time or in parallel. It is here essential that the data policies, data standards and business glossary for basic customer master data and basic supplier master data is coordinated.

Business Case Considerations

The business case for customer MDM will be stronger if the joint advantages with supplier MDM is incorporated – and vice versa.

This includes improvement in customer/supplier engagement and the derived supply/value chain effectiveness, cost sharing of third-party data enrichment service expenses and shared gains in risk assessment.  

Product Model vs Product Instance

Henrik Gabs LiliendahlLeave a comment

When working with the product domain in Master Data Management (MDM) and with Product Information Management (PIM) we have traditionally been working with the product model meaning that we manage data about how a product that can be produced many times in exactly the same way and resulting in having exactly the same features. In other words, we are creating a digital twin of the product model.

As told in the post Spectre vs James Bond and the Unique Product Identifier the next level in product data management is working with each product instance meaning each produced thing that have a set of data attached that is unique to that thing. Such data can be:

  • Serial number or other identification as for example the Unique Device Identification (UDI) known in healthcare
  • Manufacturing date and time
  • Specific configuration
  • Current and historical position
  • Current and historical owner
  • Current and historical installer, maintainer and other caretaker
  • Produced sensor data if it is a smart device

There is a substantial business potential in being better than your competitor in managing product instances. This boils down to that data is power – if you use the data.

When managing this data, we are building a digital twin of the product instance.

Maintaining that digital twin is a collaborative effort involving the manufacturer, the logistic service provider, the owner, the caretaker, and other roles. For that you need some degree of Interenterprise MDM.

10 Kinds of Product Information Needed Within Customization and Personalization

Henrik Gabs LiliendahlLeave a comment

When working with Product Information Management (PIM) I usually divide the different kinds of information to be managed into some levels and groups as elaborated in the post 5 Product Data Levels to Consider.

The 10 groups of data in this 5-level scheme are all relevant for personalization of product data in the following way:

  1. A (prospective) customer may have some preferred brands which are recognized either by collection of preferences or identified through previous behaviour.
  2. The shopping context may dictate that some product codes like GTIN/UPC/EAN and industry specific product codes are relevant as part of the product presentation or if these codes will only be noise.
  3. The shopping context may guide the use of variant product descriptions as touched in the post What’s in a Product Name?
  4. The shopping context may guide the use of various product image styles.
  5. The shopping context may guide the range of product features (attributes) to be presented typically either on a primary product presentation screen and on a detailed specification screen.
  6. The shopping context and occasion may decide the additional product description assets (as certificates, line drawings, installation guides and more) to be presented.
  7. The shopping occasion may decide the product story to be told.
  8. The shopping occasion may decide the supplementary products as accessories and spare parts to be presented along with the product in focus.
  9. The shopping occasion may decide the complementary products as x-sell and up-sell candidates to be presented along with the product in focus.
  10. The shopping occasion may decide the advanced digital assets as brochures and videos to be presented.   

The data collection track that can enable customization and personalization of product information is examined in the post The Roles of MDM in The Data Supply Chain.

Data Quality and Interenterprise Data Sharing

Henrik Gabs LiliendahlLeave a comment

When working with data quality improvement there are three kinds of data to consider:

First-party data is the data that is born and managed internally within the enterprise. This data has traditionally been in focus of data quality methodologies and tools with the aim of ensuring that data is fit for the purpose of use and correctly reflects the real-world entity that the data is describing.  

Third-party data is data sourced from external providers who offers a set of data that can be utilized by many enterprises. Examples a location directories, business directories as the Dun & Bradtstreet Worldbase and public national directories and product data pools as for example the Global Data Synchronization Network (GDSN).

Enriching first-party data with third-party is a mean to ensure namely better data completeness, better data consistency, and better data uniqueness.

Second-party data is data sourced directly from a business partner. Examples are supplier self-registration, customer self-registration and inbound product data syndication. Exchange of this data is also called interenterprise data sharing.

The advantage of using second-party in a data quality perspective is that you are closer to the source, which all things equal will mean that data better and more accurately reflects the real-world entity that the data is describing.

In addition to that, you will also, compared to third-party data, have the opportunity to operate with data that exactly fits your operating model and make you unique compared to your competitors.

Finally, second-party data obtained through interenterprise data sharing, will reduce the costs of capturing data compared to first-party data, where else the ever-increasing demand for more elaborate high-quality data in the age of digital transformation will overwhelm your organization.    

The Balancing Act

Getting the most optimal data quality with the least effort is about balancing the use of internal and external data, where you can exploit interenterprise data sharing through combining second-party and third-party data in the way that makes most sense for your organization.

As always, I am ready to discus your challenge. You can book a short online session for that here.

Direct Customers and Indirect Customers

Henrik Gabs Liliendahl2 Comments

When working with Master Data Management (MDM) for the customer master data domain one of the core aspects to be aware of is the union, intersection and difference between direct customers and indirect customers.

Direct customers are basically those customers that your organization invoice.

Indirect customers are those customers that buy your organizations products and services from a reseller (or marketplace). In that case the reseller is a direct customer to your organization.

The stretch from your organization via a reseller organization to a consumer is referred to as Business-to-Business-to-Consumer (B2B2C). This topic is told about in the post B2B2C in Data Management. If the end user of the product or service is another organization the stretch is referred to as Business-to-Business-to-Business (B2B2B).

The short stretch from your organization to a consumer is referred to as Direct-to-Consumer (D2C).

It does happen, that someone is both a direct customer and an indirect customer either over time and/or over various business scenarios.

IT Systems Involved

If we look at the typical IT systems involved here direct customers are managed in an ERP system where the invoicing takes place as part of the order-to-cash (O2C) main business process. Products and services sold through resellers are part of an order-to-cash process where the reseller place an order to you when their stock is low and pays you according to the contract between them and you. In ERP lingo, someone who pays you has an account receivable.

Typically, you will also handle the relationship and engagement with a direct customer in a CRM system. However, there are often direct customers where the relationship is purely administrative with no one from the salesforce involved. Therefore, these kinds of customers are sometimes not in the CRM system. They are purely an account receivable.

More and more organizations want to have a relationship with and engage with the end customer. Therefore, these indirect customers are managed in the CRM system as well typically where the salesforce is involved and increasingly also where digital sales services are applied. However, most often there will be some indirect customers not encompassed by the CRM system.

The Role of Master Data Management (MDM) in the context of customer master data is to be the single source for all customer data. So, MDM holds the union of customer master data from the ERP world and the CRM world.

An MDM platform also has the capability of encompassing other sources both internal ones and external ones. When utilized optimally, an MDM platform will be able to paint a picture of the entire space of where your direct customers and indirect customers are.

Business Opportunities

Having this picture is of course only interesting if you can use it to obtain business value. Some of the opportunities I have stumbled upon are:

  • More targeted product and service development by having more insight into the whole costumer space leading to growth advancements
  • Optimized orchestration of supply chain activities by having complete insight into the whole costumer space and thereby fostering cost savings
  • Improved ability to analyse the consequences of market change and changes in the economic environment in geographies and industries covered leading to better risk management.

Which business opportunities do you see arise for your organization by having a complete overview of the union, intersection and difference between your direct customers and indirect consumers?

2021 Data Management Mind Map

Henrik Gabs LiliendahlLeave a comment

Disciplines come and go in the data management world. Here is a mind map of the disciplines on top of my mind today. Some of the disciplines goes back to the emerge of IT in the previous millennium and some have risen during the latest years.