One of the bottlenecks in Product Information Management (PIM) is getting product data ready for presentation to the buying audience as fast as possible.
Product data travels a long way from the origin at the manufacturing company, perhaps through distributors and wholesalers to the merchant or marketplace. In that journey the data undergo transformation (and translation) from the state it has at the producing organization to the state chosen by the selling organization.
However, time to market is crucial. This applies to when a new product range is chosen by the merchant or when there are changes and improvements at the manufacturer.
At Product Data Lake we enable a much faster pace in these quests than when doing this by using emails, spreadsheets and passive portals.
Take two minutes to test if your company is exchanging product data at the speed of a cheetah or a garden snail.
Building 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:
There are three kinds of data monetization: Selling data, wrapping data around products and utilizing advanced analytics leading to fast operational decision making. These options were examined in the post Three Flavors of Data Monetization.
If we look at the middle option, wrapping data around products, and narrow it down to wrapping data around tangible products, there are some ways to execute that for supply change delegates, not at least if the participating business entities embraces the business ecosystem where goods are moved through:
- Manufacturers need to streamline the handling of product information internally. This includes disciplines as PLM (Product Lifecycle Management) and PIM (Product Information Management). On top of that, manufacturers need to be effective in the way the product information is forwarded to direct customers and distributors/wholesalers and merchants as exemplified in the post How Manufacturers of Building Materials Can Improve Product Information Efficiency.
- Merchants need to utilize the best way of getting data into inhouse PIM (Product Information Management) solutions or other kind of solutions where data flows in from trading partners. Many merchants have a huge variety in product information needs as told in the post Work Clothes versus Fashion: A Product Information Perspective. On top of that a merchant will have supplying manufacturers and distributors with varying formats and capabilities to offer product information as discussed in the post PIM Supplier Portals: Are They Good or Bad?.
- Shippers may extend their offerings from moving the goods between manufacturers and merchants (or directly to end users) to also moving the information about the goods as suggested in the post New Routes for Products. New Routes for Product Information.
The end goal is that the buyer personas in self-service scenarios will be able to make a fact based and full informed decision as pondered in the post Where to Buy a Magic Wand?
Product information is the data a potential buyer of a product needs to make a purchasing decision. Today purchasing is more and more made by self-services as in e-commerce. The product information is usually obtained through a supply chain between trading partners stretching from the manufacturer to the end merchant.
The most common way of exchanging product information between trading partners is using spreadsheets. Spreadsheets are marvellous, because you can do almost anything you want with them. However, spreadsheets are also horrendous, because you can do almost anything you want with them. Therefore, trading partners are often stuck with manual, cumbersome and error prone processes on both the providing and receiving end.
At Product Data Lake we have developed a new mechanism that enables a whole new process for exchanging product information between trading partners. We have kept the flexibility of spreadsheets when it comes to choosing the data standards on the providing and receiving end but at the same time introduced automation and correctness when it comes to transferring, translating and transforming the data.
When telling about our service I am often asked if we have a nice feature for on-boarding spreadsheets. We don’t. Because the process is designed to omit the spreadsheets and transfer directly from the providers in-house product information data store(s) to the receiving in-house product information data store.
This reminds me of when we talk about using robots to substitute human labor. Then we often think about a machine that looks like a human. But effective industrial robots do not look like humans. They a designed to do a specific process much more effective than a human and will therefore not look like a human. The same is true in digitalization. When we redesign business processes to be much more effective they should not include spreadsheets.
Video on demand has become a popular way to watch television series, films and other entertainment and Netflix is probably the most known brand for delivering that.
The great thing about watching video on demand is that you do not have to enjoy the service at the exact same time as everyone else, as it was the case back in the days when watching TV or going to the movies were the options available.
At Product Data Lake we will bring that convenience to business ecosystems, as the situation today with broadcasting product information in supply chains very much resembles the situation we had before video on demand came around in the TV/Movie world.
As a provider of product information (being a manufacturer or upstream distributor), you will push your product information into Product Data lake, when you have the information available. Moreover, you will only do that once for each product and piece of information. No more coming to each theatre near your audience and extensive reruns of old stuff.
As a receiver of product information (being a downstream distributor, reseller or large end user), you will pull product information when you need it. That will be when you take a new product into your range or do a special product sale as well as when you start to deal with a new piece of information. No more having to be home at a certain time when your supplier does the show or waiting in ages for a rerun when you missed it.
Learn more about how Product Data Lake makes your life in Product Information Management (PIM) easier by following us here on LinkedIn.
When working with Product Information Management (PIM) and not at least with product information exchange (product data syndication) between trading partners, I have noticed three major sectors where the requirements and means differs quite a bit.
These sectors are:
- Food, beverage at pharmaceuticals: These are highly regulated sectors where the rules for taxonomy, completeness and exchange formats are advanced. Exchange standards and underpinning services as GS1/GDSN are well penetrated at least for basic data elements among major players. This sector counts for circa 1/6 of the world trade.
- Fashion, books and mainstream electronics: The products within this sector can be described with common accepted taxonomies and do not differ that much though there certainly are room for more common adhered standards in some areas. The trade here is becoming more penetrated by marketplaces with their specific product information requirements. This sector counts for circa 1/6 of the world trade.
- The rest (including building materials, special electronics, machinery, homeware): This is a diverse segment of products groups and the product groups themselves are diverse. The requirements for product information completeness and other data quality dimensions are overwhelming and the choice of standards are many, so most often two trading partners will be on different pages. This sector counts for circa 2/3 of the world trade.
Note: Automotive (vehicles) is a special vertical, where the main products (for example cars) resembles mainstream electronics and all the spare parts resembles special electronics. Some retailers (like department stores) covers all sectors and therefore need hybrid solutions to their product information exchange handling challenges.
The main drivers for better product information handling are compliance – not at least within food, beverage and pharmaceuticals – and self-service purchasing (as in ecommerce), where the latter has raged many years within fashion, books and mainstream electronics and now also is raising in more B2B (business-to-business) biased product groups as building materials, special electronics and machinery.
Learn more about how to tackle these diverse needs in product information exchange in the article and discussion about Product Data Lake.
The term End-to-End is used a lot in marketing jargon. Now, I will jump on that wagon too.
In reality, no solution will be an End-to-End solution for all your business needs. Therefore, my take will merely be to cast some light on an End-to-End need for which there are only very scattered solutions today.
If we look at Product Information Management (PIM) there are many good solutions for taking care of the End-to-End needs within your organisation. The aim is to gather the product information that exist within your organisation in various silos, have one trusted place for all this information and being able to publish this information in a consistent way across all sales channels – the omnichannel theme.
However, product information does in many cases not live just within your organization. In most cases, it lives in a business ecosystem of manufacturers, distributors, merchants and large end users.
Therefore we need an End-to-End solution for product information exchange (product data syndication) that encompasses the path from manufacturers over distributors to merchants and large end users and in some cases the way back.
Whether you are a manufacturer, distributor, merchant, large end user or a provider of tools and services for product information you can join the business ecosystem oriented End-to-End solution for product information. Please find some more information about Product Data Lake here.
As a manufacturer, you can find your benefits on the Product Data Push site here.
As a merchant, you can find your benefits on the Product Data Pull site here.
If you are a vendor in the Product Information Management space, you can join forces with us as explained here.
Product Information Management (PIM) is challenged by the fact that product data is the kind of data that usually flows cross company. The most common route starts with that the hard facts about a product originates at the manufacturer. Then the information may be used on the brand’s own website, propagated to a marketplace (online shop-in-shop) and propagated downstream to distributors and merchants.
The challenge to the manufacturer is that this represent many ways of providing product information, not at least when it comes to distributors and merchants, as these will require different structurers and formats using various standards and not being on the same maturity level.
Looking at this from the downstream side as a merchant you have the opposite challenge. Manufacturers provide product information in different structurers and formats using various standards and are not on the same maturity level.
Supply chain participants can challenge this in a passive or an active way. Unfortunately, many have chosen – or are about to choose – the passive way. It goes like this:
- As a manufacturer, we have a product data portal where trading partners who wants to do business with us, who obviously is the best manufacturer in our field, can download the product information we have in our structure and format using the standards we have found best.
- As a merchant we have a supplier product data portal where trading partners who wants to do business with us, the leading player in our field, can upload the product information we for the time being will require in our structure and format using the standard(s) we have found best.
- As a distributor, you could take both these standpoints.
This approach seems to work if you are bigger than your trading partner. And many times, one will be bigger than the other. But unless you are very big, you will in many cases not be the biggest. And in all cases where you are the biggest, you will not be a company being easy to do business with, which eventually will decide how big you will stay.
Using (often local) industry product data hubs is a workaround, but the challenges shines through and often it leads to that everyone will only benefit from what anyone can do and still calls for many touch points when doing business internationally and across several product data groups.
The better way is the active way creating a win-win situation for all trading partners as described in the article about Product Data Lake Business Benefits.
Our February 2018 version of the Product Data Lake cloud service is live. New capabilities include:
- Subscriber clusters
- Put APIs
As a Product Data Lake customer, you can be a subscriber to our public cloud (www.productdatalake.com) or install the Product Data Lake software on your private cloud.
Now there is a hybrid option: Being a member of a subscriber cluster. A subscriber cluster is an option for example for an affiliated group of companies, where you can share product data internally while at the same time you can share product data with trading partners from outside your group using the same account.
Already existing means to feed Product Data Lake include FTP file drops, traditional file upload from your desktop or network drives or actually entering data into Product Data Lake. Now you can also use our APIs for system to system data exchange.
Get the Overview
Get the full Product Data Lake Overview here (opens a PDF file).
Sometimes keeping it simple is the shortcut to getting it all wrong. While I am a believer in mastering all master data domains under the same vision and strategy, there are still best-in-class options when it comes to orchestrating processes and applying technology in the right chunks.
Customer Data Integration (CDI)
A recent post on this blog was called What Happened to CDI? This post examines the two overlapping disciplines Master Data Management (MDM) and Customer Data Integration (CDI). In a comment Jeff Jones argues that MDM vendors have forgotten about proper CDI workflows. Jeff says: “It seems the industry wants to go from Source to Match/Merge, instead of Source to Match/Identify and finally to Merge.” Please find and jump into the discussion here.
Also, this question was touched some years ago in the post The Place for Data Matching in and around MDM.
Product Information Management (PIM)
The product domain within Multi-Domain MDM also holds some risks of forgetting the proper ways of handling product information. In this domain we must also avoid being blinded by the promise of a single source of master data with surrounding processes and applied technology.
There are many end-to-ends to cover properly as exemplified in the post A Different End-to-End Solution for Product Information Management (PIM).