Wenn nur noch einer weiß, wie es läuft: Eigenbau-Software als stiller Single Point of Failure

In vielen deutschen Mittelständlern existiert eine Anwendung, die nirgends gekauft wurde: eine Auftragsabwicklung, eine Kalkulationsmaske, ein Lagersystem, das vor zehn oder fünfzehn Jahren von einem beauftragten Dienstleister oder einem ehemaligen Mitarbeiter gebaut wurde. Sie funktioniert – bis heute. Genau darin liegt das Problem. Denn Funktionsfähigkeit ist nicht dasselbe wie Tragfähigkeit.

Das stille Risiko im Betrieb

Eigenentwicklungen geraten selten durch einen dramatischen Ausfall in die Aufmerksamkeit der Geschäftsführung. Sie kündigen sich an: durch kleine Umgehungslösungen, eine Excel-Datei am Rand, einen Kollegen, der bei jeder Änderung 'kurz den Herrn Schulze' fragt. Wenn dieser eine Wissens­träger in Rente geht oder das Unternehmen verlässt, bleibt eine Blackbox zurück – rechtlich, technisch und organisatorisch.

Hinzu kommt die Frage der Urheberrechte. Wer hat den Quellcode beauftragt und bezahlt? Liegen die Nutzungsrechte beim Unternehmen, oder hat der freiberufliche Entwickler seinerzeit nur eine Lizenz eingeräumt? Viele Firmen können diese Frage nach Jahren nicht mehr beantworten. Ein Blick in die alten Werkverträge ist daher der erste Schritt jeder Bestandsaufnahme.

Vier Prüffragen zur Zustandsanalyse

Bevor über Modernisierung oder Ersatz entschieden wird, empfiehlt sich eine nüchterne Bewertung. Vier Fragen liefern ein belastbares Bild:

1. Existiert der Quellcode – und gehört er dem Unternehmen? Ohne dokumentierten, rechtlich gesicherten Code ist jede Weiterentwicklung Verhandlungssache mit Dritten.

2. Können externe Dritte den Code verstehen? Eine Eigenentwicklung ist nicht automatisch unverständlich. Sauber strukturierter, kommentierter Code lässt sich auch durch eine neue Dienstleisterschaft übernehmen. Spaghetticode mit kryptischen Variablennamen ist etwas anderes.

3. Welche Abhängigkeiten bestehen? Läuft die Anwendung auf einer veralteten Datenbank, einem alten Windows-Server oder einer Programmiersprache, für die es keine aktiven Laufzeitumgebungen mehr gibt? Sicherheitupdates sind dann nur noch eingeschränkt möglich – ein Thema, das spätestens im Kontext von NIS2 und der BSI-Vorgaben auch juristisch relevant wird.

4. Wie groß ist der Wissens­träger-Faktor? Gibt es eine Person, ohne deren Hintergrundwissen der Betrieb kippt? Wenn ja, ist Zeit der knappste Rohstoff.

Szenario eins: Kontrollierte Weiterentwicklung

Nicht jede Eigenentwicklung muss ersetzt werden. Wenn der Code dokumentierbar ist, die Fachlichkeit stimmt und das Tool einen echten Wettbewerbsvorteil darstellt, kann eine gezielte Aufwertung sinnvoll sein: Dokumentation nachtragen, Tests aufbauen, kritische Schnittstellen modernisieren, den Betrieb auf eine tragfähige Infrastruktur heben. Der Aufwand ist oft geringer als eine Neubeschaffung – vorausgesetzt, das Unternehmen akzeptiert, dass Dokumentation und Wissenssicherung laufende Aufgaben sind, kein einmaliges Projekt.

Szenario zwei: Definierter Ersatz

Wenn Fachlichkeit und Technik auseinanderlaufen – etwa weil das Tool die Auftragsabwicklung abbildet, die Prozesse sich aber längst verändert haben –, ist ein Standardprodukt oder eine modulare Lösung häufig wirtschaftlicher. Entscheidend ist die saubere Auswertung: Welche Funktionen werden tatsächlich genutzt, welche sind still gestorben? Wer ein Eigenbau-Tool ersetzt, sollte nur das nachbilden, was den Betrieb trägt, nicht jede historische Sonderlösung.

Szenario drei: Geordnete Stilllegung

Manchmal ist die ehrlichste Antwort die Abschaltung. Für kleinere Insellösungen kann eine funktionsfähige Übergangslösung – etwa ein konfigurierbares Standardwerkzeug statt maßgeschneiderter Software – ausreichen. Wichtig ist der kontrollierte Übergang: Datenarchivierung nach GoBD-Anforderungen, Übergangsfristen für die Anwender, eine dokumentierte Abschaltentscheidung der Geschäftsführung. Was stillgelegt wird, muss protokolliert sein – auch für mögliche Auskünfte an Steuerprüfung oder Wirtschaftsprüfer.

Fazit: Der Zustand ist ein Führungsthema, kein IT-Detail

Eigenbau-Software ist neither per se schlecht noch per se gefährlich. Gefährlich ist der unbewusste Zustand: ein geschäftskritisches System ohne Dokumentation, ohne Nutzungsrechtsklärung und ohne zweiten Wissens­träger. Ein strukturierter Blick – Vertragslage, Codequalität, Abhängigkeiten, Personenrisiko – kostet wenige Beratungstage und schafft die Grundlage für eine rationale Entscheidung. Weiterentwickeln, ersetzen oder stilllegen: Alle drei Wege sind legitim. Nur der vierte Weg – nichts tun und auf den Ausfall hoffen – ist es nicht.