Not all attributes are relevant to all circumstances, processes or downstream applications. The weight of an item may be important to the courier who is selected to deliver it but not necessarily to the buyer who wishes to use it. The fitting type of a light bulb may not be important to the purchase price of the bulb but it will be to the electrician employed to install it.
A key issue for businesses is the fact that most product attributes are recorded and listed by the companies that manufacture and sell them. As a result, product data available to customers and users is biased towards the vendor, is seen from the vendor’s perspective, and customers and users require different information. In summary the information needed to support a sale is different from the information needed to support a purchase, albeit there are many common attributes to both.
With myCatalogues you can build a master product catalogue of products and services you buy and sell in a single, manageable master data set making your business more efficient and effective
So many businesses record a variety of data attributes on products in disparate systems in a chaotic fashion with no master single database or single version of the truth. Product data finds its way into quotes, purchase orders, websites, brochures, marketing material, sales orders, warranty documents, installation and maintenance manuals. Often these elements are maintained discretely by a cross-section of users in a business all creating a great deal of duplicated work and effort.
An efficient business ought to look to build a master product catalogue of products they buy and sell in a single manageable master data set.
RFQ and POP processes involve describing the items a business wants to buy such that suppliers can quote upon them. This is acceptable for buying services as rarely do services repeat themselves in a systematic fashion. Products differ. Products can be defined and are often bought frequently. Building a catalogue of products that can be bought and sold will save valuable time in populating a RFQ or PO document and all the downstream applications that rely on this data.
Let’s pick a standard product in use in most office buildings, a 2-foot fluorescent tube light.
There are tens of manufacturers of such a product and thousands of re-sellers and suppliers from retail outlets, discount electrical stores, electrical wholesalers and online platforms.
What is the industry recognised term for this product?
It is a F18W/T8/835, something all electricians would instantly recognise, but not necessarily an office administrator looking to purchase one.
The nomenclature comes from how the product is manufactured and listed by the suppliers that sell it namely:
There is an industry standard naming convention catalogue to aid manufacturers and re-sellers catalogue their products, it is called Luckins.
Luckins has a standard ID for this product comprising 4 codes and it is defined as follows:
Cat 1 - F18W/835
Cat 2 - 62534
TSI Code - 380186372
EAN Code - 43168376136
It would be simple if all re-sellers used this ID in their offers to customers but this would not be in their interests. It would allow prospective customers to compare their offering with others. As a results, suppliers mask their product descriptions so they cannot be competitively compared.
Yesss Electrical – 63171840 – Manufacturer Philips
CEF – F18/940 – Manufacturer not disclosed
Edmundsons – Polylux835 – Manufacturer GE
Medlock – Tube218840 – Manufacturer not disclosed
So, although these are identical products, they are not instantly recognisable as being so.
If I were a buyer and wished to place an order upon each of these suppliers for this particular product, for the sake of accuracy, I ought to use the vendor’s product code in the line item field of my RFQ or PO. This would be time-consuming so it invariably does not happen. Most buyers might write “2-Foot Tube” at best rather than “2-foot fluorescent tube, 18 Watt, 1-inch diameter, Cool White”. Would they enter the vendor’s product code? Unlikely. As a result the attribute data of the product bought is lost for future visibility.
In our view a client can never have enough information about a product. If they do not have to compile it why would they want to limit it?
In the above example we have used five of the attributes of the fluorescent tube in its selection to purchase it but what about all the other elements in the downstream process that may require supplemental or different attribute data?
For a small off investment in time, you now have a fully functioning catalogue management system that will populate all the downstream applications in your business, that require it. This includes websites, brochures, documents, marketing collateral purchase orders, sales orders and ERP systems.
Since 2001 OCG Software has been building master data solutions. Over many years the scope and breadth of the data we have collated cover hundreds of disciples and fields across multiple countries and continents and in multiple languages and across multiple applications. As a business the master data you will need to record and keep current will be specific to you and your business.