Wissensinseln in der Software: Wenn nur eine Person das Programm versteht

Wissensinseln in der Software entstehen, wenn das Verständnis eines Programms, seiner Regeln oder seines Betriebs bei einer einzigen Person liegt. Solange diese Person da ist, fällt das kaum auf. Fällt sie aus, wechselt sie die Stelle oder geht sie in den Ruhestand, steht der Betrieb vor einer Lösung, die läuft, die aber niemand mehr ändern kann.

Was sind Wissensinseln in der Software?

Der Begriff beschreibt einen Zustand, kein Versagen einzelner Menschen. Wissen sammelt sich dort, wo jemand über lange Zeit allein an einer Sache arbeitet, und niemand hat Anlass, es aufzuschreiben, weil die Person ja jederzeit gefragt werden kann. In mittelständischen Betrieben betrifft das besonders oft selbst gebaute Lösungen: eine Access-Datenbank, eine Excel-Mappe mit Makros, ein Programm, das ein früherer Mitarbeiter oder ein externer Betreuer geschrieben hat.

Das Wissen hat dabei mehrere Schichten: was die Lösung fachlich tut, warum bestimmte Regeln so und nicht anders gebaut sind, wie sie technisch zusammenhängt und wie man sie betreibt, sichert und nach einem Fehler wieder zum Laufen bringt. Den Nutzern ist oft nur die erste Schicht bekannt.

Wie groß das Risiko ist, hängt weniger von der Größe der Lösung ab als von ihrer Rolle. Eine kleine Mappe, über die jeden Monat die Lohnabrechnung vorbereitet wird, ist kritischer als ein umfangreiches Programm, das nur gelegentlich Auswertungen liefert. Die erste Frage lautet deshalb nicht, wie komplex eine Lösung ist, sondern was im Betrieb stillsteht, wenn sie einen Tag lang niemand bedienen oder reparieren kann.

Der Bus-Faktor: eine unbequeme Frage

In der Softwareentwicklung gibt es dafür eine drastische Kennzahl, den sogenannten Bus-Faktor. Er fragt, wie viele Personen ausfallen müssten, bis ein Vorhaben nicht mehr weitergeführt werden kann. Bei vielen Eigenlösungen lautet die ehrliche Antwort: eine einzige. Die Frage klingt makaber, ist aber nüchtern gemeint, denn Urlaub, Krankheit, Kündigung und Ruhestand sind keine Ausnahmen, sondern Ereignisse, die mit Sicherheit eintreten.

Wie Wissensinseln entstehen

• Gewachsene Lösungen. Was als kleine Hilfe begann, wurde über Jahre erweitert, ohne dass jemand den Überblick festhielt.
• Kein Anlass zur Dokumentation. Solange die Lösung funktioniert und ihr Autor greifbar ist, erscheint Aufschreiben als Zeitverschwendung.
• Keine zweite Person. Änderungen macht immer dieselbe Person, niemand prüft oder liest mit.
• Wissen im Code statt über den Code. Regeln stehen in Abfragen und Makros, aber nirgends in Worten.

Warnzeichen im Betrieb

Einige Sätze deuten zuverlässig auf das Problem hin: „Das muss ich erst mit ihr klären.“ „Da traut sich keiner ran.“ „Das hat er damals so eingerichtet.“ Ebenso aussagekräftig ist, wenn Änderungen an der Lösung nur außerhalb des Tagesgeschäfts gewagt werden oder wenn die Urlaube der betreffenden Person mit Blick auf Monatsabschlüsse geplant werden. Spätestens wenn ein Ausscheiden absehbar ist, wird aus einem Komfortproblem ein Betriebsrisiko. Ein weiteres Zeichen: Es gibt keine Kopie der Lösung, auf der gefahrlos ausprobiert werden kann, und keine Beschreibung, wie sie nach einem Rechnerwechsel wieder eingerichtet wird.

Wissen aus dem Kopf holen: Dokumentation, Prüffälle, Code

Ein Übergabegespräch allein reicht selten, weil vieles erst beim Arbeiten an der Lösung wieder einfällt. Wirksamer sind drei Schritte, die sich ergänzen. Erstens wird die Lösung auf einer Kopie gelesen, und ihre Regeln werden in einer Liste mit Beispielen festgehalten, die die bisherige Person bestätigt. Zweitens werden diese Regeln zu automatischen Prüffällen, die bei jeder Änderung laufen, sodass Wissen nicht nur beschrieben, sondern geprüft wird. Drittens liegt der Code in einem Repository des Betriebs, mit nachvollziehbarer Historie jeder Änderung.

Wird die Lösung später ersetzt, dient genau diese Liste als Grundlage der Leistungsbeschreibung. Wie sich Regeln in Tabellenblättern verstecken, zeigt der Artikel Excel als Datenbank.

Wie wir Wissen aus einer Eigenlösung sichern

Bevor wir an einer Eigenlösung etwas ändern, lesen wir sie aus und halten ihre Regeln mit Beispielen fest, am besten gemeinsam mit der Person, die sie bisher betreut. Aus der Regelliste entstehen Prüffälle, Dokumentation und Datenmodell. Repository und Zugänge liegen beim Betrieb, jede Änderung prüfen zuerst unsere KI-Werkzeuge und danach ein Entwickler, und fällt bei uns jemand aus, übernimmt das Team, sodass keine neue Insel entsteht. Den Ablauf beschreibt die Seite Softwareentwicklung.