Warum Normen den Anschluss verlieren – und wie Konzerne trotzdem standardisieren können
Die Standardisierungslücke
Jeder, der Digitalisierung in der Fertigung verantwortet, kennt den Reflex: Wir brauchen einen Standard. Ein Protokoll für die Maschinenanbindung, eine Plattform für Datenanalyse, ein Tool für Shopfloor-Management. Nicht aus Prinzipienreiterei, sondern aus nüchterner Ökonomie: Jede zusätzliche Lösung im Stack kostet Betrieb, Wartung, Security-Patches, Schulung und irgendwann den Kollegen, der als Einziger noch weiß, wie sie funktioniert.
Die Frage ist also nicht, ob man standardisieren sollte. Die Frage ist, woran man sich orientiert. Und hier beginnt das Problem. Wer heute nach einer Referenz sucht, findet entweder keine, weil die Technologie zu jung ist, oder eine, die den Stand von vor fünf Jahren beschreibt. Beides hilft bei der Entscheidung, die nächste Woche ansteht, nicht weiter.
Dabei mangelt es nicht an Standards. Es gibt viel zu viele davon. Für die Maschinenanbindung allein konkurrieren OPC UA, MQTT, Modbus, PROFINET, MTConnect und ein Dutzend herstellerspezifischer Protokolle. Auf jeder Ebene des Stacks wiederholt sich das Bild. Und dann kommt verlässlich jemand, der einen neuen Standard entwickelt, um alle bisherigen zu vereinen, und die Zahl steigt um eins. Dieser Reflex ist so bekannt, dass er als Comic zum Klassiker geworden ist, und er zeigt das eigentliche Problem: Nicht der Mangel an Standards lähmt Unternehmen, sondern die fehlende Entscheidung, welcher gilt.
Das betrifft zwei Ebenen gleichzeitig. Auf dem Shopfloor geht es um Kommunikationsprotokolle und Datenmodelle: Wie sprechen Maschinen, Sensoren und Systeme miteinander? Auf Unternehmensebene geht es um den gesamten Tech-Stack: Welche Softwarelösungen setzen wir ein, und wie viele davon dürfen es sein? Auf beiden Ebenen wird die Lücke zwischen dem, was Normen beschreiben, und dem, was der Markt längst tut, jedes Jahr größer.
Dieser Artikel ist ein Versuch, diese Lücke ehrlich zu benennen und einen praktikablen Umgang damit vorzuschlagen. Nicht als Abgesang auf die Normung, sondern als Aufforderung, sie neu zu denken.
Warum Normen den Anschluss verlieren
Eine Norm beschreibt den allgemein anerkannten Stand der Technik. Das ist ihr Auftrag und gleichzeitig ihr strukturelles Problem: „Allgemein anerkannt“ setzt voraus, dass sich eine Technologie bereits durchgesetzt hat, dass ein Gremium sie diskutiert, Einsprüche bearbeitet und einen Konsens gefunden hat. Das dauert bei DIN, VDI oder IEC in der Regel drei bis fünf Jahre. In einer Welt, in der KI-Modelle im Halbjahrestakt erscheinen, ist eine Norm bei Veröffentlichung damit fast zwangsläufig Vergangenheit.
Während ein Normungsverfahren von der Bedarfserkennung bis zur Veröffentlichung läuft, erscheinen auf der Technologieseite mehrere Versionen. Die Norm beschreibt bei Erscheinen bestenfalls den Stand, mit dem sie begonnen hat.
OPC UA ist das Lehrbuchbeispiel. Als Grundstandard seit 2008 verfügbar, brauchte es weit über ein Jahrzehnt, bis Companion Specifications für einzelne Maschinentypen praxistauglich waren. Parallel dazu haben sich MQTT, Sparkplug B und der Unified Namespace in Fabriken weltweit etabliert, ohne dass eine Norm sie je gefordert hätte. Der Markt hat entschieden, bevor das Gremium fertig war.
Dazu kommt ein zweites Problem: Normen sind Closed Standards. Sie kosten Geld, liegen als PDF vor, sind nicht maschinenlesbar und bringen keine Referenzimplementierung mit. Ein Entwickler, der heute ein Protokoll adaptieren will, erwartet ein Repository, ein SDK und eine Community. Eine Norm liefert nichts davon. Wer sie umsetzen will, muss erst kaufen, dann interpretieren, dann alleine bauen.
Die Normungsorganisationen wissen das. Zwei Antworten liegen bereits auf dem Tisch, und beide sind ernst gemeint:
- DIN SPEC ist der Schnellweg: Eine Spezifikation, die ein kleines Konsortium ohne vollständiges Konsensverfahren in wenigen Monaten erarbeitet und die meist kostenlos verfügbar ist. Sie hat keinen Normstatus, kann aber später in eine Norm überführt werden. In der Praxis bleibt sie oft ein Nischenprodukt: Wenige kennen sie, wenige nutzen sie, und der Übergang zur Norm dauert wieder Jahre. Selbst dieser Schnellweg hält mit dem Tempo großer Technologieunternehmen nicht mit: Anthropic hat MCP mit deutlich mehr Ressourcen in kürzerer Zeit entwickelt, veröffentlicht und mit SDKs ausgestattet, als ein DIN-SPEC-Konsortium für seinen ersten Entwurf braucht.
- SMART Standards sind die Initiative von DIN und DKE, Normen maschinenlesbar und maschineninterpretierbar zu machen. Das Ziel ist richtig: Inhalte sollen direkt in Engineering-Tools und Prüfsysteme fließen. Das Tempo ist es nicht. Die Initiative läuft seit Jahren, während der Großteil des Normenbestands weiter als PDF vorliegt. Auch hier ist die Realität dem Gremium bereits enteilt: Während die Normung XML als Zwischenschritt zur Maschinenlesbarkeit definiert, wandeln Open-Source-Werkzeuge wie Docling von IBM Research, unter MIT-Lizenz frei verfügbar, längst komplexe wissenschaftliche Dokumente in maschinenlesbares Markdown um. Die Technik war wieder schneller als das Verfahren.
Beide Ansätze zeigen, dass die Diagnose angekommen ist. Was fehlt, ist der Kulturwandel dahinter. Das Selbstverständnis vieler Gremien ist weiterhin: Wir definieren, was gilt. Der Zeitgeist und die Anforderungen einer schnelllebigen Technologiewelt verlangen etwas anderes: Wir stellen bereit, was funktioniert, und zwar offen, schnell und in einer Form, die Entwickler tatsächlich benutzen können.
Dieser Kulturwandel ist schwierig, und man muss ehrlich sagen, warum: Das Geschäftsmodell der Normungsorganisationen basiert darauf, am Zugang zu dem zu verdienen, „was gilt“. Wer seine Einnahmen aus dem Verkauf von Dokumenten bezieht, hat wenig Anreiz, diese Dokumente offen, kostenlos und maschinenlesbar bereitzustellen. Es geht also nicht nur um Verfahren, sondern um den Willen zur eigenen Geschäftsmodell-Innovation. Die Open-Source-Welt zeigt, dass sich mit offenen Standards Geld verdienen lässt, nur eben nicht am Standard selbst, sondern an Zertifizierung, Konformitätsprüfung, Werkzeugen und Beratung darum herum. Wer diesen Schritt nicht geht, wird nicht schneller werden können, weil er es sich nicht leisten kann.
Wer heute Standards setzt
In die Lücke, die Normen hinterlassen, treten zwei Akteure: Technologieunternehmen und Open-Source-Foundations.
Anthropic hat Ende 2024 das Model Context Protocol (MCP) veröffentlicht, eine Schnittstelle, über die KI-Modelle auf Datenquellen und Werkzeuge zugreifen. Innerhalb weniger Monate wurde es von den großen Softwareanbietern übernommen, und Ende 2025 ging die Governance an eine Foundation unter dem Dach der Linux Foundation über. Im August 2026 folgte der Model Hardware Standard (MHS): standardisierte Treiber, über die KI-Agenten Laborgeräte, Roboterarme oder Fertigungsequipment ansteuern, mit hinterlegten Grenzen für sicheren Betrieb. Das Ganze modellagnostisch, als Research Preview, mit angekündigter Open-Source-Freigabe. Kein Gremium, kein Konsensverfahren, kein Preis.
Die Linux Foundation treibt mit Margo einen offenen Interoperabilitätsstandard für Edge-Anwendungen in der Industrie voran, getragen von Automatisierungsherstellern, die sonst Wettbewerber sind. Die Eclipse Foundation hat mit Sparkplug B dem MQTT-Protokoll ein Datenmodell für die Fabrik gegeben. Und die Industrial Digital Twin Association entwickelt die Verwaltungsschale als offene Spezifikation mit Referenzimplementierung, bevor sie zur IEC-Norm wird. Das ist der interessanteste Mittelweg: Konsortium und Normung greifen ineinander, statt nacheinander zu arbeiten.
Das Muster ist bei allen gleich. Was sich durchsetzt, bringt eine Referenzimplementierung mit, ist frei zugänglich, hat eine Community und wird von denen entwickelt, die es selbst benutzen. Dokument plus Gremium plus Paywall verliert gegen Repository plus Community plus Offenheit. Nicht, weil die Inhalte schlechter wären, sondern weil Adoption heute über Nutzbarkeit entschieden wird.
Beide Modelle erzeugen Standards. Nur eines erzeugt sie in einer Form, die ein Entwicklungsteam am selben Tag einsetzen kann.
Das hat eine Kehrseite, die Entscheider im Blick behalten müssen. Ein Standard, den ein einzelnes Unternehmen kontrolliert, ist zunächst ein Produkt mit strategischem Interesse. Der Prüfstein ist die Governance-Übergabe: Wandert der Standard in eine neutrale Foundation, wie MCP es getan hat, oder bleibt er ein Werkzeug zur Marktbindung? Wer De-facto-Standards adaptiert, sollte diese Frage in seine Bewertung aufnehmen.
Fairerweise muss man sagen: Das Gremienmodell steht über dieser Kritik nicht, und es ist auch nicht so unabhängig, wie sein Selbstbild nahelegt. In Normungsgremien sitzen Vertreter genau der Unternehmen, deren Produkte die Norm später betrifft. Beispiele haben wiederholt gezeigt, wie daraus Lobbyarbeit wird: Ein Hersteller schreibt seine eigene Technologie in die Norm, ein Konsortium etablierter Anbieter definiert Anforderungen, die Newcomer nicht erfüllen können, oder eine Branche normiert sich faktisch selbst, mit geschäftlichem Interesse am Ergebnis. Der Unterschied zu einem unternehmensgetriebenen Standard liegt also nicht darin, dass der eine Interessen hat und der andere nicht. Der Unterschied liegt in der Transparenz: Ein offenes Repository zeigt, wer wann was beigetragen hat, während die Verhandlungen eines Gremiums hinter verschlossenen Türen bleiben. Unabhängigkeit garantiert keines der beiden Modelle. Sie muss in beiden geprüft werden.
Was das für Unternehmen bedeutet
Der Wunsch nach unternehmensinternen Standards ist ökonomisch richtig. Weniger Lösungen bedeuten weniger Betriebsaufwand, weniger Schnittstellen, weniger Security-Angriffsfläche und weniger Skills, die man vorhalten muss. Im Mittelstand funktioniert das auch. Die Entscheidungswege sind kurz, die Zuständigkeiten klar, und wenn die Geschäftsführung ein System vorgibt, wird es eingeführt.
Im Konzern ist genau das nahezu unmöglich. Ich habe mehrfach erlebt, wie wir versucht haben, ein Tool global über ein Gremium auszurollen. Jedes Mal machten die spezifischen Anforderungen einzelner Standorte Anpassungen nötig, und aus dem einen Standard wurden drei Varianten. Das ist kein Versagen der Beteiligten. Es ist die Logik einer Matrixorganisation: Wenn Abteilungen und Werke eigene Budgets haben, kann man ihnen die Entscheidungsgewalt nicht wegnehmen und gleichzeitig über ihr Geld verfügen. Wer zahlt, entscheidet mit.
Die größte Herausforderung, und da wird mir jeder zustimmen, der in diesem Bereich arbeitet, ist die weltweite Skalierung digitaler Use Cases. In heterogenen Gruppen mit unterschiedlichen Produktionsprozessen, Reifegraden und lokalen Vorgaben den einen Fall zu entwickeln, der überall passt, ist praktisch ausgeschlossen. Wer es trotzdem versucht, landet bei einem System, das alles irgendwie kann und nichts richtig. Niemand will ein zweites SAP einführen, das jede Anforderung abdeckt und dabei die Nutzerfreundlichkeit verliert, die den Use Case überhaupt erst wertvoll gemacht hat.
Das Top-Management kann diesen Knoten nicht durchschlagen, und das ist verständlich. Ein Vorstand wird nie bis zur letzten Technologieentscheidung hinuntergehen und sagen: „Das nehmt ihr jetzt.“ Dafür ist er zu weit von der Technik entfernt, und der Teufel steckt bei der Implementierung im Detail. Ein Mandat von oben löst also die Frage nach dem Was, aber nie die nach dem Wie.
Zwei Dinge haben sich in meiner Erfahrung bewährt, allerdings nur für das, wofür sie gemacht sind. Übergeordnete Governance-Bodies sind wichtig für das Alignment: Sie schaffen den Rahmen, in dem Entscheidungen überhaupt vergleichbar werden. Communities of Practice sind hervorragend, um voneinander zu lernen und Lösungen sichtbar zu machen. Entscheidungen herbeiführen können sie nicht, und wer das von ihnen erwartet, wird enttäuscht. Standardisierung im Konzern braucht deshalb einen Prozess, der beides verbindet und mit der Budgethoheit arbeitet, statt gegen sie.
Standards als Produkt, nicht als Vorschrift
Der Ausweg beginnt mit einer Unterscheidung, die in vielen Unternehmen fehlt: Nicht alles, was „Standard“ heißt, braucht denselben Grad an Verbindlichkeit. Drei Ebenen lassen sich klar trennen.
| Ebene | Verbindlichkeit | Beispiele | Wer setzt den Rahmen |
|---|---|---|---|
| Safety, Security, Compliance | Verbindlich, keine Ausnahmen | IEC 62443, Maschinenverordnung, Cyber Resilience Act | Normen und Gesetzgeber, hier bleiben sie unverzichtbar |
| Schnittstellen und Datenmodelle | Verbindlich auf Protokollebene | OPC UA, MQTT/Sparkplug, Unified Namespace, MCP, Verwaltungsschale | Konzernweiter Architekturrahmen, orientiert an De-facto-Standards |
| Produkte und Tools | Empfohlen, nicht vorgeschrieben | MES-Module, Analytics-Plattformen, Low-Code-Tools | Plattform-Team mit Golden Path |
Die erste Ebene ist der Bereich, in dem Normen ihre Berechtigung behalten. Hier geht es um Haftung, Zulassung und Rechtssicherheit, und hier ist Langsamkeit ein Feature, kein Fehler. Die zweite Ebene ist der eigentliche Hebel: Wer Protokolle und Datenmodelle verbindlich macht, kann die Tool-Auswahl freigeben. Ein Werk, das seine Maschinendaten über OPC UA in einen Unified Namespace liefert, darf darauf aufsetzen, was es will. Die Integration bleibt beherrschbar, weil die Schnittstelle stabil ist. Die dritte Ebene wird nicht standardisiert, sondern attraktiv gemacht.
Daraus ergibt sich ein Prozess, der mit der Realität des Konzerns arbeitet statt gegen sie:
- Tiering statt Verbot. Jede Technologie im Stack bekommt einen Status: Mandatory, Recommended, Tolerated oder Retire. Das ergibt einen internen Tech-Radar, der jede Lösung mit einem Ablaufdatum versieht. Alle zwölf Monate wird überprüft, ob der Status noch stimmt. Ein Standard, der kein Review-Datum hat, ist keiner.
- Comply or Explain. Abweichungen von Mandatory und Recommended sind erlaubt, aber sie werden dokumentiert, begründet und mit Kostenverantwortung versehen. Wer abweicht, trägt den Mehraufwand für Betrieb und Integration selbst. Das respektiert die Budgethoheit und macht die Kosten der Fragmentierung sichtbar, statt sie in der Zentrale zu verstecken.
- Plattform-Team als Enabler. Ein zentrales Team liefert Referenzimplementierungen, Templates, Integrationsbausteine und Support für den Golden Path. Der Standard wird nicht angeordnet, sondern angeboten: Wer ihn nutzt, ist schneller. Das ist genau das Prinzip, mit dem sich MCP oder Sparkplug durchgesetzt haben, nur nach innen gewendet.
- Governance-Body entscheidet, Community lernt. Der Governance-Body setzt den Architekturrahmen und den Tech-Radar und entscheidet über Statuswechsel. Die Community of Practice ist der Ort, an dem Werke Lösungen zeigen, Erfahrungen teilen und Vorschläge für den Radar entstehen. Beide Rollen bleiben getrennt. Entscheidungen werden als kurze Architecture Decision Records festgehalten, nicht als 80-seitige Richtlinie.
- Funding als Hebel. Standardkonforme Lösungen werden zentral mitfinanziert, etwa über Integration, Betrieb oder Lizenzen. Ausnahmen finanzieren sich selbst. Das ist der einzige Mechanismus, der in einer Matrixorganisation zuverlässig wirkt, weil er die Entscheidung dort lässt, wo das Budget liegt, und trotzdem eine Richtung vorgibt.
- Adoption messen, nicht Compliance. Der Erfolg eines Standards zeigt sich nicht in einem Audit, sondern darin, wie viele Standorte ihn freiwillig übernehmen. Eine Adoptionsrate unter 50 Prozent nach zwei Jahren bedeutet nicht, dass die Werke falsch liegen, sondern dass der Standard nicht gut genug ist.
Entscheidung und Lernen laufen im Kreis: Der Governance-Body setzt den Rahmen, das Plattform-Team macht ihn nutzbar, die Werke wählen darin, und ihre Erfahrungen fließen über die Community zurück in die nächste Entscheidung.
Das Modell löst das Skalierungsproblem nicht vollständig, und das behauptet es auch nicht. Es akzeptiert, dass der eine Use Case für alle nicht existiert, und sorgt stattdessen dafür, dass lokale Varianten auf einem gemeinsamen Fundament stehen. Skaliert wird die Schnittstelle, nicht das Tool.
Standardisierung ist ein Prozess, kein Dokument
Ich schreibe das nicht von außen. Als Vorstandsvorsitzender eines VDI-Bezirksverbands bin ich Teil einer Organisation, die Richtlinien erarbeitet, und ich halte diese Arbeit für wertvoll. Gerade deshalb sehe ich, wo sie sich verändern muss. Normung hat ihre Rolle nicht verloren. Sie hat sie verlagert: weg von der Definition dessen, was gilt, hin zur Absicherung dessen, was sich bereits durchgesetzt hat. Für Safety und Compliance ist das genau richtig. Für Interoperabilität und Tooling kommt sie zu spät, und das wird sich nicht ändern, solange das Verfahren bleibt, wie es ist.
An die Normungsorganisationen geht deshalb ein konkreter Wunsch: Arbeitet mit den Foundations, statt neben ihnen. Übernehmt bewährte De-facto-Standards in die Normung, statt eigene Alternativen zu entwickeln. Macht Inhalte von Anfang an maschinenlesbar und frei zugänglich, mit Referenzimplementierung. Und messt euch am Tempo der Technologie, nicht am Tempo des Gremiums.
An die Unternehmen geht ein anderer: Hört auf, Standards als Vorschriften zu behandeln, die man durchsetzen muss. Behandelt sie als Produkte, die gut genug sein müssen, um freiwillig übernommen zu werden. Standardisiert Schnittstellen, gebt Tools frei, arbeitet mit der Budgethoheit statt gegen sie und versieht jede Entscheidung mit einem Ablaufdatum.
Die Beschleunigung der Technologie ist keine Phase, die vorbeigeht. Agentic AI macht Interoperabilität zur Grundvoraussetzung: Ohne offene Schnittstellen gibt es keinen Agenten, der über Systemgrenzen hinweg arbeitet. Der Druck auf Standardisierung wird also weiter steigen. Die Frage ist nur, ob wir ihn mit Verfahren beantworten, die aus einer langsameren Zeit stammen, oder mit einem Prozess, der die Geschwindigkeit als gegeben nimmt.
