These are not the dates you are looking for

In the supply chain, we talk a lot about dates.

In fact, there probably isn't anything discussed, reviewed, analyzed, scrutinized, and argued about more than dates.

At the same time, the likelihood that you have thought significantly about dates, and what they mean, how they work, and what their implications are for your job, your department, your company, and your customers is pretty slim.

Now I get it, you are sitting there thinking: "I mean, a date is a a date. I can read a calendar. I'm pretty sure I get it."

Maybe. But my guess is probably not.

I know this because once upon a time (like a few weeks ago), I was like you. I knew what a date was. When someone said the ETA was Jan 1, I'm pretty sure I knew what that meant.

Boy was I wrong.

The Suppy Chain is a Set of Connected ETAs

You all know that the supply chain is a set of activities, performed by independent actors, working to achieve an outcome that isn't clear to most of the actors themselves. For the purposes of this article, let's use a simple example that everyone will understand.

There is a shipment that is moving from Shanghai via ocean to Long Beach.

The first thing to note is that this is an ocean move, executed by an ocean carrier

The ocean carrier has an ETA, which represents its best estimate at when the vessel will arrive at the port. (Which, just as an aside, does NOT represent when the container will be available. The ocean carrier ETA is when the vessel is berthed at port. For the container to be available for pick up, it needs to be offloaded from the vessel, transit the port, clear customs and other PGAs, and be released by the terminal and carrier.)

From an ocean carrier's perspective, they care about providing a reasonably accurate ETA, and are measured against how good they are when comparing the actual arrival to the estimate.

From this perspective, the ETA is simple and easy.

But for anyone but the carrier, this perspective is too simplistic.

As we zoom out, we can see that this shipment is being moved from Shanghai to a distribution center, which means that there is a drayage leg, and also that a freight forwarder is coordinating and overseeing the shipment.

How does that impact ETA?

Well, the first thing to note is that the freight forwarder now needs to start caring about multiple ETAs. The forwarder has committed to getting the shipment to the destination on a certain date (or date range), so there is that ETA (final destination).

The forwarder also cares about coordinating the moves with the drayman, and so for the drayage vector there is an ETA. (It just so happens that the drayage ETA is coincident with the ETA (final destination).

What's the point?

Simply this. The carrier ETA is simple. It is clean. It is not dependent on anything or anyone. The dray carrier's ETA is more complex. It is dependent on a number of things...one of which is the ETA of the ocean carrier, but it isn't the only thing it is dependent on (more on this in a bit). And, the forwarder cares about the ETA of the entire trip, which is dependent on the ocean carrier, the drayage carrier, and a bunch of other things too.

Remember, this is a simple example. Add in a rail leg, and the dependencies/complications start to multiply.

Many Dates are Multi-Dependent

What does it mean that the drayage vector is dependent on the elements that precede it?

Well, clearly, the drayage let cannot commence if the container is not available to be drayed. What is required for the container to be made available?

Let's break it down:

• Vessel needs to arrive (berthed)
• Container needs to be offloaded
• Container needs to transit the port
• Container needs to be customs cleared
• Container needs to be cleared by PGAs (if required)
• Container might need to be inspected (yikes!!)
• Container needs to be carrier released
• Fees need to be paid
• Container needs to be terminal released

Each of these things need to happen. The container is not just available for pick up when the vessel arrives.

How long do each of these steps take? It depends on the port, how quick the customs broker is, how quick the freight forwarder is, and so on.

If you are trying to manage the ETA (final destination) you might try and simplify such that all of the activities at the port get rolled up into one number, say an approximate lay time at the port of 2 days. If you were to do that, you would see that the ETA (final destination) is equal to ETA (carrier) + lay time at port + duration of drayage leg.

And you can imagine that if there was a rail leg,

ETA (final destination) = ETA (carrier) + lay time at port + duration of rail vector + lay time at rail yard + duration of drayage leg.

If you were either the freight forwarder or the Importer (the forwarder's customer), and you cared to be accurate with your ETAs, you need to be cognizant of all of these elements. And the better you are with managing these interim steps, the more reliable your outcomes will be.

But this isn't the end...and this is where a lot of confusion happens in the international supply chain. The freight forwarder's view is NOT the final view of things.

My ETA is not Your ETA

Take these two scenarios:

1) The products in the shipment will be used in a manufacturing process by the importer

2) The products will be shipped from the DC to the end customer

When the importer is going to be utilizing the inbound product in a manufacturing process of some kind (Scenario 1), they all of a sudden care about a whole set of things that go beyond the ETA date of the shipment. Firstly, they care about availability of product. The product is in the shipment, and so the ETA (final destination) of the shipment is obviously important. The product within the shipment inherit their availability dates from the ETA (final destination) on the shipment. But it isn't obvious how that transformation is done (from shipment to product) within the importer if they don't have a good method of doing it. But what is clear is that this goes beyond the realm of what the forwarder concerns themselves with, from a date perspective.

It becomes even clearer when the product (or complete shipment) is shipped from the DC to the end-customer. The end-customer requires an ETA (end customer) which goes beyond the purview of the forwarder.

It probably makes sense to recap at this point.

1) Within any given supply chain there are multiple ETAs

2) Most ETAs are dependent on the steps the come before it

3) Different players within the supply chain have different views, and therefore different understandings of the ETA that matters to them

4) It isn't always obvious which ETA any one actor is using when referring to an ETA

5) The better you are at managing all of the dependencies, the more reliable your supply chain will be.

If you have found the discussion thus far confusing, I'm afraid things are only getting started. Because the ETA, in its various forms across the various legs and perspectives, are only one type of date that matters when managing the supply chain.

It isn't just about ETAs...

If we look at a node (think: a location, like a port, a warehouse, a yard, etc.), they tend to act similarly:

Each node will have a date of arrival, a lay time (how long it takes to transit the node), and a departure date. These are all estimates, so of course they will be translated into ETA, estimated lay time, and ETD.

The ETD is a compound date that equals the arrival date (or ETA if things haven't happened yet) plus the estimated lay time.

In the case of vectors, you have a similar model:

The vector end date (or estimate), is a compound date that is a function of vector start date (or estimate) plus the duration (or estimate). It just so happens that if this vector was connected to the node, above, the vector start date (or estimate) is equal to the USLGB departure date (or estimate).

Good Stakeholder Support Changes the Game

What is your goal? To be a great international transportation team? Or to be great at supporting your stakeholders?

If you only care about being great at managing international transportation, then you will never level up your organization. But if your goal is to be amazing at stakeholder support, your success will transform your entire organization.

Great stakeholder support requires you to up your game on date management...and specifically, upping your game on understanding what dates mean.

Stakeholders Have Requirements and Demands

For the sake of simplicity, let's pretend your only stakeholder is a customer. And your job is to ensure that the customer is up-to-speed on when their shipment is arriving at their location. How could you do this?

1. They might require that the shipment arrive at their facility BEFORE a certain date. This means that there are a whole set of dates that are acceptable (anything before the date), and a whole set of dates that are unacceptable (anything after the date).
2. They might require the shipment AFTER a certain date.
3. They might require the shipment in a window, which is a composite of 1 & 2.

Each scenarios represents a customer requirement or demand, and these requirements are different in nature than other operational dates in the system. They don't change based on the vicissitudes of the supply chain. The are generally hard and fixed, and dealing with issues are almost always best done as early as possible. They represent a comparator, and evaluative framework for understanding if your execution is meeting the needs of your stakeholder.

What it means, technically, is that when the ETA (end customer) is evaluated to be within the bounds of each scenario your customer will be satisfied. When the ETA (end customer) falls outside of the evaluative range, your customer support team needs to engage to determine the best course of action and try to resolve the issue (which could take many forms).

But these aren't the only scenarios.

What if:

4. There was no requirement for a particular date, BUT your organization had previously informed the customer that their shipment would be delivered on certain date, so you have set an expectation.

This scenario is particularly pernicious. Given that you have set an expectation, not meeting it would be a problem.

The issues here aren't exactly obvious. The first is that you need to be aware, organizationally, that a date has been set in the mind of the customer. It isn't a required before or a required after date. Those are both requirements that are set BY the customer. And it isn't a required on date, because it isn't required on that date. Your organization needs to understand that when a customer was notified of a date, that you are aware that it is important to them, and are able to respond appropriately when the date changes. It requires a heightened level of sensitivity, and it will show.

The second thing that you need to be aware of, again organizationally, is that an action needs to be taken to inform the customer of the change. Early engagement not just limits the damage, but makes it obvious to your customer that you are on top of things.

I've been rambling on about dates, and this is probably sufficient for now.

What you need to understand is that your supply chain is complex, with hundreds of dates that need to be managed to up your supply chain game.

I want you to think about how you are managing your dates. How many of the dates are being managed systematically from an operational perspective?

How are your stakeholder requirements/demands understood?

Are you able to do this systematically (ERP or TMS)...or are you using spreadsheets?

If you are having trouble getting your head around this, drop me a line. I'd love to continue this conversation, and see if we can't help you up your game.