4 ms·

JIT doesn't mean you should carry no inventory or wait for orders. You should carry enough stock that you sell out of just in time for the replenishment to arri

JIT doesn't mean you should carry no inventory or wait for orders. You should carry enough stock that you sell out of just in time for the replenishment to arrive.

mschuster91 6y ago
The practical implementation of JIT production is to get rid of (expensive) warehouses and instead have rolling trucks on streets be the warehouse - you need the trucks anyway to transport stuff, but now you don't have to pay for the space as roads are owned by the public.
- drewcoo 6y ago
  Sounds like the drug dealer model, where product is largely delivered to customers as they need it. Large stashes of drugs have additional potential downside, making the model more attractive than normal.
- adingus 6y ago
  This may be the end game of JIT. But Deming and Shingo would have defined quality as "meeting the customers needs" and having them wait for parts does not accomplish that. Don't let the theoretical get in the way of the practical.
- p_l 6y ago
  Capitalist race to the bottom in action, with JIT as enabler. IIRC, one of the classic elements of kanban was also that you could easily setup a buffer at any point in the system, by controlling the number of cards/boxes, with kanban regulating the flow. I.e. it's trivial to use TPS approaches to setup a "we need X amount of slack" and have its decentralised pull-based system appropriately adjust flow to maintain said slack. Unfortunately in steady state the extra cost of maintaining slack is seen as unnecessary drag on company performance, and since you can't depend on competition having to maintain similar amount of slack... why be less competetive?
  - dragonwriter 6y ago
    > Unfortunately in steady state the extra cost of maintaining slack is seen as unnecessary drag on company performance One of the reasons for maintaining slack is that many processes have been repeatedly shown to be on-average more productive when managed with slack in normal operations than without, because the disruption that occurs when processes have no slack and irregular events occur is much more costly than a certain amount of slack. Right-sizing slack makes you more, not less, competitive. It's quite often not company performance concerns that drive out slack but the short-term performance of the unit at exactly the level the decision is made, and it's typically an eyes-open decision to gamble on unsustainable short-term gains lasting long enough to meet a short-term goal of the decision-maker (often, a bid to get a better job where they are no longer immediately responsible for the function being compromised). One of the biggest fallacies is there management decisions within a company are consistently, or even mostly, driven by interests of the company as a whole, rather than the individuals making decisions, who often face practical personal incentive structures (especially in terms of career advancement) in which seeking the broad interests of the company and it's shareholders are not optimal.
    - p_l 6y ago
      I'll admit that I might have been a bit too general (and influenced by https://slatestarcodex.com/2014/07/30/meditations-on-moloch/ https://slatestarcodex.com/2014/07/30/meditations-on-moloch/) Arguably that's a case of internal competition - the short term gamble will pay off showing you as more competitive, and you're not going to be there for the consequences, are you? That said, I have encountered (more like been in the office when the discussion happened and got rest of the tale) bean counting issues at highest levels of a telco conglomerate where the "international" level was asking why we were spending so much on BTSes, with particular issue being how we stuck sizeable UPSes on them - whose maintenance wasn't cheap. Ultimately it turned out that other national units (this was level of individual, nation-wide european telcos in one multinational) were either doing creative accounting or just skipping on reliability. But because of that, their BTSes looked much cheaper than ours, and we were getting the flack from multinational level.
Lio 6y ago
This is one of the conclusions of playing "The Beer Game"[1] which aims to have players simulate a supply chain. To begin with players try to decrease local inventory to get a better score. i.e. lower costs by holding less. Then when a shock to the system is introduced, and orders spike, the players struggle to meet demand and the system becomes chaotic. This seems to happen even when players have played the game before. The lesson seems to be that you can't easily do JIT without very good lines of communication or buffer inventory which is expensive. As I remember it the cute, old metaphor I was taught was that inventory was like water in a river. We aim to lower the water until you just expose the rocks but no more. Then you remove the rocks one by one. If you deplete your inventory too soon you're exposing too many rocks and you'll ground your boat. 1. http://web.mit.edu/jsterman/www/SDG/beergame.html http://web.mit.edu/jsterman/www/SDG/beergame.html

JIT doesn't mean you should carry no inventory or wait for orders. You should carry enough stock that you sell out of just in time for the replenishment to arrive.

mschuster91 6y ago

The practical implementation of JIT production is to get rid of (expensive) warehouses and instead have rolling trucks on streets be the warehouse - you need the trucks anyway to transport stuff, but now you don't have to pay for the space as roads are owned by the public.

drewcoo 6y ago
Sounds like the drug dealer model, where product is largely delivered to customers as they need it. Large stashes of drugs have additional potential downside, making the model more attractive than normal.
adingus 6y ago
This may be the end game of JIT. But Deming and Shingo would have defined quality as "meeting the customers needs" and having them wait for parts does not accomplish that. Don't let the theoretical get in the way of the practical.
p_l 6y ago
Capitalist race to the bottom in action, with JIT as enabler. IIRC, one of the classic elements of kanban was also that you could easily setup a buffer at any point in the system, by controlling the number of cards/boxes, with kanban regulating the flow. I.e. it's trivial to use TPS approaches to setup a "we need X amount of slack" and have its decentralised pull-based system appropriately adjust flow to maintain said slack. Unfortunately in steady state the extra cost of maintaining slack is seen as unnecessary drag on company performance, and since you can't depend on competition having to maintain similar amount of slack... why be less competetive?
- dragonwriter 6y ago
  > Unfortunately in steady state the extra cost of maintaining slack is seen as unnecessary drag on company performance One of the reasons for maintaining slack is that many processes have been repeatedly shown to be on-average more productive when managed with slack in normal operations than without, because the disruption that occurs when processes have no slack and irregular events occur is much more costly than a certain amount of slack. Right-sizing slack makes you more, not less, competitive. It's quite often not company performance concerns that drive out slack but the short-term performance of the unit at exactly the level the decision is made, and it's typically an eyes-open decision to gamble on unsustainable short-term gains lasting long enough to meet a short-term goal of the decision-maker (often, a bid to get a better job where they are no longer immediately responsible for the function being compromised). One of the biggest fallacies is there management decisions within a company are consistently, or even mostly, driven by interests of the company as a whole, rather than the individuals making decisions, who often face practical personal incentive structures (especially in terms of career advancement) in which seeking the broad interests of the company and it's shareholders are not optimal.
  - p_l 6y ago
    I'll admit that I might have been a bit too general (and influenced by https://slatestarcodex.com/2014/07/30/meditations-on-moloch/ https://slatestarcodex.com/2014/07/30/meditations-on-moloch/) Arguably that's a case of internal competition - the short term gamble will pay off showing you as more competitive, and you're not going to be there for the consequences, are you? That said, I have encountered (more like been in the office when the discussion happened and got rest of the tale) bean counting issues at highest levels of a telco conglomerate where the "international" level was asking why we were spending so much on BTSes, with particular issue being how we stuck sizeable UPSes on them - whose maintenance wasn't cheap. Ultimately it turned out that other national units (this was level of individual, nation-wide european telcos in one multinational) were either doing creative accounting or just skipping on reliability. But because of that, their BTSes looked much cheaper than ours, and we were getting the flack from multinational level.

Lio 6y ago

This is one of the conclusions of playing "The Beer Game"[1] which aims to have players simulate a supply chain. To begin with players try to decrease local inventory to get a better score. i.e. lower costs by holding less. Then when a shock to the system is introduced, and orders spike, the players struggle to meet demand and the system becomes chaotic. This seems to happen even when players have played the game before. The lesson seems to be that you can't easily do JIT without very good lines of communication or buffer inventory which is expensive. As I remember it the cute, old metaphor I was taught was that inventory was like water in a river. We aim to lower the water until you just expose the rocks but no more. Then you remove the rocks one by one. If you deplete your inventory too soon you're exposing too many rocks and you'll ground your boat. 1. http://web.mit.edu/jsterman/www/SDG/beergame.html http://web.mit.edu/jsterman/www/SDG/beergame.html