Four Ways You as a Merchant Can Exploit Product Data Syndication

Product Data Syndication has become an essential capability to manage within digital transformation at merchants as wholesalers and retailers. There are 4 main scenarios.

1: Inbound product data syndication of resell (direct) products

The process involves getting the most complete set of product information available from the supplier in order to fit the optimal set of product information needed to support the often self-service based buying decision by your customers.

This can be done by direct feeds from suppliers or through feeds via the various data pools that exist in different industries and geographies.

2: Inbound product data syndication for indirect products

You also need product data for parts used in Maintenance, Repair and Operation within facility management around logistic facilities, offices, and other constructions where products for MRO are needed. With the rise of the Internet of Things (IoT) these products are becoming more and more intelligent and are operated in an automatic way. For that, product information is needed in an until now unseen degree.

Every organization needs products and services as furniture, office supplies, travel services and much more. The need for onboarding product data for these purchases is still minimal compared to the above-mentioned scenarios. However, a foreseeable increased use of Artificial Intelligence (AI) in procurement operations will ignite the requirement for product data onboarding for this scenario too in the coming years.

3: Outbound product data syndication to marketplaces

Selling products on marketplaces has become a popular alternative to selling via ones own ecommerce site. While price and delivery options are main drivers here there are still more business to win via this channel if you can provide better and more unique product information than other resellers of the same product.

4: Outbound product data syndication to customers using products as parts

Your business-to-business (B2B) customers may also need product data for parts used directly in production or in Maintenance, Repair and Operation in production facilities and within facility management around logistic facilities, offices, and other constructions where products for MRO are needed. With the rise of the Internet of Things (IoT) these products are becoming more and more intelligent and are operated in an automatic way. For that, product information is needed in an until now unseen degree.

The Need for Collaborative Product Data Syndication

The sharp rise of the need product data syndication calls for increased collaboration through data partnerships in business ecosystems.

In the Product Data Lake venture I am working on now, we have made a framework – and a piece of Software as a Service – that is able to leverage the concepts of inbound and outbound Product Data Syndication and enable the four mentioned ways of utilizing product data syndication to create better business outcomes for you as a merchant.

Product Data Lake acts as a single point of digital contact for suppliers and customers in the product data supply chain which also provide you as a merchant with single place in the cloud from where your Product Information Management (PIM), ERP and eCommerce applications get and put external product data feeds.

This concept enables automated self-service by suppliers and customers who also can subscribe to Product Data Lake. In The Product Data Lake platform you can control the product portfolio and the product attribute set you are sharing with each business partner.

Learn more about Product Data Lake here.

Product Data Supply Chain Management in Resell

Five Ways You as a Manufacturer Can Exploit Product Data Syndication

Product Data Syndication has become an essential capability to manage within digital transformation at manufacturers. There are 5 main scenarios.

1: Outbound product data syndication for finished products

As a manufacturer you need to ensure that self-service buying decisions by the end customer through the channel partner point-of-sale will result in choosing your product instead of a product provided by your competitor.

This is achieved through providing complete product information in a way that is easy onboarded by each of your channel partners – as well as direct customers and marketplaces where this apply.

2: Inbound product data syndication for 3rd party finished products

As a manufacturer you often have a range of products that are not produced inhouse but are essential supplements when selling own produced products.

The process involves getting the most complete set of product information available from the supplier in order to fit the optimal set of product information needed to support the buying decision by the end customer where your own produced products and 3rd party products makes a whole.

3: Inbound product data syndication for raw materials and packaging

Here the objective is to get product information needed to do quality assurance and in organic production apply the right blend in order to produce a consistent finished product.

Also, the increasing demand for measures of sustainability is driving the urge for information on the provenance of the finished product and the packaging including the origin of the ingredients and circumstances of the production of these components. 

4: Inbound product data syndication for parts used in MRO

Product data for parts used in Maintenance, Repair and Operation is an essential scenario related in running the production facilities as well as in facility management around logistic facilities, offices, and other constructions where products for MRO are needed.

With the rise of the Internet of Things (IoT) these products are becoming more and more intelligent and are operated in an automatic way. For that, product information is needed in an until now unseen degree.

5: Inbound product data syndication for other indirect products

Every organization needs products and services as furniture, office supplies, travel services and much more. The need for onboarding product data for these purchases is still minimal compared to the above-mentioned scenarios. However, a foreseeable increased use of Artificial Intelligence (AI) in procurement operations will ignite the requirement for product data onboarding for this scenario too in the coming years.

The Need for Collaborative Product Data Syndication

The sharp rise of the need product data syndication calls for increased collaboration through data partnerships in business ecosystems.

In the Product Data Lake venture I am working on now, we have made a framework – and a piece of Software as a Service – that is able to leverage the concepts of outbound and inbound Product Data Syndication and enable the five mentioned ways of utilizing product data syndication to create better business outcomes for you as a manufacturer.

Product Data Lake acts as a single point of digital contact for suppliers and channel partners in the product data supply chain which also provide you as a manufacturer with single place in the cloud from where your Product Lifecycle Management (PLM), ERP and Product Information Management (PIM) applications get and put external product data feeds.

This concept enables automated self-service by suppliers and channels partners who also can subscribe to Product Data Lake. In The Product Data Lake platform you can control the product portfolio and the product attribute set you are sharing with each business partner.

Learn more about Product Data Lake here.

Product Data Supply Chain Management in Manufacturing

Interenterprise MDM Will be Hot

Interenterprise Master Data Management 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.

A poll in the LinkedIn MDM – Master Data Management group revealed that MDM practitioners are aware of that Interenterprise MDM will be hot sooner or later:

For the range of industries that work with tangible products, one of the most obvious places to start with Interenterprise MDM is by excelling – in the meaning of eliminating excel files exchange – in Product Data Syndication (PDS). Learn more in the post The Role of Product Data Syndication in Interenterprise MDM.

The Role of Product Data Syndication in Interenterprise MDM

Interenterprise Master Data Management is on the rise as reported in the post Watch Out for Interenterprise MDM. Interenterprise MDM 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.

One of the most obvious places to start with Interenterprise MDM is Product Data Syndication (PDS). While PDS until now has been mostly applied when syndicating product data to marketplaces there is a huge potential in streamlining the flow of product from manufacturers to merchants and end users of product information.

Inbound and Outbound Product Data Syndication

There are two scenarios in interenterprise Product Data Syndication:

  • Outbound, where your organization as being part of a supply chain will provide product information to your range of customers. The challenge is that with no PDS functionality in between you must cater for many (hundreds or thousands) different structures, formats, taxonomies and exchange methods requested by your customers.
  • Inbound, where your organization as being part of a supply chain will receive product information from your range of suppliers. The challenge is that with no PDS functionality in between you must cater for many (hundreds or thousands) different structures, formats, taxonomies and exchange methods coming in.

Learn more in the post Inbound and Outbound Product Data Syndication.

4 Main Use Cases for Collaborative PDS

There are these four main use cases for exchanging product data in supply chains:

  • Exchanging product data for resell products where manufacturers and brands are forwarding product information to the end point-of-sale at a merchant. With the rise of online sales both in business-to-consumer (B2C) and business-to-business (B2B) the buying decisions are self-service based, which means a dramatic increase in the demand for product data throughput.
  • Exchanging product data for raw materials and packaging. Here there is a rising demand for automating the quality assurance process, blending processes in organic production and controlling the sustainability related data by data lineage capabilities.  
  • Exchanging product data for parts used in MRO (Maintenance, Repair and Operation). As these parts are becoming components of the Industry 4.0 / Industrial Internet of Things (IIoT) wave, there will be a drastic demand for providing rich product information when delivering these parts.
  • Exchanging product data for indirect products, where upcoming use of Artificial Intelligence (AI) in all procurement activities also will lead to requirements for availability of product information in this use case.  

Learn more in the post 4 Supplier Product Data Onboarding Scenarios.

Collaborative PDS at Work

In the Product Data Lake venture I am working on now, we have made a framework – and a piece of Software as a Service – that is able to leverage the concepts of inbound and outbound PDS and enable the four mentioned use cases for product data exchange.

The framework is based on reusing popular product data classifications (as GPC, UNSPSC, ETIM, eClass, ISO) and attribute requirement standards (as ETIM and eClass). Also, trading partners can use their preferred data exchange method (FTP file drop – as for example BMEcat, API or plain import/export) on each side.

All in all, the big win is that each upstream provider (typically a manufacturer / brand) can upload one uniform product catalogue to the Product Data Lake and each downstream receiver (a merchant or user organization) can download a uniform product catalogues covering all suppliers.   

Collaborative Product Data Syndication vs Data Pools and Marketplaces

The previous post on this blog was called Inbound and Outbound Product Data Syndication.

As touched in this post there are two kinds of Product Data Syndication (PDS):

  • The public kind where everyone shares the same product information. The prominent examples are marketplaces and data pools.
  • The collaborative kind where you can exchange the same product information with all your accepted trading partners but also supplement with one-to-one product information that allows the merchant to stand out from the crowd.

When you syndicate to marketplaces everyone can easily watch and get inspired. A creepy kind of inspiration is the one surfacing at the moment where Amazon is believed to copy product data in order to make a physical twin as examined in the Wall Street Journal article telling that Amazon Scooped Up Data From Its Own Sellers to Launch Competing Products.

When syndicating – or synchronizing – through data pools you are limited to the consensus on the range of data elements, structure and format enforced by those who control the data pool – which can be you and your competitors.

With a collaborative PDS solution you can get the best of two worlds. You can have the market standard that makes you not falling behind your competitors. However, you can also have unique content coming through that puts you ahead of your competitors.

Collaborative PDS Data pools and Marketplaces

Right now, I am working with a collaborative PDS solution. This solution welcomes other (collaborative) PDS solutions as part of the product information flow. The solution will also encompass data pools in a reservoir concept. This PDS solution is called Product Data Lake.

The Long Tail of Product Data Synchronization

When discussing with peers and interested parties about Product Data Lake, some of the alternatives are often brought up. These are EDI and GDSN.

So, what is the difference between those services and Product Data Lake.

Electronic Data Interchange (EDI) is the concept of businesses electronically communicating information that was traditionally communicated on paper, such as purchase orders and invoices. EDI also has a product catalog functionality encompassing:

  • Seller name and contact information
  • Terms of sale information, including discounts available
  • Item identification and description
  • Item physical details including type of packaging
  • Item pricing information including quantity and unit of measure

The Global Data Synchronization Network (GDSN) is an internet-based, interconnected network of interoperable data pools and a global registry known as the GS1 Global Registry, that enables companies around the globe to exchange standardised and synchronised supply chain data with their trading partners using a standardised Global Product Classification (GPC).

This service focuses on retail, healthcare, food-service and transport / logistics. In some geographies GS1 is also targeting DIY – do it yourself building materials and tools for consumers.

Product Data Lake is a cloud service for sharing product information (product data syndication) in the business ecosystems of manufacturers, distributors / wholesalers, merchants, marketplaces and large end users of product information.

Our vision is that Product Data Lake will be the process driven key service for exchanging any sort of product information within business ecosystems all over the world, with the aim of optimally assist self-service purchase – both B2C and B2B – of every kind of product.

In that way, Product Data Lake is the long tail of product data synchronization supplementing EDI and GDSN for a long range of product groups, product attributes, digital assets, product relationships and product classification systems:

EDI GDSN PDLFind out more in the Product Data Lake Overview.

Using a Publish-Subscribe Pattern for Product Data Syndication

In software architecture, publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead categorize published messages into classes without knowledge of which subscribers, if any, there may be. Similarly, subscribers express interest in one or more classes and only receive messages that are of interest, without knowledge of which publishers, if any, there are.

This kind of thinking is behind the service called Product Data Lake I am working with now. Whereas a publish-subscribe service is usually something that goes on behind the firewall of an enterprise, Product Data Lake takes this theme into the business ecosystem that exists between trading partners as told in the post Product Data Syndication Freedom.

Therefore, a modification to the publish-subscribe concept in this context is that we actually do make it possible for publishers of product information and subscribers of product information to care a little about who gets and who receives the messages as exemplified in the post Using a Business Entity Identifier from Day One. However, the scheme for that is a modern one resembling a social network where partnerships are requested and accepted/rejected.

As messages between global trading partners can be highly asynchronous and as the taxonomy in use often will be different, there is a storage part in between. How this is implemented is examined in the post Product Data Lake Behind the Scenes.

Pub-Sub pattern
Image credit: MSDN blog

How Wholesalers and Dealers of Building Materials can Improve Product Information Efficiency

MaterialsBuilding materials is a very diverse product group. As a wholesaler or dealer, you will have to manage many different attributes and digital assets depending on which product classification we are talking about.

Getting these data from a diverse crowd of suppliers is a hard job. You may have a spreadsheet for each product group where you require data from your suppliers, but this means a lot of follow up and work in putting the data into your system. You may have a supplier portal, but suppliers are probably reluctant to use it, because they cannot deal with hundreds of different supplier portals from you and all the other wholesalers and dealers possibly across many countries. In the same way that you are not happy about if you must fetch data from hundreds of different customer portals provided by manufacturers and other brand owners.

This also means that even if you can handle the logistics, you must limit your regular assortment of products and therefore often deal with special ad hoc products when they are needed to form a complete range of products asked for by your customers for a given building project. Handling of “specials” is a huge burden and the data gathering must usually be repeated if the product turns up again.

At Product Data Lake we have developed a solution to these challenges. It is a cloud service where your suppliers can provide product information in their way and you can pull the information in the way that fits your taxonomy, structure and format.

Learn about and follow the solution on our Product Data Pull LinkedIn page.

If you are interested, please ask for more information here:

 

Product Data Lake is going to the next level

sdr
The path ahead

Until now my venture called Product Data Lake has been a rather technical quest. As with most start-ups the first years have been around building the actual software (in our case facilitated by Larion Computing in Vietnam), adjusting the market fit and run numerous trials with interested parties.

Now it is time to go to market for real. I am happy that another Henrik has joined as CEO and will emphasize on leading the marketing, sales and financial activities.

While I will be concentrating on the product strategy and product management activities it is time to recap the business outcomes we want our subscribers and partners to achieve. Let me express those towards three kinds of business partners:

Manufacturers and brand owners:

On the upstream side of Product Data Lake our goal is to let you as a manufacturer and/or brand owner:

  • Sell more: Your re-sellers will have the most complete, accurate and timely product information in front of their customers.
  • Reduce costs: Push your product information in one uniform way and let your re-sellers pull it in their many ways.

Our concept, using emerging technologies within Product Data Lake, will free you from applying many different solutions to providing product information to your re-sellers. You will avoid errors. You will be able to automate the processes and you will be easy to do business with in the eyes of your trading partners.

The people who will use your products want to get complete product information when making the buying decision wherever they are in the supply chain.

You can follow the news stream for this on our LinkedIn showcase page called Product Data Push.

Merchants (dealers and retailers):

On the downstream side of Product Data Lake our goal is to let you as a merchant (dealer or retailer) gain substantial business outcome.

  • You will sell more by having the most complete, accurate and timely product information in front of your online customers when they make self-service buying decisions.
  • You will reduce costs as you can pull product information in one uniform way and let your suppliers push it in their many ways. Hereby you can automate the processes, avoid errors and reduce product returns.

Our solution, using emerging technologies within Product Data Lake, will make you be easy to do business with in the eyes of your suppliers and make your product information transform into a powerful weapon in the quest for winning more online market share.

The people who may buy your product range deserves to know all about it and wants to get that information when making the buying decision. Remember: 81 % of visitors will leave a web-shop with incomplete product information.

You can follow the news stream for this on our LinkedIn showcase page called Product Data Pull.

Technology and service partners:

Ambassadors at Product Data Lake can sign up subscribers, assisting these subscribers in uploading their relevant product information portfolio to Product Data Lake and assisting these subscribers in linking their product information with the product information at their trading partners. As an ambassador, you will:

  • Have the opportunity to work with a big data solution within Product Information Management.
  • Have the opportunity to make data mapping and/or data integration services and cross-sell of other services for subscribers in a whole supply ecosystem.
  • Get 25 % kickback on new subscriptions in a potentially exponentially growing subscriber base in supply ecosystems

As Reservoir you can bring new life into product data portals and pools. Product Data Lake is a unique opportunity for service providers with product data portfolios for utilizing modern data management technology and offer a comprehensive way of linking, collecting and distributing product data within the business processes used by subscribers. Signing up as reservoir is free.

The linking theme also related to applying artificial intelligence / machine learning to mapping between the different product information taxonomies in use at trading partners, where we collaborate with business partners who provide such capabilities.

You can follow the news stream for this on our LinkedIn showcase page called Product Data Link.