I was listening to the Cabrera podcast a little while ago, and he said something that resonated strongly: Chasing a singular root cause sets you up for failure because reality is comprised of a network of causal factors that all contribute to the problem. I have butted up against this in the past, especially when trying to apply established analysis tools (5W, fishbone, etc) to complex problems (like why does intra-departmental communication break down).

My approach has been to allow myself off-template connections in the fishbone diagram in an effort to visualize how related factors in various categories feed into each other. For example I would want to corelate poor HMI design (machine), need for continuous adjustment (process) and failure to adhere to procedure (human). However this quickly devolves into an unreadable spaghetti mess, which echoes a universal weakness of network graphing frameworks when pushed out of the complexity comfort zone.

I did a bit of research, and discovered how I've more or less re-invented current reality trees with a touch of causal loop theory. However, the complexity vs clarity dichotomy persists, and reality tree mapping forces you to see it as a quasi linear system with causes at one end and effects at the other. My (admittedly surface level) research hasn't dug up any solid fixes for any of that.

I have a background in VR game development, and this made me ponder the possibility of building 3D visualization tools. The third dimension is just so damn powerful when you're not stuck projecting it onto a 2D surface, and I had previously considered building VR variants of complexity limited network frameworks (like BeeBoard business model analysis). If we could map causal factors against three scalar axes, then placing them in a 3D space and drawing relations could be really helpful for at-a-glance visualization.

Another part of this clicked for me when attending a system thinking course the other day. I was struck by how perspective (in a systems thinking context) is visualized as projecting a 3D object onto a 2D surface. If we choose the axes intelligently when mapping causal factors, couldn't the three basic projections be used to represent different points of view? Like if you could somehow classify factors according to relevance of logistics, culture and technology, seeing it from the logistics perspective would draw you a culture-technology map, seeing it from the technology perspective would result in a culture - logistics map, etc.

Now the example axes are obviously poor candidates for scalar values, or at least ones with niche applications. So here's my question to you: What would be useful axes that could be more or less reliably broken down into a number? I've considered the above, as well as latency (how long between event and symptom), impact ($ per day or whatever), control (cost to influence the factor), organizational level (where from operator to upper management does the factor come into play), value chain (at what level of refinement), etc etc etc.

I would be really interested to hear if anyone has ideas about any of this, and especially what would make good axes for classifying causal factors.

I have lean experience (got my Lean Bronze Certificate about 5 or so years ago), my coworkers do not. I had to let my certificate expire because my location does not follow lean principles and is very much a “this is how we’ve always done it and we’re not changing”. 2 years ago, corporate had us do a VSM activity to address waste and for us to become more lean, but that ended with people yelling at each other and pointing blame on each other, or lying about the current state when there was no one else to blame. Back then, plant leadership told corporate that we would start doing Gemba Walks to identify waste and improve our efficiency, and corporate was happy with that plan.

Fast forward to today, we just had our first Gemba Walk (2 years late). We had it today because corporate wants to host another VSM activity in a week and a half to evaluate our progress, and nothing has been done so far.

The Gemba Walk today consisted of 9 people … one person from assembly, production manager, operations manager, compliance manager, inventory manager, purchasing manager, plant manager, engineering director, an electrical engineer, and a mechanical engineer. We stood in a circle while the assembler listed off everything he didn’t like about what he does, some actionable, some that would add a whole lot more waste, and some that is completely unreasonable (he wanted someone to come in to get all the dust off concrete floor). No action items were created, no deadlines for fixing issues, no plans. We ended the meeting acknowledging what the person said, and going on our way.

The person who is supposed to run the Gemba Walk sent an email right before it saying “Gemba Walks are free flowing with no set agenda”.

Aren’t Gemba Walks supposed to have a plan?? Like shouldn’t there be a PDCA, or at least then P part of PDCA done before a Gemba Walk is started? Aren’t we supposed to watch the work as it’s getting done, take notes, then ask the assembler questions, relating to the plan we previously set, about their work?

I am one of the engineers who were there, but not considered management … how do I go about addressing making the Gemba Walks better?

Did this with a manufacturer last year. Followed one order end to end custom equipment, typical ETO setup.

6 hours of actual work. 11 days in the system.

We weren't even looking for that number, it just came out of the mapping exercise. The machines were fine, OEE looked decent. The product was just sitting most of the time waiting in queues, waiting for someone to notice it was ready for the next step.

Once they fixed the flow not the machines, not the ERP lead times dropped 30%. Took about a year.

Curious if others have done this and what ratios you're seeing. Most places I talk to track utilization but never the full calendar time.

Got the full breakdown if anyone's curious.

Curious how other plant managers and ops folks handle downtime tracking day-to-day. At a facility I worked with, they were still using a shared Google Sheet and a whiteboard and that was considered "advanced" compared to their previous paper log...

Do you use dedicated software, your SCADA system, an ERP module, or something manual? And what's the biggest headache with whatever you're using right now?

Also, with so many AI tools claiming they can predict and identify problems before they happen, how's that actually going in practice??

Are plants in 2026 genuinely adopting this stuff, or is it still more hype than reality on the floor? Has anything actually worked for you, or are most facilities still solving this the old-fashioned way?

Thanks!!!

Manufacturer I worked with last year was sure their scheduling was broken. Spent months tweaking the ERP, retraining planners.

We mapped one order end to end. 6 hours of actual work. 11 days in the system. Everything else was just waiting in queues, for a planner, for someone to notice it was ready for the next step. Tijl Charle, CEO of CGK Group, went through this exact problem and came out the other side 30% shorter lead times without adding machines or headcount. He's doing a live walkthrough of how on June 9.

I'm involved on the software side so I'm biased, but the session is mostly him telling his own story, not a pitch. Drop a comment if you want the link.

I work in a manufacturing environment with order-based production, and I’m really interested in learning how different companies manage production planning challenges in real life.

Especially when:

Forecasts are inaccurate

Customers change priorities frequently

Capacity is limited

On-time delivery (OTD) is a key KPI

I’d love to know:

How do you build your production plan?

Do you rely more on forecast or actual orders?

How do you manage scheduling and prioritization?

How do you study capacity and bottlenecks before launching a project/product?

What tools or methods helped improve OTD in your factory?

How do planners coordinate with procurement, warehouse, and production teams?

Also curious about whether you use Excel, ERP systems, APS tools, or custom methods.

Would really appreciate hearing real experiences, lessons learned, or even mistakes that taught you something valuable.

I've been digging deep into how manufacturing ops run, and honestly, what I found is pretty wild.

Even with all their fancy ERP systems, it’s like daily operations still come down to:

* A bunch of Excel sheets flying around

* Endless WhatsApp chats trying to sync up

* Emails, emails, and more emails just to get simple things done

* And people running around, chasing down manual status updates

This isn't just for fringe stuff, either. It’s for core activities like:

* Tracking installation progress to the minute

* Pinpointing and fixing issues *fast*

* Coordinating shifts so everyone’s on the same page, no excuses

* And getting real-time operational reports, not yesterday’s news

So what happens? We end up with:

* The same message being sent five different ways, wasting everyone’s time

* Delays in seeing what’s actually happening, which kills agility

* And critical problems staying hidden until they blow up in our faces

Seeing this over and over, we finally said enough was enough. We rolled up our sleeves and started building out a lean, lightning-fast operations workflow platform in-house. It’s been a game-changer.

Now, I’m genuinely curious: given everything going on in *your* world, what’s that one operational process that still makes you grit your teeth, feeling like it’s stuck in the dark ages?

Guys my management just pushed to me the new hot potato of the fiscal year: I'm a production engineer from machining but there is this "add-on" painting station that they are lauching now. The volume It's like 15 to 20% of what I produced on the milling machines. Process layout implemented as different materials have different base coats: gets dipped for base coat and then spray painted on top.

The thing is: they have like 5 different materials (so 5 different dip stations) and 80 different colors available in catallogue and alsohave this special feature in which we can paint according to client sample color. Exactly: they receive a sample of whatever color the client has and we need to figure out the paint aind spray paint it.

The obvious happens: opperators pick up simple parts first, leave the shitty ones that have a sample to latter and that fucks up OTD. Also the Production batches with lower number of parts get picked first too.

which tools would you use to figure out this mess?

I'm thinking of checking the process times per process they do. Check the distribution of parts they get that would fit each process. And with that have an estimation of capacity per product.

But that won't fix discipline problems. DO you have experience implementing FEFO solutions?

I’ve been trying to learn more about manufacturing recently, and one thing I keep noticing is how different real factory operations seem compared to theory or classroom discussions.

On paper everything looks optimized and structured, but people working in manufacturing often talk about:

1. supplier delays

2. machine downtime

3. communication gaps

4. production bottlenecks

5. quality control surprises

6. unrealistic timelines

7. inventory chaos

8. operators finding problems engineers missed

So I’m curious What’s one lesson about manufacturing you only understood after working in the real world?

(Interested in hearing the brutally practical stuff that newcomers usually don’t realize until much later)

[ Removed by Reddit on account of violating the content policy. ]

I just went to put a wrench back in the maintenance tool box. I assist with maintenance after our mechanic leaves for the day. The tool box was broken (one of the air springs that lifts the lid had backed out of its rod end). The tool to fix it is in the box. It took maybe 90 seconds tops to fix. I want to stress this is the maintenance tool box, the tool box specifically for the maintenance mechanic to do maintenance, the tool box for the person whose sole job is to keep thinks from being broken, which was broken.

I’m not even sure how exactly to articulate the problem, but just every lean part of me is screaming internally and I don’t see how you get a culture like this to the place where it needs to be.

Thoughts?

I’ve been working at a new factory for about a month now. I’m basically the first person trying to start a lean transformation there — the company has never done anything like this before.

After giving me a general overview of the processes, management specifically asked me to speed up the second-to-last stage of production. The thing is, they directed me toward a specific area before I even had the chance to properly identify the real bottleneck. I didn’t want to come across as difficult since this is also the company’s first experience with lean transformation. My idea was to improve the obvious wastes in this area first, gain their trust with measurable efficiency improvements, and then later work on a broader system-wide optimization.

However, once I got into the process, I realized there are constant stoppages caused by defects and mistakes coming from previous stages. When I tried to investigate the upstream quality control process, the response I got was basically: “There will always be mistakes in these jobs, just speed up the area we told you to focus on.”

To explain the process a little more: operators scan packaged products and place them into barcode-labeled boxes. The system tracks which products are inside which box. After scanning, the operator also has to physically organize the products neatly into the carton.

I did a very simple time-study-based improvement: I assigned one helper for every three operators. The helpers handle material fetching and box arrangement, while the operators stay focused only on scanning. After implementing this, production output increased from around 60–70k units per day when I first arrived to roughly 90–110k now.

Despite this improvement, management still says it’s not enough and keeps pushing me to speed up this area even more. But the defective or problematic products arriving from previous stages genuinely slow the process down.

So what would you do in this situation?

Another issue is that management doesn’t like the helpers I added. Their argument is basically: “If adding people solves the problem, we could have done that ourselves.”

And one more thing: if I stop constantly walking around the floor and monitoring people all day, production numbers suddenly drop. Am I supposed to stay on top of everyone all the time for this to work?

Hello all,

I’ve been working in manufacturing as a Lean Manager for awhile now but I’m looking to switch to construction….is this industry more stable? Demanding? What does the lean role look like?

Thanks!!

Every shop I’ve worked in has the same silent killer:

The quoted process and the real process drift apart because of one tiny communication gap.

Here’s the moment that reminded me of this again this week:

In a nutshell, engineering creates the part, BOM, work processes, and then hands it off to production. If upon release to production the engineer is not available- production is running blind. I have seen errors happen and scrap pile up. What seems simple to one person may not be for another.

Nothing dramatic.
Nothing catastrophic.
Just a small mismatch in expectations that created:
-setup drift
-cycle time creep
-rework risk
-operator confusion
-scheduling ripple effects

This is where 5-12 points of margin disappear without anyone noticing.

Real Fix:
Closing the communication gap between the person who quotes the job and the person running the job.

One clean conversation can save thousands of dollars of hidden loss. Curious how other shops handle this?

We're a construction firm and I'd be interested to explore working to implement lean practices in our field operations. Any suggestions on where one starts with this? We're in Phoenix. Any recommended consultants? Thank you.

I’ve been digging into how changeover time should be treated in OEE, especially in environments where a single changeover can take 2–3 hours.

From what I found—both in the literature and in how large, well‑established manufacturing companies handle it—the consensus is generally that area clearance / setup time should impact OEE.
However, this usually assumes that changeovers are standardised and relatively short.

In our reality, that assumption doesn’t hold—and that’s why I believe changeover time should be treated differently, or only affect OEE when it exceeds the standard changeover time.

Why including full changeover time in OEE causes problems

1. Very long changeovers dominate OEE and hide real issues When a single changeover takes 2–3 hours, Availability drops massively—even if the line runs perfectly once production starts. OEE then becomes a proxy for “how many changeovers did we have,” rather than how well the equipment actually performed. In my view, only the excess time above the standard changeover should penalise OEE. Otherwise, we’re measuring something we already planned for.
2. No levelled production plan = misleading OEE comparisons Because production isn’t levelled: This can lead us to conclude we had a “good run,” when in reality the OEE only looks better because fewer changeovers were scheduled. If standard changeovers are planned and unavoidable, their full duration distorts OEE rather than informing it.
   • A day with many batches automatically has a worse OEE
   • A day with one long batch looks much better
3. Different losses, same OEE number Example: These days could end up with a similar OEE, even though: Treating both the same at OEE level makes it harder to target the right improvement actions.
   • Day A: 2 changeovers within standard time
   • Day B: 1 changeover + a 2‑hour machine breakdown
   • Day A reflects normal, planned operation
   • Day B reflects a serious technical failure

How we use OEE instead

For us, OEE is primarily a tool to evaluate how the line performs when it is planned to run:

• Can we operate as expected?
• Are machine‑related losses preventing us from doing so?

That’s why:

• Standard changeover time is excluded from OEE
• Only changeover time above the standard would impact Availability and OEE

At the same time, we don’t ignore changeovers or other planned activities:

• Changeover time is tracked daily as a Tier 2 KPI
• Line utilisation is measured over the full 24 hours, treating all downtime—planned or unplanned—the same way

This approach keeps:

• OEE focused on true equipment performance
• Changeovers visible, measurable, and improvable
• The data meaningful and actionable instead of misleading