Das Schlüsselpersonen - Risiko in gewachsener Individualsoftware

Wenn das wichtigste System nur in einem Kopf dokumentiert ist

Viele Individualanwendungen sind nicht deshalb riskant, weil sie technisch schlecht wären. Das größere Problem ist häufig, dass entscheidendes Wissen über Jahre bei einer einzigen Person entstanden ist. Sie kennt Sonderfälle, Tabellen, Schnittstellen, Kundenanforderungen und die Gründe für scheinbar merkwürdige Programmstellen. Fällt diese Person länger aus oder verlässt das Unternehmen, wird aus einem Personalthema plötzlich ein Betriebsrisiko.

Wie Schlüsselpersonen - Risiko entsteht

Gewachsene Software verändert sich selten nach einem langfristigen Architekturplan. Ein Kunde benötigt eine Ausnahme, eine Maschine bekommt eine neue Schnittstelle, eine Auswertung wird ergänzt, ein alter Prozess bleibt aus Kompatibilitätsgründen bestehen. Der Entwickler löst diese Aufgaben – und sammelt dabei Wissen, das im Quellcode allein nicht sichtbar ist.

Über Jahre entsteht so eine zweite, unsichtbare Dokumentation im Kopf des Wissensträgers. Das funktioniert erstaunlich lange. Kritisch wird es erst, wenn jemand anderes übernehmen muss.

Typische Warnzeichen

Ein Unternehmen sollte aufmerksam werden, wenn nur eine Person produktive Releases erzeugen kann, Passwörter oder Lizenzinformationen nicht zentral dokumentiert sind, Datenbankänderungen „aus Erfahrung“ erfolgen, Schnittstellen ohne Beschreibung existieren oder Supportfälle regelmäßig bei derselben Person landen.

Ein weiteres Signal ist die Aussage: „Das kann nur Herr X.“ Sie klingt im Alltag oft nach besonderer Kompetenz. Aus Risikosicht bedeutet sie jedoch, dass ein geschäftskritischer Prozess nicht ausreichend organisatorisch abgesichert ist.

Eine Übergabe ist mehr als Quellcode kopieren

Ein ZIP-Archiv mit Quellcode ist keine belastbare Übergabe. Für eine übernehmbare Anwendung müssen mindestens Quellcode, Versionsstand, Build-Anleitung, externe Komponenten, Datenbankstruktur, Konfiguration, Deployment, Schnittstellen und betriebliche Besonderheiten nachvollziehbar sein.

Besonders wertvoll ist eine sogenannte „Cold Start“-Probe: Kann ein technisch versierter Dritter mit der vorhandenen Dokumentation auf einem vorbereiteten Rechner einen Build erzeugen und die Anwendung in einer Testumgebung starten? Wo das nicht gelingt, wird sichtbar, welches Wissen noch fehlt.

Wissen systematisch aus dem Kopf holen

Wissenstransfer sollte nicht als monatelanges Dokumentationsprojekt beginnen. Effektiver ist es, die geschäftskritischen Bereiche zuerst zu identifizieren. Dazu gehören Start und Build der Anwendung, Datenbank und Backup, zentrale Schnittstellen, Deployment, wiederkehrende Störungen und die wichtigsten fachlichen Sonderfälle.

Interviews mit dem Wissensträger lassen sich mit konkreten technischen Artefakten verbinden: Architekturübersicht, Datei- und Projektstruktur, Datenbankdiagramm, Schnittstellenliste, Deployment-Checkliste und eine Liste bekannter Risiken. Damit entsteht schrittweise eine Dokumentation, die im Alltag tatsächlich benutzt werden kann.

Versionsverwaltung als organisatorische Absicherung

Auch bei VB5-, VB6- oder älteren .NET-Projekten sollte der Quellcode in einer Versionsverwaltung liegen. Git ersetzt keine fachliche Dokumentation, schafft aber eine eindeutige Quelle für den aktuellen Stand und macht Änderungen nachvollziehbar. Wichtig ist, nicht nur Quelltext, sondern auch notwendige Projektdateien, Skripte und Hinweise zur Build-Umgebung kontrolliert zu sichern.

Vertretbarkeit herstellen

Das Ziel muss nicht sein, dass drei Entwickler jedes Detail kennen. Entscheidend ist, dass eine zweite Person das System starten, bauen, deployen und typische Störungen analysieren kann. Für besonders kritische Bereiche sollte zusätzlich klar sein, welcher externe Spezialist im Notfall unterstützen könnte.

So wird aus persönlichem Erfahrungswissen ein organisatorisch abgesichertes System. Der ursprüngliche Entwickler bleibt wertvoll – aber das Unternehmen ist nicht mehr vollständig von seiner Verfügbarkeit abhängig.

Fazit

Schlüsselpersonen-Risiko ist bei Legacy-Software kein theoretisches Problem. Es lässt sich jedoch sehr konkret reduzieren: Bestand erfassen, Build reproduzierbar machen, Abhängigkeiten dokumentieren, Quellcode versionieren und eine echte Vertretbarkeit herstellen.

Eine unabhängige Bestandsaufnahme hilft besonders dann, wenn intern schwer einzuschätzen ist, welches Wissen wirklich kritisch ist. Sie trennt unverzichtbares Betriebswissen von Details und schafft einen realistischen Übergabeplan.