Systemantics: Was IT-Projekte aus dem Scheitern komplexer Systeme lernen können

Galls zentrale Prinzipien

Gall formuliert eine Reihe von Grundsätzen über das Verhalten komplexer Systeme. Sie wirken zunächst zugespitzt, beschreiben aber Erfahrungen, die viele IT-Verantwortliche aus eigenen Projekten kennen.

Gall’s Law

Das bekannteste Prinzip lautet sinngemäß:

Ein funktionierendes komplexes System ist ausnahmslos aus einem funktionierenden einfachen System hervorgegangen. Ein von Grund auf neu entworfenes komplexes System funktioniert nie und lässt sich auch nicht nachträglich zum Laufen bringen.

Daraus folgt eine klare Empfehlung: mit einem einfachen, funktionierenden System beginnen und es schrittweise erweitern. Das erklärt, warum sogenannte Big-Bang-Projekte, die ein großes System in einem Schritt ablösen wollen, besonders häufig scheitern.

Weitere Grundsätze

• Systeme funktionieren grundsätzlich schlechter als geplant. Wer von einem reibungslosen Start ausgeht, plant an der Realität vorbei.
• Neue Systeme erzeugen neue Probleme. Jede Lösung bringt eigenen Aufwand mit sich: Betrieb, Wartung, Sicherheit und Weiterentwicklung.
• Systeme neigen dazu, zu wachsen. Funktionsumfang und Regelwerke dehnen sich oft über den ursprünglichen Zweck hinaus aus.
• Systeme entwickeln ein Eigenleben. Der Erhalt des Systems kann wichtiger werden als der Zweck, für den es geschaffen wurde.
• Menschen arbeiten um Systeme herum. Umständliche Prozesse führen zu Workarounds, Kennzahlen zu Verhalten, das die Kennzahl erfüllt, aber nicht das eigentliche Ziel.
• Das System sieht nur, was gemeldet wird. Was Kennzahlen, Dashboards und Berichte nicht erfassen, bleibt unsichtbar. Das verzerrt die Wahrnehmung der tatsächlichen Lage.

Bekannte IT-Fehlschläge im Licht von Systemantics

Einzelne Fehlschläge haben jeweils eigene technische oder organisatorische Ursachen. Ordnet man sie Galls Prinzipien zu, werden wiederkehrende Muster sichtbar. Aus der Frage „Was ist passiert?“ wird die Frage „Warum passiert so etwas immer wieder?“.

Fall	Ursache	Passendes Prinzip
Ariane 5, Flug 501 (1996)	Software der Ariane 4 wurde unter veränderten Flugbedingungen wiederverwendet. Die Umwandlung eines 64-Bit-Gleitkommawerts in eine 16-Bit-Ganzzahl führte zu einem Überlauf, zum Ausfall der Trägheitsnavigation und zur Zerstörung der Rakete.	Komplexe Systeme verhalten sich unter neuen Bedingungen unerwartet.
Gepäcksystem des Flughafens Denver (1990er)	Ein hochkomplexes automatisiertes Gepäcksystem wurde ohne funktionierende Vorstufe von Grund auf neu entworfen. Die Eröffnung des Flughafens verzögerte sich um rund 16 Monate, die Mehrkosten lagen bei etwa 560 Millionen US-Dollar.	Gall’s Law: Neu entworfene komplexe Systeme funktionieren nicht.
Therac-25 (1980er)	Bewährte Hardware-Sicherungen wurden durch Softwaresteuerung ersetzt. Ein selten auftretender Timing-Fehler führte zu Strahlungsüberdosen mit Todesfällen. Frühe Fehlermeldungen von Anwendern wurden zunächst nicht ernst genommen.	Das System sieht nur, was gemeldet wird, und schirmt Beteiligte von der Realität ab.
FBI Virtual Case File (2005)	Unklare, sich ständig ändernde Anforderungen und der Versuch, die gesamte Fallverwaltung in einem großen System abzulösen. Das Projekt wurde nach Ausgaben von rund 170 Millionen US-Dollar ohne einsatzfähiges Ergebnis eingestellt.	Systeme wachsen über ihren Zweck hinaus und wirken ihm entgegen.

Was daraus für heutige IT-Projekte folgt

Galls Beobachtungen wirken auf den ersten Blick pessimistisch. Moderne Ansätze in Softwareentwicklung, Organisation und Führung lassen sich jedoch als direkte Antworten auf die beschriebenen Muster verstehen.

Klein beginnen und schrittweise erweitern

Gall’s Law spricht gegen Großprojekte, die alles auf einmal lösen wollen. Agile Entwicklung setzt deshalb auf ein Minimum Viable Product, das früh Nutzen stiftet und iterativ wächst. Team Topologies überträgt diesen Gedanken auf interne Plattformen: Die sogenannte Thinnest Viable Platform startet bewusst schlank und wächst mit dem tatsächlichen Bedarf.

Entscheidungen dorthin verlagern, wo die Informationen liegen

Wenn Systeme ihre Beteiligten von der Realität abschirmen, helfen dezentrale Entscheidungen. Intent-Based Leadership überträgt Verantwortung an die Menschen, die die Lage aus erster Hand kennen, statt Entscheidungen auf Basis gefilterter Berichte zu treffen.

Mit dem Verhalten der Menschen arbeiten, nicht dagegen

Gall beschreibt, dass Systeme am besten funktionieren, wenn sie menschliches Verhalten berücksichtigen. Servant Leadership setzt genau hier an: Es beseitigt Hindernisse und reduziert Reibung, statt Leistung über Druck und Kontrolle zu erzwingen. Mehr dazu in unserem Beitrag Beyond Command and Control.

Fazit: Resilienz statt Perfektion

Die wichtigste Lehre aus Systemantics ist Demut gegenüber Komplexität. Ein großes soziotechnisches System lässt sich nicht vollständig vorausplanen und kontrollieren.

Erfolgreich sind deshalb nicht die Organisationen mit dem umfassendsten Plan, sondern diejenigen, die schnell lernen und sich anpassen. Schrittweise Entwicklung, eine entkoppelte Teamstruktur und eine Führung, die Verantwortung überträgt, schaffen gemeinsam die Grundlage für belastbare und innovationsfähige IT.