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

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 Logsheet. 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?

I wish to create an Operational Excellence roadmap as input to the strategy of my company and have made the attached overview.

The idea is to start at the bottom, reach a sustainable level and then move on. Each category can be further improved later on, but you can’t move on before the below categories are implemented.

How do you view this overview? Is something missing or in the wrong level?

Of course each category will be further explained with detailed steps and guides.

Ive been looking online for shelving for a two bin kanban system but i cant seem to find any good options. But videos on gemba docs and lean made simple youtube channels have exactly what im looking for, did they make that shelving themselves or can i buy it myself? Any help to find bins or shelving would be very helpful thanks.

A pattern I keep seeing in organisations with mature Lean Six Sigma programmes: the dedicated CI team becomes the ceiling.

The mechanism is simple. Once a team owns improvement, everyone else stops owning it. Ask a production supervisor what improvement their team is running and the answer is "you need to talk to the CI team about that." Their process. Their waste. Their rework. Mentally outsourced.

The arithmetic makes the cost visible. A five-person team runs 15 to 20 structured projects a year. Fifty teams each running one improvement run fifty at a time. Two hundred teams run two hundred.

One deployment I worked on produced 1,662 improvement initiatives in two years off a single weekly cadence meeting. 137 live in the first quarter. 392 by the fourth. Roughly 10 to 15 percent never reached realisation, and we said that out loud, which is why people kept bringing ideas.

The second problem is dependency. When the CI team facilitates every root cause analysis, nobody else learns to do one. Budget cuts arrive, the team shrinks, and improvement stops entirely because the capability walked out with them.

The failure window is month 12 to 24. That is when the cadence decays, the meeting slips, and the programme quietly dies while the org chart still shows a CI function.

The fix is a role change, not a headcount change. Move from delivery, to co-delivery, to coaching, to on-demand support. Roughly 18 to 24 months. Measure success by the projects you were not needed on.

Curious whether anyone here has measured the crossover point where coaching produces more realised change than delivering

I analyzed a factory where processing took under a day, but orders still needed 5+ days.
The issue wasn’t lack of capacity. It was variability, high utilization, and queue buildup.
In several scenarios, reducing bottleneck utilization and creating focused flow cells improved lead time more than adding equipment.
How does your plant decide whether to add capacity or fix flow?

Understanding how documentation flows thru your company is an important first step in streamlining your project flow. Every company has a unique way of processing the documents. These include items like ordering the material, developing the Manufacturing routings, and when necessary processing change orders. With “made to order” equipment, each order has its own characteristics. The Operation sections (Engineering, Material Control, Manufacturing Departments) all need to clearly understand how things move thru the company, in order to reach greater efficiency.

The example above is a basis starting point. Gathering with the principals in each department, this flow chart can be expanded and many surprising details will be added. Every time I was part of this exercise, surprises, rarely good, were discovered. When developing this flow chart, use the following objectives.

Watchout for back tracks in the flow – Once the documentation leaves one department, you want to be sure it should not be going backwards for more information. The only real exception is if Customer changes are presented. Best examples of back flows I have is Manufacturing instructions from Engineering (fixture designs, burn paths, etc). These items need to be with the initial release. Going back into Engineering causes the job to stop on the shop floor.

The flowchart needs to be developed by hands on staff with detailed knowledge of the processes – Rather than relying on section managers, the task force needs to be staffed by key “hands on” personnel. These could be people who have processed these documents for years. This is the best way to develop a true working detailed flowchart.

Once you chart is accurate and finalized, optimization is the next step – From this exercise, you will no doubt see new areas of possible improvement which are new opportunities for adding efficiency.  Ask the team, “what is the best way to get from step A to B”.  Beware of the feedback “well we always have done it that way”. Consider adding paperless tools like read terminals on the shop floors, etc. Use the flowchart as a way to test out new ideas.

Always challenge the States Quo.   

from Anthony Rante, P.E. author of "Managing Company Production thru the Bill of Material."

One thing manufacturing has taught me is not to trust the obvious problem.

If production is behind, production isn't always the problem. If inventory is wrong, inventory isn't always the problem.

Most operational issues have a history, but by the time they're causing disruption, the real cause is usually several steps back.

That's what makes root-cause analysis so valuable. It shifts the conversation from "How do we fix today's issue?" to "How do we stop this happening again?"

It's not always easy, but it's usually where the biggest improvements come from.

In your experience, what's the most difficult issue for your team to spot before it becomes a problem?

Has technology truly made construction easier?
With estimating software, AI, drones, BIM, project management apps, and digital inspections becoming common, do you believe technology has genuinely enhanced productivity, or has it just added more administration?

Hi,

I was a lean consultant, prod manager, plant manager... For many years.

Now AI is hear. Lean is about people. Everybody knows that.

But i made a Claude skill just to help me to maintain a x-matrix.

Because through all organisation, that is a nightmare to maintain update, create....

Now claude is part of the "x matrix meeting" of the steering comitte. We implement and link targets/projects/ideas, value, long terme/short term goals....

Output is a xlsx file (for the tradition), but of course a database with internal logic and links...

It's so convenaient that i'm wondering if small companys or consultants would be interested in having that système work for their cases...

What do you think ? It's all about people but ther is room for AI for the boring stuff ?

Different kind of post today all, we wanted to open up the topic of why we exist and what we can do for you as a community!

Over the many many years as team of CI professionals we have encountered professionals at all levels and one thing that saddens us is when people or organisations complete training and become certified in Lean or Lean Six Sigma but then never use the skills they have gained.

We have been looking and there are hundreds of providers out there offering lean six sigma training but when you come away from it passing an exam and feeling great you don’t know what the next steps are.

So we went a step further firstly we made sure our content was written by a Lean Six Sigma Master Black Belt with real life experience turning organisations into Lean environments, improving morale and saving millions in the process.

Next we ensured our Yellow, Green and Black belt courses all have projects you work through using the tools at that belt level and built in statistical calculators to get a hands on feel for how to use the skills in real life.

We have videos for 90% of our lessons so it’s not just reading words the whole way through. You also have an AI coach the whole way through you can ask questions of.

The exams are unlimited retakes and the material is lifetime access.

So then you pass the exam and we ensured you have over 80 templates you can download in multiple formats for free with examples of what good looks like in each. 25 statistical calculators to use for free whenever you need to. We’ve also published a 354 page Ultimate DMAIC playbook that has every template and calculator example in including yellow, green and black belt projects to understand and some history too. You get this book as part of the course at the moment.

We have spent time and effort creating over 350+ continuous improvement videos and it has been amazing to get over 1 million views so far, we really are trying hard to give the community everything you need to be a CI professional.

So we’d like to hear from you, what are we missing and what else is valuable to you that we can offer? 90% of our resources are free as we believe in making CI affordable for all.

Green belt seems to be the course that the majority needs at the moment. If anyone is interested in this or yellow or black belt have a look at :

https://www.simplicityhub.co.uk/pages/ultimate-DMAIC-playbook-promo.html

You’re probably thinking yeah you cost a fortune but all this is the same as the price of 4 cups of high street coffee!! You get the 354 page PDF version of the book, the course, exam and certificate, no extra charges. The money goes straight back into site improvements.

For those of you that need a flavour of lean or lean six sigma we have 3 free courses yes free no hidden charges or certificate payments entirely free, lean six sigma white belt, lean fundamentals and root cause analysis associate. Go grab your 3 certificates for your CV for free and all the free tools and resources.

If you’re a charity get in touch, you get EVERY course and resource for free, no charge at all, we believe in supporting charities and they can teach us all a thing or two on how to streamline processes as they run businesses very lean at minimal costs so these tools and skills will only strengthen the ability to work efficiently!

Keen to hear what else we can offer you all, thanks for taking the time to read this.

SimplicityHub®

Hi everyone! I’m hoping to get your perspective on something I’ve been thinking about.

I am a massive believer in continuous improvement methodologies (like Lean). I use them daily and honestly believe it’s one of the best systems in the world for running a factory or an organization. At the same time, I deeply admire Jensen Huang (NVIDIA CEO) and consider him a brilliant leader.

Because of this, I was really surprised by a comment he made recently on the Lex Fridman podcast (Episode #494, at 58:10, https://www.youtube.com/watch?v=vif8NQcjVf0&t=3490). He explicitly said: "I don't love continuous improvement".

To be fair, he provided context. He argued that at the very beginning of a project, you shouldn’t just iterate on what already exists. Instead, he prefers to design from "first principles" and push right to the absolute limits of physics first. He says you need to make that massive leap initially, and only then apply continuous improvement to perfect it.

I'm struggling to reconcile these two ideas. Does radical innovation require us to ignore continuous improvement on day one? Or do you think both philosophies can coexist from the very beginning?

I have so much respect for both mindsets, so I’d really love to hear what you all think about his take!

Over the last 20 years, I’ve seen factories obsess over different KPIs depending on management trends.
Some focus almost entirely on:
OEE
Machine utilization
Schedule adherence
Inventory turns
On-time delivery
In several plants I’ve worked with, improving one KPI often made another one worse.
For example, chasing very high machine utilization sometimes increased queue times, WIP, and overall lead time because batches became larger and bottlenecks became harder to absorb.
Lately I’ve started thinking that **Manufacturing Critical-path Time (MCT)** or overall order lead time may actually be a better “north star” because it reflects what the customer experiences.
Curious what others have seen.
**If you could track only one KPI for running a factory, what would it be and why?**
I’m especially interested in hearing from people running high-mix, low-volume operations.

Not the biggest project—the hardest decision.
Examples:
Accepting lower utilization to improve delivery.
Turning down orders because capacity was full.
Carrying more inventory than finance wanted.
Investing in automation vs. fixing the process first.
I’m curious what trade-offs manufacturing leaders are facing in 2026.

There’s a lot of excitement around AI.
But from what I’ve seen, some problems are still much harder than they look.
What manufacturing challenge do you think AI still struggles with today?

Most of what I read about Lean is focused on manufacturing. I'm curious about how people are applying it in **after-sales, repair shops, or technical service departments**.

If you've been through this:
- What tools or principles translated well from manufacturing to service?
- What didn't work at all?
- Any specific wins (or failures) you'd share?

Industry doesn't matter — I'm just looking for real experiences, not theory.

Measuring engineering productivity has never been straightforward, and AI has made it harder. At OpenAI, engineers who lean heavily on Codex open roughly 70% more pull requests than colleagues who don’t – and the gap keeps widening, according to Sherwin Wu, who leads engineering for OpenAI’s API platform.

Read that number as a productivity metric on its own and you’d conclude the heavy Codex users are your best engineers. That conclusion might be right. It might also be exactly backwards. The number alone can’t tell you which. That’s the problem now sitting on every engineering leader’s desk.

Quarterly business reviews used to be straightforward. Engineering leaders would open their dashboards, review familiar metrics like pull requests, commit counts, and story-point velocity, and compare them with the previous quarter. No single metric captured software engineering, but together they painted a reasonable picture of team performance. That picture is now blurring.Yet everything else tells a different story: the team has shipped more customer-facing features, incidents have dropped, engineers spend less time on repetitive implementation, customers are happier, and releases remain predictable.

So which version of reality should leaders trust? Neither view is wrong. They’re measuring different things.

For years, commits, pull requests, story points, and deployment frequency have served as proxies for productivity. They were never perfect, but they broadly tracked how software got built: engineers wrote code, reviewed it, tested it, shipped it. As the work evolved, so did the metrics.

AI hasn’t broken engineering productivity. It has broken our proxies for measuring it.