So versionieren Sie eine SOP

So funktioniert es

1. Legen Sie das SOP-Nummerierungsschema vor der ersten Revision fest

   Geben Sie jeder SOP eine Kennung und eine ganzzahlige Revision, gedruckt im Kopf jeder Seite neben Gültigkeitsdatum und Freigeber. Entscheiden Sie das einmal, denn eine spätere Umnummerierung zerstört jeden Schulungsnachweis und jede Auditspur, die die alte Nummer zitiert hat.

2. Protokollieren Sie den Antrag gegen die Revision, die er ändert

   Eröffnen Sie einen Antrag mit dem genauen zu ändernden Schritt und der Begründung (ein Vorfall, ein Beinaheunfall, eine Abweichung), bevor jemand den Entwurf anfasst. Tippen Sie ihn in die Spalte Boxtext eines Diagramms und nutzen Sie Linie zu, um ihn auf die Zeile zu zeigen, die den Antrag gegen die aktuelle Revision protokolliert, sodass der Antrag an eine Version gebunden ist statt frei zu schweben.

3. Erzwingen Sie die sicherheitskritische Entscheidung explizit

   Geben Sie dem Workflow eine Entscheidungszeile, die fragt, ob ein sicherheitskritischer Schritt betroffen ist, mit zwei beschrifteten Zweigen in der Spalte Linientext. Leiten Sie „Ja“ in eine dokumentierte Sicherheitsauswirkungsbewertung und „Nein“ in eine Standard-Eignungsprüfung; lassen Sie einen Antragsteller oder Freigeber die Frage niemals durch Annahme überspringen.

4. Verriegeln Sie den sicherheitskritischen Weg mit praktischer Nachschulung, nicht mit Bestätigung

   Terminieren Sie nach der Freigabe eine verpflichtende praktische Schulung und verlangen Sie eine unterschriebene Kompetenzcheckliste, bevor die Änderung live gehen kann. Eine Zeile, die nur „lesen und bestätigen“ sagt, gehört auf den Standardweg, nicht auf den sicherheitskritischen; halten Sie beide als eigene Zeilen, damit die Unterscheidung eine spätere Umsortierung übersteht.

5. Führen Sie beide Wege in einer Registeraktualisierung zusammen

   Welchen Zweig eine Änderung auch genommen hat, leiten Sie sie in eine einzige, als Datei geformte Zeile, die das SOP-Register aktualisiert und die vorherige Revision als überholt markiert, bevor die neue als aktuell veröffentlicht wird. Ein Zusammenlaufpunkt bedeutet eine Stelle zu prüfen, dass jeder Weg tatsächlich den Einzug der alten Kopie erreicht.

6. Bestätigen Sie jeden betroffenen Bediener, nicht nur die eingeteilten

   Haken Sie vor der Veröffentlichung Nachschulung oder Bestätigung für jede Schicht und jeden Fremdmitarbeiter ab, den der Schritt betrifft, nicht nur das Team, das zufällig am Freigabetag vor Ort war. Eine vergessene Nachtschicht ist die Feststellung, die in jedem Auditzyklus wiederkehrt.

Häufig gestellte Fragen

Unterscheidet sich SOP-Versionskontrolle von allgemeiner Dokumentenversionskontrolle?

Ja, in einem bestimmten Punkt: Die Versionskontrolle einer SOP muss beantworten, wer vor Inkrafttreten der neuen Revision nachgeschult werden muss, nicht nur, welches Exemplar aktuell ist. Allgemeine Dokumentenversionskontrolle (behandelt unter /de/guides/versionskontrolle-fuer-dokumente) lenkt Nummerierung, Freigabe und Einzug für jedes gelenkte Dokument. Eine SOP fügt darunter eine Kompetenzfrage hinzu: Eine erhöhte Revisionsnummer hindert einen Bediener nicht daran, die alte Methode auszuführen, bis er auf die neue nachgeschult wurde, weshalb der Versionskontrolldatensatz einer SOP neben der üblichen Freigabespur einen Schulungs- oder Bestätigungsstatus tragen muss.

Wie sollte eine sicherheitskritische SOP-Änderung anders geleitet werden als eine geringfügige?

Eine sicherheitskritische Änderung (bei der ein falsch ausgeführter Schritt eine Verletzung, ein nichtkonformes Produkt oder einen regulatorischen Verstoß riskiert) braucht eine dokumentierte Sicherheitsauswirkungsbewertung, eine QA-gesteuerte Freigabe und eine praktische Nachschulung mit unterschriebener Kompetenzcheckliste, bevor sie live gehen kann. Eine nicht sicherheitskritische Änderung kann eine Standard-Eignungsprüfung, eine gewöhnliche Freigabe und Lesen und Bestätigen durchlaufen. Beide über denselben leichtgewichtigen Weg zu leiten, führt dazu, dass eine Formulierungskorrektur und eine Änderung an einem Lockout-Schritt am Ende demselben Nachweisstandard unterliegen: für die eine zu wenig, für die andere zu viel.

Ist ein Schulungsnachweis dasselbe wie Versionskontrolle für eine SOP?

Nein: sie beantworten unterschiedliche Fragen, und ein SOP-Prozess braucht beides. Versionskontrolle verfolgt, welche Revision aktuell ist, wer sie freigegeben hat und was sie ersetzt hat; ein Schulungsnachweis verfolgt, wer Kompetenz auf dieser Revision nachgewiesen hat. Die Versionshistorie von QueryChart unter /features/version-control deckt Ersteres ab: ein Änderungsprotokoll mit Vorher-Nachher-Werten je Feld, eine Ansicht zum Versionsvergleich und Wiederherstellung. Die unterschriebene Kompetenzcheckliste, die eine sicherheitskritische Änderung verlangt, oben beschrieben, deckt Zweiteres ab, und beide müssen auf dieselbe Revisionsnummer verweisen, sonst kann ein Auditor nicht erkennen, ob die geschulte Person zur geltenden Anweisung passt.

Was ist der Mindestnachweis, den ein Auditor für eine SOP-Revision erwartet?

Eine auf dem Dokument gedruckte Revisionsnummer und ein Gültigkeitsdatum, einen Nachweis, wer sie wann freigegeben hat, eine dokumentierte Begründung für die Änderung, gebunden an den auslösenden Antrag, und (bei allem Sicherheitskritischen) einen datierten, unterschriebenen Kompetenznachweis, der benennt, wer auf welcher Version nachgeschult wurde. Für die Leit- und Freigabemechanik der SOP selbst siehe die gelenkte SOP-Vorlage unter /de/templates/gelenkte-sop-vorlage; für die engere Frage, was sich zwischen zwei Revisionen geändert hat, siehe /de/guides/aenderungen-in-einer-sop-nachverfolgen.