Prozesse · Betrieb
Warum dokumentierte Prozesse übersprungen werden (und es liegt nicht an Faulheit)
Teams schreiben den Prozess auf und verpassen trotzdem den Schritt. Die Gründe sind struktureller Art: Distanz, Timing, veraltete Dokumente und unsichtbare Einhaltung. Wie sich jeder davon an einem echten Ticket zeigt und was hilft.
Jede Führungskraft im Betrieb kennt dieses Gespräch. Einem Kunden wurde das Falsche gesagt, eine Eskalation kam von der Entwicklung zurück, ein Release ging ohne Freigabe raus. Jemand ruft die Confluence-Seite auf und sagt: Aber es steht doch da.
Es steht da. Und wurde trotzdem übersprungen. Nach ein paar hundert dieser Gespräche ist das Muster klar genug, um es zu benennen. Menschen überspringen dokumentierte Schritte nicht, weil sie nachlässig sind. Sie überspringen sie aus vier strukturellen Gründen, und jeder hat eine andere Lösung.
1. Das Dokument ist weit weg von der Arbeit
Das Runbook liegt in Confluence. Das Ticket liegt in Freshdesk. Das Engineering-Issue liegt in Jira. Die Entscheidung, die alles ändert, wurde am Dienstag in einem Slack-Thread getroffen. Wer das Ticket bearbeitet, bräuchte fünf Tabs und zehn Minuten, um zusammenzusetzen, was der Prozess für diesen Vorgang vorsieht.
Niemand hat zehn Minuten pro Ticket. Also tun die Leute, was Menschen tun: Sie handeln nach dem, was vor ihnen liegt, nämlich dem Ticket, und verlassen sich beim Rest auf ihr Gedächtnis. Das Gedächtnis reicht für den Normalfall und ist schlecht bei der Ausnahme, und genau bei der Ausnahme zahlt sich das Dokument aus.
Was hilft: den Prozess zur Arbeit bringen. Nicht einen Link – den Schritt. "Nächster Schritt: Teilen Sie dem Kunden mit, dass das erwartetes Verhalten ist, und führen Sie Recalculate aus." Das Dokument bleibt die maßgebliche Quelle; es wird nur im Namen der Person gelesen, für dieses Ticket, mit zusammengeführtem Kontext.
2. Der Schritt hängt von einer Tatsache ab, die niemand geprüft hat
Die meisten Prozesse verzweigen sich. "Wenn die LP compliance-kritisch ist, P2 eröffnen." "Wenn der Kunde auf 4.12 oder höher ist, ist der Fix bereits live." "Wenn es ein einzelner Nutzer ist, sind es Daten; wenn es viele sind, ist es Konfiguration." Die Verzweigungsbedingung ist eine Tatsache über den Vorgang, und diese Tatsache steht oft nicht im Ticket.
Hier liegt der stille Fehler: Die Person kennt die Tatsache nicht, weiß nicht, dass der Prozess davon abhängt, und nimmt den Standardzweig. Das Dokument wurde befolgt. Der falsche Zweig wurde genommen. Niemand merkt es, bis es der Kunde merkt.
Was hilft: Fragen. Die Frage, die das Dokument beantwortet haben muss, im Moment gestellt, in dem sie zählt, mit den eigenen Optionen des Dokuments: Ein Nutzer oder viele? In welcher Umgebung wurde getestet? Ein Prozess, der fragt, bevor er annimmt, wird weit häufiger befolgt als einer, der annimmt.
3. Das Dokument stimmte letztes Quartal
Prozesse driften. Das Engineering ändert den Eskalationsweg, ein neues Squad übernimmt einen Bereich, ein Tool wird ersetzt. Das Dokument wird sechs Wochen später aktualisiert, falls sich jemand erinnert. In diesen sechs Wochen folgen die erfahrenen Leute dem echten Prozess (sie waren im Meeting) und die neuen dem geschriebenen. Beide halten sich für im Recht.
Die teure Variante davon ist die Schulung: eine Kohorte, die im März auf ein Dokument geschult wurde, das sich im April geändert hat, und im Mai selbstsicher auf die alte Weise arbeitet.
Was hilft: Korrekturen zurückfließen lassen. Wenn jemand sagt "Das ist falsch, wir eskalieren jetzt an das Learn-Squad", sollte diese Korrektur (a) sofort auf ähnliche Vorgänge angewendet werden und (b) zu einem Änderungsvorschlag für das Dokument werden, über den der Verantwortliche entscheidet. Und wenn sich das Dokument ändert, sollten die auf die alte Version geschulten Personen erfahren, was sich geändert hat – in einem Absatz, nicht in einem Diff.
4. Niemand sieht die Einhaltung, bis es ein Post-Mortem gibt
Fragen Sie eine Teamleitung, wie viel Prozent der Tickets im letzten Monat dem Triage-Prozess gefolgt sind. Niemand weiß es. Die Einhaltung ist unsichtbar, bis etwas so schwer schiefgeht, dass es eine Auswertung rechtfertigt, und dann lautet die Frage "wer", nicht "wo".
Ohne Sichtbarkeit gibt es kein Feedback: Ein Schritt, der in 40 % der Fälle übersprungen wird, sieht genauso aus wie einer, der nie übersprungen wird. Das Dokument kann sich nicht verbessern, weil niemand weiß, wo es scheitert.
Was hilft: Signale. Jede Korrektur, jede Frage, die das Dokument nicht beantworten konnte, jedes Schulungsszenario, das Leute falsch beantworten, gruppiert nach Stufe. Eine Stufe, die viele verfehlen, ist ein Dokumentproblem, kein Personalproblem – und jetzt können Sie es sehen.
Der gemeinsame Nenner
Keines davon löst sich dadurch, dass man ein besseres Dokument schreibt, eine Schulung durchführt oder eine Erinnerung verschickt. Sie lösen sich, indem man die Distanz zwischen dem Dokument und dem Moment des Handelns schließt und den Moment des Handelns das Dokument korrigieren lässt. Dieser Kreislauf – befolgen, korrigieren, nachschulen – ist das, worum wir Ovenbird gebaut haben. Aber auch ohne Tool lohnt es sich, bei jedem Prozess, den Ihr Team immer wieder verfehlt, diese vier Fragen zu stellen: Wie weit ist das Dokument von der Arbeit entfernt? Von welcher Tatsache hängt der Schritt ab? Wann stimmte es zuletzt? Woran würden wir merken, dass es übersprungen wurde?