Der Moment, in dem zwei Welten zusammenfallen
1945 veröffentlichte John von Neumann einen technischen Bericht, der die Welt der Computer für immer veränderte. Er beschrieb eine Architektur, wie Maschinen Information verarbeiten: Es gibt eine Eingabe, eine Verarbeitungseinheit, einen Speicher, eine Ausgabe — und einen Bus, der alles verbindet.
Dreißig Jahre später beschrieb Six Sigma mit dem SIPOC-Framework, wie Geschäftsprozesse funktionieren: Supplier liefert Input, ein Process verarbeitet ihn, der Output geht an den Customer — und das alles ist durch Informationsfluss verbunden.
Zwei Modelle. Zwei Disziplinen. Zwei Jahrzehnte Abstand.
Dasselbe Prinzip.
Was wie eine akademische Beobachtung klingt, hat für jedes Unternehmen, das heute mit fragmentierten Tool-Landschaften kämpft, eine sehr praktische Konsequenz — denn die meisten Enterprise-Systeme ignorieren genau diesen Zusammenhang. Mit teuren Folgen.
Das Modell, das alle kennen — aber keiner zu Ende denkt
Von Neumanns Architektur beschreibt fünf Komponenten, die in jedem modernen Computersystem zu finden sind:
- Input Unit — Nimmt Daten von außen entgegen
- ALU (Arithmetic Logic Unit) — Verarbeitet die Daten nach definierten Regeln
- Memory — Speichert Zwischenergebnisse und Zustände
- Output Unit — Gibt Ergebnisse nach außen ab
- Control Unit — Steuert den Ablauf, sorgt für Konsistenz
- Bus — Verbindet alle Komponenten — der unsichtbare Rückgrat
SIPOC beschreibt dasselbe — nur für menschliche Organisationen:
- Supplier — Liefert den Input von außen
- Input — Das Rohmaterial der Verarbeitung
- Process — Die eigentliche Wertschöpfung
- Output — Das Ergebnis, das weitergegeben wird
- Customer — Der Empfänger des Outputs
Wer beide Modelle nebeneinanderlegt, sieht sofort: Das ist kein Zufall. Es ist dasselbe informationstheoretische Grundmodell — einmal für Silizium, einmal für Menschen.
Der entscheidende Unterschied: Der Bus
In Von Neumanns Modell ist der Bus das kritischste Element. Er ist der einzige Kanal, über den alle Komponenten miteinander kommunizieren. Fällt der Bus aus — oder gibt es mehrere inkompatible Busse — bricht das gesamte System zusammen. Es entstehen inkonsistente Zustände, verlorene Daten, nicht reproduzierbare Ergebnisse.
In Unternehmen heißt der Bus: Ergebnisfluss zwischen Aktivitäten.
Wer liefert was an wen — und in welchem Zustand? Das ist die eigentliche Frage hinter jedem Prozessmodell. SIPOC nennt das den Informationsfluss von Supplier zu Customer. In einer konsequenten Systemarchitektur müsste jedes Arbeitsergebnis (Work Product) genau wissen:
- Woher kommt es? (FromSupplier, FromCustomer)
- Wohin geht es? (ToCustomer, Internal)
- Wer hat es verarbeitet? (Aktivität + Rolle)
Ohne diese Klassifikation existiert kein Bus — nur Chaos mit bunten Icons.
Warum Enterprise-Tools systematisch scheitern
Betrachtet man die typische Tool-Landschaft eines mittelgroßen Unternehmens in der Automobil-, Aerospace- oder Medizingerätebranche, findet man folgendes Bild:
- IBM DOORS / Polarion — kennt Anforderungen (Input), aber nicht wohin sie fließen
- Jira / Codebeamer — kennt Tasks (Processing), aber nicht welche Ergebnisse sie produzieren
- Confluence / SharePoint — kennt Dokumente (Memory), aber nicht wer sie wann aus welchem Grund braucht
- MS Project — kennt Zeitplanung, aber nicht Ergebnisabhängigkeiten
- FMEA-Tools — kennen Risiken, aber nicht den Prozesskontext der Risiken
Jedes dieser Tools ist eine Insel. Jedes implementiert einen Teil des Von-Neumann-Modells — aber ohne den Bus. Es gibt keinen gemeinsamen Kanal, über den Anforderungen, Aufgaben, Ergebnisse, Risiken und Zeitplanung als kohärentes System kommunizieren.
Das ist kein Prozess-Problem. Das ist ein Architektur-Problem.
Wer Von Neumanns Lektion ernst nimmt, weiß: Ein System ohne gemeinsamen Bus ist kein System. Es ist eine Sammlung von Komponenten, die zufällig im selben Rechenzentrum stehen.
OTSM: Von Neumann konsequent auf Organisationen angewendet
Was passiert, wenn man Von Neumanns Architekturprinzip konsequent auf ein Process-Engineering-System anwendet? Man erhält eine Struktur, in der jedes Arbeitsergebnis — jedes Work Product — von Anfang an klassifiziert ist:
- Internal — Das Ergebnis zirkuliert innerhalb des Prozesses
- ToCustomer — Das Ergebnis verlässt den Prozess in Richtung Kunde
- FromCustomer — Das Ergebnis kommt als Input vom Kunden
- FromSupplier — Das Ergebnis kommt als Input vom Lieferanten
Das ist kein Label. Das ist die Implementierung des SIPOC-Supplier/Customer-Konzepts direkt im Datenmodell.
Der Work Product Tree in OTSM ist der Bus. Er verbindet alle Aktivitäten, alle Rollen, alle Prozesse — und er weiß bei jedem Ergebnis genau, wer Supplier und wer Customer ist. Nicht als Annotation in einem separaten Dokument. Sondern als strukturelle Eigenschaft des Systems selbst.
"Work Once, Use Many" — Die logische Konsequenz
Von Neumanns entscheidende Erkenntnis war: Wenn alle Komponenten denselben Bus nutzen, muss Information nur einmal existieren.
Der Arbeitsspeicher hält einen Wert. Die ALU liest ihn, verarbeitet ihn, schreibt das Ergebnis zurück. Die Output Unit liest denselben Speicher. Niemand kopiert Daten. Niemand synchronisiert Versionen. Es gibt eine Wahrheit.
In Unternehmensarchitekturen nennt man dieses Prinzip "Work Once, Use Many": Daten werden einmal erfasst und fließen durch das gesamte System — von der Anforderung über die FMEA bis zum Compliance-Nachweis, von der Projektplanung bis zum Testprotokoll.
Das klingt selbstverständlich. Es ist in der Praxis revolutionär — weil es voraussetzt, dass das System tatsächlich einen gemeinsamen Bus hat.
Was das für Entscheider bedeutet
Wer heute für sein Unternehmen Lizenz- und Betriebskosten für 9 verschiedene Enterprise-Tools trägt, betreibt — in Von Neumanns Begriffen — 9 verschiedene Computer ohne gemeinsamen Bus.
- Redundante Datenpflege — Dieselbe Information in 3–5 Systemen
- Inkonsistenz — Welches System hat die aktuelle Wahrheit?
- Compliance-Aufwand — Nachweise müssen manuell aggregiert werden
- Änderungsmanagement — Eine geänderte Anforderung erfordert Updates in N Systemen
- Onboarding — Jedes System hat eine eigene Lernkurve
Studien aus dem Requirements-Engineering-Bereich zeigen konsistent: Bis zu 40% der Projektkosten in komplexen Entwicklungsprojekten entstehen durch mangelnde Informationskonsistenz — nicht durch schlechte Ingenieure, sondern durch schlechte Systemarchitektur.
Ein System mit N Bussen ist kein System. Es ist N Systeme, die so tun, als würden sie zusammenarbeiten.
Fazit: Das Prinzip ist alt. Die Konsequenz ist neu.
John von Neumann hat 1945 beschrieben, wie Information fließen muss, damit ein System funktioniert. Six Sigma hat in den 1980ern beschrieben, wie Prozesse strukturiert sein müssen, damit Qualität entsteht. Beide haben — aus verschiedenen Richtungen — dasselbe Fundamentalprinzip erkannt.
Die Frage für jedes Unternehmen, das heute mit Produktkomplexität, Regulatorik und Kostendruck kämpft, ist nicht, ob dieses Prinzip gilt. Es gilt. Die Frage ist: Hat Ihre Software-Architektur einen gemeinsamen Bus — oder haben Sie 9 isolierte Systeme, die durch Excel-Exporte zusammengehalten werden?
Von Neumann wusste die Antwort bereits 1945.
