Jedes Unternehmen läuft auf Wissen, das nirgends geschrieben steht. Welcher Kunde eine Teillieferung akzeptiert und welcher zum Vorstand eskaliert. Warum die zweite Freigabe bei Aufträgen unter einem bestimmten Wert übersprungen wird — außer in einem Land. Welches Feld im System unzuverlässig ist und was die Leute stattdessen prüfen. Nichts davon steht in der Prozessdokumentation, alles davon ist wesentlich, und das meiste sitzt in den Köpfen einer Handvoll erfahrener Kolleginnen und Kollegen.
Das ist kein Dokumentationsversagen — so funktioniert Expertise. Das Problem beginnt, wenn die Organisation von diesem Wissen abhängt, ohne es zu wissen: wenn die Abwesenheit einer Person einen Prozess stocken lässt, wenn eine neue Kollegin fünf Monate braucht, um wirklich zu tragen, wenn dieselbe Frage in diesem Quartal zum vierten Mal per Mail beantwortet wird. In dieser Ausgabe von Quick Tips geht es um fünf praktische Wege, implizites Wissen in expliziten Prozess zu überführen — ohne ein weiteres Dokument zu produzieren, das niemand liest.
Nimm ein Schadenteam von neun Leuten. Zwei davon haben zwölf Jahre Erfahrung und bearbeiten alles Ungewöhnliche. Nach einem Beinahe-Vorfall in den Sommerferien beauftragt das Management Dokumentation: Es gibt einen Workshop, eine Prozesslandkarte, ein vierzigseitiges Handbuch im Intranet. Acht Monate später wurde das Handbuch dreimal geöffnet. Die zwei Experten sind weiterhin der Prozess, und niemand hat das Gefühl, der Aufwand sei verschwendet — das Dokument existiert ja.
Drei Dinge sind schiefgelaufen, und sie laufen fast immer schief. Die Dokumentation beschrieb den Idealprozess statt des tatsächlichen, weil sie aus einem Workshop kam, in dem Menschen sagen, was passieren sollte. Sie hielt Schritte fest statt Urteile — also erklärt sie die Reihenfolge, die sich jeder erschließen kann, und lässt die Entscheidungen weg, die wirklich Erfahrung brauchen. Und sie wurde abseits der Arbeit gelagert, an einem Ort, an den man sich unter Zeitdruck erst erinnern müsste.
Die nützliche Umformulierung lautet: Ziel ist nicht, aufzuschreiben, was Experten wissen. Ziel ist, den nächsten Fall für jemanden entscheidbar zu machen, der kein Experte ist. Das ist ein viel engeres Ziel — und die fünf Tipps unten zielen darauf.
Dokumentationsprojekte starten gern mit dem Prozess, der am leichtesten zu beschreiben ist. Das ist meist der, der es am wenigsten braucht. Der bessere Startpunkt ist Exposure: Wo kostet undokumentiertes Wissen dich heute Geld, Zeit oder Risiko?
Drei Signale finden das schnell. Erstens Einzelpersonen-Abhängigkeit: Schritte, die stehen bleiben, wenn eine bestimmte Person nicht da ist. Zweitens Fragevolumen: Welche Themen erzeugen wiederkehrende interne Fragen von ansonsten kompetenten Kollegen? Eine wiederkehrende Frage ist fehlender Prozess, und der interne Chatverlauf ist eine überraschend präzise Karte davon, wo Wissen dünn ist. Drittens Varianz: Fälle desselben Typs, die je nach Bearbeiter völlig unterschiedlich lange dauern — meist ein Zeichen, dass die Routing-Entscheidung eine Ermessensfrage ist, die niemand aufgeschrieben hat.
Nimm einen Bereich mit hoher Exposure und arbeite nur dort. Eine zweiseitige Beschreibung der Entscheidung, die ohne deinen Schlüsselexperten stockt, ist mehr wert als ein vollständiges Handbuch, das alles gleichmäßig abdeckt. Die Risikoseite dieses Musters haben wir in der Ausgabe darüber betrachtet, wenn eine Person der Prozess ist.
Frag dich: Welche einzelne Abwesenheit in deinem Team würde diesen Monat einen Prozess am stärksten bremsen — und ist irgendetwas über die Entscheidungen dieser Person aufgeschrieben?
Bittest du einen Experten, seinen Prozess zu beschreiben, bekommst du eine aufgeräumte Version. Nicht aus Unehrlichkeit — Erinnerung fasst zusammen, und Experten haben genau die Urteile automatisiert, die du erfassen willst. Das macht sie schwer artikulierbar. "Kommt auf den Fall an" ist meist eine wahre Antwort auf eine schlecht gestellte Frage.
Nutze also zwei bessere Quellen. Setz dich neben die Person, während sie echte Fälle bearbeitet, und notiere jeden Punkt, an dem sie eine Wahl getroffen hat — auch die, die sie selbst nicht bemerkt. Und trianguliere gegen die Systemspur. Die Timestamps in ERP, CRM oder Ticketsystem zeigen, was tatsächlich passiert ist: wie viele Varianten des Prozesses existieren, welche Schritte in der Praxis übersprungen werden, wo Fälle zurücklaufen. Process Mining macht daraus ein gemessenes Bild, und KI-gestützte Plattformen wie noreja zeigen die Treiber hinter einer Variante — ein schneller Weg, die informelle Regel zu finden, die sie erzeugt.
Die Kombination ist es, was funktioniert: Die Daten zeigen, wo der Prozess abweicht, die Beobachtung erklärt, warum. Eine Variante, die in 18 Prozent der Fälle auftritt und immer im selben Kundensegment, ist kein Chaos — sie ist eine undokumentierte Regel. Und jetzt kannst du sie aufschreiben.
Frag dich: Kommt deine Prozessbeschreibung aus dem, was Leute im Workshop gesagt haben — oder aus dem, was die Fälle und das System tatsächlich getan haben?
Die meiste Prozessdokumentation hält Reihenfolge fest — das ist der günstige Teil. Der teure Teil ist Urteil: die kleine Menge an Entscheidungen, bei denen ein erfahrener Mensch anders wählt als ein Anfänger und bei denen falsches Wählen teuer ist.
Schreib für jeden dieser Entscheidungspunkte vier Dinge auf: Was löst die Entscheidung aus, welche Informationen brauchst du dafür, wie lautet die Regel inklusive ihrer Schwellwerte, und was passiert in der Ausnahme. Die Regel ist das Stück, das Experten selten von sich aus liefern und das Anfänger am dringendsten brauchen. "Hochwertige Schäden eskalieren" ist keine Regel. "Über 25.000 Euro eskalieren, oder über 10.000, wenn beim Kunden eine offene Beschwerde vorliegt" ist eine. Eine Regel mit einer Zahl ist prüfbar, lehrbar und korrigierbar. Ein Prinzip ohne Zahl ist eine Vorliebe.
Rechne damit, Uneinigkeit zu entdecken — und behandle das als den eigentlichen Nutzen, nicht als Hindernis. Wenn zwei erfahrene Personen ihre Schwellwerte laut aussprechen, weichen sie häufig ab. Das heißt: Der Prozess lief bisher auf zwei Regeln, und niemand wusste davon. Das aufzulösen ist für sich schon eine Verbesserung, unabhängig von jedem Dokument.
Frag dich: Kannst du für die drei schwierigsten Entscheidungen in deinem Prozess die Regel mit einer Zahl darin formulieren?
Wissen, das abseits der Arbeit liegt, muss erinnert werden, um genutzt zu werden — und unter Zeitdruck wird es das nicht. Eine Wiki-Seite ist eine Referenz. Was Leute im Moment des Entscheidens brauchen, ist ein Hinweis.
Ziel also: das kleinste Artefakt, das in den Ablauf passt. Eine vierzeilige Checkliste im Ticket-Template. Ein Tooltip an dem Feld, an dem geurteilt wird. Ein Pflichteintrag, der fragt, welche Regel angewandt wurde. Ein einseitiger Entscheidungsleitfaden, angepinnt im Team-Channel. Wenn sich dein erfasstes Wissen nicht auf etwas reduzieren lässt, das am Ort der Nutzung auf einen Screen passt, ist es noch nicht fertig — lange Dokumente sind meist ein Zeichen dafür, dass Entscheidungen und Hintergrund nicht getrennt wurden.
Das verändert auch die Pflegefrage. Dokumentation, die im Tool lebt, wird korrigiert, wenn sie falsch ist — weil das Falschsein für die arbeitende Person sofort sichtbar ist. Ein Handbuch kann jahrelang falsch sein, ohne dass es jemand merkt. Genau das Muster haben wir in der Ausgabe über Prozesse, die nur auf dem Papier existieren, beschrieben.
Frag dich: Steht im Moment der Entscheidung die Orientierung auf dem Bildschirm — oder in einem System, das man erst suchen müsste?
Explizites Wissen verfällt. Regeln ändern sich, Schwellwerte verschieben sich, Systeme werden ersetzt — und eine Beschreibung, die 18 Monate alt ist, wird zu Recht als unzuverlässig behandelt. Damit gehen alle wieder zum Experten fragen. Die Lösung ist kein jährlicher Review-Zyklus, sondern ein Trigger, der an der Arbeit selbst hängt.
Der wirksamste Trigger ist die Ausnahme. Immer wenn ein Fall außerhalb der dokumentierten Regel bearbeitet wird, ist das per Definition neue Information: Entweder ist die Regel falsch, oder die Ausnahme gehört hinein. Mach in diesem Moment eine einzeilige Notiz zur Pflicht — was wurde entschieden und warum — und gib einer Person die stehende Aufgabe, diese Notizen alle paar Wochen in die Regel einzuarbeiten. Das sind fünfzehn Minuten Arbeit, und es hält das Wissen auf dem einzigen Weg aktuell, der skaliert.
Zwei unterstützende Gewohnheiten machen es haltbar. Gib jeder dokumentierten Entscheidung einen namentlichen Owner statt eines Teams, damit Korrektur eine Adresse hat. Und nutze neue Kollegen als Test: Alles, was eine neue Kollegin nach dem Lesen des Vorhandenen noch fragen muss, ist der Teil, der noch nicht explizit ist. Ihre Fragen sind das ehrlichste Audit deines Prozesswissens — und es ist kostenlos.
Frag dich: Wenn jemand einen Fall außerhalb der Regel bearbeitet — erreicht diese Tatsache den dokumentierten Prozess oder nur die Person, die entschieden hat?
Wenn dein erfahrenster Kollege einen Monat ausfiele: Welche Entscheidungen würden stocken — und was würden die Leute stattdessen tun?
Welche Frage beantwortet dein Team intern am häufigsten, und warum ist sie nie Teil des Prozesses geworden?
Wie viele deiner dokumentierten Prozessregeln enthalten tatsächlich eine Zahl?
Wo lebt deine Prozess-Orientierung, und wann hat sie zuletzt jemand korrigiert, weil sie falsch war?
Was fragt dein neuester Kollege immer noch — und was sagt das darüber, welches Wissen noch implizit ist?
Implizites Wissen ist keine Dokumentationslücke, die man mit Volumen füllt. Es ist eine Menge von Urteilen, die wenige treffen können und die meisten nicht — und es wird genau dann zum Geschäftsrisiko, wenn ein Prozess von diesen Urteilen abhängt, ohne es zu sagen. Die Überführung ist engere Arbeit, als sie aussieht: Finde, wo die Abhängigkeit teuer ist, beobachte echte Fälle statt Beschreibungen zu erfragen, schreib die Entscheidungen und ihre Schwellwerte auf statt der Schritte, bring das Ergebnis dorthin, wo gearbeitet wird, und lass jede Ausnahme die Regel aktualisieren. So gemacht, ist das Ergebnis kein Handbuch — sondern ein Prozess, den ein kompetenter Neuling fahren kann.
Ein konkreter Startpunkt: Nimm die letzten zehn internen Fragen, die dein Team per Mail oder Chat beantwortet hat, und prüfe, welche davon eine geschriebene Regel beantwortet hätte. Diese Liste ist dein Dokumentations-Backlog, sortiert nach echter Nachfrage — und sie kostet meist einen Nachmittag statt eines Projekts.
Das Urteil, das erfahrene Menschen anwenden, ohne dass es aufgeschrieben ist: welche Fälle Ausnahmen sind, welche Schwellwerte eine Eskalation auslösen, welche Daten unzuverlässig sind und was man stattdessen prüft. Das ist normal und unvermeidbar — zum Risiko wird es, wenn ein Prozess davon abhängt und die Organisation es nicht bemerkt hat.
Weil sie den Idealprozess aus Workshops beschreiben statt den echten aus Fällen, weil sie Schritte festhalten statt der Entscheidungen, die Erfahrung brauchen, und weil sie das Ergebnis abseits der Arbeit lagern, wo es erinnert werden müsste. Das Resultat ist ein Dokument, das existiert und nicht gelesen wird.
Über Exposure. Such nach Einzelpersonen-Abhängigkeiten, wiederkehrenden internen Fragen und Fällen desselben Typs, deren Dauer vom Bearbeiter abhängt. Diese drei Signale zeigen, wo undokumentiertes Urteil heute Zeit, Geld oder Risiko kostet — und sie verweisen auf einen kleinen Bereich, den man richtig machen kann, statt auf eine flächige Erhebung.
Es zeigt, was tatsächlich passiert: wie viele Varianten existieren, welche Schritte übersprungen werden, wo Fälle zurücklaufen und welche Segmente sich anders verhalten. Eine Variante, die konsistent wiederkehrt, ist fast immer eine undokumentierte Regel. Die Daten lokalisieren sie, die Beobachtung echter Fälle erklärt sie — deutlich schneller, als Menschen über ihren Prozess zu interviewen.
Häng die Aktualisierung an die Arbeit statt an einen Review-Zyklus. Mach eine einzeilige Notiz zur Pflicht, wann immer ein Fall außerhalb der dokumentierten Regel bearbeitet wird, und gib einer namentlich benannten Person die stehende Aufgabe, diese Notizen alle paar Wochen einzuarbeiten. Die Fragen neuer Kollegen sind das günstigste Audit dafür, ob das Ergebnis noch vollständig ist.