Investitionsentscheidungen in der Fertigung verlangen eine belastbare ROI-Kennzahl (Return on Investment). Beim Unified Namespace (UNS) führt diese Anforderung regelmäßig in eine methodische Sackgasse: Ein UNS ist eine Architektur, kein end-to-end Use-Case mit eigenem Ertragsbeitrag. Isoliert bewertet weist eine Architektur ausschließlich Kosten aus, während der Ertrag in den Use-Cases entsteht, die auf dieser Architektur aufsetzen. Entsprechend scheitern UNS-Vorhaben in der Praxis teilweise nicht an der technischen Umsetzung, sondern bereits in der Bewertungsphase – an einem falsch abgegrenzten Bewertungsobjekt. Dieser Artikel erläutert, warum der Unified Namespace ROI nur im Verbund mit den Use Cases bewertbar ist, welcher Bewertungsrahmen dafür erforderlich ist, und beziffert an einer Beispielrechnung den Punkt, ab dem die Investition die Alternative unterbietet.
Warum die Architektur kein eigenständiges ROI Bewertungsobjekt ist
Die Struktur des Problems lässt sich an einem Hotelbau nachvollziehen. Bevor das erste Zimmer vermietet wird, entstehen Fundament und Tragwerk – die Architektur des Gebäudes. Sie erzeugt keinen eigenen Ertrag, bestimmt aber, wie viele Zimmer möglich sind, wie schnell sich eine weitere Etage erschließen lässt und welche Kosten jeder spätere Ausbau verursacht. Bewertet wird deshalb nicht die Architektur, sondern das Gesamtobjekt aus Architektur und Nutzflächen.
Für den Unified Namespace gilt dieselbe Logik. Der UNS stellt eine Single Source of Truth (SSOT) bereit und bildet damit die Architektur der Datenebene. Auf ihr setzen die Use Cases auf: automatisierte Produktionssteuerung, Prozessautomatisierung, Traceability, KI-gestützte Anwendungen. Diese Anwendungen entsprechen den Nutzflächen des Gebäudes – sie erzeugen Erlöse, senken Kosten oder reduzieren Risiken.
Eine isolierte ROI-Rechnung für die Architekturschicht führt daher zwangsläufig zu einem negativen oder nicht interpretierbaren Ergebnis, unabhängig davon, wie tragfähig die Investition strategisch ist. Der Fehler liegt nicht im Rechenweg, sondern in der Abgrenzung des Bewertungsobjekts: Architektur und die auf ihr betriebenen Anwendungen bilden eine wirtschaftliche Einheit und amortisieren sich gemeinsam.
UNS als Fundament, Use Cases als Werttreiber
Strukturell liefert der UNS drei Leistungen, die andernfalls jeder Use Case einzeln erbringen müsste: eine harmonisierte Datenbasis, konsistenten Kontext (Asset, Einheit, Zeitstempel, ISA-95-Pfad) und einen zentralen Zugriffspunkt auf alle Daten.
Damit rückt die architektonische Weichenstellung in den Fokus, die tatsächlich zu bewerten ist: Unified Namespace gegenüber Punkt-zu-Punkt-Integration. Bei der Punkt-zu-Punkt-Integration verbindet sich jede Anwendung direkt und individuell mit jeder benötigten Datenquelle – SPS (Programmable Logic Controller), SCADA-System (Supervisory Control and Data Acquisition), MES (Manufacturing Execution System) oder ERP-System (Enterprise Resource Planning). Jeder zusätzliche Use Case erfordert damit erneut eigene, meist proprietäre Verbindungen. Der UNS kehrt dieses Muster um: Einmal angebunden und harmonisiert, steht ein Datenpunkt jedem berechtigten Consumer zur Verfügung – einschließlich der Use Cases, die zum Zeitpunkt der Anbindung noch nicht spezifiziert sind.
Der richtige Bewertungsrahmen für den ROI eines Unified Namespace
Eine belastbare Entscheidung erfordert statt der isolierten Architekturbetrachtung drei Schritte:
- Den gesamten Datenstack betrachten: UNS, Anwendungen und Use Cases gehören in eine gemeinsame Investitionsrechnung, nicht in getrennte Business Cases.
- Architekturoptionen evaluieren und testen: UNS und Punkt-zu-Punkt-Integration im Pilotbetrieb gegeneinander bewerten, nicht ausschließlich auf Basis von Schätzungen.
- ROI end-to-end berechnen: Die Rechnung umfasst die Architekturschicht und sämtliche Use Cases, die auf ihr betrieben werden.
Der entscheidende Effekt tritt erst im Zeitverlauf ein: Die Harmonisierungsschicht entsteht einmal und wird von jedem weiteren Use Case genutzt. Die Grenzkosten pro zusätzlichem Use Case sinken – und genau dieser Hebel bleibt in einer isolierten Betrachtung der Architektur systematisch unberücksichtigt.
Beispielrechnung: Unified Namespace ROI über mehrere Use Cases
Ein vereinfachtes Rechenbeispiel quantifiziert diesen Effekt. Es verwendet Richtwerte aus mittelgroßen Fertigungsumgebungen und dient der Veranschaulichung des Mechanismus, nicht als Kostenzusage für ein konkretes Projekt – die tatsächlichen Aufwände hängen von Anlagenanzahl, Protokollvielfalt und Altsystemen ab.
Zugrunde gelegt ist ein Werk mit rund 100 angebundenen Systemen (SPS, SCADA, Sensorik, Prüfstände), das über zwei Jahre drei Use Cases plant: Produktionsmonitoring, Traceability und Predictive Maintenance. Die beiden Ansätze unterscheiden sich in der Reihenfolge, in der die Integrationsarbeit anfällt. Bei der Punkt-zu-Punkt-Integration bindet jeder Use Case ausschließlich die Systeme an, die er selbst benötigt – dafür wiederholt sich diese Arbeit bei jedem weiteren Use Case. Im UNS-basierten Ansatz werden die 100 Systeme einmalig angebunden und harmonisiert; diese Vorleistung schlägt vor dem ersten Use Case als Fundamentinvestition zu Buche und steht anschließend jedem weiteren Use Case zur Verfügung.
| Use Case | Punkt-zu-Punkt (kumuliert) | UNS-basiert (kumuliert) |
|---|---|---|
| Fundament (einmalig, vor UC 1) | – | 50.000 € |
| UC 1 – Produktionsmonitoring | 30.000 € | 59.000 € |
| UC 2 – Traceability | 61.000 € | 68.000 € |
| UC 3 – Predictive Maintenance | 93.000 € | 78.000 € |
Der Unterschied liegt in den Grenzkosten: Bei Punkt-zu-Punkt schlägt jeder weitere Use Case erneut mit rund 30.000–32.000 € zu Buche, da seine Anbindungen vollständig neu entstehen und die Zahl der parallel zu pflegenden Verbindungen mit jedem Schritt wächst. Im UNS-basierten Ansatz reduziert sich der Aufwand pro Use Case nach der Fundamentinvestition auf 9.000–10.000 €, weil die Anbindung der 100 Systeme und deren Harmonisierung bereits geleistet sind. Der Break-even liegt in diesem Beispiel zwischen dem zweiten und dritten Use Case: Nach UC 2 ist die Punkt-zu-Punkt-Lösung noch günstiger (61.000 € gegenüber 68.000 €), nach UC 3 kehrt sich das Verhältnis um (93.000 € gegenüber 78.000 €) – und der Abstand wächst mit jedem weiteren Use Case der Roadmap.
i-flow als Fundament für den vollen Datenstack
Die sinkenden Grenzkosten aus der Beispielrechnung treten nur ein, wenn die Architekturschicht auf Wiederverwendung statt auf Neubau ausgelegt ist. i-flow setzt dies über drei Komponenten um: Der i-flow Edge verbindet sich über native Protokolle wie OPC UA, Modbus oder Siemens S7 direkt mit SPSen, Sensoren und SCADA-Systemen und normalisiert die Rohdaten an der Quelle. Der i-flow Hub verwaltet die UNS Semantik zentral, sodass eine einmal definierte Semantik für jeden weiteren Use Case wiederverwendet wird. Der i-flow Broker stellt die harmonisierten Daten über MQTT oder NATS zuverlässig jedem berechtigten Consumer bereit.
Für die Beispielrechnung bedeutet das: Ein neuer Use Case befasst sich weder erneut mit SPS-Protokollen noch mit Datenmodellierung, sondern abonniert bereits harmonisierte Topics im UNS. Diese Wiederverwendbarkeit senkt die Grenzkosten pro Use Case und lässt den Unified Namespace ROI mit jedem neuen Use-Case steigen.
Fazit
Der Unified Namespace ROI entsteht nicht in der Architektur selbst, sondern in den Use Cases, die auf ihr betrieben werden. Eine isolierte Bewertung der Architekturschicht misst am falschen Objekt – analog zur Frage nach dem ROI der Gebäudearchitektur eines Hotels. Drei zentrale Erkenntnisse:
- Architektur hat keinen eigenständigen ROI: Der Wert entsteht in den Use Cases auf dem UNS-Fundament, nicht im Fundament selbst.
- ROI end-to-end berechnen: Der Datenstack aus UNS, Anwendungen und Use Cases gehört in eine gemeinsame Rechnung – im Beispiel mit Break-even ab dem dritten Use Case.
- Bewertungsobjekt korrekt abgrenzen: Maßgeblich ist nicht der ROI des Unified Namespace, sondern der ROI der Anwendungslandschaft, die er ermöglicht.
