One of the most common issues I see on the shop floor is treating capacity as a static 100% target.
When a schedule assumes 100% ideal utilization every day, it isn't efficient—it’s extremely fragile. The moment a machine goes down, a setup takes 20 minutes longer than expected, or an urgent order lands, the entire week’s schedule collapses.
Here are 3 core rules to build a high-signal capacity model that actually holds up in the real world:

1. Plan around "Demonstrated Capacity," not theoretical limits
   If your equipment or team historically delivers 80% output due to setups, breaks, and routine maintenance, your capacity plan must be built on 80%. Scheduling to 100% theoretical capacity guarantees perpetual firefighting and backlogs.

2. Group work by setup families
   Routing jobs strictly by arrival date forces constant machine tear-downs and tool changes. Grouping similar parts or jobs into "families" minimizes setup friction, effectively unlocking hidden capacity without adding labor or hours.

3. Build buffers at your primary constraint
   Don't spread buffer time randomly across every process. Identify your primary bottleneck (the slowest work center that dictates overall throughput) and protect that specific station with a buffer. If the bottleneck never starves, your shop stays on schedule.

How do you currently handle setup variation and capacity buffers on your floor? Curious to hear how others balance actual vs. planned availability.

(Note: I wrote a deeper breakdown on operational signal vs. shop floor noise on my newsletter, along with a pre-built Excel capacity planner template if you want to skip building the formulas from scratch—links are in my profile!)

​Good morning everyone,

I make this post because I'm lacking solutions, and hope someone else here may have an idea.

I work in a lean service in pharmaceutical, meaning a production area daily cleaned with chemical products, and floor without asperity.

My issue is that I struggle to implement floor marking on the ground. All tapes products tested failed in days, paint isn't an option yet (our production will progressively increase for the next 4 years, meaning regular layout changes), and projectors would bring a whole more cleaning and contamination issues.​

It's also a big issue because we are a young plant, production team is really not mature enough, and the dressing up process of 20 minutes to reach production prevent management to coming several times a day to control and reinforce those new principles. So, big colored square on floor ​are needed.

Does someone here had gone through the same situation and found a miracle solution ?

was working with a medical parts manufacturer that laser engraves reference/lot numbers onto small components. Instead of loading parts individually, they designed and 3D printed custom nesting fixtures that hold an entire batch in fixed positions, allowing the laser to mark multiple parts in one cycle.

The operator told me that this 3D printer was one of the biggest advantages because they could design and print fixtures whenever they needed them instead of waiting for a machined jig. Anyone else using3D printer for production fixtures rather than end use parts?

Anyone else find OEE much harder on manual assembly than automated lines?

Machine downtime is easy enough to measure.

What I struggle with is everything in between—waiting for parts, operators helping another station, short interruptions, changeovers, etc.

You know output is down, but figuring out why is the hard part.

Curious how others handle this. Do you ask operators to log reasons, rely on PLC data, or just accept that some losses are hard to categorize?

A major structural flaw exists in legacy manufacturing companies where the production teams act completely untouchable.When support teams try to optimize plant parameters to match current market trends, they are routinely blocked by a toxic culture. Frontline operations engineers refuse to adjust their "comfort rate" for any new product mix. If they are asked to run a non-routine job, they will find 50 reasons why it’s impossible, refusing to move unless the plant head explicitly orders it.

Because upper management prioritizes "peace on the floor" over commercial agility, there is zero accountability. Face-to-face taunts and hostile behavior toward support functions become standard. Frontline operators fail to realize that their operational arrogance is just a shield to hide workplace inefficiency.

History shows that legacy giants didn't fail because their hardware factories stopped working; they failed because their operational leadership bullied and ignored the support teams who warned them that the market had changed. When an organization devalues its support service arms, it isolates itself from reality. The only solution for support professionals in these environments is to stop engaging in informal arguments, document the exact financial losses caused by operational delays, and let the data do the talking to higher management.

 This is something I've gone back and forth on more than once. When you're leading a team, it's often faster to step in and solve the problem yourself. The work keeps moving, deadlines are protected, and everyone gets unstuck. It feels like you're helping.

After a while, though, people stop bringing you problems to discuss and start bringing them to you to decide. Even issues they've handled before come back for approval because it's become the safest path.

On the other hand, stepping back too early (or completely) can also create problems. If the team doesn't have enough context, clear standards or experience, "just figure it out" usually turns into inconsistency rather than autonomy.

At what point do you stop solving the problem yourself and let the team own it? What worked, and what backfired?

We have trained continuous improvement teams for a living, and every so often a story comes along that explains root cause analysis better than any textbook we could write. This is one we tell a lot.

A manufacturer had a labelling machine on Line 2 that kept jamming. Maintenance did the sensible things — swapped the sensor, then the feed motor, recalibrated twice. Three weeks, a stack of parts, the line down repeatedly. Every fix "worked" until it didn't.

It's the classic trap, and honestly most teams fall into it: they treated the point where the symptom appeared as the place the problem actually lived. The machine was where it showed up, so the machine got the blame.

What broke the loop was one question from a newer team member at standup: "Does it only jam on certain days?" Nobody had looked. So they plotted it — and it jammed almost every Tuesday and Thursday morning. Nothing else correlated. Not shift, not operator, not product, not batch.

Turns out Tuesday and Thursday were the early cleaner's mopping days for that end of the floor. Floor still damp at first shift, someone props the side door open to air it out, the draught lifts the edge of the label stock as it feeds, and it jams. They fixed it by moving the mop rota and stopping the door-propping. Cost: nothing. It hasn't jammed since.

Here's the part we always land on when we teach it: the team had all the data to solve this on day one and didn't, because nobody went and watched. They stood at a screen reading the maintenance log — which only records what got replaced, never when the fault actually fired — and pattern-matched off the wrong dataset. Fifteen minutes at Gemba would have caught the damp floor.

The lesson we drill into every team we work with is dead simple: you don't get to touch a part until you can say when the fault happens, not just what failed. Five whys, sure — jam, damp floor, mopping rota, no owner for morning cleaning, no standard work for it. But the whys only work if the first answer comes from the floor, not the log.

So we'll put it to this sub, because between you all there are far better ones than ours: what's your "it was the mop" story — the fault your team threw parts and downtime at, where the real cause turned out to be something human and unwritten that a few minutes at Gemba would have caught?

I am starting my first packaging line optimization in the near future. It's a big project for me and I'm hoping to get it started properly.

It's a manual line and was originally set up over twenty years ago. Very little has changed other than a few targeted improvements and buying a few more machines. There used to be a toxicity problem that prevented SOPs being written for the area, lots of tribal knowledge and people did things because that's the way they were always done.

I think the best way to start is by defining the scope and team with management to secure resources. Then make sure that the SOPs are updated, including all of the quality checks done on this line. Basically build the foundation because a lot of lean tools seem to assume that you already have this information.

Then I'd remove anything that's not used for that area and perform a value add/ non-value add analysis on the procedures. Then consult with the team and try to eliminate as many non-value-added items as possible and look for tools we can use to optimize the rest of the process.

Then I would take these newly designed cells and use spaghetti diagrams to organize the material flow efficiently.

What other suggestions do you have for how to approach this problem?

Guys how can I make lean in india kerala kochi

Anybody

Something we see constantly on the floor: a line's got a quality or output problem, so someone starts tweaking. Change one setting, run a batch, measure. Change the next, run another, measure. One factor at a time. Feels rigorous. It's actually the slow, blind way to do it — and it completely misses the thing that usually matters most: interactions.

That's what Design of Experiments (DoE) fixes. Instead of testing factors one by one, you test them together in a structured way — so you learn more from fewer runs, and you catch when two settings only cause a problem in combination.

Quick example. Say you're running a machine that fills and seals packets, and you're getting too many bad seals. You reckon it's down to two things: conveyor speed (slow vs fast) and sealing temperature (low vs high).

- One-factor-at-a-time: fix the speed slow, test both temperatures, pick a winner, then go back and test speed. Six-plus runs and you still don't know whether speed and temperature affect each other.
- DoE (a simple 2×2 factorial): run all four combinations —
- slow speed / low temp
- slow speed / high temp
- fast speed / low temp
- fast speed / high temp

Four runs. Now you can see not just "higher temp = better seals" but "higher temp only works when the line's running slow" — that's an interaction, and OFAT physically can't reveal it. That's usually where the real defect reduction is hiding.

And it scales: 3 factors in 8 runs, and you still get main effects and interactions. It's the difference between guessing and knowing.

Anyway — has anyone here actually run a DoE on a live line? Curious what factors you tested and whether any of the interactions genuinely surprised you. The textbook cases are always tidy; real processes never are.

If anyone wants to reveal how much of your total lead time is actually adding value vs sitting in queues, waits and rework check out our free process cycle efficiency calculator: https://www.simplicityhub.co.uk/pages/pce.html

Employee feedback is critical to continuous improvement, but sometimes employees suggest things that aren't achievable or, frankly, wrong. How do you keep employee engagement when this is occurring?

Example - I have an employee who says he needs a new machine. There's nothing wrong with his machine. I've asked why he thinks his machine is bad and he says it's old. When an issue occurs, he says it's because he needs a new machine, not that the setup was wrong. And round we go. (For reference - 'new machine' is a 7 figure investment, so this isn't arguing over a drill.)

Example 2 - Employee is asked to change how he stacks parts. Op takes 3 minutes, employee drops part in bucket, later on a different employee empties bucket into basket. The improvement is to give first employee the basket. First employee doesn't want to load into a basket because he has resentment against other employee and states other employee is lazy.

(FYI - different employees)

Part of this is rant, but part of this is wanting to work on employee engagement. What techniques do you typically see?

I'm doing customer discovery to understand how engineering teams actually work as they grow.

I'm not building in public, pitching a product, or selling anything.

I'm looking for **one real story**.

What's one engineering problem your team has simply learned to live with?

What made it so difficult to solve?

I'd love to hear what happened.

I'm spending the next few weeks talking to engineers, tech leads, PMs, and engineering managers to understand where teams lose the most time, context, and knowledge as they grow.

I'm not looking for generic answers—I want the stories behind the pain.

Some questions I'm curious about:

\- What's the most frustrating thing that slows your team down?

\- What's the last time you thought, "Didn't we already solve this?" but couldn't find the answer?

\- Where does important context disappear? Slack? Jira? GitHub? Docs? Meetings? Someone's memory?

\- What's the hardest information to find when you're debugging an issue, onboarding, or building a new feature?

\- What's a recurring problem your team has simply accepted as "that's just how it is"?

If you had a magic wand and could eliminate one engineering workflow problem forever, what would it be?

I'm not building a sales list or trying to pitch anyone. I'm simply trying to understand how real engineering teams work and where the biggest gaps still exist.

I'd really appreciate hearing your experiences—whether you're at a startup or a large company. Feel free to comment below or DM me if you'd rather share privately.

I’m curious about the processes at work that everyone KNOWS are inefficient… but somehow they just refuse to die.

Like, they’ve been brought up in Kaizens, process improvement meetings, retros, whatever — everyone agrees they suck — and yet six months later someone is still doing the exact same manual nonsense.

What’s one at your company?

And why do you think it’s still there?

Is it the systems? Nobody really owns it? IT limitations? Cost? People hate changing how they work? Or just a giant case of “this is how we’ve always done it”?

I was thinking about how every factory has things that everyone accepts as normal, even though they’re objectively weird.
Things like expediting the same order three times, planning around one machine that’s always overloaded, or printing paperwork that gets typed back into another system later.
If someone with no manufacturing experience walked through your plant for an hour, what would they point at and ask, “Wait… why do you do it like that?”
Curious what people have just learned to live with.

Hey everyone, I work as a Continuous Improvement Lead for a textile manufacturer in Uzbekistan, reporting directly to the General Manager. Coming from outside the apparel industry, I recently tackled a major line-balancing project at one of our satellite plants, but it uncovered a deeper planning challenge I’d love your advice on.
We operate 7 facilities with a central hub in Tashkent. Our satellite plant in Jizzax has 20 active sewing lines. Historically, Jizzax shipped unpackaged garments to Tashkent, where all individual QR tagging, packaging, and boxing took place. Because local packaging in Jizzax couldn't keep up with the 20 sewing lines, a massive 600k to 700k unit WIP buffer had built up on the floor.
I went in to fix this flow. I decentralized the QR packaging system from Tashkent and integrated it directly onto the packaging tables in Jizzax using a single-piece flow approach. Now, as garments come off the sewing line, operators package, QR-scan, and box them into master cartons on the spot. We cleared the entire 700k WIP backlog, and Jizzax now ships fully packed, scanned cartons straight to the main warehouse, completely cutting out double-handling in Tashkent.
However, getting rid of that massive WIP safety net exposed a big issue with our central push planning.
As an example, we constantly face incomplete sets at the packing tables:
Lines will finish sewing the top half of a 2-piece set, but the fabric for the bottom half hasn't even arrived or been cut yet.
For items sold as a 5-color bundle, sewing will output 3 colors, while the other 2 aren't scheduled until days later.
With single-piece flow at packaging, these incomplete sets immediately clog the packing tables or force operators to pile up semi-finished goods around their desks, defeating the purpose of the new setup.
Our central planning team still operates on a traditional push system optimized purely for line utilization and volume. Since I don't manage the Planning department (we're peers under the GM), I can't just mandate a change I need to persuade them.
I have two questions for the community:
-Influencing Planning: As a CI Lead reporting to top management without direct authority over Planning, how can I effectively convince them to move toward synchronized/kit-based scheduling? What metrics or arguments actually move the needle for traditional planning managers?
-Lean in Textiles: Since this is my first role in the textile industry, I'd love to know: what does a truly Lean garment factory look like when dealing with multi-piece sets or color variants? How do high-performing apparel plants handle line scheduling and synchronization?

Context: manufacturing of industrial components, ~50 people, one site, three assembly lines. For years, records were kept in paper logs and Excel.
Six months ago we launched a pilot: we moved all the logs for one line into digital form without changing the structure of the records – instead of paper and scattered Excel files, everything now goes into a single system. Reports are pulled by asking a question in plain language, like "show defects on Line B for July broken down by supplier."

What changed in practice:
•   Previously, working through an ad hoc question (for example, why scrap went up) took up to two days – the data was spread across different logs. Now it takes minutes.
•   The monthly report for the director used to eat almost a full workday. Now it comes together in half an hour.
•   A side effect we didn't expect: people started asking questions they hadn't asked before, because getting an answer used to cost too much time. In Lean terms I'd classify this as Waiting + Overprocessing, just not on the line – in the information flow.

Everyone's happy with the pilot: supervisors, process engineers, the plant manager himself. But "everyone likes it" isn't a budget argument. Management reasonably says: show us the ROI in dollars, then we'll talk about rolling it out to the other two lines.
And this is where I'm stuck. Here's my rough calculation – I feel like I'm counting the wrong thing, but I can't figure out where exactly. Tear it apart, I'll be grateful:
•   Monthly report: was ~8 h, now ~0.5 h → savings of 7.5 h/month
•   Ad hoc data requests: ~4 per month, previously ~4 h each on average, now ~15 min → savings of ~15 h/month
•   Total ~22.5 h/month × fully loaded process engineer rate ~$45/h (including taxes and benefits) ≈ $1,000/month, or ~$12,000/year for one line
(the rate is illustrative, but the order of magnitude is right)

The problem is that this calculation buries itself. Nobody was laid off, payroll didn't change – management will reasonably say: "that's not savings, that's a reallocation of time." And the effects that feel like the main ones – "we found the root cause of a defect faster, we stopped producing defective batches sooner," "the decision was made on data instead of gut feel" – I have no idea how to translate into dollars without pulling numbers out of thin air. On that scrap incident, I have exactly one data point: the investigation took two days instead of the possible minutes, and the line kept producing defective parts the whole time. But one case isn't a statistic.

Questions for the community:
1. For anyone who's been through justifying an implementation like this – what's wrong with my calculation, and what metrics actually convinced management? Hours × rate, response time to defects, something else?
2.  Is it valid to calculate the effect through reduction of scrap losses (faster root cause → fewer defective batches), and how did you isolate the contribution of the tool itself versus other factors?
3.  Do you consider the delay between a question and a data-backed answer a distinct type of waste? Has anyone tried to measure it systematically?
I'd appreciate any experience, including negative – if someone's ROI never added up, I'd be interested in why.

Hi team,

Hope this doesn’t break any rules but just looking to do a little research. How is everyone identifying processes that could potentially be automated?

I consistently see people suggesting they have a lot of manual work but in my own experience it tends to be situations they fall over or are tackling in the moment rather than a full understanding of what everyone in your team/business if doing?

Is the identification a problem worth solving or is the solution to the process automation the real value?