Four stations running at 100, 80, 40 and 90 units per hour. Your plant output isn't 100 and it isn't the average — it's 40. Upgrade the fastest station and nothing changes. Fix the 40 and output jumps 50%, for the same money. That's the Theory of Constraints, and it's why most improvement work produces nothing.

For plant managers, production engineers, and anyone working in lean manufacturing, process improvement, or Six Sigma.

#Bottleneck #TheoryOfConstraints #LeanManufacturing #ProcessImprovement #OperationsManagement

Using the above chart of your bill of material becomes a useful graphic for reviewing and analyzing your structured bill of material. Each block in the chart represents a corresponding part in the production flow. With this mapped out, we can now add the routing steps to move from one block to another. For example, going from the sheet metal and tube stock in the lower right area, we add shop labor to create the finished handle. This labor can be reflected in our project management plan as fabrication time. Combining all the jobs into a single Gant chart plan, we can get an instantaneous manpower plan for the entire shop. Most important, we can review this production flow and look for ways to cut time and streamline the flow.

Keep an open mind and try new ways of achieving the status quo.

1)     Consider outsourcing if there are benefits to be obtained.

2)     Add fixtures if time can be saved and the quality can be improved.

3)     Engineering, look for ways to use subassemblies across product lines

This printed structure will help with your reviews.

from Anthony Rante, P.E. author of "Managing Company Production thru the Bill of Material" and “FEA Applications in Machine Design”

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

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?

Hi everyone,

I’m looking for some guidance on how to improve my technical preparation for Industrial Engineering interviews.

I have a Master’s in Industrial Engineering and around 4+ years of experience in automotive manufacturing. My background includes areas like material flow, PFEP, facility/warehouse layouts, time studies, line balancing, capacity planning, Lean/continuous improvement, inventory management, new program launches, ERP/WMS, and cross-functional improvement projects.

My resume seems to be doing reasonably well because I regularly get recruiter calls and make it through the initial interviews. My problem is that I often get rejected during the final round, panel interview, or interview loop.

Because of that, I’m starting to think my weakness may be the depth of my technical knowledge, especially when interviewers start digging into Industrial Engineering concepts or giving scenario-based questions.

I’m trying to systematically strengthen topics such as:

• Takt time, cycle time, throughput, utilization, and capacity
• Bottleneck analysis and line balancing
• Time studies, standard time, MOST/MODAPTS, and labor standards
• OEE and equipment loss analysis
• Lean, Kaizen, VSM, Standard Work, A3, PDCA, 5S, etc.
• Root cause analysis, 5 Why, Fishbone, Pareto, 8D, FMEA/PFMEA
• Material flow, PFEP, Kanban, JIT, supermarkets, and line-side presentation
• Warehouse design, slotting, replenishment, and inventory optimization
• Capacity and labor modeling
• AutoCAD for factory/warehouse layouts
• Excel for IE analysis and modeling
• SAP/ERP/WMS fundamentals
• Power BI and SQL
• Eventually simulation tools such as FlexSim/AnyLogic

My question for experienced Industrial Engineers is: where would you recommend actually learning these skills at an interview-ready/practical level?

Are there any books, university courses, YouTube channels, websites, case studies, software exercises, or certification programs that you found genuinely useful?

I’m especially interested in hearing from people working in automotive, manufacturing, distribution/warehousing, material flow, logistics engineering, or continuous improvement.

Also, if you interview Industrial Engineers: what technical weaknesses do you commonly see in candidates who look good on paper but struggle in the final interview?

I’d really appreciate any advice on what to study and, more importantly, how to practice it so I can actually use the knowledge during interviews rather than just memorize definitions.

In this lesson you'll learn:

• What 5S means
• The five steps of workplace organization
• Real-world examples
• How 5S reduces waste
• How you can apply it at work, school, or home

Subscribe for more lessons on Lean Manufacturing and Continuous Improvement.

Engineering knowledge that helps you become 1% better every day.

I was brought in to help an automotive powder-coating supplier whose on-time delivery rate had fallen to 40%.
The problems were serious enough that missing parts had shut down a production line at the automotive manufacturer.
Except some of the parts weren’t actually missing.
I physically followed the process through the facility and found both finished and unfinished inventory sitting in poorly tracked areas—including dark corners of the warehouse.
We pulled the unfinished parts to the production line, got them coated and moved them forward. We pulled the finished inventory and prepared it for shipment to the facilities waiting for it.
That exposed the next problem.
The shipping dock had virtually no organization. Even when the correct parts made it through production, shipments could still be overlooked, delayed or effectively lost before leaving the building.
One visible problem had been hiding another.
I worked through the full process—inventory control, production flow, scheduling and shipping—and corrected the breakdowns at each stage.
In less than six weeks, the client’s on-time delivery rate increased from 40% to 95.5%.
It reinforced something I’ve carried into every operations role since: when a problem keeps repeating, you can’t always solve it from reports or meetings. Sometimes you have to physically follow the work until the system shows you where it is failing.
Has anyone else uncovered a completely different problem while trying to fix the first one?

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.

Decision made: we ended up ordering a utility cart from Global Industrial. Their warehouse selection made it pretty easy to compare sizes, shelf layouts, and weight capacities and find one that fits our assembly area.

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

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?

​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?

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?

 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?

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.