Improve the process before adding more to it

I wouldn't assume the problem is simply that production needs to move faster.

I would start by following the process from beginning to end. Where does work start accumulating? Which operation is everyone waiting on? Are materials available when they're needed? Is the schedule realistic? Are people waiting for approvals, equipment, or information?

A production delay is often the result of something happening earlier in the process. The first step is finding the actual constraint. Then we can determine what needs to change.

One of the easiest signs of a bottleneck is work consistently piling up in the same place.

But I don't only look at equipment. A bottleneck can also be caused by people, approvals, material availability, scheduling, information, or the way work is prioritized.

I like to map the process and use the available production data to understand where capacity and demand aren't matching. Once we find the constraint, we can focus improvement efforts there instead of trying to make every part of the operation faster.

Being busy and being productive aren't necessarily the same thing.

People can spend an entire day moving materials, looking for information, waiting, correcting mistakes, entering the same information twice, or working on something that isn't the current production priority.

I look at how employees actually spend their time and where unnecessary work has become part of the normal process. Sometimes improving productivity means removing work rather than asking people to work faster.

I wouldn't start by cutting resources.

In Lean, waste is anything consuming resources without creating the value the customer needs. That can include waiting, unnecessary movement, excess inventory, overproduction, defects, and unnecessary processing.

The objective is to understand where time, material, and resources are being consumed unnecessarily and improve those areas without compromising the product or the customer. Reducing waste should make the process better, not simply cheaper.

If the same defect keeps appearing, correcting the individual defective product isn't solving the whole problem.

I want to understand where the defect begins and what conditions allow it to happen. Is the process inconsistent? Is there a missing control? Are instructions unclear? Is something changing between shifts? Are materials contributing to the problem?

That's where root-cause analysis becomes important. The objective is to prevent the defect instead of becoming very efficient at correcting it.

First, I want to know what's creating it.

Rework can come from quality issues, unclear specifications, inconsistent processes, poor communication, material problems, or errors that aren't detected until much later.

I look at where the problem originates and where it's currently being detected. Sometimes a relatively small change earlier in the process can prevent a much larger problem later.

Because having a lot of inventory and having the right inventory at the right time are two different things.

A company can have money tied up in materials and still experience shortages that stop production. I would look at demand, purchasing, lead times, production schedules, usage patterns, safety stock, and how inventory decisions are being made.

The objective isn't automatically to have less inventory. It's to have inventory that actually supports the operation.

Not automatically.

More inventory can sometimes protect production, but it can also hide problems and tie up cash. Before increasing inventory, I would want to understand why the shortage is happening. Is demand changing? Are lead times unreliable? Is purchasing reacting too late? Is production using more than expected? Is the inventory information accurate?

Once we understand the cause, we can decide whether additional inventory is actually the right solution.

A production schedule has to reflect what the operation can actually do.

I look at demand, capacity, materials, dependencies, available resources, and constraints. If a schedule ignores those things, employees end up constantly changing priorities and management spends the day reacting.

A useful schedule should help the team understand what needs to happen next while giving management enough visibility to recognize when something is starting to go wrong.

It can be.

Sometimes experienced employees have found a better way to do something. Other times, the company simply never established a standard process.

I don't believe in standardizing something just for the sake of documentation. First, we should understand which method works best and why. Then we can establish a practical standard so quality and performance aren't dependent entirely on who happens to be doing the work that day.

That depends on what you're trying to improve.

I wouldn't recommend tracking a metric simply because every manufacturing company is supposed to have it. We might look at throughput, cycle time, downtime, defects, rework, schedule performance, inventory, productivity, or other measures — but the important question is what decision the metric helps management make.

If nobody uses a KPI to understand performance or take action, I would question why we're spending time tracking it.

Before adding labor, I would look at how the existing capacity is being used.

Are employees waiting? Is work unevenly distributed? Is one operation restricting everything downstream? Are people spending significant time on activities that aren't adding value?

There are situations where additional employees are absolutely necessary. But I would want the data to show us that capacity is actually the problem before increasing permanent costs.

First I would ask: is that machine actually the constraint?

Buying equipment that isn't addressing the real bottleneck may increase capacity in one area without increasing total production at all. Before making a major capital investment, I would want to understand utilization, capacity, cycle times, demand, and the rest of the production flow.

Sometimes additional equipment is the right answer. Sometimes the existing process needs to be improved first.

The people doing the work usually know things about the process that aren't visible from a report.

I want to understand what makes their job harder, where they lose time, what problems they see repeatedly, and what workarounds they've created.

That doesn't mean every suggestion automatically becomes the solution. But ignoring the people who actually perform the process means ignoring an important source of information.

Sometimes companies implement Lean tools without addressing the underlying problem.

Putting tape on a floor, creating another board, or asking employees to complete additional forms doesn't automatically improve a process. Lean should help us understand value, waste, flow, and the causes of poor performance — the tools are useful when they solve a real problem.

I focus more on why we're changing something than on whether we're following a particular Lean tool perfectly.

Yes, but I wouldn't automate an inefficient process without examining it first.

If a process contains unnecessary steps, automating those steps simply allows the company to perform unnecessary work faster.

I would first simplify the process. Then we can identify repetitive tasks, data analysis, reporting, information management, or other areas where automation or AI could provide measurable value. Technology should support the operation, not become another problem it has to manage.

I start by understanding what management believes the problem is, but I don't stop there. I want to see the process.

We look at how work actually moves through the operation, where time is being lost, where inventory accumulates, where defects or delays occur, what employees are experiencing, and what the data tells us.

From there, we identify the root causes, prioritize the opportunities, and determine which changes make practical and financial sense. The objective isn't to redesign everything — it's to fix what's preventing the operation from performing the way it should.