Visibility Example #3: When and How to Capture Data

In 2010 a reader emailed with a question concerning how a visibility solution ought to handle certain data elements, both in terms of when they are captured in time and how they are captured. In answering that real-life question I went on to raise two guiding principles which ought to be behind our supply chain visibility initiatives. I call these principles the Representation Principle and the Key-Once / Use Often Principle. This article from 2010 looks at them in more detail…

The Setup:

This visibility example starts with a computer manufacturer who conducts international trade in laptops. The laptops are assembled in Asia and imported to markets in the USA for distribution and sale. Each laptop carries a unique ID tag on it for later identification. Many laptops are packaged together in the same case, which may be further aggregated into master-cases, pallets, and eventually to ocean freight containers.

The Business Problem:

The business in question requires that the supply chain visibility solution incorporate the laptop’s unique ID. Downstream activities may depend on properly visibility to events associated with the unique laptop ID. For example, insurance claims may only be possible based on the laptop’s unique ID. Or, some laptops might be custom built to end user specifications and the unique ID is needed to direct downstream workers to send a specific laptop to a specific customer. Leveraging the Visibility Framework I proposed in another post, we could say that the visibility solution must be:

  • Sensitive to the laptop ID, meaning that the laptop ID (or lack of) is captured
  • Integrative of the laptop ID with other data elements, such as case #, order #, or container #
  • Intelligent about what the laptop # represents and how it ought to be used or updated. For example, the laptop # should remain globally unique.
  • Interruptive of business decisions which would benefit from knowing something about the laptop ID or its related data. This could include sourcing decisions, customer service, transportation, accounting, etc.

Although the guidelines above help, the questions asked by the reader where (1) when should the data about laptop IDs be incorporated, and (2) how should it be incorporated into the other data, i.e. what is the meta-data model?

The Representation Principle:

One way to approach solving this real-life visibility example is to use the Representation Principle. The Representation Principle goes something like this…

“All else being equal, visibility solution should attempt to represent the physical realities of the supply chain as faithfully as possible”


The Representation Principle should call to mind a map, where the overall representation of a space is maintained while details are aggregated so as to allow scaling. A globe successfully represents the entire earth. A flat map of China successfully represents that land area at a different scale. A street map of Shanghai represents that area at even another scale. A map attempts to faithfully represent relative geography while sacrificing other aspects (such as absolute size).

I think a common reaction to the Representation Principle is to assume it is an obvious statement, and to ask “why wouldn’t a supply chain visibility solution faithfully represent the physical reality of a supply chain?”. Most people already think of supply chain visibility as “track and trace” or the “glass pipeline”, so this design principle is too obvious for them to find useful.

But, in fact, there are other design principles which would lead us to break with representing physical supply chain reality. We’ll look at an example later, after introducing the next design principle.

The Key-Once, Share-Often Principle:

Supply chain visibility involves data capture, and data capture almost always comes back to a human being keying in data. For example, consider a cross-dock facility where a carton’s bar code is scanned on a conveyor belt. The conveyance system relays with the WMS, which looks at an item-master data table. The Item master data table is updated every night via interface with the ERP system. And the new items are added to the ERP system by a product-development assistant who types-out the item setup information. So, even in an automated environment (that setup has millions of dollars in supply chain system investment, most likely) there is still an anchor someplace in the data stream where a human being keys in the information.

For a couple reasons, I propose the supply chain visibility systems are best when they re-leverage existing data rather than enforcing the data to be keyed in again. First, it reduces human touch points which can be expensive and slow. Second, it uncovers data errors and inconsistencies in individual systems by having the supply chain visibility solution match various data sources. If the item pack details differ between a transportation system’s data base and an ERP data base, the visibility solution should bring this issue to the front and hopefully jump-start a resolution.

As a design guideline, the Key-Once, Share-Often Principle suggests that for each data element we ask “Where does this already exist and how can I draw from that source?”.

Now, the design conflict…

A good observer will note that the two principles discussed are not always aligned. What happens when the physical flow of events has item ABC being loaded onto a shipment on day 0, but the data is only captured and available on day 3? Should the visibility solution be designed to wait until the data is available, so as to avoid re-keying, or should the visibility solution expend additional effort, cost, and introduce risk of data inconsistency in order to stay more aligned with the physical realities of when items are loaded onto shipments?

Back to the business problem…

In the business problem being discussed we are trying to design a visibility solution which captures laptop serial numbers and ties them into other meta-data, such as shipment ID, date of events, etc. The Visibility Framework answers some question about how to design a good solution. But two questions remain…

  1. When should the data about laptop IDs be incorporated?
  2. How should it be incorporated into the other data, basically what is the meta-data model?

From the Representation Principle we would try to design a solution that captures the laptop IDs at the same time as they are actually applied. So if a laptop is given an ID tag on November 22nd, on that day it is also identified uniquely by its ID in the visibility system. On the day that the ID is applied, the meta-data model may be simplistic, say linking laptop IDs to a case ID. Then, as new linkages occur, the meta-data model would be continuously updated. For example, when a specific case of laptops is used to fulfill a customer order, the meta-data model would be updated to show a linkage between the PO, the Case ID, and the Laptop ID.

Following the Key-Once, Share-Often Principle results in a different design. For example, if the laptops are ID-stamped on November 22nd we would not update the visibility solution until a later time when data was readily available. Knowing the lifecycle of the process, we may even wait until the laptop ID and the customer order linkage is made, to avoid having to re-connect these data pieces in two systems.

Solving the business problem:

As a supply chain leader, the two approaches described above should be contextualized into what the supply chain is using visibility for. If visibility is about supporting asset tracking after customer orders are fulfilled, the Key-Once, Share-Often Principle will give the right decision support at lower cost. If new customer orders cannot be taken unless the laptop ID is available, then the Representation Principle will make inventory available earlier, and thus make inventory more effective and result in better return on assets.

By placing the visibility solution within the context of what the supply chain is trying to accomplish, we can choose between these two opposing principles fairly easily.

Visibility Example #3: Monday Morning Summary

As usual, I’m closing this article with a summary of the important points for supply chain leaders facing similar supply chain visibility design decisions.

  • A good design principle is to make the visibility solution faithfully represent the physical reality of the supply chain… if something happens “out there”, it’s best if it also happens “in here”
  • Another good design principle for supply chain visibility is to try to re-use data from other systems or processes rather than collecting it directly again. This is the Key-Once, Share-Often Principle
  • These two design principles will conflict at times, and should be mediated or balanced by looking at what the supply chain is trying to do with its visibility solution… what are the decisions that will be affected and the desired outcomes?
  • Finally, both of these design principles lend themselves to performance measurement. For example, out of X data elements we can benchmark what percentage have to be manually captured only for visibility vs. integrated from other sources.

Leave a Reply