In the round of presenting the solutions for The Disruptive MDM / PIM / DQM List 2022 the next vendor is Magnitude Software.
Magnitude Software has two solutions on the list:
Kalido MDM where you can define and model critical business information from any domain – customer, product, financial, vendor, supplier, location and more – to create and manage accurate, integrated, and governed data that business users trust.
Agility Multichannel PIM which has the capabilities to get products to market faster with a simple-to-use, comprehensive Product Information Management solution that makes it easy to support commerce across digital and traditional channels.
Product Information Management (PIM) has a sub discipline 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.
Marketplaces
Marketplaces is the new kid on the block in this world. Amazon and Alibaba are the most known ones, however there are plenty of them internationally, within given product groups and nationally. Merchants can provide product information related to the goods they are selling on a marketplace. A disruptive force in the supply (or value) chain world is that today manufacturers can sell their goods directly on marketplaces and thereby leave out the merchants. It is though still only a fraction of trade that has been diverted this way.
Each marketplace has their requirements for how product information should be uploaded encompassing what data elements that are needed, the requested taxonomy and data standards as well as the data syndication method.
Data Pools
One way of syndicating (or synchronizing) data from manufacturers to merchants is going through a data pool. The most known one is the Global Data Synchronization Network (GDSN) operated by GS1 through data pool vendors, where 1WorldSync is the dominant one. In here trading partners are following the same classification, taxonomy and structure for a group of products (typically food and beverage) and their most common attributes in use in a given geography.
There are plenty of other data pools available emphasizing on given product groups either internationally or nationally. The concept here is also that everyone will use the same taxonomy and have the same structure and range of data elements available.
Data Standards
Product classifications can be used to apply the same data standards. GS1 has a product classification called GPC. Some marketplaces use the UNSPSC classification provided by United Nations and – perhaps ironically – also operated by GS1. Other classifications, that in addition encompass the attribute requirements too, are eClass and ETIM.
A manufacturer can have product information in an in-house ERP, MDM and/or PIM application. In the same way a merchant (retailer or B2B dealer) can have product information in an in-house ERP, MDM (Master Data Management) and/or PIM application. Most often a pair of manufacturer and merchant will not use the same data standard, taxonomy, format and structure for product information.
1-1 Product Data Syndication
Data pools have not substantially penetrated the product data flows encompassing all product groups and all the needed attributes and digital assets. Besides that, merchants also have a desire to provide unique product information and thereby stand out in the competition with other merchants selling the same products.
Thus, the highway in product data syndication is still 1-1 exchange. This highway has these lanes:
Exchanging spreadsheets typically orchestrated as that the merchant request the manufacturer to fill in a spreadsheet with the data elements defined by the merchant.
A supplier portal, where the merchant offers an interface to their PIM environment where each manufacturer can upload product information according to the merchant’s definitions.
A customer portal, where the manufacturer offers an interface where each merchant can download product information according to the manufacturer’s definitions.
A specialized product data syndication service where the manufacturer can push product information according to their definitions and the merchant can pull linked and transformed product information according to their definitions.
In practice, the chain from manufacturer to the end merchant may have several nodes being distributors/wholesalers that reloads the data by getting product information from an upstream trading partner and passing this product information to a downstream trading partner.
Data Quality Implications
Data quality is as always a concern when information producers and information consumers must collaborate, and in a product data syndication context the extended challenge is that the upstream producer and the downstream consumer does not belong to the same organization. This ecosystem wide data quality and Master Data Management (MDM) issue was examined in the post Watch Out for Interenterprise MDM.
Data fabric has been named a key strategic technology trend in 2022 by Gartner, the analyst firm.
According to Gartner, “by 2024, data fabric deployments will quadruple efficiency in data utilization while cutting human-driven data management tasks in half”.
Master Data Management (MDM) and data fabric are overlapping disciplines as examined in the post Data Fabric vs MDM. I have seen data strategies where MDM is put as a subset to data fabric and data strategies where they are separate tracks.
In my head, there is a common theme being data sharing.
Then there is a different focus, where data fabric seems to be focusing on data integration. MDM is also about data integration, but more about data quality. Data fabric takes care of all data while MDM obviously is about master data, though the coverage of business entities within MDM seems to be broadening.
Another term closely tied to data fabric – and increasingly with MDM as well – is knowledge graph. Knowledge graph is usually considered a mean to achieve a good state of data fabric. In the same way you can use a knowledge graph approach to achieve a good state of MDM when it comes to managing relationships – if you include a data quality facet.
The latest Gartner Hype Cycle for Data and Analytics Governance and Master Data Management includes some of the MDM trends that have been touched here on the blog.
If we look at the post peak side, there are these five terms in motion:
Single domain MDM represented by the two most common domains being MDM of Product Data and MDM of Customer Data.
Multidomain MDM has moved on from the Trough of Disillusionment to climbing up the Slope of Enlightenment. I have been waiting for this to happen for 10 years – both in the hype cycle and in the real-world – since I founded the Multi-Domain MDM Group on LinkedIn back then.
Interinterprise MDM has swapped place with Cloud MDM, so this term is now ahead of Cloud MDM. It is though hard to imagine Interenterprise MDM without Cloud MDM, and MDM in the cloud will also according Gartner reach the the Plateau of Productivity before ecosystem wide MDM. The promise of this is also in accordance with a poll I made as told in the post Interenterprise MDM Will be Hot.
You can get the full report from the MDM consultancy parsionate here.
One of the most addressed domains in Master Data Management (MDM) is the vendor domain – or is it called the supplier domain?
I have seen the terms vendor and supplier used synonymously many times at different MDM end user organizations, by MDM system integrators and by MDM platform vendors where I have been engaged. This ambiguity exists in English, the most used corporate language, whereas in other languages the distinction seems to be much clearer.
In a recent post by Jignesh Patel of Stibo Systems it is suggested that supplier and vendor are two opposite terms. The post is called What Vendor Data Is and Why It Matters to Manufacturers. I remember to have read the similar post before, probably in a previous version, and commented that this interpretation, in an MDM context, confuses me.
The linguistic issue is to me that a supplier is someone you buy from, and a vendor is someone who sells to you. But as interpreted in the above post, a vendor could also be someone who sells for you. In the latter case I however have mostly seen terms as dealer and reseller used.
Another possible distinction will be that a supplier is someone who deliver goods and services. A vendor will be someone who deliver the bill. So, in an MDM implementation supplier will be used if the MDM implementation is product oriented and vendor will be used if the MDM implementation is procurement and/or financial oriented or dominated.
This distinction reveals an interesting MDMish observation which is that usually the one who deliver the goods and services and the one who deliver the bill is the same entity – but not always.
What is your stance? Is vendor and supplier the same, a bit different or opposite?
The previous acquisitions have strengthened the Precisely offerings around data quality for the customer master data domain and the adjacent location domain.
The Winshuttle take over will make Precisely a multidomain vendor adding cross domain capabilities and specific product domain capabilities.
The original Winshuttle capabilities revolves around process automation for predominately SAP environments covering all master data domains and further Application Data Management (ADM).
As Winshuttle recently took over the Product Information Management (PIM) solution provider Enterworks, this will bring capabilities around product master data management and thus make Precisely a provider for a broad spectrum of master data domains.
The interesting question will be in what degree Precisely over the time will be willing to and able to integrate these different solutions so a one-stop-shopping experience will become a one-stop digital experience for their clients.
As said in there: “Potential areas where small and wide data can be used are demand forecasting in retail, real-time behavioural and emotional intelligence in customer service applied to hyper-personalization, and customer experience improvement.”
Small data is in my eyes very much equivalent to master data besides the meaning promoted by Gartner, which is approaches involving “certain time-series analysis techniques or few-shot learning, synthetic data, or self-supervised learning”.
The concrete wide data to be used and connected in the retail scenario is customer data and product data. There is a current trend of mastering wide customer data in a Customer Data Platform (CDP). Wide product data are best handled in a Product Information Management (PIM) platform with a collaborative Product Data Syndication (PDS) add-on.
So, is the term “small and wide data” better than “big data”?
I think it, besides the narrow analytic purpose forwarded by Gartner, can help unlocking the opportunities in master data underpinned big data that have existed the past decade but that have- by far – not been utilized as much as it could.
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.
Many analyst market reports in the Master Data Management (MDM), Product Information Management (PIM) and Data Quality Management (DQM) space have a generic ranking of the vendors.
The trouble with generic ranking is that one size does not fit all.
On the sister site to this blog, The Disruptive MDM / PIM / DQM List, there is no generic ranking. Instead there is a service where you can provide your organization’s context, scope and requirements and within 2 to 48 hours get Your Solution List.
The selection model includes these elements:
Your context in terms of geographical reach and industry sector.
Your scope in terms of data domains to be covered and organizational scale stretching from specific business units over enterprise-wide to business ecosystem wide (interenterprise).
Your specific requirements covering the main capabilities that differentiate the vendors on market.
Vendor capabilities.
A model that combines those facts into a rectangle where you can choose to:
Go ahead with a Proof of Concept with the best fit vendor
Make an RFP with the best fit vendors in a shortlist
Examine a longlist of best fit vendors and other alternatives like combining more than one solution.
The vendors included are both the major players on the market as well as emerging solutions with innovative offerings.
Master Data Management (MDM) and the overlapping Product Information Management (PIM) discipline is the centre of which the end-to-end data supply chain revolves around in your enterprise.
The main processes are:
Onboard Customer Data
It starts and ends with the King: The Customer. Your organization will probably have several touchpoints where customer data is captured. MDM was born out of the Customer Data Integration (CDI) discipline and a main reason of being for MDM is still to be a place where all customer data is gathered as exemplified in the post Direct Customers and Indirect Customers.
Onboard Vendor Data
Every organization has vendors/suppliers who delivers direct and indirect products as office supplies, Maintenance, Repair and Operation (MRO) parts, raw materials, packing materials, resell products and services as well. As told in a post on this blog, you have to Know Your Supplier.
Enrich Party Data
There are good options for not having to collect all data about your customers and vendors yourself, as there are 3rd party sources available for enriching these data preferable as close to capture as possible. This topic was examined in the post Third-Party Data and MDM.
Onboard Product Data
While a small portion of product data for a small portion of product groups can be obtained via product data pools, the predominant way is to have product data coming in as second party data from each vendor/supplier. This process is elaborated in the post 4 Supplier Product Data Onboarding Scenarios.
Transform Product Data
As your organization probably do not use the same standard, taxonomy, and structure for product data as all your suppliers, you have to transform the data into your standard, taxonomy, and structure. You may do the onboarding and transformation in one go as pondered in the post The Role of Product Data Syndication in Interenterprise MDM.
Consolidate Product Data
If your organization produce products or you combine external and internal products and services in other ways you must consolidate the data describing your finished products and services.
Enrich Product Data
Besides the hard facts about the products and services you sell you must also apply competitive descriptions of the products and services that makes you stand out from the crowd and ensure that the customer will buy from you when looking for products and services for a given purpose of use.
Customize Product Data
Product data will optimally have to be tailored for a given geography, market and/or channel. This includes language and culture considerations and adhering to relevant regulations.
Personalize Product Data
Personalization is one step deeper than market and channel customization. Here you at point-of-sale seek to deliver the right Customer Experience (CX) by exercising Product eXperience Management (PXM). Here you combine customer data and product data. This quest was touched in the post What is Contextual MDM?
Liliendahl on Data Quality 