Best Practices für die SOP-Versionskontrolle

Kurz gesagt

• Sperren Sie eine sicherheitskritische Revision hinter praktischer Nachschulung und einer unterschriebenen Kompetenzprüfung, nicht hinter Lesen und Bestätigen: siehe /de/templates/sop-change-control-prozess.
• Benennen Sie einen verantwortlichen Eigentümer für die SOP selbst, unabhängig davon, wer die jüngste Revision entworfen hat.
• Ziehen Sie eine abgelöste SOP von jedem Anwendungsort ein (Ordner am Arbeitsplatz, Aushänge, gemeinsame Laufwerke), nicht nur aus dem Register.
• Setzen Sie das Prüfintervall nach betrieblichem Risiko, nicht nach einem starren, für jede SOP gleichen Jahresdatum.
• Das Änderungsprotokoll und die Ansicht zum Versionsvergleich von QueryChart, unter /features/version-control, liefern den Wer-hat-welches-Feld-geändert-Nachweis ohne zusätzlichen Prozess.

Vier Disziplinen, die eine allgemeine Checkliste auslässt

Diese Seite setzt voraus, dass die Mechanik bereits läuft. Braucht Ihr Änderungshistorie-Protokoll noch einen Workflow (wer entwirft einen Eintrag, wer prüft ihn, wer unterschreibt), ist das unter /de/guides/aenderungen-in-einer-sop-nachverfolgen behandelt, und der Takt, der Einträge planmäßig hält, steht unter /de/guides/sop-revisionen-verwalten. Was keine der beiden Seiten fragt, ist, ob die Praxis überhaupt gut ist, sobald sie läuft, und für eine SOP speziell bedeutet „gut“ etwas Engeres als bei einer Richtlinie oder einer Tabellenvorlage.

/de/guides/best-practices-dokumentenversionskontrolle behandelt die allgemeine Disziplin (eine stabile Kennung, ein verbindlicher Ort, ein Prüfintervall mit benanntem Verantwortlichen), und jede dieser Regeln gilt weiterhin für eine SOP. Zusätzlich kommt hinzu, dass eine SOP jemandem sagt, wie eine Aufgabe physisch auszuführen ist, sodass eine Revision, die das Verfahren ändert, verändert, was eine Person mit ihren Händen tut, nicht nur, was in einer Datei steht. Aus diesem Unterschied folgen vier Praktiken, die eine allgemeine Dokumentencheckliste keinen Grund hat zu erwähnen: ein Kompetenztor vor dem Livegang einer sicherheitskritischen Revision, ein Verantwortlicher, der an die SOP gebunden ist statt an wer sie zuletzt entworfen hat, ein Einzug, der bis zum Arbeitsplatz reicht und nicht nur bis zum Register, und ein Prüfintervall, das nach Risiko statt nach einem starren Kalenderdatum gesetzt wird.

Drei der vier zeigen sich direkt im unten durchgegangenen Änderungshistorie-Protokoll: ein sicherheitskritischer Zweig, der manche Einträge anders leitet als andere, eine Prüfung auf einen bereits offenen Doppeleintrag zur selben SOP, und ein Einzugsschritt, der bis zum genutzten Exemplar reichen muss, nicht nur bis zum Protokoll. Der vierte (ein verantwortlicher Eigentümer) ist eine Regel darüber, wer im Datensatz benannt ist, nicht etwas, das eine Diagrammform erzwingt. Die eigene Versionshistorie von QueryChart gibt einem Dokumentenbeauftragten denselben Nachweis für das Diagramm selbst: ein Änderungsprotokoll mit Diffs je Feld, eine Ansicht zum Versionsvergleich und Wiederherstellung mit einem Klick, alles kostenlos und standardmäßig aktiv, vollständig beschrieben unter /features/version-control.

Wo die Praktiken in einem echten Protokoll auftauchen

Dasselbe 18-zeilige Änderungshistorie-Protokoll, das zwei frühere Anleitungen durchgingen, hier gelesen dafür, was es bei Verantwortlichkeit, Weiterleitung und Einzug richtig macht.

1. Der Verantwortliche markiert Risiko, bevor irgendjemand entwirft

   Die Start-Zeile ist ein Ereignis („Änderung an einer SOP erkannt“), und die Bahn des Prozessverantwortlichen beschreibt die Änderung und ihre Begründung, bevor die Entscheidungszeile „Änderung betrifft sicherheitskritischen Schritt?“ sie auf einen von zwei Wegen schickt.

2. Ein Eintrag pro SOP, nicht einer pro Bearbeiter

   „Änderungshistorie hat bereits einen offenen Eintrag für diese SOP?“ prüft auf ein laufendes Duplikat, und „Mit dem Verantwortlichen des offenen Eintrags abstimmen“ führt zusammen oder staffelt, statt zwei offene Einträge zwei konkurrierende Versionsnummern erzeugen zu lassen.

3. Prüfung und Freigabe prüfen den Eintrag, nicht nur den Entwurf

   Die Zeile des Freigebers prüft den Eintrag „gegen die SOP-Stammfassung und die abgelöste Version“, nicht nur den Entwurf allein, und ein abgelehnter „Freigegeben?“-Zweig kehrt zu derselben Nacharbeitszeile zurück, die auch ein offener Prüferkommentar nutzen würde.

4. Sperren, dann überall einziehen

   „Freigegebenen Eintrag als final erfassen“ sperrt Datum, Namen des Freigebers und Versionsnummern, damit die Zeile nicht stillschweigend umgeschrieben werden kann, dann muss „Als abgelöst referenzierte Version einziehen oder archivieren“ das gedruckte Exemplar am Arbeitsplatz erreichen, nicht nur diesen Protokolleintrag, bevor die SOP wieder ausgegeben wird.

So funktioniert es

1. Fügen Sie sicherheitskritischen Revisionen ein Nachschulungstor hinzu

   Leiten Sie jede Revision, die einen sicherheitskritischen Schritt betrifft, vor dem Livegang zu praktischer Nachschulung und einer unterschriebenen Kompetenzcheckliste, nicht zu Lesen und Bestätigen. /de/templates/sop-change-control-prozess zeigt das Tor als QA-Freigabezweig, der den Livegang blockiert, bis jeder betroffene Bediener unterschrieben hat.

2. Benennen Sie einen verantwortlichen Eigentümer pro SOP

   Setzen Sie den Namen des Verantwortlichen auf den SOP-Datensatz selbst, in ein Feld getrennt vom Autor einer einzelnen Revision. Die Verantwortlichkeit sollte einen Personalwechsel oder eine Entwurfsübergabe überstehen; ist der „Verantwortliche“ einfach, wer die Datei zuletzt bearbeitet hat, ist niemand über das gesamte Leben des Dokuments hinweg verantwortlich.

3. Bauen Sie eine Einzugscheckliste nach Anwendungsort

   Listen Sie jeden Ort auf, den eine Revision erreicht, bevor Sie sie ausgeben (Ordner am Arbeitsplatz, Aushang, gemeinsames Laufwerk, Einweisungsmappe), und haken Sie jeden ab, sobald das abgelöste Exemplar entfernt ist. Ein Registereintrag, der „eingezogen“ markiert ist, während noch ein gedrucktes Exemplar an der Wand hängt, wurde nicht eingezogen.

4. Staffeln Sie Prüfintervalle nach Risiko, nicht nach starrem Kalender

   Geben Sie einer sicherheitskritischen SOP ein kürzeres Intervall als einer risikoarmen administrativen; jedes Dokument mit demselben Jahresdatum zu stempeln macht die Überprüfung zu einer Formalität, für die niemand Zeit hat. Setzen Sie das Intervall bei Ausgabe der SOP, nicht erst, wenn das Register es zufällig anzeigt.

5. Beweisen Sie die Praxis mit dem Änderungsprotokoll, nicht nur mit dem Register

   Öffnen Sie den Versionsvergleich am Diagramm, um genau zu sehen, welches Feld sich geändert hat, von welchem Wert und wer es freigegeben hat, statt sich auf die eigene Darstellung des Änderungshistorie-Protokolls zu verlassen. QueryChart führt diese kostenlose Versionshistorie für jedes Diagramm: siehe /features/version-control.

Häufige Fehler

• Eine Unterschrift, die nichts beweist

  Eine Lesebestätigung beweist, dass jemand die Datei geöffnet hat, nicht dass er die neue Methode korrekt ausführen kann. Reservieren Sie sie für risikoarme Änderungen und verlangen Sie praktische Nachschulung mit unterschriebener Checkliste überall dort, wo der Schritt sicherheitskritisch ist.

• Verantwortlichkeit, die mit jeder Bearbeitung wechselt

  Verfällt Verantwortlichkeit standardmäßig an wer den Entwurf zuletzt angefasst hat, hinterlässt ein ausscheidender Autor die SOP ganz ohne Eigentümer. Weisen Sie die Rolle des Verantwortlichen einmal der SOP zu und aktualisieren Sie sie bewusst, statt sie mit der Autorschaft driften zu lassen.

• Im Register eingezogen, an der Wand lebendig

  Eine Revision im Protokoll als abgelöst zu markieren ändert nichts an dem laminierten Exemplar am Arbeitsplatz. Gehen Sie Ihre eigene Einzugsliste ab, bevor Sie ihr vertrauen: die Exemplare, die Sie finden, sind die, die der Prozess verpasst hat.

• Ein Intervall für jede SOP unabhängig vom Risiko

  Ein pauschales jährliches Prüfdatum macht hochriskante SOPs zu niedrig priorisiertem Papierkram und risikoarme zu verschwendeter Prüfkapazität. Staffeln Sie das Intervall nach dem, was die SOP regelt, nicht danach, wann es zufällig fällig wird.

Bauen Sie Ihr eigenes SOP-Änderungshistorie-Protokoll

Öffnen Sie das Beispiel zur SOP-Änderungshistorie als eigenes Diagramm und passen Sie den sicherheitskritischen Zweig, das Verantwortlichenfeld und das Prüfintervall an Ihre eigenen SOPs an.

Bauen Sie Ihr eigenes SOP-Änderungshistorie-Protokoll

Verwandte Anleitungen

• So erstellen Sie eine Dokumenten-Änderungshistorie
• So versionieren Sie eine SOP
• So verfolgen Sie Änderungen in einer SOP

Häufig gestellte Fragen

Unterscheidet sich SOP-Versionskontrolle von allgemeiner Dokumentenversionskontrolle?

Die Mechanik ist dieselbe (eine stabile Kennung, ein verbindliches Exemplar, ein Prüfintervall), und /de/guides/best-practices-dokumentenversionskontrolle behandelt sie. Der Unterschied liegt in der Konsequenz einer Lücke: Eine SOP sagt jemandem, wie eine Aufgabe physisch auszuführen ist, sodass ein veraltetes oder nicht eingezogenes Exemplar tatsächlich verändert, was eine Person tut: weshalb SOP-Praxis ein Nachschulungstor und eine Einzugsprüfung am Anwendungsort ergänzt, die eine Richtlinie oder ein Formular nicht braucht.

Wann braucht eine Revision Nachschulung statt Lesen und Bestätigen?

Wenn die Änderung einen sicherheitskritischen Schritt betrifft: alles, wo die alte Methode eine Verletzung, ein nichtkonformes Produkt oder einen regulatorischen Verstoß riskiert. /de/templates/sop-change-control-prozess leitet diesen Fall über eine QA-gesteuerte Freigabe und verpflichtende praktische Nachschulung mit unterschriebener Kompetenzcheckliste; alles andere kann den leichteren Lesen-und-bestätigen-Weg nehmen.

Sollten der Verantwortliche und der Autor der SOP dieselbe Person sein?

Nicht zwingend, und sie getrennt zu halten ist meist die dauerhaftere Anordnung. Der Autor entwirft eine bestimmte Revision; der Verantwortliche ist über jede Revision hinweg verantwortlich, die die SOP je haben wird, einschließlich solcher, die jemand anderes entwirft, nachdem der ursprüngliche Autor weitergezogen ist.

Ist SOP-Versionskontrolle dasselbe wie SOP-Change-Control?

Nein. Versionskontrolle identifiziert und verfolgt Revisionen; Change Control ist das Prüftor, das eine vorgeschlagene Änderung durchläuft, bevor sie zu einer wird. /de/guides/versionskontrolle-vs-change-control behandelt die allgemeine Abgrenzung, und speziell für SOPs ist /de/templates/sop-change-control-prozess das Change-Control-Tor, das die Version erzeugt, die die Praktiken dieser Seite anschließend lenken.