InsightFab
Knowledge Base/Standard Operating Procedure (SOP) Writing: A Format Operators Can Truly Follow
Lean Production6 min read

Standard Operating Procedure (SOP) Writing: A Format Operators Can Truly Follow

Hey, did you know? Sometimes production line issues aren't high-tech failures but rather because of an SOP "written for auditors"! This article shares a classic case where a machine's yield plummeted, CPK dropped to 1.08, and DPMO soared. The root cause was a vaguely written "manual calibration" SOP, leading to different interpretations by different shifts. After reading this, you'll learn how to break free from an engineer's mindset and write SOPs that operators will actually read and follow, preventing the production line from halting due to such blunders.

That Day the CPK Report Came Out, the Entire Room Fell Silent for Three Seconds

I remember several years ago, the yield of a machine on our production line suddenly dropped to an inexplicably low level. The CPK value was only 1.08, and DPMO surged to 6210. At that time, everyone was trying to figure out what went wrong. Later, we discovered the problem stemmed from a very simple "manual calibration" step. The machine's SOP mentioned it, but the text description was extremely vague, stating, "Please fine-tune to the optimal state based on experience." As a result, three shifts of machine operators had three different "experiences," and naturally, there were three types of output.

Frankly, many SOPs are not written for operators at all, but for auditors. A thick binder filled with dense text – do you think operators will read it? To be honest, even I'm too lazy to read it. Yet, SOPs are our most fundamental line of defense in production. How you write them dictates how operators perform. Therefore, writing SOPs that operators will truly follow is paramount.

Where Did the Problem Lie?

To put it bluntly, most SOPs share a common flaw: they are written by engineers for operators. Engineers are accustomed to precise textual definitions and rigorous logic. However, operators, especially novices, need intuitive guidance on "how to do it," not theoretical explanations of "why to do it."

We often perceive "standard" as "profound," but in reality, "standard" simply means "everyone does it the same way." When an SOP reads like a university textbook, operators naturally operate "based on experience." And since everyone's experience differs, the result is yield fluctuating like a roller coaster.

So the key is, an SOP is not written for yourself, nor for auditors; it is written for someone who "has never touched this machine before."

How to Do It in Practice?

To write a good SOP, it's essentially about empathy. Imagine if you were a newcomer who just reported for duty, knowing nothing about the machine; what kind of SOP would you want to see?

  1. Rich in visuals, fewer words are better: If something can be explained with pictures or photos, don't use text. A good SOP should have eighty percent of its content as images. For example, instead of "Please turn the button to position A," it's better to directly include a photo labeling "Position A."
  2. Clear steps, no vague terms: Absolutely avoid ambiguous terms like "appropriate amount," "fine-tune," "experience," or "approximately." For instance, "Please adjust the pressure to an appropriate value" should be changed to "Please adjust the pressure to 2.5 ± 0.1 MPa." With concrete numbers, operators know exactly what to do.
  3. Include error examples or checkpoints: Besides teaching the correct method, also warn about potential errors. For example, after setting a certain parameter, a checkpoint can be added: "Please confirm the screen displays a value of 100±5; if not, repeat steps 3-5." This can intercept errors early.

In other words, an SOP should be like an IKEA assembly manual: no superfluous text, clear steps, and visual evidence.

Common Pitfalls

When we used to write SOPs, the most common pitfall we fell into was "laziness." We thought, since there's an old version, just copy, paste, and make a few changes. What was the result? Even though the machine model had been updated, the images in the SOP were still of the old machine. Operators, seeing this, couldn't match them up and had to figure things out for themselves.

Another pitfall is "getting it right the first time." The idea was to include every possible scenario, which resulted in the SOP becoming a thick dictionary. Operators were too lazy to flip through it and would just ask veteran employees when they encountered a problem. If the veteran was in a good mood, they'd teach; if not, they'd tell you to read the SOP. This vicious cycle ultimately harmed the yield.

Frankly, an SOP cannot be perfect on the first try; it requires continuous updates and iterations. Every time a new problem arises, one should revisit the SOP, check if anything is unclear, and then add the necessary information. This is how an SOP can truly become a living document.

One Thing You Can Do Today

Open an SOP you find most difficult to use and try to identify three text-based steps that could be replaced with images.

Want to try it yourself?

Every tool mentioned in this article is available on InsightFab — just upload a CSV to analyze.

Go to Tools