Key-Person-Risiko: Wenn das Systemwissen an einer Person hängt

Ein Key-Person-Risiko in der IT entsteht leise. Ein Systemausfall lässt sich meist reparieren, schwerer wiegt es, wenn nur eine einzige Person weiß, wie das System überhaupt funktioniert. Sichtbar wird es erst, wenn diese eine Person krank wird, kündigt oder schlicht im Urlaub nicht erreichbar ist, und dann steht ein Bereich still, den vorher niemand als gefährdet eingeschätzt hätte.

Wie ein Key-Person-Risiko in der IT entsteht

Der Bus-Faktor ist eine einfache, aber wirkungsvolle Kennzahl. Er beschreibt, wie viele Personen ausfallen müssten, damit ein Bereich im Unternehmen stillsteht. Je kleiner diese Zahl, desto verletzlicher ist die Organisation gegenüber Krankheit, Kündigung oder schlicht einem verlängerten Urlaub.

Wissensmonopole reichen dabei über Zugangsdaten weit hinaus. Sie umfassen Konfigurationen, Systemabhängigkeiten und über Jahre gewachsene, undokumentierte Umgehungslösungen, die eine einzelne Person irgendwann selbst kaum noch vollständig erklären kann, wie SAC beschreibt (SAC, 2026). Wer glaubt, mit einem Passwort-Tresor sei das Problem gelöst, unterschätzt, wie viel Wissen tatsächlich nur im Kopf einer Person existiert.

Der Fachkräftemangel verschärft diese Lage zusätzlich. Nach Bitkom fehlen in Deutschland rund 109.000 IT-Fachkräfte, eine Nachbesetzung dauert entsprechend lange (Bitkom, 2025). Wer eine Schlüsselperson verliert, kann selten kurzfristig jemanden mit vergleichbarem Wissen einstellen, selbst wenn das Budget dafür bereitsteht.

Wo das Risiko in der Praxis am größten ist

Am häufigsten trifft ein Key-Person-Risiko in der IT auf drei Konstellationen. Die erste ist die eine Person, die ein zentrales System vor Jahren allein aufgebaut hat und seitdem als Einzige jede Ecke davon kennt. Die zweite ist die kleine IT-Abteilung, in der aus Kostengründen nie eine echte Vertretung eingeplant wurde. Die dritte ist ein extern eingekauftes System, dessen Wissen komplett bei einer einzelnen Ansprechperson im eigenen Haus liegt, während der ursprüngliche Dienstleister längst gewechselt hat.

In Projekten, die wir übernehmen, zeigt sich ein wiederkehrendes Muster. Gerade die zuverlässigsten Mitarbeitenden werden am seltensten vertreten, weil sie Probleme meist selbst lösen, bevor jemand anderes überhaupt bemerkt, dass es eines gab. Genau diese Zuverlässigkeit verschleiert das Risiko, bis die Person tatsächlich ausfällt und niemand weiß, wo er ansetzen soll.

Wirtschaftlich betrachtet ist das Risiko selten Teil einer Kalkulation. Ein Ausfall in der Produktion oder Logistik wird schnell in Euro pro Stunde beziffert, ein tagelanger Stillstand eines internen Systems, für das niemand sonst zuständig ist, taucht in keiner Risikoliste auf, bis er tatsächlich eintritt. Besonders deutlich wird das in den ersten Wochen nach einer Übernahme, wenn plötzlich ein fremdes Team auf gewachsene Systeme angewiesen ist. Wie sich diese Phase organisieren lässt, beschreibt der Beitrag Post-Merger-IT-Integration: Die ersten 100 Tage.

Welche Gegenmaßnahmen den Bus-Faktor erhöhen

Eine geregelte Zugangsverwaltung ist der einfachste Schritt und zugleich der am häufigsten vernachlässigte. Zugänge gehören auf Rollen statt auf Personen, damit ein Ausscheiden keine Systeme unerreichbar macht und niemand nachträglich raten muss, welches Passwort wo noch gilt.

Betriebsdokumentation ist der aufwendigere, aber wirksamere Hebel. Sie muss nicht jede Codezeile erklären, aber die Architektur, die wichtigsten Abhängigkeiten und die bekannten Umgehungslösungen festhalten, an die sich sonst nur eine Person erinnert.

Pair-Arbeit verteilt Wissen im laufenden Betrieb, ohne einen separaten Dokumentationstermin zu brauchen. Zwei Personen, die gemeinsam an einem System arbeiten, bauen automatisch ein zweites Verständnis auf, selbst wenn keiner der beiden das als Wissenstransfer geplant hatte.

Ein Notfallhandbuch beantwortet die Frage, was in den ersten Stunden eines Ausfalls zu tun ist, wenn genau die Person fehlt, die es sonst beantworten würde. Eine externe Zweitmeinung, ähnlich wie bei einer technischen Due Diligence vor einer Übernahme, prüft von außen, ob diese Maßnahmen tatsächlich greifen oder ob sich das Wissensmonopol nur auf dem Papier aufgelöst hat.

Häufige Fragen

Wie erkennt man den eigenen Bus-Faktor?

Eine einfache Übung hilft weiter, für jedes wichtige System die Frage zu stellen, wer es außer der aktuell zuständigen Person noch bedienen könnte, ohne tagelang recherchieren zu müssen. Bleibt die Antwort bei einem einzigen Namen hängen, liegt der Bus-Faktor bei eins. Diese Übung lässt sich für jedes kritische System einzeln wiederholen, die Ergebnisse unterscheiden sich oft deutlich. Wer die Übung nüchtern durchführt statt die Lage schönzureden, findet meist mehr als ein System mit diesem Muster.

Wie dokumentiert man, ohne den Betrieb zu lähmen?

Kleine, feste Zeitfenster funktionieren besser als ein einmaliges großes Dokumentationsprojekt, das neben dem Tagesgeschäft selten fertig wird. Eine Stunde pro Woche, konsequent für die kritischsten Systeme genutzt, bringt über einige Monate mehr als ein ambitionierter Anlauf, der nach zwei Wochen wieder einschläft. Sinnvoll ist außerdem, mit dem System zu beginnen, dessen Ausfall am teuersten wäre, nicht mit dem, das am einfachsten zu dokumentieren ist.

Was tun, wenn die Person kündigt?

Die Kündigungsfrist wird zur wichtigsten Ressource, sie gehört von Anfang an für Wissenstransfer reserviert statt allein für die Übergabe laufender Aufgaben. Feste Sitzungen mit dem restlichen Team, eine schriftliche Zusammenfassung der wichtigsten Zusammenhänge und ein Testlauf, bei dem jemand anderes eine typische Aufgabe ohne Hilfe löst, zeigen, ob der Transfer tatsächlich funktioniert hat. Ist die Frist kurz, hilft es, den Transfer auf die zwei oder drei Systeme zu beschränken, deren Ausfall am teuersten wäre, statt alles gleichmäßig abzuarbeiten.

Ein Key-Person-Risiko in der IT betrifft selten nur die IT-Abteilung, es reicht bis in Produktion, Logistik und Kundenservice hinein. Es lässt sich selten von innen zuverlässig einschätzen, wer selbst das Wissensmonopol hält, sieht die eigene Lücke oft nicht. torck bringt eigene Entwicklungsteams aus Maxhütte-Haidhof, Wien und Rabat mit, die Wissen im laufenden Betrieb aktiv aufbauen und dokumentieren, statt nur eine Checkliste zu übergeben. Vertragspartner ist die deutsche torck GmbH. Wer den eigenen Bus-Faktor einschätzen lassen will, kann das in einem Erstgespräch besprechen.

Gespräch vereinbaren