SOP-Beispiele: 3 ausgearbeitete Standardarbeitsanweisungen
Drei SOP-Beispiele mit Arbeitsschritten, Systemen und Ausnahmen. Erfahren Sie, was eine SOP enthalten sollte und wie sie aktuell bleibt.
Ein Beispiel für eine Standardarbeitsanweisung ist dann besonders hilfreich, wenn es die konkreten Arbeitsschritte, eingesetzten Systeme und möglichen Ausnahmen zeigt, statt nur Überschriften aufzulisten. Hier finden Sie drei ausgearbeitete Beispiele. Anschließend erfahren Sie, wie eine pflegbare Standardarbeitsanweisung aufgebaut ist, wie Sie sie direkt am Arbeitsplatz dokumentieren und wie Sie prüfen, ob sie die tatsächliche Arbeit noch korrekt beschreibt.
Was ist eine Standardarbeitsanweisung?
Eine SOP beschreibt, wie eine wiederkehrende Aufgabe ausgeführt wird: wer sie erledigt, in welcher Reihenfolge und in welchem System. Sie legt auch fest, was zu tun ist, wenn der übliche Ablauf nicht greift. So erhält Ihr Team eine gemeinsame Arbeitsgrundlage und neue Mitarbeitende eine Orientierung für die Einarbeitung. Wie gut die SOP ist, hängt davon ab, wann sie zuletzt mit der tatsächlichen Arbeit abgeglichen wurde.
Worin unterscheidet sich eine SOP von einer Richtlinie, einer Arbeitsanweisung oder einer Prozesslandkarte?
Diese Dokumente erfüllen unterschiedliche Zwecke:
- Eine Richtlinie hält fest, was Ihre Organisation beschlossen hat. Zum Beispiel: „Alle Rechnungen über 10.000 benötigen eine doppelte Freigabe.“
- Eine Arbeitsanweisung erklärt, wie ein bestimmter Schritt ausgeführt wird, etwa welchen Bildschirm, welches Feld oder welche Schaltfläche Sie verwenden. Eine SOP beschreibt, was als Nächstes passiert. Eine Arbeitsanweisung erklärt, wie der jeweilige Schritt auszuführen ist.
- Eine Prozesslandkarte zeigt, wie die Arbeit über Rollen und Systeme hinweg abläuft. Eine SOP beschreibt eine einzelne Aufgabe genauer. Lesen Sie dazu unseren Leitfaden zur Prozessmodellierung.
Verfassen Sie eine SOP für die Person, die die Arbeit ausführt. Berücksichtigen Sie dabei auch Situationen, in denen sie eine Entscheidung treffen oder eine Ausnahme bearbeiten muss.
Drei Beispiele für Standardarbeitsanweisungen
Jedes Beispiel enthält eine Tabelle mit den einzelnen Schritten, der zuständigen Rolle, dem System, dem erwarteten Ergebnis und dem Ablauf für Ausnahmen. Diese Angaben erleichtern die Anwendung der Vorgehensweise und den Abgleich mit der in Ihren Systemen erfassten Arbeit.
Beispiel 1: Bearbeitung von Rechnungsabweichungen im Shared Service Center
Diese Vorgehensweise beginnt, wenn eine Rechnung den Drei-Wege-Abgleich nicht besteht. In der Spalte für Ausnahmen steht, was zu tun ist, wenn ein Schritt nicht wie geplant verläuft.
| Schritt | Zuständige Person | System | Ergebnis | Vorgehen bei Problemen |
|---|---|---|---|---|
| 1 | Sachbearbeitung Kreditorenbuchhaltung | ERP | Ausnahmefall mit Grundcode angelegt | Kein Grundcode: Vor der Prüfung an die Teamleitung der Kreditorenbuchhaltung weiterleiten |
| 2 | Sachbearbeitung Kreditorenbuchhaltung | ERP, Lieferantenportal | Abweichung bei Preis, Menge oder Lieferung festgestellt | Preisabweichung innerhalb der Toleranz von 2 %: Rechnung buchen und Abweichung protokollieren |
| 3 | Einkauf | ERP | Bestätigung, dass die Waren wie bestellt eingegangen sind | Zuständige Person im Einkauf zwei Tage nicht verfügbar: an die Kategorieverantwortlichen eskalieren |
| 4 | Sachbearbeitung Kreditorenbuchhaltung | ERP | Gutschrift angefordert oder Rechnung zur Zahlung freigegeben | Lieferant widerspricht der Gutschrift: zum Verfahren für Streitfälle wechseln und den Case nicht offen lassen |
| 5 | Teamleitung Kreditorenbuchhaltung | ERP | Case mit dokumentiertem Grund geschlossen | Derselbe Grundcode tritt drei Monate in Folge auf: Prozessänderung beantragen |
Die letzte Zeile gibt dem Team die Möglichkeit, wiederkehrende Probleme zur Prüfung zu melden. Sie setzt nicht voraus, dass jede Ausnahme auf dieselbe Weise behoben werden muss.
Beispiel 2: Wareneingang und Einlagerung
| Schritt | Zuständige Person | System | Ergebnis | Vorgehen bei Problemen |
|---|---|---|---|---|
| 1 | Mitarbeitende im Wareneingang | WMS | Lieferung anhand der ASN geprüft | Keine ASN: Wareneingang manuell erfassen und Lieferanten kennzeichnen |
| 2 | Mitarbeitende im Wareneingang | WMS | Menge und Schäden erfasst | Schaden festgestellt: fotografieren, Palette sperren und Einkauf informieren |
| 3 | Qualitätsprüfung | QMS | Freigabeentscheidung für die Charge | Charge gesperrt: Ware bleibt in Quarantäne. Einlagerung nicht beginnen |
| 4 | Lagerpersonal | WMS | Einlagerung am vorgeschlagenen Lagerplatz | Lagerplatz gesperrt: Ausweichlagerplatz verwenden und dokumentieren |
| 5 | Lagerpersonal | WMS | Bestand zur Kommissionierung verfügbar | Wareneingang nach dem Annahmeschluss gebucht: prüfen, ob offene Aufträge neu geplant werden müssen |
Beispiel 3: Erstbewertung eines IT-Vorfalls am Service Desk
| Schritt | Zuständige Person | System | Ergebnis | Vorgehen bei Problemen |
|---|---|---|---|---|
| 1 | Service-Desk-Agent | ITSM | Vorfall mit Service, Auswirkung und Dringlichkeit erfasst | Benutzer nicht erreichbar: Vorfall im Namen des Benutzers erfassen und Quelle dokumentieren |
| 2 | Service-Desk-Agent | ITSM, CMDB | Priorität anhand der Matrix für Auswirkung und Dringlichkeit festgelegt | Zuständige Lösungsgruppe widerspricht der Priorität: an den Serviceverantwortlichen eskalieren und nicht stillschweigend neu verhandeln |
| 3 | Lösungsgruppe | ITSM | Diagnose und Lösungsversuch innerhalb des SLA-Zeitraums | Lösung erfordert eine Änderung: Änderungsdatensatz verknüpfen und Vorfall offen halten |
| 4 | Service-Desk-Agent | ITSM | Bestätigung des Benutzers und Abschluss | Benutzer bestätigt nicht innerhalb von drei Tagen: mit dokumentiertem Grund schließen |
Was gehört in eine SOP?
Nutzen Sie diesen Aufbau als Ausgangspunkt für Ihre nächste Standardarbeitsanweisung:
- Zweck und Geltungsbereich: Beschreiben Sie, was die Vorgehensweise abdeckt und was nicht. Klare Grenzen helfen, eine SOP auf eine Aufgabe zu beschränken.
- Auslöser: Benennen Sie das Ereignis, das die Vorgehensweise startet. So erkennen die Lesenden, wann sie gilt.
- Rollen: Beschreiben Sie Zuständigkeiten anhand von Rollen statt Personennamen. Mitarbeitende wechseln, Rollen sind beständiger.
- Nummerierte Schritte und Systeme: Beschreiben Sie jeden Schritt, die zuständige Rolle und das verwendete System.
- Ablauf für Ausnahmen: Erklären Sie, was zu tun ist, wenn der normale Ablauf nicht greift. Berücksichtigen Sie häufige Abweichungen und nicht nur den Idealfall.
- Kontrollen und Nachweise: Legen Sie fest, was wo dokumentiert und wie lange aufbewahrt werden muss.
- Verantwortliche Person und Änderungshistorie: Benennen Sie die verantwortliche Person und halten Sie Datum und Art jeder Änderung fest.
- Prüfanlass: Legen Sie fest, was eine Prüfung auslösen soll, zum Beispiel eine Änderung am System, an Vorschriften oder im Team oder eine messbare Leistungsänderung.
Die Änderungshistorie hält fest, was wann geändert wurde. Ein definierter Prüfanlass gibt Ihnen einen Grund, die Vorgehensweise erneut zu prüfen, bevor sie veraltet.
Wie prüfen Sie, ob eine SOP einsatzbereit ist?
Stellen Sie sich vor der Veröffentlichung oder Überarbeitung einer Vorgehensweise folgende Fragen:
- Ist im Geltungsbereich festgehalten, was die SOP nicht abdeckt?
- Ist der Auslöser am Anfang klar beschrieben?
- Sind für jeden Schritt die zuständige Rolle, das System und das erwartete Ergebnis angegeben?
- Zeigen die Schritte in einer Anwendung den Bildschirm, den die lesende Person tatsächlich sieht?
- Erklärt die Vorgehensweise, was zu tun ist, wenn der normale Ablauf nicht greift?
- Sind eine verantwortliche Person und eine Änderungshistorie angegeben?
- Löst ein konkretes Ereignis eine Prüfung aus?
- Können Sie die Vorgehensweise mit Ereignisdaten vergleichen, und haben Sie Abweichungen mit der prozessverantwortlichen Person geprüft?
Wenn Sie die letzte Frage nicht beantworten können, ermitteln Sie zunächst, welche Systeme die Arbeit erfassen. So können Sie prüfen, ob die Vorgehensweise noch der Praxis entspricht. Aus der SOP-Pflege wird damit ein regelmäßiger Prüfprozess statt einer reinen Ablageaufgabe.
SOPs verwalten
Eine SOP zu erstellen ist die einfache Hälfte. Schwieriger ist die Verwaltung: Wo liegt die Vorgehensweise, welche Version ist aktuell und wer prüft sie? Ob Sie spezielle Software für die Verwaltung von Standardarbeitsanweisungen oder einen Dokumentenordner verwenden: Eine Kopie für jedes Team veraltet irgendwann. ProcessMind hält die Vorgehensweise beim beschriebenen Prozess. So bleibt die Governance mit dem Text verknüpft:
- Fügen Sie die Vorgehensweise zur beschriebenen Aktivität hinzu. Für jeden Prozess gibt es einen Dokumentationsbaum mit Abschnitten, die einmal auf Umgebungsebene konfiguriert werden. So beginnt jede Vorgehensweise mit denselben Überschriften für Beschreibung, Geltungsbereich, Rollen, Ziele und Governance. Ergänzen Sie bei Bedarf eigene Abschnitte für Ihre Organisation. Die Arbeitsanweisung bleibt beim zugehörigen Schritt, statt in einem Ordner zu liegen, den jemand erst finden muss.
- Prüfen Sie die Vorgehensweise zusammen mit dem Prozess. Ein Prozess durchläuft die Status Entwurf, In Prüfung, Genehmigt, Veröffentlicht, Ausgemustert und Archiviert. Prüfende finden ihre Aufgaben über den Filter Wartet auf meine Prüfung. Eine Freigabe kann im selben Schritt eine veröffentlichte Version erstellen. So wird ein Dokument nicht an einer Stelle freigegeben und an einer anderen geändert.
- Kommentieren Sie direkt am Ort der Arbeit. Mit Kommentar hinzufügen am Schritt starten Sie eine Diskussion zur jeweiligen Aktivität. Fragen zu einem Feld, einer Kontrolle oder einer Ausnahme bleiben so bei der Anweisung und verschwinden nicht im Posteingang.
- Bewahren Sie die Versionen auf. Der Versionsverlauf hält fest, was wann und von wem geändert wurde. Durch die Veröffentlichung legen Sie fest, welche Version die Lesenden sehen.
- Übernehmen Sie die Rollen aus dem Modell. Die RACI-Matrix im Dokument übernimmt die Rollen, die den Aktivitäten im Modell zugewiesen sind. So stimmen die Zuständigkeiten im Text mit denen im Modell überein.
- Erfassen Sie Bildschirmschritte direkt in der Anwendung. Erstellen Sie in ProcessMind einen Screenshot oder eine Bildschirmaufnahme und schneiden Sie die Aufnahme auf die relevanten Bedienelemente zu. Schwärzen Sie personenbezogene Informationen, damit die Schwärzung im gespeicherten Bild erhalten bleibt, und ergänzen Sie Anweisungen in Markdown. Der Editor kann wahrscheinlich sensible Felder auch automatisch erkennen. Die Schwärzungsfelder bleiben bearbeitbar, sodass Sie sie vor dem Speichern korrigieren können. Die Aufnahme wird als Datei an die Aktivität angehängt.
- Exportieren Sie das Dokument für alle, die eine Datei benötigen. Word eignet sich für Prüfzyklen und Qualitätsmanagementsysteme, Markdown für die Versionsverwaltung und PDF oder Druck für die Verteilung und Archivierung. In den Exporteinstellungen legen Sie fest, ob auch noch undokumentierte Modellelemente, die Prozess-Charts und die RACI-Matrix für jede Aktivität aufgeführt werden. Eine Liste undokumentierter Elemente zeigt oft am schnellsten, wo in der Vorgehensweise noch Lücken bestehen.
Das Dokument ist nur die eine Hälfte. Die andere ist die Prüfung, und auch sie gehört an denselben Ort: Vergleichen Sie die dokumentierten Schritte mit den in Ihren Systemen erfassten Aktivitäten. Entscheiden Sie dann, ob die Schulung, das Dokument oder der Prozess geändert werden muss. Eine freigegebene Änderung wird mit einem eigenen Versionsstatus in die Dokumentation übernommen.
Zwei Einschränkungen sollten Sie kennen. ProcessMind strukturiert den Prozessdatensatz und liefert Nachweise für die Prüfung. Die Plattform zertifiziert jedoch keine Compliance und ersetzt weder die Freigabe, die Ihr Qualitätsmanagementsystem verlangt, noch die Richtlinienbibliothek Ihrer Rechtsabteilung. Bildschirmaufnahme-Tools außerhalb dieses Workflows, zum Beispiel Scribe, können ebenfalls dokumentieren, wie jemand eine Aufgabe erledigt. Für eine Handvoll Vorgehensweisen, die ein Team pflegt, kann auch ein Wiki ausreichen. Weder ein Wiki noch ein separater Dokumentenspeicher zeigt jedoch, ob die Vorgehensweise noch der tatsächlichen Arbeit entspricht.
Warum weichen schriftliche Vorgehensweisen von der tatsächlichen Arbeit ab?
Vorgehensweisen geraten aus dem Takt, wenn sich die Arbeit ändert, nachdem sie dokumentiert wurde. Das ist nicht unbedingt ein Fehler beim Schreiben. Es zeigt, dass sich der Prozess weiterentwickelt hat.
Die Vorgehensweise beruht auf Erinnerungen. In einem Workshop wird festgehalten, wie die Beteiligten den Prozess verstehen. Das kann eher dem ursprünglich geplanten Ablauf entsprechen als der tatsächlichen Ausführung. Ausnahmen werden leicht übersehen, obwohl sie einen großen Teil der Arbeit ausmachen können.
Teams entwickeln eigene Lösungen. Jemand findet für einen häufigen Fall einen schnelleren Weg und teilt ihn mit den Kollegen. Wenn die Aktualisierung der SOP mehr Aufwand bedeutet als die Umgehungslösung, kann die Dokumentation veralten.
Systeme ändern sich. Ein Feld erhält einen neuen Namen, eine Prüfung wird automatisiert oder ein Freigabeschwellenwert ändert sich. Die Vorgehensweise beschreibt möglicherweise noch den vorherigen Stand.
Änderungen sind schwer zu erkennen. Ein schriftliches Dokument zeigt nicht, wann die Arbeit vom beschriebenen Ablauf abwich. Ohne Belege aus dem Prozess müssen Sie möglicherweise die Beteiligten bitten, den Ablauf nachträglich zu rekonstruieren.
So bleibt eine Vorgehensweise aktuell
Ein Dokument in einem Ordner kann diese Frage nicht allein beantworten. Wird die Vorgehensweise lebendig gehalten, bleibt sie mit dem Prozess und der beschriebenen Aktivität verknüpft. Änderungen an einem Schritt und an der zugehörigen Dokumentation werden gemeinsam geprüft, und zwar von den Rollen, die bereits im Modell aufgeführt sind. Die veröffentlichte Version ist die einzige Quelle der Wahrheit, die Ihr Team im Process Portal liest. Jeder Export basiert auf diesem Datensatz und nicht auf einer lokal bearbeiteten Kopie.
Zwei Dinge sorgen dafür, dass die Dokumentation verlässlich bleibt. Die Konformitätsprüfung misst die Abweichung zwischen dem dokumentierten Prozess und den von Ihren Systemen erfassten Aktivitäten. So können Sie Veränderungen untersuchen, statt sie nur zu vermuten. Die Prozess-Governance sorgt für klare Zuständigkeiten. Unter Governance und Veröffentlichung finden Sie den Prüfprozess und die Versionierung.
Eine schriftliche Vorgehensweise veraltet erst, nachdem sich die Arbeit bereits geändert hat. Dann kann niemand mehr sagen, wann das begonnen hat. Die Vorgehensweise direkt beim Prozess und neben der beschriebenen Aktivität zu führen, ist der einzige Weg, den ich kenne, um solche Änderungen früh zu erkennen. Lesen Sie die Dokumentation zusammen mit den Belegen, sonst ist immer eine der beiden Quellen veraltet.
Wie erstellen Sie eine SOP aus Event-Daten?
Event-Daten zeigen, welche Schritte in den Systemen ausgeführt werden, die die Arbeit bereits erfassen, etwa in einem ERP-, ITSM- oder WMS-System. Verwenden Sie diese Daten zusammen mit dem Prozesswissen, um eine Vorgehensweise zu entwerfen und zu prüfen. Dafür eignet sich unter anderem Process Mining:
-
Event Log laden
Ermitteln Sie in den Systemen, die den Prozess erfassen, die Case-ID, die Aktivität und den Timestamp. Verwenden Sie durchgehend denselben Case-Begriff und denselben Zeitraum, damit die Ergebnisse vergleichbar bleiben. -
Dem dokumentierten Prozess zuordnen
Stellen Sie die erfasste Abfolge den Schritten in der SOP gegenüber. Einige dokumentierte Schritte kommen in jedem Case vor, andere nur selten und manche gar nicht. Jeder dieser Fälle wirft eine Frage auf. -
Abweichungen analysieren
Messen Sie, wie häufig die einzelnen Abläufe vorkommen, wo Arbeit wartet und welche Schritte wiederholt werden. Eine Abweichung in den Daten ist ein Anlass zur Untersuchung, aber kein Beweis dafür, dass die Arbeit falsch ausgeführt wird. -
Relevante Abweichungen in die SOP aufnehmen
Ergänzen Sie wiederkehrende Abweichungen als Ausnahmefälle mit einer Rolle, einem System und einem erwarteten Ergebnis, wie in den drei Beispielen oben. Bitten Sie anschließend die Mitarbeitenden, zu bestätigen, was sich aus den Daten nicht ablesen lässt.
Mit Prozessdaten können Sie eine Vorgehensweise überprüfen. Die Daten erklären jedoch nicht jede Entscheidung und legen auch nicht fest, wie der Prozess ablaufen sollte. Stimmen Sie die Erkenntnisse mit den Mitarbeitenden und Prozessverantwortlichen ab. Legen Sie dabei auch eine verantwortliche Person und einen Auslöser für die nächste Prüfung fest. Ohne klare Zuständigkeit veraltet eine Vorgehensweise.
Where to Go From Here
You have a procedure and a way to check it. Compare the documented steps with the activity your systems already record, and use the differences to decide what to review with your process team.
