Apr 4 2013
The Purpose of Standard Work in Manufacturing
The articles by Art Smalley‘s and Mike Rother about Standards in The Lean Edge puzzle me, because it seems we all mean different things by “standard.” On a manufacturing shop floor, in particular, I don’t see Standard Work as a basis for comparison, the best way known to perform a task, or a target condition. Instead, it is a set of rules published for the purpose of ensuring that different people perform the same tasks in the same way. This is consistent with the Wikipedia definition of a technical standard.
A process can only produce a consistent output at a consistent pace on different shifts in the same plant, as well as in different plants, if it is performed on the same materials, with the same equipment, and by the same methods. That is what standard work is supposed to accomplish, and it is, for both human and technical reasons, more difficult than meets the eye.
So here are a few thoughts I would like to share on this subject:
Contents
Standard Work versus Craft Control
When operators on a manufacturing shop floor remain on the same job for years, they come up with their private tricks on how to perform it. They attach “cheater bars” to wrenches, rearrange parts around their stations, and develop the ability to detect anomalies by sight, sound, touch, or smell. By default, as operators perceive this knowledge to be the key to job security, they make sure it remains hidden away in their heads.
It leads to a situation that economist William Lazonick called Craft Control, in which management leaves the organization of work on the shop floor to the operators. The focus of Frederick Taylor’s “scientific management” was to replace craft control with managerial control, and it entailed the detailed specification of all operations by specialists. For decades after Taylor’s death in 1915, the management of American manufacturing companies engaged in a tug-of-war with labor to put an end to craft control, and ultimately failed, resulting in shelves of binders full of specs that nobody pays attention to, except external auditors.
Human resource policies that involved laying off whenever business slows down were an incentive to retain rather than share information. And leaving operators on the same job for years made the specs unnecessary except to train new operators but, when you tried to use them for this purpose, more often than not you found them to be obsolete.
TPS/Lean pursues managerial control too, but in ways that differ as follows:
- Operators are hired for a career in the company and retained through downturns.
- They are frequently rotated between jobs and become multi-skilled, which requires them to share what they know.
- They participate in continuous improvement, leading to the integration of their private tricks into the shared specs.
- Instead of Victorian novels in binders, the specs are concise memory joggers on A3 sheets of paper posted above work stations.
See last July’s post on What are standards for? for examples and details. These differences do not make it easy to implement, but they remove the key obstacles that account for the earlier failure.
Use of A3 instruction sheets
A3 instruction sheets above work stations help supervisors notice discrepancies between the standard and the practice of the operators. When there is such a discrepancy, however, the supervisors must investigate it rather than always “retrain” the operator to conform to the standard. The operator may in fact have improved the process; this improvement needs to be documented and the standard updated so as to propagate this improvement to all other operators doing the same process. When walking through a shop floor that has such posted instructions, one should check the signature block to see when it was last updated. If it was five years ago, the sheet is useless. In fact, It should have been updated in the last six months.
In The Birth of Lean (p. 9), are Taiichi Ohno’s own words on the subject:
“…the standard work display panels […] let the foremen and supervisors see easily if the operators were adhering to the standard work procedures. […] I told everyone that they weren’t earning their pay if they left the standard work unchanged for a whole month.”
Changing specs once a month for every operation seems a hectic pace, leaving operators barely enough time to master the new method before changing it. Perhaps it was justified in Toyota’s single machine shop, that Ohno was running in the early 1950s. Managing revisions in a network with dozens of factories worldwide that is Toyota today is a different kind of challenge.
Avoiding Lean Wallpaper
Posting too many instructions, maps, charts, forms, before-and-after pictures, etc., is counterproductive. The result is visual clutter rather than visual management. Producing, posting, and maintaining displays is work, and it should be done selectively, when it has a clear purpose and is worth the effort.
In daily life, we use complex products like computers, cars, or kitchen appliances without posted instruction sheets. We can, because these products have been engineered for usability and mistake-proofed. Usability engineering is the art of designing human-machine interfaces so that users find the right actions to take without prompting or instruction; it is widely applied to household appliances, based on techniques described in Don Norman’s The Design of Everyday Things. In Taming HAL, Asaf Degani expands on these techniques for application to airliner cockpits and ship control rooms, and Chapters 1 and 2 of Working with Machines summarizes them as they apply to production equipment. Usability engineering is about making mistakes unlikely, but not impossible; this is why, whenever possible, it is supplemented by mistake-proofing. The following pictures illustrate one of the usability engineering principles. In Pixar’s “Lifted,” the young alien taking a test cannot tell which switch to press; Don Norman shows an example of a control room in a nuclear power plant where technicians have replaced identical joysticks with different beer keg handles to make them easier to tell apart.
Toyota in recent years has been pursuing a reduction in the amount of information posted on the shop floor. They simplified the tasks to eliminate the need for posted instructions, which also made it easier to train new people. This has been going on in several plants worldwide for several years, resulting in continuing improvements in quality and productivity. Instruction materials are kept off line and brought out as needed, like a car’s owner manual.
April 5, 2013 @ 8:31 am
Consensus on this topic is definitely difficult:
Check out this forum thread on lean.org right after Rother first introduced this concept on his Toyota Kata page:
http://www.lean.org/FuseTalk/Forum/messageview.cfm?catid=49&threadid=5991&highlight_key=y&keyword1=Mike%20Rother
I think you can clear up the confusion by being very specific about separating the two terms, “standard work” and “standard”. Your definition for a technical standard falls under the term standard work. Mike Rother is talking about “standards” which can be anything that defines normal vs abnormal (or maybe good vs bad). In this sense, all standard work is a standard but not all standards are standard work.
This was a response I had in that forum that I think explained it further:
This is how I would define the two schools of thought succinctly (not all that succintly in retrospect):
1) Set standards (improve) and then hold people accountable to following the standards. (standards hold PDCA up)
2) Set standards to distinguish normal from abnormal. Abnormal conditions are opertunities to develop new standards/improve. (standards are a part of PDCA)
First of all: Both of these schools of thought are “good”. In comparison to not having a standard at all, either of these is a vast improvement. I note that the two philosophies do not necessarily conflict. So start with the basic assumption: Standards are Good. There everyone agrees.
The debate isn’t between having standards or not having standards. Removing the chock from behind the PDCA wheel doesn’t mean that no standards should exist. It’s the purpose of the standard that the picture seems to imply that is the problem.
It implies that the sole purpose of the standard is to keep things as good as they supposedly currently are. You improve incrementally and then you throw a standard under the wheel and keep from moving backward. It’s not a bad model to think this way. It’s better than not using standards at all but I don’t think it is the best model for continuous improvement.
The standard is the current best method for doing something. Emphasize current and when I say current I mean that as soon as i write it down it is already dated. It will only be the best practice given that Man, Material, and Machine remain absolutely constant.
This is where the two different approaches start differing.
In the first, there is an emphasis on compliance to the standard. If the purpose of the standard is to keep you from backsliding, then you treat any seperation from the standard as a violation of the process. You do everything you can to get back to the standard. With this mindset, the solutions to problems will often be disciplinary.
In the second, there is an emphasis on continuous improvement. Instead of striving to get back to the standard whenever there is non-compliance, you ask Why until you understand what has changed about the process. The standard is there to drive the next improvement. It’s purpose is not to hold people accountable but to force improvement.
So when Ohno says, “there can be no kaizen without standards” there can be two interpretations. The chock behind the PDCA wheel would imply that kaizen is useless without a standard. i.e. you can improve but it won’t represent continuous improvement unless you don’t backslide. The other interpretation is that kaizen simply doesn’t occur without a standard. If you don’t define the current best practice, you will not notice when waste is introduced to the process and you will not take the opertunity to improve.
My perspective is that you don’t need the chock. PDCA is a cycle for a reason. I use the word Standard and the term “Plan” almost completely interchangeably when I am talking about PDCA. The standard (be it standardized work, a metric, a kanban, etc.) is simply the physical representation of the Plan. You are continuously running to that plan (Do) and you should be continuously Check-ing to ensure the plan is a good one. When you Adjust the plan, you should also establish a new standard thus starting the next cycle.
When you put a chock behind the wheel, you imply that you can shut off PDCA and come back to it later. That is absolutely incorrect. PDCA is continuous and it is always on. If you walk away and ignore it, it isn’t PDCA and it isn’t kaizen.
April 5, 2013 @ 11:35 am
Kris – Yes, standard work is a special case within technical standards, and I hope I made it clear that this post is only about standard work. When I read the thread you linked to, I don’t see any consideration given to the daily operations issues I brought up in my post. Standard Work is not all about improvement; we also have to build products today and tomorrow, and they must be built the same way by different teams on different shifts and in different plants.
Besides standard work, we are awash in technical standards issued by ISO, NIST, JIS, DIN, AFNOR, BSI, IEEE, AIAG, and many other organizations, in addition to de facto standards set by popular products. These standards are also rules set by organizations for others to follow, The ability to get a standard adopted by an industry conveys great power over it. The players know it, leading sometimes to surprising behaviors and to the adoption of technically inferior standards. It is a fascinating topic for game theorists, but outside the scope of this blog.
Your comment refers extensively to PDCA, which I didn’t mention. I think we make too much of PDCA. I have found it useful when facilitating projects with people who are more comfortable with tools than with a white board and are so eager to start doing that it is hard for them to first spend some time together on planning and designing. Professionals tend to have the opposite tendency, but don’t react well to being lectured on something they feel is as simple-minded as PDCA.
When I look at the Japanese literature on manufacturing, I barely find any mention of PDCA. And that is true of the books that have been translated into English, like Fujimoto‘s, Monden‘s, Sekine‘s, or even Ohno‘s and Shingo‘s. So why do we make such a big deal of it?
April 8, 2013 @ 7:53 am
“Yes, standard work is a special case within technical standards, and I hope I made it clear that this post is only about standard work.”
Actually, what I meant to imply was that your definition of technical standard is narrow. What I am saying is that Standard Work might fall under the category of technical standard (that you provided) but Technical Standards fall under the category of General Standards (or just Standards). A lot of confusion stems from the fact that a lot of people are talking about “standards” and everybody else is thinking to themselves “standard work” (or in your case, technical standard). A footprint on the floor for where material goes is a standard in that it defines the normal best place to put the material. When you say, “I hope I made it clear that this post is only about standard work”, that is actually my point. Your post was about standard work while Smalley and Rother’s posts were about standards in general. I think that is why you are puzzled (as well as so many others).
“Standard Work is not all about improvement; we also have to build products today and tomorrow, and they must be built the same way by different teams on different shifts and in different plants.”
So this is the meat of it. I am the manager on the floor who has to actually get people to do things the same way across multiple shifts and in different plants (literally, it’s what I do). Does the act of writing a standard work document somehow get people to follow it? Of course not. So how does “standard work” actually help me to standardize?
1) It is a training tool that I can use to help train people
2) It is an accountability tool that I can hold people accountable to following
3) It is a reference document to help me (i.e. leadership) recognize normal vs. abnormal and then presumably, do something about it
My experience is that these three purposes are actually counterproductive to each other.
1) The most effective training tool is the simplest of documents with very clear memory and site words in the style of Job Instruction from TWI. They combine the visual showing of a task by a trainer actually doing the task with actually telling the trainee how to do it.
2) A document that can actually be used to hold someone accountable has to be much more in depth and if you plan on actually disciplining someone with the standard it has legal ramifications (especially in a union shop). In order to make something legally binding, you actually have to make it either more complex or less precise because the document has to cover all possible scenarios that might come up. For instance, an associate may handle a part a couple different ways depending on the way it was handed to them. In order to hold them accountable, you can either make the document much more complex by writing every possible scenario or make the document much less precise by simply saying that the operator should “grab” the part. This sounds inane but it happens to varying degrees continuously as you write and rewrite documents of this type. The “improvement” of the document almost always occurs when an associate “gets away with” doing something and can’t be held accountable to a mistake made. Then the document becomes more complex (and less useful for training).
3) The simplicity of a document created for a training tool and the complexity of an accountability tool make them cumbersome for a leader to use as a reference. In this instance, you go ahead and create the standard very precisely to identify the most common (or best) way that an associate will handle the part. Whenever that associate cannot handle the part in that way, it is an abnormal condition.
This is why Rother draws the corollary of a standard and a target condition. If you create a standard that will/can be followed 100% of the time, then it is either an imprecise standard or an overly complex and useless standard. Instead create standards that are very precise but can only be followed ~95% (maybe the number is 80% maybe it’s 99.99%) of the time. The target is to be able to follow the standard 100% of the time but variation in the process does not allow it. That variation is opportunity for improvement.
The requirement for a document that holds people accountable actually becomes unnecessary because you are actually focused on controlling process variation instead of controlling people. If you focus on understanding what keeps people from being able to perform their job the exact same way every time, they don’t really have to opportunity to wander (to a degree). I actually think that there is some need for 3 different types of standards. Training standards, technical standards, and improvement standards. The technical standards are like your specification limits on an SPC chart while your improvement standards are like your calculated control limits. Don’t tighten the spec limits any more than you absolutely have to so create these standards in a vague way. You don’t create control limits that will never be violated however. Much like the rules of SPC, if you react to your control limits, the specification limits are simply a reference that you shouldn’t be worrying about too much (this is where reality and theory meet of course).
April 8, 2013 @ 12:36 pm
It’s really not my definition of a technical standard but Wikipedia’s, but who is to say that Wikipedia is the standard? “Standard” is otherwise used to mean so many different things that you have to set the context precisely before using it if you want to be understood.
What I hear you saying is that a document, by itself, does nothing. It is all about the way you use it. If you want to point out every possible deviation from the process for every product variation, you will need a Victorian novel at each station. I see posting A3 sheets as a way to focus on key points. The sort of discrepancies I have seen detected with their help includes the following:
Training an experienced operator on a new task is not the same as training a new hire. The recipe for the same dish may run 3 pages in a cookbook for beginners and 3 lines in a cookbook for chefs, at the same level of precision. I see Standard Work sheets as the latter, meant for trained operators, for whom, for example, “protective gear” does not need to be broken down further.
When you say “A footprint on the floor for where material goes is a standard in that it defines the normal best place to put the material,” the implication is that it is only a guideline, and putting the material elsewhere is tolerable. If you interpret markings as optional, how can you expect anyone to take them seriously?
Visiting Alcatraz a few years ago, I noticed a shadow board for knives in the kitchen, a picture of which Kevin Meyer later posted on LeanCEO. I don’t think of this board as just the “normal best place” to store the knives.
April 9, 2013 @ 8:01 am
It’s not just how you use the standard. How you intend to use it ends up driving the content and format of the standard immensely. The opposite can be true as well. Creating the standard in a certain way will drive the way it is used. You’re right though, you don’t want to improve everything. I could for instance even more precisely define where the Alcatraz knives go and make sure they always hang at a 32.4deg angle but what would be the point? Your good enough so you don’t need any more kaizen in that direction.
But think about the day that shadow board was created. Do you think they expected 100% compliance? They may have but I guarantee they didn’t get it from day one. It took follow up and continuous coaching (in this case the word coaching was probably in the form of beatings but…) to get to the point where the knives were always there. That’s why a standard is a target condition.
By creating the standard for where the knives go, you are kicking off the process of kaizen. Now every time a knife is not in its proper location at the proper time, you have the opportunity to ask the prisoner why he didn’t get it back to where it belongs. Did he get distracted while doing clean up? Is there enough time to get clean up done properly. Is the work balanced so that he always ends up back at the knife table when the process is complete? Is the shadow board in the proper location? The point is that creating a standard is the start of kaizen, not the end of kaizen. Every standard created is a target condition the day it was created. Creating the standard does nothing. It is the output of a process that you decided you need. No improvement occurs until you start actually improving/changing the actual process. The act of creating a standard if applied properly, will obviously lead to the creation of other standards. And thus PDCA is a cycle where Plan=Standard.
The Toyota Way 2001: the Necronomicon of Lean | Michel Baudin's Blog
June 13, 2013 @ 6:49 am
[…] Art Smalley, the standard is a basis for comparison; to Mike Rother, a target condition. I consider Standardized Work to be just a set of rules published for the purpose of ensuring that different people perform the […]
What Poka-Yokes Are And Are Not, And How To Sustain Them | Michel Baudin's Blog
November 30, 2015 @ 6:59 am
[…] hard to follow. This is discussed in my recent conversation with Philip Marris and in Section 3 of The Purpose of Standard Work in Manufacturing. The art of making human interfaces to machines and systems simple and intuitive is called […]