F FulcrumGrid

Startseite / Blog / SOPs schreiben, die Ihr Team befolgt

Betrieb

Wie man SOPs schreibt, die Ihr Team wirklich befolgt

Ein praktischer Leitfaden zum Schreiben von Standardarbeitsanweisungen, die Ihr Team tatsächlich nutzt — Format, Überprüfungsrhythmus, Verantwortlichkeit und häufige Fehler, die man vermeidet.

· 6 Min. Lesezeit

Die meisten Standardarbeitsanweisungen scheitern aus demselben Grund: Jemand hat einmal ein langes, sorgfältiges Dokument geschrieben, und seither hat es niemand geöffnet. Es liegt auf einem geteilten Laufwerk, während der tatsächliche Prozess im Kopf einer einzigen Person lebt, jeder neuen Einstellung von Grund auf neu erklärt wird und sich jeden Monat ein Stück weiter von dem entfernt, was aufgeschrieben ist.

Eine SOP, die genutzt wird, ist nicht länger oder gründlicher als eine, die es nicht wird — sie ist von Anfang an anders aufgebaut. So sieht das aus.

1. Schreiben Sie sie als Schritte, nicht als Fließtext

Ein Absatz, der einen Prozess beschreibt, wird einmal gelesen und vergessen. Eine nummerierte Liste konkreter Handlungen kann man mitten in der Aufgabe befolgen, ohne alles neu zu lesen. Jeder Schritt sollte eine einzelne Handlung mit klarem Ergebnis sein — „Den Bericht exportieren“, nicht „Den Berichtsprozess handhaben“. Erfordert ein Schritt eine Entscheidung, benennen Sie die Entscheidung ausdrücklich, statt sie als offensichtlich vorauszusetzen.

2. Geben Sie jeder SOP einen Verantwortlichen

Eine SOP ohne benannten Verantwortlichen veraltet langsam, weil sich niemand zuständig fühlt zu bemerken, wenn sie nicht mehr der Realität entspricht. Weisen Sie jeder Prozedur eine Person zu, zu deren Aufgabe es gehört, sie aktuell zu halten — nicht unbedingt die Person, die die Aufgabe am häufigsten erledigt, sondern jemand mit dem Stand, sie zu aktualisieren, wenn sich der Prozess ändert.

3. Legen Sie sie dorthin, wo die Arbeit tatsächlich stattfindet

Eine Prozedur, die drei Ordner tief auf einem geteilten Laufwerk vergraben ist, könnte ebenso gut nicht existieren. Die SOP für eine Aufgabe muss in dem Moment erreichbar sein, in dem jemand diese Aufgabe erledigt — verlinkt aus dem genutzten Werkzeug, nicht getrennt davon abgelegt. Müssen Menschen danach suchen, fragen sie lieber eine Kollegin, und das Dokument ist nicht mehr die Quelle der Wahrheit.

4. Legen Sie einen Überprüfungsrhythmus fest, keine einmalige Niederschrift

Prozesse ändern sich schneller als die Dokumentation, sofern die Überprüfung der Dokumentation geplant statt zufällig erfolgt. Eine einfache Regel funktioniert gut: Jede SOP wird in einem festen Rhythmus überprüft (vierteljährlich für alles Kundenbezogene oder Compliance-relevante, zweimal jährlich für den Rest), und wer den zugrunde liegenden Prozess zuletzt angefasst hat, ist dafür verantwortlich, sie zu melden, falls sich zwischenzeitlich etwas geändert hat.

5. Testen Sie sie an jemandem, der die Aufgabe nie erledigt hat

Die Person, die eine SOP geschrieben hat, ist die schlechteste Instanz zu beurteilen, ob sie klar ist, weil sie bereits weiß, was darin stehen soll. Bevor Sie eine Prozedur als fertig betrachten, geben Sie sie jemandem, der die Aufgabe nicht kennt, und beobachten Sie, wo er zögert oder es falsch macht. Jeder Punkt der Verwirrung ist eine Lücke im Dokument, keine Lücke beim Leser.

Häufige Fehler, die die Akzeptanz leise abwürgen

  • Für die Compliance schreiben, nicht für den Gebrauch. Eine Prozedur, die eine Audit-Checkliste erfüllen soll, und eine, die jemanden tatsächlich durch eine Aufgabe führen soll, lesen sich sehr unterschiedlich — und nur eine davon wird freiwillig geöffnet.
  • Keine Versionskontrolle. Wenn Menschen nicht erkennen können, ob sie die aktuelle Version vor sich haben, verlieren sie das Vertrauen und fragen wieder herum.
  • Zu viele Details, zu früh. Decken Sie zuerst die 80 % der Fälle ab, die jedes Mal vorkommen. Sonderfälle können in einem verlinkten Anhang leben, statt den Hauptablauf zu verschütten.

SOPs funktionieren am besten, wenn sie an die Systeme gebunden sind, die Menschen ohnehin für die Aufgabe nutzen, statt als separate Übung gepflegt zu werden. Das ist einfacher, wenn der zugrunde liegende Prozess — Genehmigungen, Warnungen, Berichte — bereits über ein einziges Betriebs-Dashboard läuft, statt über Werkzeuge verstreut zu sein. Es passt natürlich dazu, dem Team überhaupt erst die richtigen Kennzahlen vor Augen zu führen, und zu einem sauberen Onboarding-Prozess, um Prozeduren an Neueinstellungen zu übergeben.

Zurück zum Blog

FulcrumGrid Command Center

Prozeduren dort halten, wo die Arbeit passiert

Command Center gibt Ihrem Team einen Kontrollraum für Live-KPIs, Warnungen und Workflows — damit der dokumentierte Prozess der Prozess ist, der tatsächlich läuft.