SOPs: Why Most Plants Have Too Many and Follow Too Few

The Standard Operating Procedure is, on paper, the most uncontroversial document in a manufacturing plant. A clear written instruction for how a critical task should be performed is a prerequisite for a controlled, repeatable, auditable operation. Nobody argues against the concept. The argument that needs to happen is about what actually happens to SOP libraries over time — because in most plants I have worked with across twenty-five years of MES rollouts and quality work, the library that exists in the document management system and the procedures that actually govern behavior on the shopfloor are two largely separate things. Closing that gap is harder than writing more SOPs, and most organisations never seriously try.

This article is about the gap. Why it opens, why it persists, what it costs, and what the small minority of plants that have closed it have done differently. The methodology literature on SOPs concentrates almost entirely on how to write a good one. The harder and more important question, in my experience, is how many SOPs an organisation can actually sustain — and what happens to the rest.

What an SOP is, and what most people think it is

A Standard Operating Procedure is a written instruction that defines exactly how a specific task is to be performed: the steps, in order, with parameters, responsibilities, safety requirements, and acceptance criteria. The intent is reproducibility — anyone with the appropriate training, holding the SOP, should be able to perform the task in a way that produces the same outcome as anyone else. In regulated environments (pharma, medical devices, aerospace) the SOP is a legal artifact; in non-regulated environments (most automotive, FMCG, general industry) it is a quality and operational-discipline artifact. The intent is the same; the consequences of divergence differ.

The intent is sound. The execution gap is where the discussion has to happen. In a meaningful share of the plants I have audited, the documented SOPs and the actual operator practice diverge — not because operators are wrong, but because SOPs are usually written for an earlier process state, an earlier supplier, an earlier piece of equipment, an earlier organisational structure, and they are not updated when reality changes. The procedures that operators actually follow are the ones they remember from training, refreshed by experience and by talking to colleagues. The rest of the library is inventory.

Why SOP libraries inflate

The proliferation pattern is not random. It is a structural consequence of how SOPs get created and how they get retired. Creating an SOP is cheap, fast, and politically rewarded — it closes audit findings, demonstrates response to incidents, and signals process discipline to customers. Retiring an SOP is the opposite: it requires someone to formally state that a documented standard is no longer needed, which feels risky to anyone whose job depends on appearing rigorous. The math works out the same way in plant after plant. SOPs flow into the library faster than they flow out, and the library grows monotonically until somebody finally undertakes a painful, multi-month consolidation project. Then the cycle starts over.

The other structural cause is fragmentation of ownership. SOPs are typically written by the function that owns the process — quality writes quality SOPs, maintenance writes maintenance SOPs, production writes production SOPs. Nobody owns the library as a whole. There is no SOP architect role in most plants. So the library accumulates redundancies (multiple slightly different SOPs for the same task, written by different functions over different years), conflicts (an SOP that contradicts a more recent one nobody remembered to retire), and dead branches (procedural families for equipment that left the plant years ago). The auditor sees a complete library. The operator sees a search problem.

The shadow SOP problem

The flip side of the inflated library is the existence of what I have come to call shadow SOPs — the procedures that operators actually follow, transmitted verbally, refined over time, and not documented anywhere. Every plant has them. They are usually better than the documented SOP they replaced (which is why the operators converged on them) but they have three properties that should worry any quality leader: they are not auditable, they are not reproducible across shifts, and they walk out of the plant when the operator who carries them leaves.

The pharmaceutical industry has spent decades wrestling with this gap because the regulatory consequences of the shadow-SOP pattern are severe. The automotive industry wrestles with it less rigorously and pays the cost in inconsistent quality between shifts. Many consumer-goods sectors do not seriously wrestle with it at all and pay the cost in scrap and yield variations that get attributed to "operator differences" without anyone investigating what those differences actually are.

The conventional response is to launch a "documentation sprint" to capture the shadow SOPs and bring them into the official library. This has two failure modes. First, the operators who actually know the procedures are usually too busy producing to spend time documenting, so the documentation sprint produces SOPs written by people who do not actually know the procedure, which then get added to the library and continue to be ignored. Second, even when the documentation is correct, it gets added to a library that is already too large for anyone to navigate, so the new accurate SOP joins the old inaccurate one in the same pool of unread documents. The volume problem and the accuracy problem compound each other.

The four conditions for SOPs that actually govern

From the plants I have seen sustain a working SOP discipline over multi-year periods — and there are fewer of them than the methodology literature implies — the conditions are consistent. Notably none of them are about the SOPs themselves. They are about the governance system around the library:

1. Named ownership of the library, not just of individual SOPs. Someone in the plant is responsible for the SOP library as a single asset, with explicit authority to retire documents. In plants that work, this person is senior enough that "no, we are not adding another SOP for this" is a credible answer they can give to an audit response. In plants that do not work, this role does not exist and the library grows by default.
2. Mandatory retirement-on-creation. Every new SOP added to the library requires the author to identify which existing SOP (or section of one) is being replaced or rendered obsolete, and to retire it as part of the same approval. This single rule, when actually enforced, is the most effective brake on library inflation I have seen. It forces the cost of retirement onto the moment of creation, when the political will exists, instead of onto a future cleanup project that never happens.
3. SOPs delivered at the point of work, not in a document library. An SOP that lives in a SharePoint folder is read by auditors. An SOP that appears on the operator's terminal at the moment they begin the task it governs is read by operators. The technology to do this has existed for fifteen years. Most plants still do not do it because the integration between the SOP system and the production system was never built. This is the single largest gap I see in plants that have invested in good SOPs but get poor compliance.
4. Regular cross-checking against production data. If the documented SOP for a setup procedure says it should take 22 minutes and the actual cycle data shows it consistently taking 35, one of the two is wrong, and an honest organisation finds out which. The cross-check is not an audit event — it is a continuous data feed. Where production data and SOP-prescribed parameters can be compared automatically, the divergence between documented and actual practice surfaces continuously, instead of being discovered during an annual review when the gap has been open for eighteen months.

What this looks like operationally

The plants I have seen run honest SOP libraries do not have more SOPs than other plants. They have fewer. The reduction is not a target; it is a consequence of the four conditions above. When ownership is named and retirement is enforced, libraries shrink to the size that the organisation can actually maintain. The remaining SOPs get read more often (because there are fewer of them to navigate), get updated more often (because each one matters more), and govern behavior more reliably (because operators trust that what is in the document represents current practice). Beyond a certain threshold, the relationship between library size and library effectiveness is inverse, not proportional.

This is the conclusion that most leadership teams resist most strongly. The instinct, when an SOP fails, is always to write more SOPs — to address the specific failure with another document. The honest response is usually the opposite: to reduce the library to the documents that actually get read and governed, accept that the rest were inventory all along, and build the discipline around a smaller, sharper, regularly-maintained set.

In SYMESTIC's customer base, the third governance condition above — SOPs delivered at the point of work — is where the platform makes the most direct contribution. The Process Data module captures per-cycle parameters that the operator's terminal can compare against the SOP-prescribed values in real time, surfacing deviations as they happen instead of in a quarterly audit. The Shopfloor Documents capability brings the relevant SOP onto the operator's screen at the moment of the task, removing the SharePoint-search step that kills compliance in most plants. Combined with Alarms on parameter excursions, this turns the SOP from a document that exists into an instruction that is followed and verified. None of this replaces the governance discipline — named library ownership, retirement-on-creation, regular cross-checking — that has to come from the organisation. But it removes the technical friction that, in most plants I worked in before SYMESTIC, was the largest single excuse for why SOPs were not being followed at the workstation.

About the author

Christian Fieg

Head of Sales at SYMESTIC. 25+ years in manufacturing — Johnson Controls, Visteon, iTAC, Dürr. Six Sigma Black Belt. Globally responsible for MES & traceability at Johnson Controls (900+ machines, 750+ users, 7 countries). Author of OEE: One Number, Many Lies (2025). · LinkedIn