Are Your SOPs Being Followed? How to Check for Process Drift
How to check whether the procedure on file still matches how the job is done, using a re-recording. Covers method variance across shifts, sites, and operators.
TL;DR
Process drift is the gap between a written procedure and the way the work is actually performed. It builds up over months of small changes, not in one decision. The reliable way to measure it is to re-record the task as it is done today and compare that against the document on file. Standard operating procedures do not prevent defects on their own. What they do is make the process auditable, so when quality moves you can see which step changed and where.
- Drift usually starts as a sensible local improvement that never made it back into the document.
- Method variance between operators, shifts, and sites is the most common form and the hardest to see from an office.
- A procedure nobody opens is not a control, and usage analytics are the fastest way to find out which ones those are.
- Updating monthly without irritating the floor is a distribution problem: change the document, not the routine of collecting it.
What is process drift?
Process drift is the gradual divergence between a documented procedure and the way the task is actually performed on the floor. It is not usually the result of anyone deciding to ignore the document. It happens because a tool changed, a fixture was moved, a supplier’s part arrived slightly different, or an experienced operator found a faster sequence and started using it, and none of those changes were written down.
The reason it matters is that the document is what you train new people on, what you show an auditor, and what you fall back on when something goes wrong. Once it no longer describes reality, all three of those uses are compromised at the same time, and typically nobody notices until one of them is tested.
Why do different operators do the same task differently?
Because the procedure left room, and each person filled it in from their own experience. Method variance is the everyday form of drift. One operator does a changeover in one order, another does it in a different order, and both produce acceptable parts. Neither is following a written instruction closely enough for the difference to show up anywhere.
Some of that variance is harmless. Some of it is the reason your reject rate moves between shifts and nobody can explain it. The distinction is worth making explicitly, because teams that treat all variance as a problem end up writing procedures so rigid that operators stop following them, which produces more drift rather than less.
The practical question is not “are people doing this the same way” but “is the part of this task where variance matters actually specified”. A procedure that pins down torque, sequence, and the two checks that catch the common failure, and stays quiet about which hand you use, is followed far more reliably than one that specifies everything.
How do you find out which method is the best one?
Record several people doing the same task, then compare. This sounds obvious and is rarely done, because until recently comparing three recordings meant three people watching three videos and taking notes.
The workable version is to film each operator performing the task, generate a structured procedure from each recording, and lay the step lists side by side. The differences surface immediately: a step one person does that the others skip, a different ordering, a check that only the most experienced operator performs. That last category is the valuable one. It is usually where the tribal knowledge lives, and it is exactly what disappears when that person retires.
From there, standardizing means choosing deliberately rather than defaulting to whoever wrote the original document. Then you publish the chosen method as the procedure and retrain against it.
How do you tell if the current SOP still matches the work?
Re-record the task and compare the new procedure against the one on file.
This is the most useful check in this article, and it costs almost nothing. Film the job as it is performed today, let AI draft the steps from that recording, and read the draft against the existing document.
The comparison produces four outcomes, and each one needs a different response:
| What the comparison shows | What it means | What to do |
|---|---|---|
| The draft and the document match | The procedure is current | Nothing. Re-check on a schedule, not in a panic |
| The draft has a step the document does not | The process moved and the document did not | Decide whether the change is an improvement. If it is, update the document. If it is not, retrain |
| The document has a step nobody performed | The step is obsolete, or it is being skipped | Find out which. The two fixes are opposites, and guessing wrong is worse than not looking |
| Two operators’ drafts differ from each other | Method variance rather than drift | Compare the recordings and choose the standard deliberately |
The third row is the one that matters most for safety. A step that has quietly stopped being performed looks identical to a step that was never needed, and only the person doing the job can tell you which.
Run this on your highest-risk procedures first: the ones tied to safety, the ones an auditor will ask about, and the ones where a defect is expensive. Doing it across an entire library at once is how the exercise gets abandoned.
One honest caveat. This is a comparison you perform, not something the software watches for you. SOPX does not monitor the floor and flag when execution diverges from the document, and no tool in this category reliably does. What it does is make the comparison cheap enough to actually run.
How do you keep procedures current across shifts and sites?
Distribution is where multi-site standardization usually fails. Head office updates the controlled document, and three plants keep running the version they were trained on, because the updated one lives in a folder nobody opens and the printed copy at the station never changed.
The fix is to remove the copy step entirely. If the station has a QR code rather than a printed sheet, and that code resolves to the current approved version, then publishing a revision propagates everywhere at once with nobody walking the floor. The same applies across sites and languages: one source procedure, translated, with each site opening the version in the language its people actually read.
That gives you one document rather than many. Every shift, site, and language reads the same record instead of holding its own copy. Separate copies are what drift apart.
How do you update procedures monthly without annoying the floor?
By changing what gets updated, not how often you update.
Teams that revise procedures frequently and get resistance are usually doing two things at once: they revise the document, and they re-run the whole distribution and acknowledgement routine every time. The second part is what people find tiring, not the first.
Three practical adjustments:
- Edit the step, not the document. A procedure built as discrete steps lets you change one step and publish, rather than reissuing a whole revised manual for a single sentence.
- Separate substantive changes from cosmetic ones. Only the substantive ones need to be pushed to people. A typo fix does not need a training event.
- Make acknowledgement lightweight and targeted. Assigning the updated procedure as a task to the six people it affects is different in kind from a plant-wide sign-off sheet.
The underlying principle is that adoption survives frequent updates when the cost of each update to the individual operator is close to zero.
Do SOPs prevent defects?
No, and it is worth being direct about this because it is a common expectation and it sets teams up for disappointment.
A written procedure does not stop a mistake at the moment it happens. What documentation gives you is an auditable process: a stated standard, a record of what changed and when, and evidence of who ran the procedure and confirmed each step. When quality moves, those records are what let you narrow the cause down to a specific step and a specific change, instead of arguing from memory.
That is a real benefit, but it is diagnostic rather than preventive. The prevention comes from what you do with the finding: fix the step, retrain against it, and add a check that catches the failure earlier. Documentation makes that loop possible. It does not close it for you.
How do you know if anyone is actually opening the procedure?
Look at usage rather than assuming it. A procedure that is technically current but never opened is not working as a control. It also drifts faster than one people use, because nobody is reading it closely enough to notice when it stops matching.
Usage data answers this quickly. Which procedures get opened, how often, and by whom. The first time most teams look at this the result is uncomfortable, and useful: a small number of procedures carry nearly all the traffic, and a long tail has never been opened at all. That tail is where you stop maintaining documents nobody needs and concentrate on the ones that matter.
Where you need proof rather than a usage signal, running a procedure as a checklist with per-step confirmations and a sign-off at the end produces a record of execution. That is evidence someone worked through the steps. It is not evidence the physical work matched the document, and the difference between those two claims is worth keeping straight when an auditor is in the room.
Where to start
Pick your five highest-risk procedures. Re-record each task as it is performed today, generate a fresh draft, and read it against the document on file. Write down every difference.
Sort what you find into the four outcomes in the table above. Sorting them is most of the work, and each one has a different fix. Doing this once a year on the procedures that matter beats a documentation project that tries to review everything and finishes nothing.
Frequently Asked Questions
How do you get field technicians to follow documented steps instead of their own shortcuts?
Make the documented method faster to follow than the shortcut, and make it reachable at the moment of work. Technicians take shortcuts for two reasons: the documented method is genuinely slower, or the document is not available where the job happens. The first is a signal that the procedure should be rewritten around what the experienced technicians actually do. The second is fixed by putting the procedure on a phone or a QR code at the asset rather than in a binder in a van. Where you need evidence rather than compliance, a run-mode checklist with per-step confirmations records what was actually done.
How do you create a single source of truth so different shifts do not do the task differently?
Publish one procedure and give every shift a view of it rather than a copy of it. Drift between shifts almost always traces to duplication: a printed sheet on nights, a slightly different file on days, and no mechanism to keep them equal. If the station has a QR code that resolves to the current approved version, there is only one document to disagree with. Then record each shift performing the task, compare the step lists, and standardize on the best method deliberately rather than on whoever wrote the original.
Which tools reduce process variation and improve quality consistency?
Any tool that makes the standard visible at the point of work and cheap to revise will reduce variation more than a tool with a richer feature list that nobody opens. Four practical criteria: can it capture the work as it is actually done, does it reach the operator during the task, can you revise one step without reissuing the whole document, and can you see whether it is being used. SOPX covers those four for physical work. What no tool in this category does reliably is detect variation on its own; that still comes from comparing recordings.
How do you keep adoption when procedures are updated monthly?
Reduce the cost of each update to the individual operator rather than reducing how often you update. Resistance to frequent revisions is usually resistance to the routine around them: a full reissue, a plant-wide sign-off, and a training event for a one-sentence change. Editing a single step and publishing, separating substantive changes from cosmetic ones, and pushing acknowledgement only to the people a change actually affects removes most of that friction.
Can AI verify that SOPs are followed across multiple sites?
Not directly, and it is worth being precise about this. AI can generate a procedure from a recording, and it can generate a second procedure from a new recording, which lets you compare the documented method against current practice at each site quickly. That is a human-run comparison made cheap, not automated monitoring. No tool in this category watches the floor and flags divergence in real time. What you can automate is the record: run-mode checklists and sign-offs capture that each step was confirmed, and analytics show which sites open which procedures.
Do standard operating procedures prevent defects?
No. Documented procedures do not stop a mistake as it happens; they make the process auditable so you can find where method drift contributed after quality moves. The value is diagnostic: a stated standard, a record of what changed and when, and evidence of who ran the procedure. Prevention comes from acting on that finding by fixing the step, retraining, and adding an earlier check. Expecting documentation itself to reduce defects is the most common way SOP projects get judged a failure.
