Master Data Lifecycle
One of the challenges in preparing master data requests that are issues by customers is the notion of the “lifecycle” of the product sold to the customer. This is particularly true in mass merchant and supermarket retail where an item is sold in the stores to consumers and is always “stocked” in the same section of the store, or at least it is supposed to be in stock when you go to look for it. Out of stock conditions drive everyone in the supply chain crazy.
Products change from time to time; for example, formulas change. High fructose corn syrup used to be “good, but now many people believe it is bad; out with the sugar and in with the corn syrup; and out with the corn syrup, in with the next new thing. So, when master data includes ingredients and images, the information for the product in the stores and the retail distribution system is different from the information for the products in the supplier’s warehouse. Thus, the information about new shipments is different from the information about old shipments, which causes some orders sent to or from multiple distribution systems to change.
In other cases, the country of origin (also with master data, often times) changes which can cause differences in the product formula, as with fabric content, for example, in fashion items. So as an item’s sourcing moves from Mexico to China, or from Ohio to China, there are differences in master data.
Regardless of where the” knowledge” about this is stored, someone, somewhere, in the organization of the supplier “knows” when this is happening. Unfortunately, “systems” in place, built perhaps when China was never considered for sourcing items, do not have this knowledge. So when a customer asks for “synchronized” data, or when a customer makes an information request for a radio frequency identification (RFID) tag, sourcing the correct information is often times problematic.
At Dhara, we have been working in this space (master data staging) for ten years, and as we have reported in this blog, we believe that mashing up the various sources of data for the fulfillment of the information requests is essential. We believe that discovering and storing knowledge about the requested data is an essential step in the proper fulfillment of the information request.
When we talk about knowledge, what are we talking about? Well, some examples might help. What warehouse is used for each customer request? What warehouse is used for backfilling requests that cannot be handled by the prime warehouse? Who sources each warehouse? When a sourcing is changing, how is it staged and whose orders are affected? What is the schedule for the change of formula in the product? What lots are affected, and who is getting those lots? Does an order for a customer span lots?
This is not just about the fulfillment of information about business-to-business requests. This information should be available for business to consumer requests. My spouse and I have used the Internet for much of our shopping for some time now. In buying things that are fashionable, it would be very helpful for us to know that a pair of jeans that one of us bought is being sourced in the same place the next time we go to buy them. There seems to be something “unstandard” about sizes between different sources of products. The consumer might not know to ask, but she realizes that there is a difference when the next pair of the “same” jeans does not fit as well as the last pair. In this case, the knowledge of where the last order was sourced from, and information about the fulfillment from the same source for the next one, is really needed by the operating system’s supplier–the consumer should not have to know that.
There is new technology for storing this knowledge inside of computer systems, and next week I plan to look at the use of a semantic plane inside of the supplier’s systems, which processes source information requests for master data.
Fred Geiger
www.dharacg.com
Products change from time to time; for example, formulas change. High fructose corn syrup used to be “good, but now many people believe it is bad; out with the sugar and in with the corn syrup; and out with the corn syrup, in with the next new thing. So, when master data includes ingredients and images, the information for the product in the stores and the retail distribution system is different from the information for the products in the supplier’s warehouse. Thus, the information about new shipments is different from the information about old shipments, which causes some orders sent to or from multiple distribution systems to change.
In other cases, the country of origin (also with master data, often times) changes which can cause differences in the product formula, as with fabric content, for example, in fashion items. So as an item’s sourcing moves from Mexico to China, or from Ohio to China, there are differences in master data.
Regardless of where the” knowledge” about this is stored, someone, somewhere, in the organization of the supplier “knows” when this is happening. Unfortunately, “systems” in place, built perhaps when China was never considered for sourcing items, do not have this knowledge. So when a customer asks for “synchronized” data, or when a customer makes an information request for a radio frequency identification (RFID) tag, sourcing the correct information is often times problematic.
At Dhara, we have been working in this space (master data staging) for ten years, and as we have reported in this blog, we believe that mashing up the various sources of data for the fulfillment of the information requests is essential. We believe that discovering and storing knowledge about the requested data is an essential step in the proper fulfillment of the information request.
When we talk about knowledge, what are we talking about? Well, some examples might help. What warehouse is used for each customer request? What warehouse is used for backfilling requests that cannot be handled by the prime warehouse? Who sources each warehouse? When a sourcing is changing, how is it staged and whose orders are affected? What is the schedule for the change of formula in the product? What lots are affected, and who is getting those lots? Does an order for a customer span lots?
This is not just about the fulfillment of information about business-to-business requests. This information should be available for business to consumer requests. My spouse and I have used the Internet for much of our shopping for some time now. In buying things that are fashionable, it would be very helpful for us to know that a pair of jeans that one of us bought is being sourced in the same place the next time we go to buy them. There seems to be something “unstandard” about sizes between different sources of products. The consumer might not know to ask, but she realizes that there is a difference when the next pair of the “same” jeans does not fit as well as the last pair. In this case, the knowledge of where the last order was sourced from, and information about the fulfillment from the same source for the next one, is really needed by the operating system’s supplier–the consumer should not have to know that.
There is new technology for storing this knowledge inside of computer systems, and next week I plan to look at the use of a semantic plane inside of the supplier’s systems, which processes source information requests for master data.
Fred Geiger
www.dharacg.com
Comments