A while back, I had a conversation with a colleague regarding a company’s “Standard Work” initiative. Unfortunately, the initiative was not resulting in the benefits the company was expecting.
The more questions I asked the more it became obvious that my colleague had applied a countermeasure in search of a problem, instead of the other way around.
Someone had decided that making standard work documents would somehow "magically" cure the ills listed prior.
Why is this so common? Especially when it comes to something so "ubiquitous" as Standard Work? Everyone knows about Standard Work right?
Well everyone thinks they know about it..,
One reason a Standard or Standardized Work initiative can fail, is that what is actually being done is not Standardized Work.
Most company’s (and consulting firm unfortunately) teach that Standardized Work is about creating and adhering to a standard work instruction. While this has benefits, it is not true Standardized Work.
Toyota refers to these types of documents simply as "Work Standards" (and they certainly do have these, a lot them actually), but "Standardized Work" has a very specific set of criteria that should be met before it’s applied and is not just about creating a standard...it’s about analyzing the work to prep for kaizen, or improvement in that work, and about making problems / waste visible.
The second most common reason is that companies assume that once they have the Standard Work documents made, they will magically induce better and more consistent training among their work teams.
This again is a fallacy, as Toyota does not rely on Standardized Work for training either, and neither should you.
(Though a team leader may reference it, that's not the real purpose)
Training in lean is a method, not a document.
At best these companies end up with a pretty wall of documents (assuming they’re even posted in the work area) that gather dust, never change, and well aren't really doing any good.
Another reason is that they assume the creation of Standard Work is some task that has a finite end i.e. that once we get around to making all these documents we’ll have Standard Work tackled and can proclaim all is good in the world.
Taiichi Ohno in fact believed that if the Standard Work was not constantly changing that there was simply no improvement work being done. If your company has Standard Work, take a look at the last revision date…how often is it changing? Is it laminated, pretty and a year old, or is it in pencil, erased and rewritten many times over changing all the time?
[supposedly he berated his supervisors if a month went by without change for the better in their teams Standard Work, I have no idea if this is really true, but it helps drive the point home, so let's just assume it is!]
The real story is that there are many, many documents and methods that all work together to create an environment for kaizen and Standardized Work.
Training is done with methods developed here in the US pre and during WWII, called:
Job Instruction Methodology
It was created by the Training Within Industry group sometime around 1939. If your grandma or great grandma worked in a factory during WWII supporting the war effort, there's a good chance she was trained to do her job with this exact method...
It's a 4 step method, but also includes some forms, namely training matrices, training plans, and job breakdown sheets. But it is the METHOD of training that's important. It's so successful that is still today in Toyota today exactly as it was taught to them by the US some 50+ years ago.
[I believe the only change Toyota has made is changing the verbiage of "worker" to "team member".]
It is not a document; it is a method that can be used regardless of the document or even in lieu of a document.
It takes practice and a willingness to only teach in small bites and an acceptance of responsibility that
“if the student hasn't learned, the teacher hasn't taught”.
If it’s a new process, or one that has never been broken down, the process generally starts by through the creation of a Job Breakdown Sheet. The small bite sized element of the jobs are broken down into a small number of steps.
[Less than 10 or so, or you’re probably teaching too much at one time, like drinking from a fire hose]
The key points and reasons behind them are captured for the trainer to reflect on. This process is for the trainer, not the student. This can be the basis for Standardized Work later but not always. The trainer then follows the Job Instruction Methods to teach each individual element of the job…being sure the student has learned before moving on.
The student might never even see the document...
For those operations where:
THEN, Standardized Work applies in its truest form, through a combination of the:
It has three elements:
If these conditions are not met then it is probably not true standardized work. If not, that's OK - the job element is probably best served by creating some form of work instruction or other standard…or you need to work on improving the process and layout so that pure standardized work can apply.
What's the point? Can't we just document what we do and teach people to the standard ? Sure, you can do that. But...
Standardized Work forms part of the base for Just-In-Time production by preventing over-production, by relying upon takt time and Standard WIP, and by preventing Muri, or the waste of overburden by distributing the work between the appropriate number of team members.
Most importantly, it becomes an important base line for comparison in continuous improvement efforts. Through these efforts, changes are suggested, tested, and result in new Standardized Work. Which means the training plan must be revisited, new Job Instruction sessions, etc and the process repeats.
The only thing "standard" about standard work is that it should always be changing.
Now I dare the readers who think they’re “doing Standard Work” to reflect on whether or not it is a part of the continuous improvement cycle, or if it’s just a pretty work instruction that no one has looked at since someone made it (probably in an office somewhere).