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.
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.
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:
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.
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:
Sharing the burden of collecting business partner records like CDQ.
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.
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 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.
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 (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.
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.
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.
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.
Some months ago, Gartner published the latest Hype Cycle for Digital Business Capabilities.
The hype cycle includes 4 concepts that in my mind will shape the future of Master Data Management (MDM) and data management in all. These are:
Industrie 4.0
Business Ecosystems
Digital Twin
Machine Customer
Industrie 4.0
You will find Industrie 4.0 near the trough of disillusionment almost ready to climb the slope of enlighten. Several of the recent MDM blue prints I have worked with have Industrie 4.0 as an overarching theme.
Industrie 4.0 is about using intelligent devices in manufacturing and thus closely connected to the term Industrial Internet of Things (IIoT). The impact of industry 4.0 is across the whole supply chain encompassing not only product manufacturing companies but also for example product merchants and product service providers.
With intelligent devices in the supply chain product MDM will evolve from handling data about product models to handle data about each instance of a product.
Business Ecosystems
The concept of business ecosystems has just passed the peak of inflated expectations.
In a modern business environment, no organization can do everything – or even most things – themselves. Therefore, any enterprise needs to partner with other organizations when working on new digital powered business models.
This also calls for increasing sharing of data, including master data, with business partners. This leads to the rise of interenterprise MDM, which by the way is at about the same position in the Hype Cycle for Data Analytics and MDM.
On the climbing side of the peak of inflated expectations we find the concept of a digital twin.
A digital twin is a virtual representation of a real-world entity such as an asset, person, organization, or process. This fits somehow with what MDM is doing which traditionally has been providing virtual descriptions of customers, suppliers, and products.
With the digital twin flavour, you can sharpen and extend MDM in two ways:
Have a more real-world on customers and suppliers by looking at those has roles of business partners along with handling many other external and internal organizational entities
Putting more asset types than direct products under the MDM umbrella with improved data governance as a result
Machine Customers
A bit further down the climbing side of the peak you will see the concept of the machine customer.
The expectation is that more and more buying tasks will be automated so there will be no human interaction in the bulk of purchasing processes.
This will only be possible if the products involved at those who sell them are digitally described in sufficient details and categorized the same way on the selling and buying side.
This seems like a job for Master Data Management and the adjacent Product Information Management (PIM) discipline where the buying side needs the right capabilities not only for direct trading products but also indirect supplies.
Also, the concept of augmented MDM will play a role here by applying Artificial Intelligence (AI) to the MDM and PIM side of enabling the machine customer.
Liliendahl on Data Quality 