The Need for Speed in Product Information Flow

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.

Cheetah

To use Excel or not to use Excel in Product Information Management?

Excel is used heavily throughout data management and this is true for Product Information Management (PIM) too.

The reason of being for PIM solutions is often said to be to eliminate the use of spreadsheets. However, PIM solutions around have functionality to co-exist with spreadsheets, because spreadsheets are still a fact of life.

This is close to me as I have been working on a solution to connect PIM solutions (and other solutions for handling product data) between trading partners. This solution is called Product Data Lake.

Our goal is certainly also to eliminate the use of spreadsheets in exchanging product information between trading partners. However, as an intermediate state we must accept that spreadsheets exists either as the replacement of PIM solutions or because PIM solutions does not (yet) fulfill all purposes around product information.

So, consequently we have added a little co-existence with Excel spreadsheets in today´s public online release of Product Data Lake version 1.10.

PDL version 1 10

The challenge is that product information is multi-dimensional as we for example have products and their attributes typically represented in multiple languages. Also, each product group has its collection of attributes that are relevant for that group of products.

Spreadsheets are basically two dimensional – rows and columns.

In Product Data Lake version 1.10 we have included a data entry sheet that mirrors spreadsheets. You can upload a two-dimensional spreadsheet into a given product group and language, and you can download that selection into a spreadsheet.

This functionality can typically be used by the original supplier of product information – the manufacturer. This simple representation of data will then be part of the data lake organisation of varieties of product information supplemented by digital assets, product relationships and much more.

1,000 Blog Posts and More to Come

number_1000I just realized that this post will be number 1,000 published on this blog. So, let me not say something new but just recap a little bit on what it has been all about in the last nearly 10 years of running a blog on some nerdy stuff.

Data quality has been the main theme. When writing about data quality one will not avoid touching Master Data Management (MDM). In fact, the most applied category used here on this site, with 464 and counting entries, is Master Data.

The second most applied category on this blog is, with 219 entries, Data Architecture.

The most applied data quality activity around is data matching. As this is also where I started my data quality venture, there has been 192 posts about Data Matching.

The newest category relates to Product Information Management (PIM) and is, with 20 posts at the moment, about Product Data Syndication.

Even though that data quality is a serious subject, you must not forget to have fun. 66 posts, including a yearly April Fools post, has been categorized as Supposed to be a Joke.

Thanks to all who are reading this blog and not least to all who from time to time takes time to make a comment, like and share.

Supply Chain Participants and PIM Requirements

A recent post on this blog was called B2C vs B2B in Product Information Management. This post was my take on the differences, if any, between doing Product Information Management (PIM) in a Business-to-Consumer (B2C) scenario versus in a Business-to-Business (B2B) scenario.

In a comment in the Product Information Management Professional Association group on LinkedIn Hans de Gier of SyncForce replied:

“For many of our B2B customers information plays a bigger role in the Market-to-Order process than for consumer products. But most of our customers (Consumer & Professional Packaged Goods Manufacturers) serve both retail and professional/wholesale channels, which have different information needs, even regarding the same products. So, any manufacturer targeted solution should be able to serve both channels with the right content via the right data channels. In our vision a more relevant question is: What is your take on the differences on doing PIM in Manufacturing versus Wholesale / Retail.”

Indeed, there are several ways to slice the PIM space and the supply chain position of a company as a supply chain delegate is for sure very relevant. Exchanging product information between trading partners in upstream and downstream (and midstream) positions must be very flexible and one size fits all thinking will not work.

The different positions of a company as they are in my mind is illustrated below:

supply chain

The possible combinations when exchanging product information between supply chain delegates are plentiful. To mention a few channels:

  • Manufacturer to wholesaler to retailer to end private consumer
  • Manufacturer to distributor to dealer to end business customer
  • Manufacturer to distributor to dealer to manufacturer as raw material
  • Manufacturer to merchant to marketplace to end customer
  • Manufacturer to marketplace to end customer
  • Manufacturer to/from brand owner to any midstream/downstream delegate

This variety is why the means of exchanging product information (product data syndication) between trading partners is essential in almost any PIM solution.

At Product Data Lake we offer the remedy to this challenge and in combination with any PIM solution or other application where in-house product information is managed.

B2C vs B2B in Product Information Management

The difference between doing Business-to-Consumer (B2C) or Business-to-Business (B2B) reflects itself in many IT enabled disciplines.

Yin and yangWhen it comes to Product Information Management (PIM) this is true as well. As PIM has become essential with the rise of eCommerce, some of the differences are inherited from the eCommerce discipline. There is a discussion on this in a post on the Shopify blog by Ross Simmonds. The post is called B2B vs B2C Ecommerce: What’s The Difference?

Some significant observations to go into the PIM realm is that for B2B, compared to B2C:

  • The audience is (on average) narrower
  • The price is (on average) higher
  • The decision process is (on average) more thoughtful

How these circumstances affect the difference for PIM was exemplified here on the blog in the post Work Clothes versus Fashion: A Product Information Perspective.

To sum up the differences I would say that some of the technology you need, for example PIM solutions, is basically the same but the data to go into these solutions must be more elaborate and stringent for B2B. This means that for B2B, compared to B2C, you (on average) need:

  • More complete and more consistent attributes (specifications, features, properties) for each product and these should be more tailored to each product group.
  • More complete and consistent product relations (accessories, replacements, spare parts) for each product.
  • More complete and consistent digital assets (images, line drawings, certificates) for each product.

How to achieve that involves deep collaboration in the supply chains of manufacturers, distributors and merchants. The solutions for that was examined in the post The Long Tail of Product Data Synchronization.

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

Two Forms of Narcissism within Business-to-Business

Narcissus-CaravaggioThe term narcissism originates from Greek mythology, where the young Narcissus fell in love with his own image reflected in a pool of water. While this is about how a natural person may behave it can certainly also be applied to how a company behaves.

Not to show empathy to customers

I think we all know the classic sales presentation with endless slides about how big and wonderful the selling company is and how fantastic the products they sell are. This approach contradicts everything we know about selling, which is to start with the needs and pain points at the buying company and then how the selling company effectively can fulfill the needs and make the pain points go away.

Not to show empathy to trading partners

While business outcomes originate from selling to your customers it certainly also is affected by how you treat your trading partners and how you can put yourself in their place.

An example close to me is exchange of product information (product data syndication) between trading partners. We often see solutions which is made to make it easy for you but then being difficult for your trading partner. This includes requiring your spreadsheet format to filled out by your trading partner, may be a customer data portal set up by a manufacturer or opposite a supplier data portal set up by a merchant. These are narcissistic dead ends as told in the post The Death Trap in Product Information Management: Your Customer/Supplier Portal.

The emphatic way forward is putting your company as being an active delegate in a business ecosystem as examined in post A Product Information Management (PIM) Solar System.

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.