Skip Navigation
115 comments

  • I blame lean philosophy. Keeping spare parts and redundancy is expensive so definitely don't do it...which is just rolling the dice until it comes up snake eyes and your plant shuts down.

    It's the "save 5% yearly and stop trying to avoid a daily 5% chance of disaster"

    Over prepared is silly, but so is under prepared.

    They were under prepared.

    • Lean philosophy is supposed to account for those dice-rolling moments. It's not just "keep nothing in inventory", there is supposed to be risk assessment involved.

      The problem is that leadership doesn't interpret it that way and just sees "minimizing inventory increases profit!"

      • The problem is that leadership doesn’t interpret it that way and just sees “minimizing inventory increases profit!”

        Yep. Managers prioritize short-term gains (often personal gains, too) over the overall health of a business.

        There's also industries where the "lean" strategy is inappropriate because the given industry is one that booms in times of crisis when logistics to get "just in time" supplies go kaput due to the same catastrophe that's causing the industry to boom. Hospitals and clinics can end up in trouble like this.

        But there's other industries too--I haven't looked for it, but I'm sure there's a plethora of analysis already on what Covid did to companies and their supply chains.

      • In my own impression from the side of software engineering (i.e. the whole discipline rather than just "coding") this kind of thing is pretty common:

        • Start with ad-hoc software development with lots of confusion, redundancy, inneficient "we'll figure it out as when we get there" and so on.
        • To improve on this somebody really thinks things through and eventually a software development process emerges, something like Agile.
        • There are lots of good reasons for every part of this processes but naturally sometimes the conditions are not met and certain parts are not suitable for use: the whole process is not and can never be a one size fits all silver bullet because it's way to complex and vast a discipline for that (if it wasn't you wouldn't need a process to do it with even the minimum of efficency).
        • However most people using it aren't the "grand thinkers" of software engineering - software architect level types with tons of experience and who thus have seen quite a lot and know why certain elements of a process are as they are, and hence when to use them and when not to use them - and instead they're run-of-the-mill, far more junior software designers and developers, as well as people from the management side of things trying to organise a tech-heavy process.

        So you end up with what is an excellent process when used by people who know that each part tries to achieve, what's the point of that and when is it actually applicable, being used by people who have no such experience and understanding of software development processes and just use it as one big recipe, blindly following it with no real understanding and hence often using it incorrectly.

        For example, you see tons of situations where the short development cycles of Agile (aka sprints) and use cases are used without the crucial element which is actually envolving the end-users or stakeholders in the definition of the use cases, evaluation of results and even prioritization of what to do in the next sprint, so one of the crucial objectives of use cases - the discovery of the requirement details by interactive cycles with end-users where they quickly see some results and you use their feedback to fine-tune what gets done to match what they actually need (rather than the vague very high level idea they themselves have at the start of the project) is not at all achieve and instead they're little more than small project milestones that in the old days would just be entries in Microsoft Manager or some tool like that.

        This is IMHO the "problem" with any advanced systematic process in a complex domain: it's excellent in the hands of those who have enough experience and understanding of concerns at all levels to use it but they're generally either used by people without that experience (often because managers don't even recognize the value of that experience until things unexpectedly blow up) or by actual managers whose experience might be vast but is actuallly in a parallel track that's not really about dealing with the kinds of technical concerns that the process is designed to account for.

    • I work in a manufacturing company that was owned by the founder for 50 years until about 4 years ago when he retired. He disagreed with a lot of the ideas behind lean manufacturing so we had like 5 years worth of inventory sitting in our warehouse.

      When the new management came in, there was a lot of squawking about inefficiency, how wasteful it was to keep so much raw material on the shelf, and how we absolutely needed to sell it off or get rid of it.

      Then a funny little thing happened in 2020.

      Suddenly, we were the only company in our industry still churning out product. Other companies were calling us, desperate to buy our products or even just our raw material. We saw MASSIVE growth the next two years and came out of the pandemic better than ever. And it was mostly thanks to the old owners view that "Just In Time" manufacturing was BS.

  • This is a fun read in the wake of learning about all the personal data car manufacturers have been collecting

115 comments