Thoughts and Insights from the Shop Floor
I still see companies struggle to apply a financial return on every improvement proposed.
PC has made an excellent analogy in a post on the forum. Rather than repeat it here, I’ll give you the link, maybe we can get a conversation started.
http://forums.theleanthinker.com/viewtopic.php?f=9&p=903#p903
(Sidebar: I am pretty aggressive about deleting accounts that look like spammers. If I got yours by mistake, write to me at “Contact Mark” on the right sidebar, and I’ll fix it.)
I have been noticing a significant linguistic difference between those who still embrace the “implement the tools” paradigm, and a much smaller (but growing) group are are adopting the PDCA thinking structure as a framework for everything else.
It comes down to how a problem is stated.
We were looking at an operation with a lot of variation from one team member to another, both in terms of performance, and actually, what precisely was being done.
When asked what the obstacle was, the immediate reply was “Lack of standard work.”
While this may have been true, it is not a statement of the problem. Rather, it is defining the problem as “lack of a specific solution.”
This may seem to be an semantic discussion, but consider what the responsible supervisor hears, and interprets, from these two statements:
“There isn’t any standard work.”
or
“There is a lot of variation from one operator to another.”
In the first case, we are telling the supervisor what she isn’t doing, hasn’t done, needs to do. It isn’t even teaching.
In the second case, we are pointing out something that we can both agree on. I haven’t even said it is a problem, and honestly, in some cases it might not be (yet). It is a simple observation.
If, then, we agree that this variation is leading to some undesirable effect, then we can talk about countermeasures. That might include trying to capture a baseline, teach it to a few of the team members, and see if that helps. We can name it later.
Which of those approaches is more likely to enlist the support of the supervisor, which is more likely to put her on the defensive?
Lean thinking is not a checklist of which tools are in place. It is a step-by-step convergence on smoother flow, dealing with observed obstacles and problems.
This isn’t to say that the coach doesn’t have intimate knowledge and experience with flow, with standard work, and everything else. But the approach must be respectful of the people who are struggling with the real world issues every day. Saying “You need to implement standard work” isn’t helpful no matter how much logical justification is wrapped around it.
Teaching someone to observe the impact of variation on the process might seem slower, but it will get them there much faster because it engages their curiosity.
I’m looking at a form labeled as an X-Bar / R-Bar SPC chart. It is filled out pretty consistently by the operators.
But the “control limits” are actually specification limits, and the “standard deviation” looks like it is calculated as 1/3 x the spec limits to force the lines to where they want them from the mean… er ah… nominal.
When I asked about it, at least one company leader was under no illusion that this was a statistical process control, it is simply a means to develop a run chart of actual parameters vs. a nominal value and the specification limits.
I’ve seen far worse, like the time an engineer didn’t understand the difference between “in control” and “in specification.”
But what do they say in their everyday conversations? Do they talk about this process being “within specification” or “in control?” I expect the later.
We had five sequential operations. Although the lowest repeatable times for each were well within the planned / target cycle time, there was a lot of variation.
Though Operation 3 was working pretty continuously, Operations 4 and 5 (downstream) were getting starved on occasion, and the empty “bubble” was working its way to the output. The exit cycles, therefore, were irregular enough that they weren’t making rate.
The team set their target to stabilize Operation 3, with the expectation that doing so would smooth out the overall exit cycles.
To that end, they went back and started to study Operation 3 in a little more detail to better understand the obstacles that were impacting the Team Member’s ability to complete the work smoothly.
Then a wrinkle – a different team member was now doing the work, and his cycles were faster.
This actually was an opportunity. Why is one Team Member faster than another?
Their hypothesis was that the faster Team Member had some knack or technique, that enabled him to perform more consistently. And indeed, he did have a few tricks.
So the first experiment was to capture this work cycle in a Job Breakdown, then see if using Job Instruction and teaching it to the first Team Member they could duplicate the results of the second.
Then another wrinkle. The first team member was back on the job. Armed with the knowledge gained by breaking down the steps, key points and reasons for Team Member #2, they took more baseline data from Team Member #1 to set up their experiment.
…only to discover that Team Member #1 was also doing things that #2 didn’t do.
One of those things was unbending a part that was sometimes being bent by an upstream operation.
It seems that #2 was just passing those along as he got them. With that background, the conversation went something like this:
“What obstacle are you addressing?”
“The manual rework in Operation 3 is adding variation and extending his cycles.”
“What experiment are you running next?”
“We think the jig being used in Operation 1 is a bit undersize, allowing the part to deform. We are going to adjust the jig to the proper size.”
“What do you expect from that?”
“We expect to eliminate bent and deflected parts, and see more consistency in Operation #3’s cycles.”
Then they tried it. Skipping ahead a bit:
“What actually happened?”
“The parts are now more consistent, and there Operation #3 has a lot less variation, and is running closer to the planned cycle time… except that now he is waiting on parts from the upstream operation.”
“Huh. What is happening there? What did you just learn?”
“Well, it looks like Operation #3’s variation was masking inconsistent delivery from Operation #2. That team member is operating in small batches, then turning and delivering 3-5 parts at a time. When there was a lot of variation in Op #3, those parts were kind of buffering everything. Now he is working more consistently and faster, and ends up waiting on parts.”
“Because of the layout, the Operation #2 Team Member has to turn to his left and pass the parts behind him. He said he batches so he doesn’t have to turn so often. So what we are thinking is we want to…”
“Hang on, I want to stick to the structure so you guys can practice hearing and responding to it… So – what is your next step?”
“We talked to the team members, and they all agree that if we straighten out that bend in the layout, this will be a lot easier on them, so we are going to do that during the lunch break.”
“And what do you expect from that?”
“Operation #3 will get his parts one-by-one, as they are ready, and won’t have to wait on them.
“Great, so when can we see what you have learned?”
“Give us about 30 minutes after lunch break is over.”
You can probably surmise that things smoothed out a bit.
Then they went back to capturing a hybrid of the best practices of both operators in a job breakdown. At this point, the Team Members were genuinely interested in how they were doing, and both were quite open to learning the “tricks” of the other, so “Get the worker interested in learning the job” had pretty much been done.
A lot was learned over a few hours.
The “real world” is often quite a bit messier than the real world. There was actually a lot more dialog than I reconstructed here to keep the “learners” on track and focused on their stated target vs. resorting to an action of “improvements.”
In addition, merely beginning to work on one obstacle revealed enough information that they were dealing with a different underlying problem.
At another point in the week, they also believed they saw a need for more consistent part presentation. I happened to agree with them, but…
when pressed for what result they expected, the initial response was “The parts will be consistently presented.”… but what does that have to do with your target?
That was tough because, at the time, they were looking at the cycles of the 2nd operator that were, actually, pretty consistent, and lost sight of the fact that they were working on reducing the overall variation of output from that position.
They had a very hard time articulating why consistent part presentation would address the issue, even though they knew it should.
I think this is the result of years of conditioning that the “tools” – such as consistent part presentation – are good for their own sake, without really examining the underlying problems and causes that are being addressed.
If we lean practitioners are scratching our heads wondering why people don’t see this stuff helps, it would be a lot easier to deal with if we could point to the issue being addressed at the moment.
More tomorrow.
The world continues to move toward meeting customer’s true demand of one of something, when they want it, where they want it.
3D printing is one area where we can see the beginnings of a disruptive technology curve.
Laser printing has been around even longer.
Books are an area where the traditional mass-printing model is under assault from a number of directions.
Now On Demand Books is offering their Espresso Book Machine, fully automated production technology for a copy of a traditional paperback book. Check out the video.
Yes, the costs are higher for now, but in a niche market (which is where disruptive technology matures), that is less of an issue.
The trend is inevitable – it isn’t how fast you can go, it is how slow can you go while preserving the economy of scale. That is the challenge.
While we lean practitioners seem to have earned a reputation of distain for high-speed automation, industries like mass production consumables, and the food and beverage industry, would not be viable without that approach.
These plants are capital intensive, and the main focus of the people is to keep the equipment running. I hinted at some of these things a couple of years ago from the Czech Republic.
Here are some more recent thoughts.
This is not a paradox at all. People are the ones who are getting cranky equipment to run, scurrying about clearing jams, clearing product that got mangled. Until you have a “lights out” plant, people are critical to keeping things running.
In a purely manual world, you can get away with burying issues under more people and more inventory.
With interconnected automated equipment, not so much. The hardware has to run. It all has to run or there is no output.
How the organization responds to a technical problem makes the difference between quickly clearing the issue, or struggling with it for a couple of hours while everything else backs up.
This is where standard processes are critical, not only to short-term success, but also to capture new information as it is learned. This is the “chatter as signal” issue I have written about a couple of times.
Quoting from the above link:
Most organizations accept that they cannot possibly think of everything, that some degree of chatter is going to occur, and that people on the spot are paid to deal with it. That is, after all, their job. And the ones that are good at dealing with it are usually the ones who are spotlighted as the star performers.
The underlying assumptions here are:
- Our processes and systems are complex.
- We can’t possibly think of and plan for anything that might go wrong.
- It is not realistic to expect perfection.
- “Chatter is noise” and an inevitable part of the way things are in our business.
Those underlying assumptions say “Our equipment is complicated and difficult to get adjusted. All we can do is try stuff until it runs.”
That assumption actually lets people off the hook of actually understanding the nuances of the equipment; as well as letting them off the hook of a disciplined approach to troubleshooting. The assumption essentially says “We can’t do anything about it.”
A dark side of this designed ignorance is that the only thing leaders are really able to do is hover about and apply psychological pressure to “do something” or, at best, contribute to the noise of “things to try.”
Neither of those is particularly helpful for an operator who is trying to get the machine running. Both of those actually have a built-in implication that the operator (1) Does not know how to do his job or (2) Is somehow withholding his expertise from the situation.
But we get a different result from the alternative assumptions:
On the other hand, the organizations that are pulling further and further ahead take a different view.
Their underlying assumptions start out the same, then take a significant turn.
- Our processes and systems are complex.
- We can’t possibly think of and plan for anything that might go wrong.
- But we believe perfection is possible.
- “Chatter is signal” and it tells us where we need to address something we missed.
What does this look like in practice?
A known starting condition for all settings, that is verified.
A fixed troubleshooting checklist for common problems (that starts with “Verify the correct initial settings).
What things should be verified, in what sequence? (Understand the dependencies).
If a check reveals an issue, what immediate corrective action should be taken?
I would also strongly recommend using the format of a Job Breakdown (from TWI Job Instruction) for all of this. It is much easier to teach, but more importantly, it really forces you to think things through.
Of course, the checklist is unlikely to cover everything, at least at first. But it does establish a common baseline, and documents the limit of your knowledge.
The end of the operator checklist then defines the escalation point – when the operator must involve the next level of help.
It takes robust problem solving skills (and willingness to take the time to use them) to develop these processes; but doing so can save a mountain of time that pays back many times over.
The alternative is taking the time to mess with things until it sort of works, and never really understanding what was done or what had an effect – every single time there is an issue.
Cry once, or cry every day.
The obvious answer is that, if done well, it will save time.
The more subtle effect is that it sharpens the organization’s knowledge base, as well as their ability to really understand the nuances of the equipment. But this must be done on purpose. It isn’t going to happen on its own.
By getting things up and running sooner; and reducing the time of stoppages; it increases equipment capacity.
But more importantly, all of this increases people capacity.
It gives people time to think about the next level of problems rather than being constantly focused on simply surviving the workday. Of course you need the right organizational and leadership structure to support that.
Reflecting today on the death of Neil Armstrong, I am recalling growing up in an era defined by “challenge.”
Armstrong walked on the moon a few weeks after my 13th birthday. My room was full of model rockets, and I knew everything published about the Saturn V by heart. It was an exciting time for me, and I felt a part of it. (So today’s news did tear something out of my insides, even though I knew it had to come someday soon.)
The challenge that this nation issued to itself in May 1961 was one of those rare events that galvanized an effort in ways that could never be predicted. No one knows for sure what challenge will trigger that kind of mobilization. There was certainly nothing imperative other than “Let’s prove we can do this, and do it in front of the whole world.”
“Challenge” is a core tenet of “The Toyota Way 2001” and, at least according to authors who are in a position to know, defines a huge piece of that company’s culture.
To be effective, though, a challenge cannot be a hollow directive. It has to be “I think you can do this, and I’m going to support you along the way.” Anything less is fear based motivation where the person or team is working to avoid a negative consequence (losing a bonus, a bad review, etc) rather than pursuing something exciting for its own sake. (That is why I am not a big fan of “setting the platform on fire.”)
In other words, if people recoil instead of stepping up, then either they aren’t ready, the challenge is too big, or the person issuing the challenge lacks credibility that the course will be held in the face of inevitable setbacks.
While Project Apollo was certainly much more than Neil Armstrong, he was the guy literally on the pointy end of the program, and so he represents all of people who stepped up to do something truly extraordinary.
“One small step…”
August 24, 2012 Wall Street Journal:
Since I was a lean director there, this bears reporting on.
The fact that there is a film business to sell is a testament to years of hard work by some talented lean implementers, including Tom, a regular reader here. The challenge, as the collapse kicked into exponential rates, was to hold the margins as long as possible to generate cash for the transition plan.
We all have opinions on how well that transition is being executed, whether it ever had a chance, or the motivations behind some of the strategies, but I really don’t want to get into that here.
What is germane, though, is that we are witnessing an entirely predictable process that was described many years ago in Clayton Christensen’s book The Innovator’s Dilemma.
Kodak was not slow to grasp digital photography… they invented it.
Nor were they slow to understand its implications.
As in Christensen’s model, the problem was that film was too profitable. The problem for Kodak, and other companies who have suffered a similar fate, was that the core business model simply could not easily adapt to a completely different profit engine.
Though Kodak has largely exited the consumer products industry (except for their consumer inkjet printers, which never disrupted the market like Kodak intended them to), they remain a market leader in commercial graphics and printing, thanks to a couple of key acquisitions back around 2004-05.
Because they have a dominant market share, however, the only avenue for growth is through growth of that market, as there isn’t much headroom for capturing market share. As even large-scale graphics transition to “soft” display, the open question is whether or not they are continuing to chase shrinking markets with the latest obsolete technology. (They sold off their OLED business a couple of years ago.)
Kodak was traditionally a chemical company specializing in light-sensitive coatings, and the technology to manufacture them into useful products. They saw themselves, though, as being in the imaging business. When imaging separated from their actual core competency, these troubles began.
What business are you in? How well you answer that question is more important than you think.
When we did the first “Toyota Kata” based kaizen event here a second shift lead came up and told me “I’ve been working here 34 years and this week I learned what my job is.”
In most companies leads are expediters charged with forcing product out of the process when the system breaks down.
As we have introduced better flow into this process, things generally work better for overall output, but obstacles still occur.
The leads now assume a critical role for daily kaizen. They are the nerve endings for the entire production process. They are the ones who see the issues when they are small.
We are working with them this week to develop their skills to see, and capture those issues – the rough spots where the production team members struggle a bit to get things working; or where the team needs to bypass the intended process flow to make things work.
By helping them see the difference between smooth flow and rough flow, we are increasing the sensitivity of those nerve endings, and starting to flush out more sources of unplanned variation in a process with a fair amount of part and cycle variation.
At the same time, we are working with the core shop floor leadership team running then through PDCA cycles to develop their skills for improving flow.
What is kinda cool is that it is working, and the linguistic patterns (which reflect thought patterns) are shifting.
(Apologies for this post being “Password Protected” – I posted it from my smart phone, and obviously need to mistake-proof something in the interface.) – MR
A key element of TWI Job Instruction is breaking down the job into important steps, key points, and reasons why.
An important step advances the work.
A key point is a critical aspect of the work that would:
If it is worth making a key point over, it is worth putting a visual cue in the workplace.
If the key point is about something that would injure the worker, or make or break the job, you have a rich opportunity for mistake proofing.
In other words, a key point is something you are asking the team member to remember.
Help him out by reminding him or even better, engineering the work so that he doesn’t have to remember.