Prozessgestaltung und SOPs, die in Notion nicht veralten

Letztes Quartal habe ich ein Audit an einem Notion-Workspace mit 47 Dokumenten durchgeführt. Einunddreißig davon wurden archiviert. Nicht "zur Überprüfung markiert". Archiviert. Aus der Seitenleiste verschwunden. Das Team hat es zwei Wochen lang nicht bemerkt, und als es aufgefallen ist, haben sich drei Personen bedankt.

Das ist der tatsächliche Zustand der meisten Ops-Dokumentation. Sie erben einen Workspace mit vierzig-und-mehr SOPs, verteilt über Notion, Confluence und ein Google Drive, zu dem niemand mehr den Link hat. Nach sechs Monaten haben ungefähr 73 % den Anschluss an den tatsächlichen Prozess verloren. Der Autor hat das Unternehmen vor zwei Quartalen verlassen. Neue Mitarbeitende werden verbal durch die "echte" Version geführt, von wem auch immer an dem betreffenden Dienstag Zeit hat. Das Dokument existiert als Schaufensterstück für Audits. Niemand öffnet es.

Dieses Playbook beschreibt das, was ich stattdessen tue. Das 1-seitige SOP, Loom-first-Walkthroughs, einen 90-Tage-Überprüfungsrhythmus und eine Ghost-Doc-Diagnostik, die Ihnen sagt, welche 60 % Ihrer Bibliothek vor dem nächsten Quartal gestrichen werden sollten. Nichts davon ist theoretisch. Ich habe es bei drei Ops-Teams eingeführt, und dasselbe Muster bestätigt sich immer: Bibliothek halbieren, Leserzahl des Verbleibenden verdoppeln.

Das 1-seitige SOP (und was gestrichen wird)

Ein funktionierendes SOP hat fünf Felder. Das war es. Wenn Sie ein sechstes schreiben, schreiben Sie ein Schulungsdokument, kein SOP, und das gehört woanders hin.

Hier ist die genaue Vorlage, die ich in jedes neue Dokument einfüge:

# {Prozessname}

**Zweck** (1 Satz): Warum dieser Prozess existiert und was ausfällt, wenn er nicht läuft.
**Verantwortliche Person**: {Namentlich genannte Person, kein Team}
**Zuletzt geprüft**: {JJJJ-MM-TT}
**Nächste Prüfung**: {JJJJ-MM-TT + 90 Tage}

## Schritte
1. {Aktionsverb + Objekt + Tool}
2. {...}
3. {...}

## Erfolgskriterien
- {Messbares Ergebnis 1}
- {Messbares Ergebnis 2}

## Eskalation
Wenn {Auslösebedingung}, {Person} innerhalb von {Zeitraum} kontaktieren.

Das passt auf eine gedruckte Seite. Es ist bewusst schmucklos. Keine Screenshots, keine Kontexttabellen, kein "Hintergrund und Begründung". Diese Dinge gehören in ein Wiki, ein Loom oder ein Kickoff-Meeting. Nicht hierher.

Was gestrichen wird und warum:

Hintergrundabschnitte. "Dieser Prozess wurde entwickelt, um einen Vorfall von 2024 zu adressieren, bei dem..." Das interessiert niemanden. Das SOP ist für die Person gedacht, die die Arbeit heute erledigt. Wenn die Geschichte relevant ist, wird sie danach fragen.

Entscheidungsbäume mit mehr als einem Ast. Wenn Ihr SOP verschachtelte Bedingungen hat, sind das zwei SOPs, die so tun, als wären sie eines. Aufteilen.

Eingebettete Screenshots der Tool-Oberfläche. Screenshots veralten schneller als der Prozess, den sie dokumentieren. Salesforce ändert eine Schaltflächenfarbe, und Ihr SOP sieht aus, als wäre es von jemandem geschrieben worden, der sich dieses Jahr nicht eingeloggt hat. Verwenden Sie stattdessen ein Loom. Dazu gleich mehr.

"Profi-Tipps"- und "Achtung"-Kästen. Wenn es wichtig genug ist, es hervorzuheben, ist es ein Schritt. Wenn es kein Schritt ist, ist es Rauschen.

Das Erfolgskriterien-Feld ist dasjenige, das die meisten Ops Manager weglassen, und es ist das wichtigste. "Monatlichen Abschluss durchführen" ist kein Prozess. "Monatlichen Abschluss durchführen, sodass alle Bankabstimmungen null Abweichung zeigen und das GL bis zum 5. Werktag gesperrt ist" ist ein Prozess. Die Kriterien geben an, ob der Prozess funktioniert hat. Ohne sie können Sie nicht erkennen, wenn das SOP defekt ist.

Loom-First-Dokumentation: 5 Minuten schlagen 8 Seiten

Hier ist die Reihenfolge, in der ich SOPs jetzt schreibe, und sie ist das Gegenteil von dem, was ich früher getan habe:

1. Ein Loom von mir selbst aufnehmen, wie ich den Prozess von Anfang bis Ende durchführe. Fünf bis acht Minuten.
2. Mit 1,5-facher Geschwindigkeit zurückschauen. Notieren, wo ich pausiere, wo ich einen Schritt überspringe, wo ich mich korrigiere.
3. Das 1-seitige SOP aus diesen Notizen schreiben.
4. Das Loom oben im Dokument einbetten.

Das Loom ist die Primärquelle. Das 1-seitige Dokument ist der Index. Das klingt verkehrt herum, weil wir darauf trainiert wurden, schriftliche Dokumente als maßgeblich zu betrachten, aber die Mathematik ist einfach: Ein fünfminütiger Walkthrough wird angeschaut. Ein achtseitiges Dokument wird nach der Überschrift durchgescannt, die der Leser zu brauchen glaubt, und dann geschlossen.

Aufrufdaten bestätigen das. Beim letzten Team, das ich geführt habe, wurden unsere zehn meistgenutzten SOPs gemessen an Loom-Aufrufen durchschnittlich 14 Mal pro Quartal abgespielt. Dieselben SOPs als Notion-Dokumente hatten durchschnittlich 3 Seitenaufrufe und 22 Sekunden Verweildauer. Die Leute haben das Video geschaut, die Arbeit erledigt und das Dokument nicht geöffnet.

Ein paar Regeln, die ich für das Loom befolge:

• Mit dem Auslöser beginnen. "Ich tue das, weil eine Anbieter-Verlängerung in meinem Posteingang gelandet ist." Nicht "Hallo zusammen, heute werden wir über..."
• Den Bildschirm zeigen, nicht das Gesicht. Die Webcam kostet Zeit und Aufmerksamkeit. Die Arbeit findet auf dem Bildschirm statt.
• Entscheidungen kommentieren, nicht Klicks. "Ich markiere das für Legal, weil die automatische Verlängerungsklausel über 30 Tage geht." Nicht "Ich klicke jetzt auf den Kommentarknopf."
• Bei 6 Minuten neu aufnehmen. Wenn Sie überzogen haben, haben Sie einen Planungsschritt übersprungen. Nochmals versuchen.
• Bei jeder Prozessänderung neu aufnehmen. Das alte Loom nicht bearbeiten. Ein neues aufnehmen und den eingebetteten Link ersetzen. Die alte Version verbleibt in Ihrer Loom-Bibliothek als historische Aufzeichnung.

Der Loom-first-Ansatz löst auch etwas, über das niemand spricht: den Autoren-Fluch. Wenn Sie zuerst ein SOP schreiben, beschreiben Sie den Prozess, der Ihrer Meinung nach stattfindet. Wenn Sie zuerst aufnehmen, dokumentieren Sie den Prozess, der tatsächlich stattfindet. Das sind fast nie dasselbe Dokument. Das Loom erzwingt Ehrlichkeit.

Der 90-Tage-Überprüfungsrhythmus

Jedes SOP in meiner Bibliothek hat zwei Datumsfelder: zuletzt_geprüft und nächste_prüfung. Die nächste Prüfung liegt immer 90 Tage in der Zukunft. Nicht "jährlich". Nicht "bei Bedarf". Neunzig Tage, im Kalender, mit einer Benachrichtigung.

Zum 90-Tage-Termin erledigt die benannte Verantwortliche Person eines von drei Dingen:

1. Den Prozess erneut ausführen. Tatsächlich ausführen. Abweichungen in Echtzeit erkennen.
2. Bestätigen, dass es keine Änderungen gibt. zuletzt_geprüft auf heute setzen. nächste_prüfung um 90 Tage verschieben. In zwei Minuten erledigt.
3. Das Dokument bearbeiten und das Loom neu aufnehmen. Dauert 30 Minuten. Lohnt sich.

Die Regel, die das zum Funktionieren bringt: Zwei verpasste Überprüfungszyklen, und das Dokument wird archiviert, nicht "später aktualisiert". Sechs Monate, ohne dass eine Verantwortliche Person es anfasst, ist ein starkes Signal, dass niemand es braucht. Wenn doch, löst das Archivieren eine Slack-Nachricht von jemandem aus, und jetzt wissen Sie, wer es tatsächlich nutzt. Wiederherstellen, neu zuweisen, 90-Tage-Prüfung festlegen.

Ich behalte die Audit-Abfrage als gespeicherte Ansicht in Notion. Drei Spalten: SOP-Name, Verantwortliche Person, Tage seit der letzten Prüfung. Absteigend sortiert. Alles über 180 Tage steht auf der Streichliste. Ich führe das am Ende jedes Quartals durch, archiviere die toten Dokumente und sende dem Team eine einzeilige E-Mail: "Diese Woche 9 SOPs archiviert. Wenn Sie eines suchen und es weg ist, melden Sie sich bei mir."

In zwei Jahren dieses Rhythmus habe ich genau vier "Melden Sie sich"-Antworten erhalten. Davon waren zwei Personen, die ein Dokument suchten, das durch ein neueres ersetzt worden war (ich habe sie weitergeleitet). Zwei waren echte Archivierungsfehler (ich habe sie wiederhergestellt). Über vierzig Dokumente verschwanden ohne eine einzige Beschwerde.

Dieses Verhältnis sagt Ihnen alles darüber, wie viele Ihrer SOPs tatsächlich genutzt werden.

Die "Ghost-SOP"-Diagnostik

Ein Ghost-SOP ist ein Dokument, das in Ihrem Workspace existiert, aber in der täglichen Realität des Teams nicht vorkommt. Es ist die größte Kategorie in den meisten Ops-Bibliotheken, und das Audit zur Identifizierung dauert etwa eine Stunde.

Drei Anzeichen, von denen jedes einzelne ausreicht:

Verwaister Verantwortlicher. Das Verantwortlichkeitsfeld nennt jemanden, der das Unternehmen verlassen hat, das Team gewechselt hat oder nie bestätigt hat, dass er zuständig ist. Wenn Sie keinen aktuellen Mitarbeitenden im Dokument taggen können, ist es ein Ghost.

Letzte Bearbeitung älter als 180 Tage. Ein halbes Jahr ohne eine Änderung, bei einem Prozess, der angeblich "aktiv" ist. Entweder hat sich der Prozess nicht verändert (selten, in meiner Erfahrung) oder niemand hat ihn überprüft. In beiden Fällen wird das Dokument nicht gepflegt.

Keine eingehenden Links und keine aktuellen Aufrufe. Wenn kein anderes Dokument, keine Einarbeitungscheckliste und keine Slack-Nachricht in den letzten 90 Tagen auf dieses SOP verlinkt, ist es in keinem Workflow vorhanden. Es existiert isoliert. Es ist ein Ghost.

Die schnellste Variante des Audits ist eine mündliche. Drei Personen im Team auswählen. Jede einzeln fragen: "Wenn Sie jetzt X tun müssten, wo würden Sie nachschauen?" Wenn sie das SOP nennen, lebt es. Wenn sie sagen "Ich würde Jamie fragen", ist das Dokument tot und Jamie ist das eigentliche SOP. Das Dokument durch ein Loom von Jamie ersetzen, bevor Jamie das Unternehmen verlässt.

Ich habe das einmal an einem Workspace mit 47 Dokumenten durchgeführt. Achtundzwanzig haben alle drei Anzeichen nicht erfüllt. Drei weitere haben zwei von drei nicht erfüllt. Ich habe 31 Dokumente an einem einzigen Nachmittag archiviert. Das Team hat sich im nächsten Monat schneller bewegt, nicht langsamer, weil die Suchergebnisse nicht mehr mit Ghost-Treffern überfüllt waren.

Vorlage vs. individuelle Erstellung: Wann wiederverwenden, wann neu schreiben

Nicht jeder Prozess verdient ein individuelles SOP. Manche Prozesse sind Standardware, und ein neues Dokument dafür zu schreiben, ist selbst eine Form von Verschwendung.

Vorlage verwenden für:

• Einarbeitungschecklisten. IT-Einrichtung für neue Mitarbeitende, Anfragen für Softwarezugang, Erste-Tag-Walkthroughs. Das Muster ist bei allen Rollen identisch, nur die Zugriffsliste ändert sich.
• Anbieterprüfungen. Verlängerungstermin, Vertragswert, Verantwortliche Person, letzte Leistungsüberprüfung, Kündigungsfrist. Fünf Felder, jeder Anbieter.
• Incident Response. Schweregrade, Bereitschaftsrotation, Eskalations-Timing, Post-Mortem-Vorlage. Der Rahmen ist wiederverwendbar; die Einzelheiten des Vorfalls kommen ins Post-Mortem.
• Monatlicher Abschluss. Dieselben Konten, dieselben Abstimmungen, dasselbe Sperrdatum. Die Abweichungen eintragen.

Neu schreiben für:

• Alles Funktionsübergreifende. Ein Prozess, der Sales, Finance und Legal berührt, hat Übergaben, die für die Berichtsstruktur Ihres Unternehmens einzigartig sind. Eine Vorlage wird die relevanten Reibungspunkte verbergen.
• Alles mit einer echten Übergabe. "Sales übergibt den Deal an Einarbeitung." Wo liegen die Daten? Wer sendet wem eine Nachricht? Was ist der SLA für die Antwort? Vorlagen kennen Ihre Tools nicht.
• Alles, was Umsatz berührt. Quote-to-Cash, Vertragsgenehmigungen, Deal-Desk-Prüfung. Die Kosten eines generischen SOP, das Ihre Genehmigungsmatrix verfehlt, sind Tage von Nacharbeit. Immer individuell.

Die Kurzformel, die ich verwende: Wenn ich mir vorstellen kann, dass dasselbe SOP bei drei verschiedenen Unternehmen mit minimalen Anpassungen funktioniert, wird es zur Vorlage. Wenn der Prozess durch Ihren spezifischen Tech-Stack, Ihre spezifische Teamstruktur oder Ihr spezifisches Umsatzmodell geprägt ist, wird er neu geschrieben.

Ein praktischer Hinweis: Vorlagen-SOPs kommen in einen _templates-Ordner. Wenn jemand eine Einarbeitungscheckliste für eine neue Rolle benötigt, dupliziert er die Vorlage und passt die rollenspezifischen Felder an. Die Vorlage selbst ist schreibgeschützt. Das verhindert die schleichende Abweichung, bei der das Einarbeitungs-SOP jedes Teams nach 18 Monaten eine leicht unterschiedliche Variante ist.

Eigentumsregeln: Eine Person, nie "Das Team"

"Das Ops-Team ist dafür zuständig" bedeutet, dass niemand dafür zuständig ist. Ich habe dasselbe Muster bei jedem Unternehmen gesehen: Ein Dokument listet ein Team als Verantwortlichen auf, das Team wechselt, das Dokument veraltet, und nach 12 Monaten sagt das Dokument eines und der Prozess tut etwas anderes.

Die Regel ist: Eine namentlich genannte Person pro SOP, keine Ausnahmen. Vor- und Nachname im Verantwortlichkeitsfeld. Wenn sie das Unternehmen verlassen, wird das SOP in demselben Austrittsprozess-Ticket neu zugewiesen, das auch den Zugang entzieht. Kein SOP ohne aktuell zuständige Person wird in den Workspace aufgenommen. Wenn Sie ein neues Dokument prüfen und das Verantwortlichkeitsfeld "Operations" oder "TBD" lautet, senden Sie es zurück.

Das klingt bürokratisch. Ist es nicht. Es ist die einzige Regel, die Verantwortlichkeit schafft. Die namentlich genannte Person ist diejenige, die:

• Den Prozess alle 90 Tage erneut ausführt.
• Das Loom neu aufnimmt, wenn sich etwas ändert.
• Die Slack-Benachrichtigung erhält, wenn es ein Problem gibt.
• Änderungen von anderen genehmigt.

Wenn die Zuständigkeit geteilt wird, passiert nichts davon. Wenn sie namentlich benannt ist, passiert alles davon, denn der Name der Verantwortlichen Person steht im Dokument, und niemand möchte die Person sein, deren SOP in der Produktion versagt hat.

Ein Muster, das ich verwende, um das zu festigen: In der vierteljährlichen Teamprüfung erhält jede namentlich genannte Verantwortliche Person eine Liste ihrer SOPs und deren Prüfungstermine. Das zu erstellen dauert mich ungefähr zehn Minuten. Die Liste ist öffentlich. Niemand möchte derjenige mit drei überfälligen Prüfungen sein. Innerhalb von zwei Quartalen sank die Überfälligkeitsrate von 40 % auf unter 10 % in dem Team, das ich damit geführt habe, ohne andere Prozessänderungen als die Sichtbarkeit.

Ein zweites Muster für größere SOPs, die sich wirklich über mehrere Personen erstrecken: Benennen Sie eine primäre Verantwortliche Person und eine Vertretung. Die Primärperson führt die 90-Tage-Prüfung durch. Die Vertretung ist diejenige, die Sie kontaktieren, wenn die Primärperson im Urlaub oder in einem Meeting ist. Zwei Namen. Nicht fünf. Nicht "das Team".

Wenn Sie nur eine Regel aus diesem Playbook mitnehmen, nehmen Sie diese. Das 1-seitige Format ist hilfreich. Der Loom-first-Ansatz ist hilfreich. Der 90-Tage-Rhythmus ist hilfreich. Ohne eine namentlich benannte Verantwortliche Person, die weiß, dass das SOP ihr gehört, funktioniert nichts davon.

So sieht das in der Praxis aus

Drei Monate nachdem ich das beim letzten Team eingeführt hatte, schrumpfte der Workspace von 47 SOPs auf 19. Die Loom-Aufrufe pro SOP verdreifachten sich. Die "Wo finde ich das Dokument für X"-Slack-Nachrichten sanken auf ungefähr eine pro Woche, ausgehend von einem Basiswert von fünf oder sechs pro Tag. Zwei neue Mitarbeitende arbeiteten sich in ihrem ersten Monat nur anhand der Looms und der 1-Seiter ein, ohne begleitende Walkthroughs von erfahrenen Teammitgliedern.

Die Aufgabe besteht nicht darin, mehr Dokumente zu schreiben. Die Aufgabe besteht darin, weniger, aber bessere zu pflegen, jedes mit einer namentlich genannten Verantwortlichen Person, alle 90 Tage geprüft und ohne Aufhebens archiviert, wenn es still wird. Die meisten Ops-Teams sind überdokumentiert und unterpflegt. Das Verhältnis umkehren.

Weiterführende Lektüre

• Operations Manager Job Description mit der vollständigen Rollendefinition, KPIs und Interview-Rubrik
• Ihre ersten 30/60/90 Tage als neuer Ops Manager: Wo SOP-Audits in Ihren Einarbeitungsplan passen
• Ein Tag im Leben eines Operations Managers: Wie Dokumentationsarbeit in den wöchentlichen Rhythmus passt
• Funktionsübergreifende Koordination: Wie man SOPs für Übergaben schreibt, die Teams übergreifend sind