[throwaway0a5e]

It should go without saying that there are nuances in implementation. What I'm describing here is a fundamental tradeoff of JIT systems. If you get the wrong thing delivered it throws a bigger wrench into things because you don't have the buffer. Can you make this rare enough that the amortized cost is low enough to make JIT overall cheaper? Of course, that's why everyone does JIT.

[Jtsummers]

> If you get the wrong thing delivered it throws a bigger wrench into things because you don't have the buffer.

JIT, in Lean, does not mean no buffer, it means as little of a buffer as you can get away with. If you have issues with delivery like this on a regular basis, then you'd increase the buffer size (at least temporarily) and also take your suppliers to task for sending the wrong thing over and over.

The buffer size should be increased if any upstream supply issues exist that regularly cause a shortage. Ideally, you should address those issues themselves, but if you have and they can't (or won't) be fixed then you increase your buffer to accommodate reality. However, the shortage is itself a signal. Too high an inventory permits supply issues to persist without being addressed for a long time because you never get the signal about the issues with them (the downstream production slowdowns).

[hencq]

> JIT, in Lean, does not mean no buffer, it means as little of a buffer as you can get away with.

Yeah, spot on. One of my college professors used to compare it to a river with rocks in it. If you want to safely sail on the river, you can either a) keep the water level high enough or b) remove the rocks. In a production system inventories/buffers are the water level and variance is the rocks. The philosophy of JIT is to remove as much variance from your system as possible so you can lower your buffers. If you have identified areas of high variance you're forced to keep buffers until you've removed enough variance to lower your buffers.

[pishpash]

Or, you've lowered your water to barely cover the rocks so one little mishap and you've capsized.

[cptskippy]

> JIT, in Lean, does not mean no buffer, it means as little of a buffer as you can get away with.

Eh... I would argue that JIT means making that buffer someone else's problem.

I was doing EDI at a logistics firm that contracted with Seagate who provided HDDs to Hitachi for their SANs around 2006. Hitachi was doing JIT for their manufacturing, Seagate however was just speculating Hitachi's demand and literally stockpiled HDDs in this firms warehouses geolocated next to Hitachi's factories.

We would pickup stock from Seagate and ship it to these warehouses where they would remain Seagate's property until Hitachi requested it, then we would simply transfer ownership to Hitachi.

Interestingly, we used rail shipping as a buffer to reduce warehouse size by sending freight on slow/cheap/indirect routes.

[Jtsummers]

In this case you have two buffers. Seagate/you have a buffer for the outflow based on expected consumption rate. Hitachi almost certainly has some buffer of their own. This is not unusual with physical goods where you have the transportation time and cost to consider (which you/your employer took advantage of).

If Hitachi couldn't consume your delivered HDDs as fast as they were delivered and anticipated any kind of delay/disruption could ever happen, they'd have some buffer of their own.

[cptskippy]

In this case Hitachi didn't have a buffered supply. The warehouses were located literally across the street. The products were palletized at Seagate's factory in quantities matching Hitachi's product lines then delivered to the warehouse in a cadence closely matching Hitachi's consumption rate. So when Hitachi placed an order, a pallet was pulled and the ownership of the serial numbers on that pallet were transferred to Hitachi as it was delivered.

The logistics firm was the buffer allowing Seagate's product rate and Hitachi's consumption to be asymmetric in nature.

[hef19898]

The last bit works, as long as the slow transportation is closely controlled. I tried it once, in the end warehouse space was cheaper.

EDIT: What you describe sounds more like VMI, vendor managed inventory, than JIT. Both require half way reliable forecasts and collaborative planning so to worl properly. Have to agree so that both solutions tend to push inventory risk to suppliers. Done correctly, overall inventory does decrease so.

[cptskippy]

JIT and VMI go hand-in-hand, they aren't mutually exclusive. Implementing JIT is to impose VMI on your suppliers.

The interesting thing was that Seagate avoided managing inventory by outsourcing to the logistics firm. The stock was technically Seagate's until it was ordered by Hitachi but the logistics company took immediate possession as pallets rolled out of the factory.

> The last bit works, as long as the slow transportation is closely controlled.

It didn't need to be controlled, just scheduled. You knew you need x units by d. The factory output n per week, so you could stagger shipments by way of different lines.

All of the inventory was tracked by serial numbers and it was interesting to watch it move because supply was often delivered to the warehouse out of order or shipments weeks apart arrived simultaneously.

[hef19898]

The way I used was VMI to avoid the limited flexibility of JIT, bit yes both concepts tackle the same problem. What you describe sounds like a lot of fun to run on a daily basis, would have loved to do that!

[a9h74j]

I wonder if Toyota was a little slower at starting to expedite, for having had a large buffer stock already in hand.