Standards Part 4: How to Write a Standard (Continued)

Standards are one of the cornerstones of modern manufacturing. However, they are not easy to write, and a bad standard can make things even worse than before. In my previous post I started to introduce how to write a standard. This post continues the topic of writing a standard with a few more tips.

A Standard Should Not Have Options

This is related to the point from the previous post of making a standard easy to understand. If your standard has options like “If situation A then do x, if situation B then do Y,” then it makes the standard more complicated. You cannot always avoid such if-then clauses or similar branching in the flow of work, but the fewer you have the better. Especially for standard work (i.e., assembly or manufacturing) any branches will be mura (unevenness) and will cause the cycle time to fluctuate. Unfortunately, you can’t always avoid such branching options, especially if it is not assembly or manufacturing work, but do try to keep them in check. The fewer options the better.

Involve the Employees

I mentioned this in my last post when setting up an improvement team (and I will mention it again further down during testing if the standard actually works). When creating the standard, actively involve the employees. Depending on how you do the actual writing (Excel, specialized software, pen and paper, etc.), it may be easier for one person to do the typing, but the workers on the team should be continuously updated. This helps to improve the standard, because the workers will usually quickly catch anything that could cause problems or won’t work.

The standard should be written by a person as close to the process as possible but that can still create structured written documents. But it must also involve the people even closer to the process, even if they can’t write.

Don’t Forget the Organizational Header

The key part of a standard, especially a work standard, is the actual instructions on how to do the work. But there is also some organizational framework around it. The standard should have somewhere (usually in a header) some of the following elements:

• Title: What is the standard called.
• Area of the Standard: Which department does the standard belong to, and which part or machine is the standard used for.
• Version Number and Date: Standards are (ideally) often updated as part of the continuous improvement process. You need to keep track of which version of the standard it is. If you visit an unfamiliar shop floor, the date on a standard also gives you an indication on how active the improvement process is on this particular shop floor.
• Index Number: Especially if you manage your standards with a central database, the standard should have an unique number (including the version) that the database can reference to.
• Responsible: The person or persons responsible for the standard should be named. This could even have multiple names for “prepared,” “confirmed,” and “approved” or similar including dates of the preparation/confirmation/approval.

In general, try to use similar headers for your standards. If you have too many different formats, it can be come confusing for the users.

Test and Improve the Standard before Implementation

You have written your standard… or the first draft thereof. Next is the check if the standard actually works. This is very important. This is the “Check” part of the PDCA. Give the standard to the people that actually use them later on, and have them try it out. It is especially helpful if it is an experienced person who knows the process well, and double especially helpful if that person was involved in the creation of the standard.

Ideally you should try out the standard a few times. How often depends on the situation, in particular on the duration of the standard. If it is an assembly line with a part being completed every 60 seconds, then you could easily try 15, 30, or even more times. If it is a standard for a changeover workshop that happens only 10 times per year, you may get away with only one try. The more often you try during this testing of the standard, the fewer hiccups your standard will have and the easier it will be to use the standard.

When trying out the standard, take notes on what works and what either does not work at all or feels wrong. These are the items that would need to be looked at and hopefully improved before the standard is released. In a few lucky cases, you may not find anything at all. However, chances are that you will find some issues that either must or should to be fixed before the standard is widely adopted. Effectively, you may have multiple PDCA loops before the standard is working as flawless as you can manage. It is the responsibility of the person issuing the standard to provide the users with a good working standard. Any sloppiness during the creation of the standard will cause much bigger problems later on during the use of the standard.

Teach the Standard to Your People

Once you are certain that the standard is good, the standard can be rolled out for general use. The main part here is to teach the workers in the use of the standard. This follows the common approach for training. It also depends how well the operators know the work already. If the workers know the work well and the new standard is only a few minor modifications, explain the new standard to them and also why there are changes, before having them try it out a few times.

If the worker is new to the standard and has to be trained completely in the use of the standard, then I find the Training within Industry Job Instructions very helpful. The card below is the summary of the four steps on how to instruct people in their job.

Like any training, it may involve some documentation of who is trained and in what, or an update to the skills matrix. In any case, do not forget to verify at a later time that the workers actually follow the standard. In my next post I will look in more detail at how to use and improve a standard. There are also different ways how to do that. Now, go out, improve your standards, and organize your industry!

Series Overview

• Standards Part 1: What Are Standards?
• Standards Part 2: Why and Where to Do Standards
• Standards Part 3: How to Write a Standard
• Standards Part 4: How to Write a Standard (Continued)
• Standards Part 5: How to Use and Improve a Standard
• Standards Part 6: Standardized Work
• Standards Part 7: How to Write a Work Standard
• Standards Part 8: Example for a Work Standard
• Standards Part 9: Leader Standard Work

Source:

Many thanks to Osamu Higo for writing the excellent article Crucial Misconceptions on Lean – Standardization, which inspired this series of blog posts.