No Improvement Without Standards

We had a packaging line that would not settle on start up.

It could start up. That was not the problem. The problem was what happened after it started. Stop after stop. Adjustment after adjustment. The team chasing the line rather than running it. Ninety minutes before we had five continuous minutes at full speed.

Then another stop.

Then more adjustments.

On a line running batches of two hours, that is not a ramp up problem. That is a line that barely runs.

This was a pharmaceutical site. The only line in the network that could blister and package this product. A critical, life saving drug. No alternative source. No huge stock buffer. Most batches were scheduled for about two hours. By the time the line was running, the batch should have been done.

Every lost minute mattered in a way that some production losses do not.

We had started an Autonomous Maintenance programme and found a significant run rate problem, the line had been running below its validated speed for long enough that the lower speed had not only become normal, but had been built into the metrics. When we returned it to standard, we uncovered the minor stops that had been hidden underneath.

Ninety minutes to get the line running smoothly. Every batch. Every shift.

So we went to look.

The jam location was obvious. The flap fold just before the outfeed, awkward to un jam. Isolate the machine. Open the guarding. Remove the jam by hand. Close the guarding. Restart at the workstation. Every single time.

We looked at every centreline standard at that point on the machine. All within specification.

So we looked at the packaging material.

This is where we spent most of the next three months.

The material had been changed a few months earlier as a cost saving exercise. The operators and supervisor were convinced this was the cause. And they were not entirely wrong, the cheaper material did tear more easily. That was real. That was observable. It felt like the answer.

But when we tracked the data, there was no meaningful correlation between batch to batch material variation and the minor stop rate. More importantly, the stops were not significantly worse with the new material than they had been with the old. The cheaper material tore more easily, that was real and observable, but it was not explaining the problem we were seeing. The problem existed before the material changed. We had just not been looking at it this closely.

It took some convincing. Not because the team were resistant, they were part of the investigation, not being reported out to. They had looked at the data themselves. But when you can see with your own eyes that cheaper material tears more easily, and you have a jam that involves tearing, the conclusion feels obvious. Letting go of an obvious conclusion that is not quite right is one of the hardest things in problem solving.

Eventually we did a full return to standard on the entire machine.

That is when we found it.

A guide rail on the infeed. Not on any drawing. Not in any standard. Not in any centreline document.

Nobody on the current team had installed it. Nobody could say with certainty when it had appeared. Engineering, eventually, confirmed it had been added years earlier to fix a problem, the flap that jams at the outfeed was not opening fully enough at the start of the process, apparently, so the rail had been added to correct it.

It had always been a problem. At lower speeds it was mostly hidden. At standard speed it was tearing the carton slightly at the infeed, not enough to cause a jam there, not enough to be obvious, just enough to weaken the fold. When that slightly torn, slightly weakened carton reached the flap fold at the outfeed seconds later, it was catching. Turning. Jamming.

The fix for the infeed problem was causing the outfeed problem.

The team's instinct, when we found the rail, was to set a centreline for it. Document the position. Add it to the standard. Make it official.

I understood the instinct. It is the right instinct in most situations, if something exists and the machine is running, you document it and control it. That is what centrelines are for.

But this was different. The rail should not exist. It had been added to compensate for a problem that may or may not still be present, by someone who is no longer there, at a speed the line was no longer running at. The right question was not what setting should this rail be at. It was whether the rail should be there at all.

I framed it as a trial. Remove the rail, run the line, see what happens at the infeed. If the original problem returns, we can discuss the centreline. But this test was quicker and easier than the alternative, and we had not yet confirmed the original problem still existed.

We removed it.

No infeed jams.

We put it back.

Outfeed jams returned.

We removed it again.

The issue was dramatically worse with the rail in place and almost non-existent without it.

Some people still wanted to add the centreline. The infeed had not jammed, but it might. The rail had been there for years. Removing it felt like a risk.

The team went along with it, if not very happily.

Until it worked.

The operators on that line became the biggest asset to the AM pilot after that.

Not because of a training programme or an engagement initiative. Because we had spent three months investigating a problem that was making their shift harder every single day, and we had fixed it. Really fixed it. Not managed it, not added a standard to control the symptom, not documented the workaround and called it a centreline.

Fixed it.

When the people closest to the work see that the system is capable of actually solving their problems, not just recording them, not just managing them, but eliminating them, something changes. They start to believe that raising a problem is worth the effort. They start to look more carefully. They start to bring better observations, more specific descriptions, more willingness to stay in the investigation when the obvious answer turns out not to be the right one.

That is what it looks like when everyone believes the system will actually do something with what they bring to it. Real engagement. Not a survey score. Not a suggestion box. A team that has seen the system work and has decided to be part of it.

After that investigation, returning to standard became one of my first checks in any problem solving process.

Not because the answer is always hiding in an undocumented modification. But because the question, does what exists match what should exist, and does what should exist still make sense, cuts through a lot of the noise that problem solving accumulates.

We spent three months investigating packaging material before we found a guide rail that was not on a drawing.

The material was part of the story. The cheaper material did make the carton more vulnerable. But it was not the only, or main, cause of the variation. The cause was upstream, invisible in the standard documentation, installed by someone trying to solve a different problem years ago, and running quietly at the wrong speed ever since.

The problem was not where we were finding it.

It was where it was originating.

Here is what three months on that line taught me about fixing real problems.

The obvious cause is can be a factor, but is not always the main culprit. Cheaper material can tear more easily. That is true. It is just not the explanation for the pattern you are seeing.

The fix that is already in place is the last thing anyone looks at. A guide rail that has been there for years becomes part of the machine. It stops being a modification and starts being furniture. Nobody questions furniture.

Returning to standard is not a diagnostic tool that most teams use. It should be one of the first. Before you investigate variation, confirm that what exists matches what should exist. You may find that the gap between the two is the entire investigation.

And the team that solves the real problem becomes a different team. Not because of what they learned about guide rails or carton tolerances. Because of what they learned about what is possible when the investigation goes far enough.

What problem in your organisation has been managed for so long that the management has become part of the standard?