r/LeanManufacturing

Ciao a tutti, sono un neo laureato in Scienze e Tecnologie Alimentari che lavora da quasi 10 mesi in una grande azienda alimentare italiana e lavoro in produzione come tecnologo di produzione. Vorrei approfondire la tematica Lean Management perché un giorno vorrei avere competenze in ottimizzazione dei processi per aggiungere skills al mio curriculum. Tuttavia, non so da dove iniziare e cosa fare per avere queste competenze, mi potete aiutare?.

P.S. Attualmente non potrei applicare Lean Management in azienda perché c'è una figura che già fa questo, io gestisco il processo produttivo. Quindi a tal proposito chiedo anche, è il caso di iniziare a studiare questo mondo anche se l'applicazione non sarà ancora utile alla causa?.

I work at a local pet food factory and we tried rolling out predictive maintenance on the extrusion line last year, only to spend the first month just realizing how patchy our sensor history actually was. Tags had been renamed twice over the years, a motor got swapped without anyone updating the documentation and nobody could agree on what a normal cycle even looked like anymore. Some teams start with vibration, temperature and current data on a few critical assets and build from there while others spend months cleaning data before touching anything predictive. Im trying to find the middle ground where the setup is useful without turning into its own data cleanup project. How much data quality did you need before predictive maintenance started helping on your line?

Most morning dispatch bottlenecks aren't actually caused by a shortage of drivers or vehicles. They’re usually caused by invisible route overloads.

When orders are assigned strictly based on customer deadlines without a quick check on vehicle and driver capacity limits, heavy routes get stacked way beyond capacity while reserve fleet vans sit half-empty. Then morning shift hits: drivers are stuck at the dock, cargo gets reshuffled on the fly, and deliveries go out late.

A recently published case study breaks down how a regional courier fleet can systematically fix this using a simple workload capacity planner framework. The core approach relies on calculating backlog hours relative to vehicle limits to spot route overloads a few days early—allowing dispatchers to level-load cargo before loading ever starts.

Core takeaways from the walkthrough:
- Eliminates last-minute loading dock reshuffling
- Drastically shortens daily dispatch planning huddles
- Gives full fleet visibility using standard spreadsheet logic instead of expensive enterprise software.

How do your operations currently track route capacity limits during busy dispatch weeks?

A lot of the conversation around reshoring focuses on whether it's the right move.

I don't hear nearly as much about what happens once the decision has been made. In my opinion, that's when the real work starts.

New suppliers need onboarding, planning assumptions change, lead times shift, and costing models must be revisited. Processes that worked well in one supply chain suddenly don't fit another.

None of that means reshoring is the wrong decision. It just reminds us that changing a strategy is usually quicker than changing an operation.

For those who've reshored or nearshored, what surprised you most once implementation got underway? Was it supplier onboarding, planning, inventory, costing, something you never saw coming?

I had a company a few years ago, trying to sell digital Kanban / manufacturing execution systems. The reason I started it is to digitize and optimize manufacturers to prep them for my true passion, robotic automation.

What happened seems to be very typical in the industry: manufacturers don't have time to play around, which is why you need full-time sales effort to sell them, on-board and train them over multiple months, which then has to cost at least $3000/month to make any economical sense. I see this everywhere in the industry, and while I think these softwares are actually worth their money, they leave thousands of small manufacturers behind.

We eventually stopped the company as it is too hard to scale that way, but I have not forgotten about the product and just recreated it, which got easier thanks to AI.

My current thesis: many low-cost tools with very limited, easy-to-learn functionality that play well with others and hence capture the complexity and diversity of manufacturing. In turn, thousands of people can use them, making it valuable enough for the software make to maintain it and break the silly sales model.

I'd be glad for your thoughts here.

I'm in a position where I'm going to be teaching my team One Piece Flow, and I'd like some advice from people who have done this before.

My thought is that I don't just want to tell operators, "This is One Piece Flow, do it this way." I want them to see the waste for themselves.

For example, I want them to recognize things like:

Excessive movement

Waiting

Batching

Excess WIP

Transportation

Rework

Other forms of waste they encounter in their own process

The goal is for them to become uncomfortable with the waste they're participating in and start asking, "Why are we doing it this way?"

My management wants us to approach this as a change-management exercise rather than simply rewriting the WI and telling everyone to follow a One Piece Flow process. They want the team convinced that the future state is actually better.

The One Piece Flow process appears to be faster, so I'm planning to establish a baseline of the current state, then demonstrate the future state and compare the results. I understand that I'll need to go through the current state → identify waste → develop future state → test/measure → standardize process.

Where I'm unsure is how to teach this effectively.

I've taught individuals before and have shown people how I try to get as close to One Piece Flow as possible. Most of the people I've worked with understood the concept and ended up applying it themselves.

But this is different. Now I have an entire department, and I also have a manager I need to get buy-in from.

For those of you who have implemented/taught One Piece Flow:

Would you approach it this way?

Would you have the operators map/observe the current process, identify the 8 wastes themselves, then run a timed comparison between the current state and a One Piece Flow future state?

Or am I overcomplicating this and approaching the change incorrectly?

I'm especially interested in how you got operators to want to change the process rather than simply comply with a new WI.

For a small factory, the first automation project can set the tone for everything after it. Packaging, palletizing, inspection and repetitive material handling all look like obvious places to start, but the best choice probably depends on volume, changeovers, scrap and how much operator time the task eats. A simple project with a clear before and after seems safer than automating a messy process too early. Which process gave you the best first automation win?

We’re trying to organize a small assembly area where people keep walking back and forth for parts, so im looking for carts that can hold a decent amount without being bulky or annoying to move. What wheel size, shelf layout, and weight capacity work well for daily use, and is there anything you wish you checked before getting yours? thx

What is the biggest thing you've seen senior management misunderstand about Six Sigma? or Lean Six Sigma?

So I'm curious: How do you actually create awareness and promote Lean Six Sigma / continuous improvement in your organizations? What are good and bad ways of doing that?

I had a company a few years ago, trying to sell digital Kanban / manufacturing execution systems. The reason I started it is to digitize and optimize manufacturers to prep them for my true passion, robotic automation.

What happened seems to be very typical in the industry: manufacturers don't have time to play around, which is why you need full-time sales effort to sell them, on-board and train them over multiple months, which then has to cost at least $3000/month to make any economical sense. I see this everywhere in the industry, and while I think these softwares are actually worth their money, they leave thousands of small manufacturers behind.

We eventually stopped the company as it is too hard to scale that way, but I have not forgotten about the product and just recreated it, which got easier thanks to AI.

My current thesis: many low-cost tools with very limited, easy-to-learn functionality that play well with others and hence capture the complexity and diversity of manufacturing. In turn, thousands of people can use them, making it valuable enough for the software make to maintain it and break the silly sales model.

I'd be glad for your thoughts here.

**India’s manufacturing strategy may already be obsolete. Here’s why.**
For decades, developing countries escaped poverty through the same formula: move workers from farms into factories, export cheap manufactured goods, and climb the industrial ladder.
That strategy worked for Japan, South Korea, China, Vietnam, and Bangladesh.
But what if the ladder no longer exists?
As industrial robots become cheaper, more capable, and increasingly powered by AI, the advantage of low-cost labor is shrinking. In many industries, automation is becoming the cheaper option—not just in wealthy countries, but globally.
My latest essay argues that India’s biggest manufacturing challenge isn’t competing with China on wages. It’s competing with automated factories.
If that’s true, then policies built around labor-intensive assembly may have a much shorter shelf life than we think. The real competition could shift toward robotics, industrial software, component manufacturing, semiconductors, and R&D rather than simply creating more assembly lines.
I’d genuinely like to hear different perspectives on this.
**Do you think India can still follow the manufacturing path that transformed East Asia, or has AI fundamentally changed the economics of industrialization?**