3 ms·

I work in a custom fabrication environment, and this solution doesn't really apply, because what happens in a dynamic system is that the bottleneck shifts all a

I work in a custom fabrication environment, and this solution doesn't really apply, because what happens in a dynamic system is that the bottleneck shifts all around the shop dynamically. It's never just one operation that is the constant bottleneck.

owenmarshall 5y ago
How doesn't it? I've lived in a world of coordinated microservices before, where a nice linear progression of queues only happens at the atomic level; when you zoom out you've got a digraph full of cycles, nodes that come & go in response to various events & schedules, and the transitory nature of those services entering could cause a smooth-sailing pipeline to suddenly seize up because some downstream dependency is servicing higher-priority requests. The only way we could stay sane was aggressively following Ferd's rule – nobody got to surface an API unless it surfaced HTTP 429s on overload[1], and if you called a downstream API without checking for and responding to a 429, tough noogies, your requests got dropped and you had to figure out what to do to fix it. Funny enough, at the time I did software for a manufacturing facility that did high-throughput manufacturing for many varying products. I was lucky enough to do a "gemba walk" where they made us engineers put on hard-hats and eye protection and reminded us who actually made the company money, and by god those guys were doing exactly what we did: they had JIT delivery of raw materials / sub-components to assembly lines, and the delivery of resources to the line was always constrained by a fixed buffer, quite literally "how many units you could put on a shelf". You couldn't just toss more product at a line that wasn't ready for it, it would literally not fit. Sure, they used different terms than we did – muda and muri and value-stream mapping – but the outcome was very similar. Their version of the NOC was a team of managers who watched the cycle time of each line, how long it took material to be transported, which areas were bottlenecking and which were at risk of running into resource starvation, and they had the ability to balance the hot spots by bursting product in, caching upstream components into hold docks, releasing held work product to downstream lines, or even turning on a flex line to work around longer-term constraints. They rarely had fixed, static bottlenecks, because they optimized the life out of them. Their bottlenecks arose when a shipment didn't arrive (and you better believe those were tracked just as aggressively), a machine broke down, an operator got sick, things like that. But at the end of the day? Same principle: downstream components would only accept as much as they could process from upstream components; you asked before you pushed. [1]: and if you said "I swear, you can't overload this service, we don't need to send 429s" a swarm of senior engineers descended upon you and only left until you convinced them they were wrong, or – way more likely – they convinced you.
- prometheus76 5y ago
  Manufacturing and fabrication are two different worlds. Manufacturing is all about reducing/eliminating variance, whereas fabrication (high-mix, low volume) is all about absorbing variance. Most of the things we build have never been built before, and most of them will never be built again. So the estimates on how long it will take to build one is just that: an estimate. And the process of fabricating it is affected by MANY variables, but I'll just list a few. Materials with long lead times. Materials not arriving on time. Wrong materials sent. A pareto distribution of time it will take to finish an operation depending on which employee I give it to. What else is in the queue for an operation. Whether customers put a hold on the part. And so on, and so on. Every manufacturing person I've met thinks we're just idiots. Then they come to our shop and it takes them about 1-2 years of trying to "we just need to implement Lean, guys!" before they realize that fabrication has very little, if anything, in common with manufacturing and the only lean principle that really applies is keeping your work area tidy and your tools organized. Our business model is built around our ability to absorb and manage variance, rather than eliminate it.
  - owenmarshall 5y ago
    Very interesting - thanks!
  - galaxyLogic 5y ago
    Would this apply to "Software Fabrication" as well?
    - prometheus76 5y ago
      Yes, we have much more in common with software development than we do with manufacturing. We have more stages of production than software, and we have a challenging situation of shared resources between projects (we are generally working anywhere from 25-50 projects at once in our shop using shared resources), but the variance factor of 1) not knowing exactly how long it will take to make something because it's never been made before, and 2) different employees taking vastly different amounts of time to accomplish the same task are both shared challenges that we face along with software development.

owenmarshall 5y ago

How doesn't it? I've lived in a world of coordinated microservices before, where a nice linear progression of queues only happens at the atomic level; when you zoom out you've got a digraph full of cycles, nodes that come & go in response to various events & schedules, and the transitory nature of those services entering could cause a smooth-sailing pipeline to suddenly seize up because some downstream dependency is servicing higher-priority requests. The only way we could stay sane was aggressively following Ferd's rule – nobody got to surface an API unless it surfaced HTTP 429s on overload[1], and if you called a downstream API without checking for and responding to a 429, tough noogies, your requests got dropped and you had to figure out what to do to fix it. Funny enough, at the time I did software for a manufacturing facility that did high-throughput manufacturing for many varying products. I was lucky enough to do a "gemba walk" where they made us engineers put on hard-hats and eye protection and reminded us who actually made the company money, and by god those guys were doing exactly what we did: they had JIT delivery of raw materials / sub-components to assembly lines, and the delivery of resources to the line was always constrained by a fixed buffer, quite literally "how many units you could put on a shelf". You couldn't just toss more product at a line that wasn't ready for it, it would literally not fit. Sure, they used different terms than we did – muda and muri and value-stream mapping – but the outcome was very similar. Their version of the NOC was a team of managers who watched the cycle time of each line, how long it took material to be transported, which areas were bottlenecking and which were at risk of running into resource starvation, and they had the ability to balance the hot spots by bursting product in, caching upstream components into hold docks, releasing held work product to downstream lines, or even turning on a flex line to work around longer-term constraints. They rarely had fixed, static bottlenecks, because they optimized the life out of them. Their bottlenecks arose when a shipment didn't arrive (and you better believe those were tracked just as aggressively), a machine broke down, an operator got sick, things like that. But at the end of the day? Same principle: downstream components would only accept as much as they could process from upstream components; you asked before you pushed. [1]: and if you said "I swear, you can't overload this service, we don't need to send 429s" a swarm of senior engineers descended upon you and only left until you convinced them they were wrong, or – way more likely – they convinced you.

prometheus76 5y ago
Manufacturing and fabrication are two different worlds. Manufacturing is all about reducing/eliminating variance, whereas fabrication (high-mix, low volume) is all about absorbing variance. Most of the things we build have never been built before, and most of them will never be built again. So the estimates on how long it will take to build one is just that: an estimate. And the process of fabricating it is affected by MANY variables, but I'll just list a few. Materials with long lead times. Materials not arriving on time. Wrong materials sent. A pareto distribution of time it will take to finish an operation depending on which employee I give it to. What else is in the queue for an operation. Whether customers put a hold on the part. And so on, and so on. Every manufacturing person I've met thinks we're just idiots. Then they come to our shop and it takes them about 1-2 years of trying to "we just need to implement Lean, guys!" before they realize that fabrication has very little, if anything, in common with manufacturing and the only lean principle that really applies is keeping your work area tidy and your tools organized. Our business model is built around our ability to absorb and manage variance, rather than eliminate it.
- owenmarshall 5y ago
  Very interesting - thanks!
- galaxyLogic 5y ago
  Would this apply to "Software Fabrication" as well?
  - prometheus76 5y ago
    Yes, we have much more in common with software development than we do with manufacturing. We have more stages of production than software, and we have a challenging situation of shared resources between projects (we are generally working anywhere from 25-50 projects at once in our shop using shared resources), but the variance factor of 1) not knowing exactly how long it will take to make something because it's never been made before, and 2) different employees taking vastly different amounts of time to accomplish the same task are both shared challenges that we face along with software development.