Clean Code

Digitalisierung

Development

Der Bus-Faktor in der Industrie: Wenn eine einzige Person zum Unternehmensrisiko werden kann

‍Wieso unternehmenskritische B2B-Software mehr braucht als nur guten Code – und wie Industrieunternehmen ihre Abhängigkeiten systematisch auflösen

Montag, 7:15 Uhr. Ein System zeigt nach einem Update einen kritischen Fehler. Aufträge lassen sich nicht mehr anlegen, die Fertigung wartet, der Zugriff zu wichtigen Dashboards ist nicht mehr verfügbar. Alle Blicke richten sich auf Thomas aus der IT – den Einzigen, der weiß, wie die Software konfiguriert ist. Aber Thomas ist krank. Oder im Urlaub. Oder hat letzten Monat gekündigt.

Was jetzt passiert, hat einen Namen: Bus-Faktor.

Plakativ formuliert ermittelt der Bus-Faktor, wie viele Menschen „von einem Bus überfahren werden müssten", damit ein Unternehmen in bestimmten Bereichen handlungsunfähig wird. Was makaber klingt, stellt eine reale Gefahr für Industrieunternehmen dar: Ruhen das Wissen über ERP-Schnittstellen, Produktionssoftware, Maschinenanbindungen oder zentrale Systemzugänge bei nur einer einzigen Person, stehen im schlimmsten Fall die Fertigungslinien still.

Die Frage ist nicht, ob dieser Moment kommt, sondern wann.

Inhalte:

Bevor wir tiefer einsteigen – lesen Sie die folgenden fünf Szenarien. Nicht alle. Nur die, bei denen Sie innerlich nicken:

‍Der stille Held: In Ihrem Unternehmen gibt es diese eine Person, die „einfach alles weiß". Software-Konfigurationen, historische Schnittstellenlogik zwischen Auftragsmanagement und Fertigung, Workarounds in der Maschinenanbindung, die nirgends dokumentiert sind. Alle wissen es. Niemand spricht es aus. Was passiert, wenn diese Person morgen kündigt?‍
Die gewachsene Komplexität: Über Jahre wurden Software Features ergänzt, das CRM angebunden, Produktionskonfiguratoren gebaut, Dokumentenmanagementsysteme integriert – ohne übergreifende Architektur. Heute versteht nur noch eine Handvoll Menschen, wie alles zusammenspielt. Jede Änderung fühlt sich an wie Operation am offenen Herzen. Also fasst niemand etwas an. Kennen Sie das Gefühl?‍
Der externe Retter: Ein ehemaliger Mitarbeiter oder externer Dienstleister wird immer wieder herangezogen, weil nur er bestimmte Systeme versteht – sei es die Schnittstelle zwischen ERP und Fertigung oder eine historisch gewachsene Individualsoftware. Sie zahlen Premium-Tagessätze für Wissen, das eigentlich in Ihrem Unternehmen liegen sollte. Und mit jedem Einsatz wächst die Abhängigkeit. Haben Sie schon einmal ausgerechnet, was Sie das pro Jahr kostet?‍
Das Kopfmonopol: Ein Automatisierungsingenieur oder IT-Leiter sitzt auf kritischem Wissen über die gesamte Systemlandschaft – und weiß das auch. Wissenstransfer? Wird immer wieder aufgeschoben. Dokumentation? „Mache ich, wenn Zeit ist." Die Zeit kommt nie. Und insgeheim weiß jeder: Wenn diese Person geht, haben wir ein Problem.‍
Die Wissensinsel: Fertigung arbeitet mit anderen Tools als der Vertrieb, das Lager hat eigene Prozesse, die Qualitätssicherung eigene Datenbanken. Wer das Gesamtbild versteht – wie ERP, CRM, Produktionssysteme und Dokumentenmanagement zusammenspielen – ist oft eine einzelne Person. Fällt sie aus, stehen nicht nur einzelne Prozesse still – es bricht die Brücke zwischen den Systemen weg.‍
Wie viele Szenarien haben Sie wiedererkannt? Wenn Sie bei mindestens einem genickt haben: Ihr Instinkt stimmt. Die meisten Industrieunternehmen, mit denen wir sprechen, erkennen sich in drei oder mehr dieser Szenarien wieder. Es ist eines der häufigsten und gleichzeitig am meisten unterschätzten Risiken in der industriellen Softwarelandschaft.

Und nachdem Sie diesen Artikel gelesen haben, werden Ihnen diese Abhängigkeiten in Ihrem Alltag auffallen – im Jour fixe, wenn wieder alle auf eine Person schauen. Im Projektmeeting, wenn es heißt „Das muss Thomas entscheiden". Im Flurgespräch, wenn jemand über den nächsten Rentenabgang spricht. Der Bus-Faktor ist überall – man muss nur einmal hinschauen.

Was ist der Bus-Faktor: Eine Definition

Der Begriff Bus-Faktor kommt aus dem Risikomanagement und schätzt Projektrisiken ein. Es geht darum, aufzuzeigen, wie viele Personen maximal ausfallen dürfen, um ein Unternehmen in einem bestimmten Bereich handlungsunfähig zu machen.

Je niedriger die Nummer, desto höher das Risiko. Ein Bus-Faktor von 1 ist die denkbar schlechteste Zahl – sie besagt, dass ein einzelnes Team-Mitglied entscheidend für den Erfolg eines Projektes, die Steuerung eines Systems oder die Bedienung einer unternehmenskritischen Software ist.

Gerade in der Industrie, wo Software direkt in Wertschöpfungsprozesse eingreift – von der Auftragsanlage über die Fertigungssteuerung bis zur Qualitätskontrolle – kann ein Bus-Faktor von 1 existenzbedrohend sein. Und trotzdem wird er in den meisten Unternehmen stillschweigend akzeptiert. Nicht, weil niemand das Risiko sieht. Sondern weil das Nicht-Handeln sich bequemer anfühlt als das Handeln. Solange nichts passiert.

„Könnte ein 82-jähriger Mitarbeiter ein Risiko darstellen?“

Was makaber oder auch sehr pessimistisch klingt, ist nicht selten der Fall, weiß Marcel Dambach, Team Lead Software Engineering bei generic.de. Seit über 25 Jahren unterstützt generic.de Industrieunternehmen bei der Entwicklung und Modernisierung unternehmenskritischer Software. Marcel ist in seiner Funktion regelmäßig bei Kunden vor Ort und analysiert unter anderem Verantwortlichkeiten, Systemlandschaften und Projektrisiken.

Er sagt: „Grundsätzlich ist es den meisten Kunden bewusst, dass einzelne Wissensträger, die zum Beispiel für eine wettbewerbsentscheidende Software zuständig sind, ein potenzielles Risiko darstellen. Sie müssen nicht gleich vom Bus überfahren werden. Es reicht schon, wenn sie das Unternehmen verlassen, etwa weil sie kündigen oder in Rente gehen.

‍

Marcel Dambach, Solution Architekt und Bus-Faktor Experte

Aber obwohl gerade der letztere Fall ein planbares Risiko darstellt, wird er im Berufsalltag gerne übersehen oder beiseitegeschoben. Mir ist das im Projekt schon begegnet: Es ging darum, eine sehr alte, aber fürs Unternehmen kritische Software zu überarbeiten. Auf die Frage, wo denn der Quellcode liegt, kam dann: ‚Ja, das ist ein Grund, wieso ihr da seid. Der Einzige, der sich mit der Software auskennt, ist unser ehemaliger Kollege. Der macht das noch so nebenbei, obwohl er schon 82 Jahre alt und seit 15 Jahren in Rente ist.' Da sind wir fast vom Stuhl gefallen.

"Was viele überrascht: Auch dieses Unternehmen wusste seit Jahren vom Risiko. Auch dort dachte man: „Das wird schon gutgehen." Solche Fälle begegnen uns in der Industrie regelmäßig. Historisch gewachsene Softwarelandschaften, bei denen Wissen über Produktionssysteme, ERP-Konfigurationen und Eigenentwicklungen über Jahrzehnte bei Einzelpersonen akkumuliert wurde. Das Problem ist nie, dass es niemand gesehen hat – sondern dass es immer weiter aufgeschoben wurde, weil der Tagesbetrieb Priorität hatte.

Was wurde aus dem 82-Jährigen? Das Unternehmen hat gehandelt – aber spät. Die Wiederherstellung des Wissens und die Modernisierung der Software dauerte Monate und kostete ein Vielfaches dessen, was eine rechtzeitige Planung gekostet hätte.

Kosten des Ausfalls: Wie teuer ist ein Krankentag?

Fällt diese eine Person aus, sprechen wir nicht über eine kleine Unannehmlichkeit. Aber die Kosten beginnen nicht erst beim Ausfall. Sie entstehen jetzt – jeden Tag, an dem das Risiko existiert:

‍Produktionsstopps und Fertigungsausfälle: Wenn der einzige Wissensträger für ein kritisches Produktionssystem ausfällt, stehen Fertigungslinien still. In der produzierenden Industrie kostet jede Stunde ungeplanter Stillstand schnell 10.000 bis 100.000 Euro – je nach Branche und Auftragslage deutlich mehr. Die OEE sinkt, Liefertermine geraten in Gefahr, Vertragsstrafen drohen. Stellen Sie sich vor, wie der Anruf bei Ihrem wichtigsten Kunden klingt: „Wir können diese Woche nicht liefern."‍
Wissensverlust, der nicht wiederherstellbar ist: Was nicht dokumentiert ist, ist mit dem Ausscheiden der Person unwiederbringlich verloren. Bei einem unserer Kunden im Maschinenbau lag die Onboarding-Zeit für einen Nachfolger bei 6 Monaten – weil das gesamte Wissen in einem einzigen Kopf steckte. Reverse Engineering von Individualsoftware, die über Jahre an spezifische Produktionsprozesse angepasst wurde, kostet ein Vielfaches der ursprünglichen Entwicklung. Bei einem Projekt, das einmal 200.000 Euro gekostet hat, sprechen wir schnell von 500.000 Euro oder mehr für die Wiederherstellung.‍
120 Stunden pro Monat – für nichts: Unternehmen mit gewachsenen Systemlandschaften verlieren durchschnittlich 120 Arbeitsstunden pro Monat durch Medienbrüche zwischen Systemen, die nicht miteinander kommunizieren. Das sind anderthalb Vollzeitstellen, die mit Doppeleingaben, manuellen Abgleichen und Workarounds beschäftigt sind. Was könnte Ihr Team mit dieser Zeit anfangen, wenn die Systeme endlich miteinander reden würden?‍
Innovationsstau: Teams, die von Einzelpersonen abhängen, innovieren langsamer. Digitalisierungsprojekte werden aufgeschoben, weil „erst geklärt werden muss, wie das Altsystem funktioniert". Modernisierung der On-Prem-Infrastruktur, KI-gestützte Prozessautomatisierung, Integration neuer Datenquellen – alles bleibt liegen. Und während Sie warten, machen Ihre Wettbewerber den nächsten Schritt.‍
Fehlende Verzahnung wird zum Blindflug: Wenn Wissensträger wegfallen, die als einzige verstehen, wie ERP, CRM, Produktionssysteme und Dokumentenmanagement zusammenspielen, entstehen Datensilos und Informationsverluste. Stellen Sie sich vor, Ihr Produktionsleiter trifft Entscheidungen auf Basis von Daten, die seit Wochen nicht mehr aktuell sind – ohne es zu wissen. Bestellungen werden doppelt angelegt, Lagerbestände stimmen nicht, Kundenanfragen können nicht nachvollzogen werden.‍
Teure Notfall-Lösungen: Wenn der Ernstfall eintritt, werden in Panik externe Spezialisten engagiert – zu Premium-Tarifen und unter Zeitdruck. Und oft entsteht durch den neuen Dienstleister gleich die nächste Abhängigkeit. Sie haben das Problem nicht gelöst – nur den Namen auf der Rechnung gewechselt.‍
Das Tückische: Die meisten Industrieunternehmen wissen, dass sie ein Bus-Faktor-Problem haben. Aber solange die Produktion läuft, wird es verdrängt. Und genau das ist das teuerste: Nicht der Moment, in dem es passiert. Sondern die Monate und Jahre davor, in denen Sie die Kosten des Nichtstuns tragen – ohne sie auf einer Rechnung zu sehen.

Die Frage ist nicht „Wird es passieren?" – sondern: Was kostet Sie jeder weitere Monat, in dem Sie es aufschieben?

Selbsttest: Wie hoch ist Ihr Bus-Faktor-Risiko?

Nehmen Sie sich 60 Sekunden. Gehen Sie die folgenden acht Fragen durch – und zählen Sie ehrlich mit:

Es gibt mindestens eine Person, ohne die ein kritisches Produktions- oder ERP-System nicht gewartet werden kann
Wichtige Systemzugänge, Admin-Berechtigungen oder Schnittstellenkonfigurationen liegen bei einer einzelnen Person
Sie haben Individualsoftware im Einsatz, deren Quellcode niemand im aktuellen Team vollständig versteht
Dokumentation zu kritischen Systemen und Schnittstellen ist veraltet, unvollständig oder nicht vorhanden
Ein ehemaliger Mitarbeiter oder externer Dienstleister wird regelmäßig für Wartung oder Wissensabfragen herangezogen
Änderungen an bestimmter Software werden vermieden, weil „das zu riskant ist" oder „niemand weiß, was dann passiert"
Ihre Systemlandschaft (ERP, CRM, DMS, Produktionssysteme) ist über Jahre gewachsen – ohne übergreifende Integrationsarchitektur
Der Gedanke, dass eine bestimmte Person kündigen oder in Rente gehen könnte, bereitet Ihnen echte Sorgen

Bereits zwei Häkchen sind ein deutliches Warnsignal. Die meisten Industrieunternehmen, die zu uns kommen, kreuzen fünf oder mehr Punkte an. Wenn es Ihnen ähnlich geht: Sie sind in guter Gesellschaft. Und jedes dieser Probleme ist lösbar – wenn man es angeht, bevor der Ernstfall eintritt.

Nicht jedes Risiko muss sofort gelöst werden. Aber jedes Risiko sollte bewusst sein. Den ersten Schritt haben Sie gerade gemacht: ehrlich hinschauen.

Was bedeutet RACI in der Risikoanalyse?

In besagtem Fall war das Risiko offensichtlich. Das ist aber nicht immer so. Oft schlummern Bus-Faktor-Risiken dort, wo man sie nicht vermutet – in Berechtigungen, Zugängen, Konfigurationen oder undokumentierten Workarounds.

Um aufzuzeigen, wo es potenzielle Schwachstellen geben könnte, arbeitet generic.de mit der Verantwortungszuweisungs-Matrix, oder auch RACI-Diagramm. Viele unserer Industriekunden haben dieses Werkzeug inzwischen als festen Bestandteil ihrer Projektarbeit übernommen.

Ein RACI-Diagramm beschreibt die Verantwortlichkeiten der Teammitglieder in einem bestimmten Projekt in vier Kategorien:

‍Responsible | Task ausführen: Diese Person verantwortet, dass ein bestimmter Task innerhalb der vereinbarten Parameter und Frist erledigt wird. Ein Task kann mehrere verantwortliche Personen haben.
‍Accountable | Projektaufsicht: Die Person, die dafür sorgt, dass der Task von allen Verantwortlichen erledigt wird. Um hier nicht selbst einen Bus-Faktor = 1 zu erzeugen, sollte direkt eine Vertretungsregelung eingerichtet werden.
‍Consulted | Informationsbereitstellung: Die „konsultierte" Person ist ein Wissensträger im Team. Sie bietet Hilfe, zusätzlichen Kontext und Ratschläge, stellt benötigte Informationen zur Verfügung und gewährt Zugriffe.‍
Informed | Erhält Status-Updates: Stakeholder, die Informationen über das Projekt erhalten oder benötigen.

Gerade in der Industrie, wo IT-Leiter, Produktionsleiter, Automatisierungsingenieure und externe Dienstleister zusammenarbeiten müssen, zeigt das RACI-Modell schnell Schwachstellen auf: Wer hat welche Systemzugänge? Wer versteht die Schnittstellen zwischen ERP und Fertigung? Wer kann Berechtigungen vergeben oder Konfigurationen ändern?

Oft genügt ein Blick auf die ausgefüllte Matrix, um den Handlungsbedarf schwarz auf weiß zu sehen. Marcel Dambach weiß: „Manchmal wollen die Personen, die sehr viel Verantwortung tragen, diese überhaupt nicht abgeben. Da muss dann, am besten von außen, Überzeugungsarbeit geleistet werden. Das Argument des Bus-Faktors kann manchmal ein Weckruf sein."

Ein konkreter Tipp: Nehmen Sie Ihre drei kritischsten Systeme und fragen Sie: Wer kann dieses System konfigurieren, warten und im Notfall wiederherstellen? Wenn bei allen drei Systemen derselbe Name steht, haben Sie Ihren Bus-Faktor gefunden.

Wissensaustausch aktiv vorantreiben, um Nachvollziehbarkeit zu gewährleisten

Was bei der RACI-Matrix gilt, gilt auch im gesamten Projekt: Es muss eine stetige Kommunikation zwischen allen Projektbeteiligten stattfinden. Denn ohne regelmäßige Kommunikation oder Dokumentation kann dasselbe Problem wie zu Beginn auftreten. Die Folge: Niemand weiß mehr, was wieso wie entwickelt wurde. Das wird vor allem bei der Evolvierbarkeit und der Nachvollziehbarkeit des Codes zum Problem – und in der Industrie, wo Software direkt in Wertschöpfungsprozesse eingreift, kann mangelnde Nachvollziehbarkeit Produktionsrisiken bedeuten.

Marcel Dambach zufolge ist dieser Punkt für viele Industriekunden entscheidend bei der Auswahl eines Entwicklungspartners: „Die Kunden möchten heute nicht mehr von einem bestimmten Produkt oder einer Firma abhängig sein. Der sogenannte Vendor Lock-In, der Kunden daran hindert, den Anbieter zu wechseln, muss vermieden werden.

Das gewährleisten wir durch die absolut transparente Zusammenarbeit mit dem Kunden, der zu jeder Zeit vollen Zugriff auf den Quellcode hat. Durch die Verwendung der Clean Code Development Prinzipien stellen wir sicher, dass technische Schulden minimiert werden. Das bedeutet, dass wir selbst und auch andere Entwickler, die ggf. später das Projekt übernehmen, nachvollziehen können, wieso welche Entscheidungen getroffen wurden."

Warum das gerade in der Industrie entscheidend ist: Wer einen Bus-Faktor auflöst, indem er die Abhängigkeit von einer internen Person durch die Abhängigkeit von einem externen Dienstleister ersetzt, hat das Problem nicht gelöst – nur verlagert. In einer Branche, in der proprietäre Systeme, herstellerabhängige ERP-Module und gewachsene On-Prem-Infrastrukturen ohnehin für Abhängigkeiten sorgen, muss das Ziel ein anderes sein: Kein Umbau, sondern intelligente Vernetzung des Bestehenden. Keine neuen Abhängigkeiten, sondern Nachvollziehbarkeit. Ihr Wissen liegt bei Ihnen, Ihr Code gehört Ihnen, und Sie können jederzeit entscheiden, wie es weitergeht.

Aber was, wenn es einen Weg gäbe, das Wissen, das in Ihrem Code steckt, zugänglich zu machen – auch für Entwickler, die den Code noch nie gesehen haben?

Wie Künstliche Intelligenz und das Model Context Protocol Wissen zugänglich machen

Die klassische Antwort auf den Bus-Faktor lautet: Clean Code - besser dokumentieren, mehr Pair Programming, regelmäßige Code-Reviews. Das bleibt auch weiterhin wichtig. Aber es hat eine Grenze: Menschen vergessen, wechseln den Job, und Dokumentation veraltet schneller, als sie geschrieben wird.

Heute gibt es einen zusätzlichen Ansatz, der das Spiel grundlegend verändert: KI-gestützte Code-Interaktion über das Model Context Protocol (MCP).

Was ist MCP?

Das Model Context Protocol ist ein offener Standard, der es KI-Modellen ermöglicht, strukturiert auf externe Datenquellen zuzugreifen – darunter auch Codebasen, Dokumentationen, Ticketsysteme oder Wissensdatenbanken. Statt dass ein neuer Entwickler sich wochenlang durch tausende Zeilen Code lesen muss, kann er die KI fragen – und bekommt Antworten, die auf dem tatsächlichen Code und seiner Historie basieren.

Ein Beispiel: Wie ein neuer Entwickler Legacy-Code versteht

Stellen Sie sich folgendes Szenario vor: Lisa ist seit zwei Wochen im Team. Sie soll ein Modul weiterentwickeln, das vor fünf Jahren geschrieben wurde – von einem Entwickler, der längst nicht mehr im Unternehmen ist. Der Code ist funktional, aber komplex. Keine Kommentare, keine Architekturdokumentation, keine README.

Ohne MCP: Lisa verbringt Tage damit, den Code Zeile für Zeile zu lesen. Sie versteht die Syntax, aber nicht die Intention. Warum wurde hier ein Workaround eingebaut? Welche Geschäftsregel steckt hinter dieser Validierung? Welche Seiteneffekte hat eine Änderung an dieser Stelle? Sie fragt Kollegen – aber niemand war dabei, als der Code geschrieben wurde. Nach zwei Wochen hat sie ein grobes Verständnis. Produktiv ist sie noch lange nicht.

Mit MCP: Lisa öffnet ihre Entwicklungsumgebung, die über MCP mit der gesamten Codebasis, der Git-Historie, den verknüpften Tickets und der vorhandenen Dokumentation verbunden ist. Sie fragt die KI:

„Warum wurde in der Klasse OrderValidation ein separater Validierungsschritt für Bestandskunden eingebaut?"

Die KI analysiert den Code, die zugehörigen Commits, die verlinkten User Stories und antwortet: Der Schritt wurde eingeführt, weil Bestandskunden im alten System andere Konditionen hatten. Das Ticket XY-1247 beschreibt die Anforderung. Der Workaround umgeht eine Limitierung der damaligen Datenbankstruktur, die inzwischen behoben ist – der Workaround könnte also entfernt werden.

Lisa hat in fünf Minuten verstanden, wofür sie ohne KI zwei Tage gebraucht hätte. Und sie hat nicht nur den *Was*-Kontext, sondern den Warum-Kontext – die wertvollste und am schwersten zu übertragende Form von Wissen.

Was MCP konkret leistet

‍Codebasis verstehbar machen: Neue Entwickler können mit dem Code „sprechen" – sie stellen Fragen in natürlicher Sprache und bekommen Antworten, die auf dem tatsächlichen Code, der Commit-Historie und verknüpften Dokumenten basieren.‍
Implizites Wissen explizit machen: Die Gründe hinter Architekturentscheidungen, die sonst nur im Kopf des ursprünglichen Entwicklers existierten, werden durch KI-Analyse von Code, Commits und Tickets rekonstruierbar.‍
Onboarding drastisch beschleunigen: Statt Monate brauchen neue Teammitglieder Wochen, um produktiv zu werden – weil sie jederzeit einen KI-gestützten „Mentor" haben, der die gesamte Codehistorie kennt.‍
Abhängigkeit von Einzelpersonen reduzieren: Wenn das Wissen nicht nur in Köpfen, sondern auch in einer KI-zugänglichen Wissensbasis liegt, sinkt der Bus-Faktor messbar.‍
Legacy-Code modernisierbar machen: Bevor Legacy-Code refactored werden kann, muss er verstanden werden. MCP-gestützte KI macht dieses Verständnis schneller, günstiger und weniger abhängig von einzelnen Personen.

Der Unterschied zu klassischer Dokumentation

Dokumentation ist ein Dokument. Sie ist statisch, veraltet schnell und wird selten dort gelesen, wo man sie braucht.

MCP-gestützte KI ist anders: Sie ist *kontextbezogen* – sie antwortet genau dort, wo die Frage entsteht: im Code, in der IDE, im Moment des Nicht-Verstehens. Sie ist *aktuell*, weil sie direkt auf die aktuelle Codebasis zugreift. Und sie ist *interaktiv* – man kann nachfragen, präzisieren, tiefer bohren.

Das ersetzt keine gute Dokumentation und kein Pair Programming. Aber es ergänzt beides um eine Dimension, die bisher fehlte: Wissen, das zugänglich bleibt – auch wenn der Mensch, der es hatte, nicht mehr da ist

Nicht jeder Bus-Faktor ist eine Katastrophe

Ein wichtiger Punkt, der in der Diskussion oft untergeht – und den wir Ihnen bewusst sagen, auch wenn es uns keinen Auftrag bringt: Nicht jedes Bus-Faktor-Risiko muss sofort und mit maximalem Aufwand aufgelöst werden. Es gibt Situationen, in denen wir Unternehmen ehrlich sagen: „Sie haben kein akutes Problem. Beobachten Sie es, dokumentieren Sie gezielt, und handeln Sie, wenn sich die Situation ändert."

Manchmal ist ein Bus-Faktor von 1 für ein unkritisches internes Tool akzeptabel. Manchmal reicht eine gute Dokumentation als erster Schritt. Und manchmal ist die ehrliche Antwort: Das System sollte ohnehin abgelöst werden, bevor man in Wissenstransfer investiert.

Gerade in der Industrie, wo dutzende Systeme parallel laufen, geht es nicht darum, alles gleichzeitig anzupacken. Entscheidend ist die Priorisierung:

Welche Software greift direkt in die Wertschöpfung ein?
Wo würde ein Ausfall Produktionsstopps verursachen?
Wo sind die Kosten am höchsten, wenn Wissen verloren geht?
Und wo lohnt es sich, bewusst ein Risiko zu akzeptieren?

Entscheidend ist, dass Sie Ihre Risiken kennen und bewusst priorisieren – statt sie zu verdrängen, bis der Ernstfall eintritt. Die Frage ist nicht: „Müssen wir alles sofort ändern?" Sondern: „Wissen wir, wo es brennen würde, wenn morgen jemand ausfällt – und haben wir uns bewusst entschieden, dieses Risiko zu tragen?"

Fazit: Handeln Sie, bevor der Bus kommt

Erinnern Sie sich an Thomas? Montag, 7:15 Uhr, ERP-Fehler, Fertigung steht. Die Unternehmen, die in dieser Situation ruhig bleiben, haben eines gemeinsam: Sie haben vorher gehandelt. Nicht in Panik, nicht mit einem Riesenprojekt – sondern mit einem klaren Blick auf ihre Abhängigkeiten.

Was diese Unternehmen anders gemacht haben:

Hingeschaut statt verdrängt – sie kennen ihre Bus-Faktoren und haben sich bewusst entschieden, welche sie auflösen und welche sie akzeptieren
Dokumentiert als Teil des Arbeitsprozesses – nicht als Projekt, sondern als Haltung
Wissen zugänglich gemacht – durch Clean Code, KI-gestützte Code-Interaktion über MCP und systematischen Wissenstransfer, sodass neue Entwickler in Wochen statt Monaten produktiv werden
Keine neuen Abhängigkeiten geschaffen – kein Vendor Lock-In durch proprietäre Systeme oder undokumentierten Code
Auf Nachvollziehbarkeit gesetzt – damit ihre Software auch in fünf Jahren noch weiterentwickelt werden kann, egal von wem

Der Bus-Faktor ist kein theoretisches Gedankenexperiment. Er beschreibt ein konkretes, messbares Unternehmensrisiko, das jeden Tag realer wird – mit jedem undokumentierten Workaround, jeder aufgeschobenen Wissensübergabe, jeder ungeplanten Schnittstelle zwischen Altsystemen.

Die Frage, die bleibt, ist einfach: Wissen Sie, wo Sie stehen?

Drei Wege, wie Sie jetzt weitermachen können.

Wenn Sie beim Lesen dieses Artikels an bestimmte Personen, Systeme oder Situationen in Ihrem Unternehmen gedacht haben – dann haben Sie den wichtigsten Schritt bereits gemacht. Sie haben hingeschaut.

Wie es weitergeht, hängt davon ab, wo Sie stehen:

Weg 1: Selbst starten – 30 Minuten, die alles verändern können

Nehmen Sie den Selbsttest weiter oben, drucken Sie ihn aus, und legen Sie ihn in Ihrem nächsten Jour fixe auf den Tisch. Gehen Sie ihn gemeinsam mit Ihrem Entwicklungsteam durch. Nicht als Schuldzuweisung – sondern als ehrliches Gespräch: Welche Module versteht nur eine Person? Wo wären wir aufgeschmissen?

Oft entsteht allein durch dieses Gespräch eine Dynamik, die vorher jahrelang gefehlt hat. Das kostet Sie nichts – außer 30 Minuten Ehrlichkeit.

---

Weg 2: Einordnung holen – für alle, die wissen wollen, wie kritisch es wirklich ist

Wenn Sie unsicher sind, ob Ihre Situation akut ist oder wo Sie anfangen sollten – sprechen Sie mit jemandem, der solche Situationen jede Woche sieht.

In einem kurzen, unverbindlichen Gespräch ordnen wir gemeinsam ein, ob und wo Handlungsbedarf besteht. Wir zeigen Ihnen auch, wie MCP-gestützte KI-Interaktion konkret aussieht – anhand Ihrer eigenen Codebasis, nicht anhand eines Demobeispiels. Wir sagen Ihnen ehrlich, wenn wir der Meinung sind, dass Sie kein akutes Problem haben – oder wenn ein anderer Weg der richtige ist. Nicht jedes Gespräch führt zu einem Projekt. Manchmal ist ein guter Rat der wertvollste erste Schritt.

---

Weg 3: Codebasis zugänglich machen – für Unternehmen, die es jetzt angehen wollen

Für Unternehmen, die wissen, dass sie ein Problem haben und es systematisch angehen wollen, bieten wir einen fokussierten Discovery Workshop an:

‍1–2 Tage, nicht 6 Monate
‍Ein konkreter Fokus: Ihre kritischsten Codebasen und Wissensabhängigkeiten
‍Gemeinsam mit Ihrem Team: Sie priorisieren die Module, Sie entscheiden, wo MCP-gestützte KI-Interaktion den größten Hebel hat
‍Das Ergebnis gehört Ihnen: Kartierte Abhängigkeiten, ein erster MCP-Prototyp für Ihren wichtigsten Use Case und priorisierte nächste Schritte – unabhängig davon, ob wir danach weiter zusammenarbeiten‍
Kein Vendor Lock-In. Kein Folgezwang. Clean Code und Wissenstransfer sind bei uns keine Zusatzleistung, sondern Standard. Sie behalten die volle Kontrolle – über den Prozess, über den Code und über die Entscheidung, wie es weitergeht.

‍

Schreiben Sie uns an [team@generic.de] oder rufen Sie an unter [+49 721 6190960] – wir melden uns innerhalb von 24 Stunden.

generic.de unterstützt seit über 25 Jahren Industrieunternehmen dabei, ihre Software-Abhängigkeiten aufzulösen – transparent, nachvollziehbar und ohne neuen Vendor Lock-In. Durch Clean Code Development, Dual Track Agile, konsequenten Wissenstransfer und KI-gestützte Code-Zugänglichkeit über das Model Context Protocol bleibt Ihr Wissen bei Ihnen – auch wenn die Menschen, die es hatten, nicht mehr da sind.

‍