Es gibt in fast jedem Mittelständler einen Bernd. Bei Ihnen heißt er vielleicht anders: Petra, Uwe, Sabine. Aber die Funktion ist immer dieselbe: der Mensch, der als Einziger weiß, warum die Schnittstelle zur Waage nur nachts läuft. Warum der Auftragsdruck bei einem bestimmten Kunden anders ist als bei allen anderen. Und welchen Haken man im System niemals, wirklich niemals setzen darf.

Kein Handbuch. Keine Doku. Nur ein Kopf.

Solange Bernd da ist, läuft alles. Und genau deshalb taucht er auf keiner Risikoliste auf. Ein Risiko, das sich nicht bemerkbar macht, wird nicht gemanagt. Es wird einfach übersehen, Jahr für Jahr, bis der Tag kommt, an dem Bernd nicht mehr da ist.

Der teuerste Tag ist nicht der erste

Ich habe darüber vor Kurzem auf LinkedIn geschrieben. Die Reaktionen haben mir nur bestätigt, was ich aus eigenen Projekten längst kenne. Ein Leser schilderte ein Unternehmen mit gut 100 Millionen Euro Umsatz, bei dem die komplette Auftragsannahme an einem einzigen Kopf hing. Nicht an einem System. An einem Menschen. Erst als dieser Mensch ging, wurde aus dem Abschied ein Aufräumen: Automatisierung, Dokumentation, alles das, was man auch vorher hätte machen können.

Das ist der Kern des Problems: Der erste Nachmittag, an dem man aufschreibt, was nur eine Person weiß, kostet fast nichts. Der letzte Arbeitstag dieser Person kostet ein Vermögen — an Nacharbeit, an Fehlern, die niemand mehr erklären kann, an Wochen im Blindflug. Jedes Risiko trägt ein Datum. Man kennt es nur meistens nicht, bis es zu spät ist, danach zu fragen.

Warum das an der Technik vorbeigeht

Wenn ich mit Geschäftsführern über ERP- oder CRM-Projekte spreche, kreist das Gespräch fast immer um Systeme, Anbieter, Kosten. Das Wissensträger-Risiko taucht selten von allein auf — dabei ist es oft der eigentliche Grund, warum ein Systemwechsel überhaupt so schwierig wird. Nicht weil die neue Software schlechter ist als die alte, sondern weil das alte System über Jahre um die Eigenheiten eines einzigen Kopfes herumgewachsen ist. Der Kopf kennt jede Abkürzung, jeden Workaround, jede stille Regel. Die Software allein kennt keine davon.

Das heißt: Ein Systemwechsel ist nicht nur ein IT-Projekt. Er ist die letzte gute Gelegenheit, Kopf-Wissen in dokumentierte Prozesse zu übersetzen — statt es unbemerkt in ein neues System mitzuschleppen oder, schlimmer, es beim Wechsel ganz zu verlieren. Wie eine Auswahl aus den eigenen Prozessen heraus funktioniert, habe ich an anderer Stelle aufgeschrieben.

Was tatsächlich hilft

Der erste Schritt kostet, wie gesagt, einen Nachmittag: eine ehrliche Liste. Was weiß bei uns nur eine einzige Person? Nicht, was steht dokumentiert — sondern was steckt nur in einem Kopf. Diese Liste ist unbequem, weil sie meistens länger ausfällt, als man dachte. Aber alles, was darauf steht, ist ab sofort ein Risiko mit Datum statt ein Risiko ohne Namen.

Danach wird es konkret:

  • Nachfolge früh genug einplanen. Nicht erst, wenn die Kündigung auf dem Tisch liegt, sondern mit bewusst bezahlter Überlappung. Zwei Jahre vor einer absehbaren Rente ist keine Übertreibung, sondern der Unterschied zwischen Übergabe und Ausfall.
  • Individuallösungen, die nur eine Person versteht, gezielt ablösen. Gerade dann, wenn ohnehin ein Systemwechsel ansteht.
  • Die Abhängigkeit nicht nur bei Mitarbeitenden prüfen, sondern genauso bei einzelnen Dienstleistern. Ein externer Bernd ist genauso ein Risiko wie ein interner.

Wie man die Lücken überhaupt findet

Das Schwierige an der Liste ist nicht das Aufschreiben. Es ist, überhaupt zu merken, wo eine Lücke ist — weil einem im Alltag ja nichts fehlt. Bernd ist da, es läuft.

Der einfachste Weg, das zu knacken: eine Frage stellen, keine Inventur machen. „Was würde passieren, wenn du morgen zwei Wochen krank wärst?" Diese Frage an jeden stellen, der irgendwo eine Schnittstelle, eine Ausnahme oder einen Sonderfall im Kopf hat. Die Antwort verrät sofort, wo es klemmt. Meistens kommt zögerlich ein „Na ja, dann müsste jemand erstmal rausfinden, wie…"

Genau an diesem Punkt fängt Dokumentation an. Nehmen wir die Waage-Schnittstelle aus dem Beispiel oben:

  • Erkennen: Die Frage „Was würde passieren, wenn du morgen krank wärst?" bringt raus: „Dann würde die Schnittstelle zur Waage tagsüber laufen und Fehlbuchungen produzieren — und keiner wüsste erstmal warum."
  • Definieren: Jetzt drei einfache Fragen an die Person stellen, die es weiß. Wann greift das (Auslöser)? Was macht man konkret (Schritte)? Und was ist die Ausnahme, die man nie vergessen darf? Bei der Waage: Auslöser ist der nächtliche Batch-Lauf, die Schritte sind die zwei, drei Klicks in der Steuerung, die Ausnahme ist ein bestimmter Kundenauftrag, bei dem es anders läuft.
  • Dokumentieren: Kein Handbuch, keine Prozesslandkarte — eine halbe Seite reicht. Auslöser, Schritte, Ausnahme, fertig. Wichtig ist nur, dass es an einem Ort liegt, den auch jemand anderes findet. Nicht in Bernds Kopf oder seiner privaten Notiz-App.

Diese drei Schritte — erkennen, definieren, dokumentieren — dauern pro Lücke vielleicht eine Stunde. Für die ganze Liste ein paar Tage, verteilt über ein paar Wochen. Das ist der Punkt, an dem aus einem vagen Bauchgefühl („wir sind da von Bernd abhängig") eine kurze Sammlung von Prozessen wird, die auch ohne ihn funktionieren.

Die eigentliche Frage

Das Unbequeme an diesem Thema ist, dass es sich nie dringend anfühlt — bis es zu spät ist. Es gibt keinen Alarm, der losgeht, wenn Wissen sich in einem einzigen Kopf konzentriert. Es läuft einfach. Bis es nicht mehr läuft.

Wenn Sie Ihre Liste haben und jemanden brauchen, der sie nüchtern gegen Ihre System- und Projektrealität hält: Genau dafür gibt es den Reality Check — drei Tage, ein ehrlicher Lagebericht, ohne Lizenzinteresse. Für den Anfang reicht ein Erstgespräch.

Deshalb ist die Frage nicht, ob Sie einen Bernd haben. Die Frage ist: Was weiß in Ihrem Unternehmen nur ein einziger Mensch — und was würde es kosten, wenn dieser Mensch morgen nicht mehr da wäre?