Two documents, two purposes
A standard operating procedure is written to be complete and defensible. Everything is in it, in the right order, with the right references. It is a reference work and an accountability document.
A learning module has a different purpose: somebody who cannot do it yet has to be able to afterwards. That calls for leaving things out, for ordering by difficulty rather than by chronology, and for rehearsal at the points where it goes wrong.
Those two purposes collide. An SOP dropped one-to-one into an e-learning module produces a course that is entirely correct and teaches nothing, the digital version of “read this document and sign for receipt”.
That is also exactly what happens when you automate this conversion completely. The structure of the source document stays, just with navigation buttons around it.
What is missing from an SOP
Four things are rarely in there, and those four are what separate knowing from being able.
Why the step is there. Procedures describe what has to happen, not what goes wrong if you skip it. And that second thing decides whether somebody does it anyway under time pressure.
Where people actually get it wrong. That information sits in incident reports, in near-misses and in the head of the senior operator, not in the procedure itself.
What counts as an exception. SOPs describe the normal course of events. Practice consists for a considerable part of deviations, and that is exactly where experience counts.
How you know it is right. Recognition points, check moments, the difference between “tightened” and “properly tightened”.
This is why the conversion is not a translation job but a design job, and why somebody with practical experience always has to be at the table.
The conversion, step by step
In our practice it looks roughly like this.
1. Decide what somebody has to be able to do. Not “know the procedure” but “recognise and isolate a leak within the set time”. That is the assessment everything gets calculated back from.
2. Collect the failure modes. An hour’s conversation with two experienced people produces more usable material than the entire procedure manual. Do not ask what should happen, ask what they have seen others get wrong.
3. Reorder by difficulty. The SOP follows the chronology of the task. Learning follows a build-up from simple to complex, and the two are rarely the same.
4. Generate the first version. This is where the time saving sits: structure, on-screen text, variants and language versions. On the basis of the learning objectives and failure modes from steps 1 and 2, not on the basis of the SOP alone.
5. Have a subject matter expert correct it. Not review it, correct it. This is the quality moment it stands or falls on.
6. Build the assessment around the failure modes. If the assessment only checks whether somebody worked through the module, you have a completion rate and not a competence.
Step 4 is the only step substantially changed by AI. The other five are human work, and they stay that way.
What you do not automate
It is tempting to push the whole chain through: SOP in, module out. Technically that works, and the result looks professional.
But the choices in steps 1, 2 and 3 are precisely the choices that decide whether somebody works more safely afterwards. A model cannot know that at your site the fault is always at the same coupling, that the night shift keeps a different order, or that there is one step in there everybody has skipped since the equipment was replaced.
Your own people know that. The art is getting it out of them, and that is a conversational skill, not a technical one.
The way back matters just as much
One thing is nearly always forgotten in these projects: the conversion exposes faults in the source document.
Converting a procedure into a module means working it out step by step, and then it turns out step seven is unclear, that an operation is missing, or that two versions are in circulation. That is valuable information, and it belongs flowing back into the SOP.
Organise that explicitly. Otherwise you get exactly what you wanted to avoid: a modern learning module that holds, alongside an official procedure that does not, and nobody knowing which of the two is leading.
That link between documentation and learning material is something you set up structurally, not per project. How it fits into the whole is in the guide on setting up or renewing a corporate academy. The approach is described under SOP documentation.