So erstellen Sie ein SOP-Flussdiagramm

Kurz gesagt

• Eine Prozedur pro Diagramm. Zwei Startpunkte bedeuten zwei SOPs.
• Die Schritte sind nummeriert und kurz genug, um sie unter Druck vorzulesen.
• Jede Entscheidung nennt ihre Kriterien, oder die Rolle, die sie trifft.
• Eskalations- und Wiedereröffnungswege werden gezeichnet, nicht mitgedacht.
• Gelenkt ist eine SOP erst mit freigegebener Version, Verantwortlichem und Prüftermin.

Was eine SOP von einem Prozessdiagramm unterscheidet

Ein SOP-Flussdiagramm wird in einer völlig anderen Situation gelesen als ein Prozessdiagramm. Ein Prozessdiagramm liest man im Meeting; eine SOP liest um zwei Uhr nachts jemand, der diesen Fall noch nie bearbeitet hat und wissen muss, was als Nächstes zu tun ist. Dieser Unterschied bestimmt jede Gestaltungsentscheidung: kurze Schritte, nummeriert, damit man sie am Telefon vorlesen kann, Entscheidungen mit den Kriterien direkt am Knoten, und kein Zweig, der dem Ermessen überlassen bleibt, sofern nicht eine benannte Rolle die Entscheidung trifft.

Grenzen Sie das Diagramm auf eine einzige Prozedur ein. Der häufigste Mangel in SOP-Flussdiagrammen ist, dass es in Wahrheit drei Prozeduren sind, die sich eine Seite teilen, und dadurch so lang werden, dass niemand sie mehr öffnet. Hat Ihr Diagramm zwei Startpunkte oder einen Abschnitt, der nur für ein Team gilt, teilen Sie es auf. Querverweise zwischen SOPs kosten nichts; eine zwanzigseitige SOP, die niemand liest, kostet.

Die andere Hälfte einer SOP ist die Lenkung. Eine Prozedur ohne dokumentierte Freigabe, ohne Versionsstand und ohne Prüftermin ist ein Vorschlag, und in einem regulierten Umfeld ist eine SOP ohne Versionslenkung für sich genommen bereits eine Abweichung. Das Beispiel unten ist eine Prozedur für das Incident-Management mit einem Zweig für Major Incidents, einer Eskalation bei drohender SLA-Verletzung und einer Schleife für wiedereröffnete Tickets, samt Prozedurtext, der aus denselben Zeilen erzeugt wird.

Eine SOP als Flussdiagramm

Eine Prozedur für das Incident-Management, in vier Etappen aufgebaut. Der nummerierte Prozedurtext darunter stammt aus denselben Zeilen wie das Diagramm.

1. Erst erfassen, dann diagnostizieren

   Erkannt, mit Auswirkung erfasst, kategorisiert und priorisiert. Eine SOP beginnt genau dort, wo die lesende Person tatsächlich steht, und bei einem Incident ist das, bevor irgendjemand weiß, was defekt ist. Deshalb steht die Erfassung vor der Diagnose.

2. Die Verzweigung an der Schweregrad-Einstufung

   „Major Incident?“ teilt die Prozedur: ausrufen, Bridge öffnen, Stakeholder informieren, oder mit der Erstdiagnose im First Level weitermachen. Die Kriterien für diese Einstufung gehören an die Entscheidung selbst, weil sie unter Zeitdruck von der Person mit Bereitschaft getroffen wird.

3. Eskalieren Sie nach Regel, nicht nach Gefühl

   Untersuchung im Second Level, ein expliziter SLA-Check mit eigenem Zweig für die Eskalation bei Verletzung, danach Wiederherstellung und Bestätigung durch den Nutzer. Beachten Sie den Weg für wiedereröffnete Tickets: eine nicht bestätigte Lösung geht zurück in die Diagnose, statt in der Hoffnung geschlossen zu werden, dass sie hält.

4. Schließen und das Gelernte zurückführen

   Lösungsnotiz, danach die Entscheidung, ob die Ursache weiterhin unbekannt ist: wenn ja, wird ein Problem-Datensatz angelegt. Eine SOP, die bei „Service wiederhergestellt“ endet, verliert genau das Ergebnis, das die Wiederholung desselben Incidents verhindert.

So funktioniert es

1. Grenzen Sie auf eine einzige Prozedur ein

   Schreiben Sie den Auslöser in einem Satz: „Ein Incident wird erkannt oder gemeldet.“ Braucht der Auslöser ein „oder“, das eine wirklich andere Situation abdeckt, ist das eine zweite SOP. Genau diese Beschränkung auf eine Prozedur hält das Diagramm kurz genug, um es im Ernstfall überhaupt zu öffnen.

2. Formulieren Sie die Schritte als Anweisungen

   Verb zuerst, eine Handlung je Schritt, an die ausführende Person gerichtet: „Incident mit Auswirkung erfassen“, nicht „Der Incident wird erfasst“. Passive Formulierungen verstecken den Verantwortlichen, und eine SOP, deren Schritte niemandem gehören, ist der Grund, warum zwei Personen denselben Schritt ausführen und eine dritte gar keinen.

3. Schreiben Sie die Kriterien an die Entscheidungen

   „Major Incident?“ braucht eine Definition daneben: Zahl der betroffenen Nutzer, Service-Klasse, Umsatzwirkung, was auch immer bei Ihnen gilt. Nutzen Sie das Kommentarfeld des Schritts für diese Regel. Entscheidungen ohne Kriterien werden von jeder lesenden Person anders getroffen, und dann trägt das Wort „Standard“ nichts mehr.

4. Ergänzen Sie Eskalations- und Wiedereröffnungswege

   Zeichnen Sie, was passiert, wenn das SLA-Ziel zu reißen droht, wenn die Lösung nicht hält und wenn die sonst zuständige Person nicht verfügbar ist. Genau dafür schlägt man eine SOP nach. Jeder dieser Wege führt entweder in den Ablauf zurück oder endet in einem eigenen Endpunkt.

5. Verteilen Sie die Swimlanes und gehen Sie alles mit der Bereitschaft durch

   Legen Sie jeden Schritt in die Swimlane der Rolle, die ihn ausführt (Service Desk, Incident Manager, Support Level 2 / 3), und lesen Sie das Diagramm mit denen durch, die damit arbeiten werden. Fragen Sie, wo sie zögern würden. Jedes Zögern markiert einen Schritt, dem entweder ein Kriterium oder eine Aufteilung fehlt.

6. Freigeben, versionieren und einen Prüftermin setzen

   Schicken Sie das Diagramm durch den Freigabe-Workflow, damit die gültige Version einen Prüfer und ein Datum trägt, und setzen Sie einen Auslöser für die Überprüfung: nach jedem Major Incident und mindestens einmal jährlich. In QueryChart liegen Freigabe und Änderungshistorie beim Diagramm: auf „Welche Version galt im März?“ gibt es damit eine Antwort.

Häufige Fehler

• Eine SOP, die eigentlich drei sind

  Zwei Startpunkte oder ein Abschnitt, der nur für ein Team gilt, heißt: aufteilen. Die Länge ist genau das, was verhindert, dass eine SOP in dem Moment geöffnet wird, in dem sie zählt.

• Ermessensentscheidungen ohne Kriterien

  „Eskalieren, wenn es ernst ist“ ist keine Standardarbeitsanweisung. Schreiben Sie den Schwellenwert auf oder benennen Sie die Rolle, die entscheidet: nur diese beiden Wege machen die Einstufung wiederholbar.

• Keine Fehlerwege

  Den Happy Path kennen die Leute ohnehin. Eine SOP, die SLA-Verletzung, Wiedereröffnung und den abwesenden Verantwortlichen auslässt, schweigt genau dort, wo sie gebraucht wurde.

• Ohne Versionslenkung

  Ohne freigegebene Version und Änderungshistorie kann niemand belegen, welche Prozedur galt, als etwas schiefging, und in einem regulierten Umfeld ist das für sich genommen eine Abweichung.

Erstellen Sie Ihr eigenes SOP-Flussdiagramm

Öffnen Sie das Beispiel zum Incident-Management als eigenes Diagramm oder starten Sie leer und schreiben Sie Ihre Prozedur in die Zeilen.

Erstellen Sie Ihr eigenes SOP-Flussdiagramm

Verwandte Anleitungen

• So erstellen Sie einen Prozess zur Dokumentenlenkung
• So versionieren Sie eine SOP
• So erstellen Sie einen Change-Control-Prozess

Häufig gestellte Fragen

Was ist der Unterschied zwischen einer SOP und einem Prozessdiagramm?

Eine SOP ist eine gelenkte Anweisung zur Ausführung einer bestimmten Aufgabe: nummeriert, mit Verantwortlichem, freigegeben, versioniert und für die ausführende Person geschrieben. Ein Prozessdiagramm bildet ab, wie Arbeit fließt, häufig über mehrere Rollen hinweg, und darf beschreibend statt verbindlich sein. Zeichnen Sie eine SOP als Flussdiagramm, bekommen Sie beides (die Lesbarkeit eines Diagramms mit den Lenkungseigenschaften einer Prozedur), solange Freigabe und Versionshistorie mitkommen.

Soll eine SOP ein Flussdiagramm oder ein Text sein?

Beides, aus einer Quelle. Ein Flussdiagramm ist unter Druck schneller zu befolgen und macht Lücken in den Verzweigungen sichtbar; der Text trägt die Details, die ein Diagramm nicht fassen kann, etwa exakte Feldwerte oder Sicherheitshinweise. Der Fehler ist, beides als zwei getrennte Dokumente zu führen, denn dann laufen sie auseinander. Erzeugen Sie den Prozedurtext aus denselben Zeilen wie das Diagramm, dann ist eine Änderung an der einen Stelle eine Änderung an beiden.

Wie lang sollte ein SOP-Flussdiagramm sein?

Kurz genug, um in lesbarer Größe auf einen Bildschirm zu passen: in der Praxis fünfzehn bis fünfundzwanzig Schritte. Darüber hinaus suchen Sie eine natürliche Übergabe und teilen in zwei Prozeduren, die aufeinander verweisen. Lange SOPs sind nicht gründlicher; sie werden nur seltener geöffnet, und eine SOP, die niemand öffnet, bewirkt genauso viel Lenkung wie gar keine SOP.

Wer gibt eine SOP frei?

Der Prozessverantwortliche und zusätzlich derjenige, der für das gelenkte Risiko einsteht: häufig Qualität, Compliance oder der Service-Verantwortliche. Verfahrenstechnisch entscheidend ist, dass die Freigabe mit Name und Datum an einer bestimmten Version hängt, damit es keinen Zweifel gibt, welcher Text zu welchem Zeitpunkt in Kraft war. Genau dieser Nachweis macht aus einem Dokument ein gelenktes Dokument.