Composable MES (cMES): Modularer Baukasten statt Monolith

Was ist ein Composable MES?

Ein Composable MES (cMES) ist ein Manufacturing Execution System, das nicht als monolithische Komplettlösung kommt, sondern aus kombinierbaren Funktionsbausteinen besteht: eigenständige Module oder Apps, die über ein gemeinsames Datenmodell und offene Schnittstellen zusammenarbeiten. Statt "ein MES für alles" werden passende Module für konkrete Use Cases zusammengestellt und schrittweise erweitert.

Der Begriff "Composable" stammt aus der Softwarearchitektur und wurde durch Gartner populär gemacht. Die Grundidee: Statt ein großes, eng gekoppeltes System zu kaufen, das 80 % Funktionen mitbringt, die man nicht braucht, stellt man sich genau die Bausteine zusammen, die man braucht, und ergänzt schrittweise. In der Fertigungsindustrie bedeutet das: Einstieg mit Maschinendatenerfassung und OEE, dann Erweiterung um Auftragssteuerung, Traceability, Qualität oder Energie-Monitoring, je nach Bedarf.

Mark Kobbert (CTO, SYMESTIC): "Wir haben Mitte der 2010er Jahre aufgehört, bestehende Software in die Cloud zu verschieben, und stattdessen von Grund auf neu entwickelt. Cloud-native, Microservices, API-first, auf Microsoft Azure. Das war kein inkrementelles Update, das war ein Neuanfang. Jede Entscheidung, von der Datenbankarchitektur bis zum Gateway-Protokoll, wurde auf Skalierbarkeit, Echtzeitfähigkeit und Wartbarkeit ausgelegt. Das Ergebnis ist ein modularer Baukasten, bei dem jeder Kunde genau die Module aktiviert, die er braucht, und eigenständig erweitert."

Die 5 Merkmale eines echten Composable MES

Nicht jedes System, das sich "modular" nennt, ist ein Composable MES. Die folgende Prüfliste unterscheidet echte cMES-Architektur von Marketing-Labels:

Wenn ein System alle fünf Merkmale erfüllt, ist es ein Composable MES. Wenn es nur zwei oder drei erfüllt, ist es wahrscheinlich ein modularer Monolith mit cMES-Marketing.

Composable MES vs. Monolith vs. Modularer Monolith

Die meisten Vergleiche stellen cMES nur dem "klassischen MES" gegenüber. Das greift zu kurz. In der Praxis gibt es drei Architekturtypen, und der mittlere wird oft verwechselt:

Der entscheidende Unterschied zwischen einem modularen Monolith und einem Composable MES: Beim modularen Monolith können Sie Module kaufen, aber nicht unabhängig betreiben. Updates eines Moduls erfordern ein Redeployment des gesamten Systems. Bei einem echten cMES können Module unabhängig aktiviert, aktualisiert und skaliert werden, weil sie technisch entkoppelt sind.

Risiken und Governance: Was cMES nicht automatisch löst

Composable klingt attraktiv, hat aber Fallstricke:

Ohne Datenmodell entstehen neue Silos. Wenn jedes Werk eigene Definitionen für Maschinen, Stillstandsgründe und KPIs verwendet, produziert ein cMES genauso viele Inseln wie ein Excel-basierter Ansatz, nur moderner verpackt. Die Lösung: Einheitliches Datenmodell vor dem Rollout definieren. ISA-95 als Basis. Reason Codes standardisieren. KPI-Definitionen zentral festlegen.

Self-Service ist nicht Self-Governing. Wenn Key User eigenständig Dashboards, Reason Codes und Konfigurationen ändern können, braucht es klare Governance: Wer darf was ändern? Wie werden Änderungen dokumentiert? Wie wird sichergestellt, dass Werk A und Werk B vergleichbar bleiben? Die Freiheit der Konfiguration braucht den Rahmen der Standards.

Proprietäre Low-Code-Plattformen schaffen neue Abhängigkeiten. Manche Anbieter verpacken Vendor Lock-in als "No-Code-Flexibilität". Die Prüffrage: Kann ich meine Daten jederzeit über dokumentierte APIs exportieren? Kann ich das System wechseln, ohne alle Konfigurationen zu verlieren? Echte Composability setzt offene Standards voraus, nicht proprietäre Plattformen.

Cloud-native ist nicht gleich Cloud-native. "Lift and Shift" (bestehende On-Premise-Software in einer VM in der Cloud betreiben) ist kein Cloud-native. Ein echtes Cloud-native-System wurde für die Cloud entwickelt: Microservices, automatische Skalierung, automatische Updates, Multi-Tenancy. Die Prüffrage: Kann der Anbieter 200 Maschinen auf einmal aufschalten, ohne dass ein Server provisioniert werden muss?

Kundenbeispiele: Composable MES in der Praxis

Klocke (Pharma, Verpackung): Einstieg in Tagen, Skalierung in 3 Wochen. Einstieg mit einem Modul (MDE: Stückzahlen und Stillstände über DI-Gateway). Keine LAN-Infrastruktur nötig. Skalierung auf alle Linien in 3 Wochen. Eigenständige Erweiterung durch den Kunden. Ergebnis: "7h mehr Produktionszeit innerhalb einer Woche. 12 % Verbesserung der Ausbringung." Das ist cMES in Reinform: Klein starten, schnell Mehrwert sehen, eigenständig erweitern.

Meleghy (Automotive, 6 Werke): Multi-Werk-Skalierung ohne Redeployment. Einstieg im Werk Wilnsdorf. Skalierung auf 5 weitere Werke (Gera, Brandys, Bernsbach, Reinsdorf, Miskolc) in 6 Monaten. Einheitliches Datenmodell über alle Werke. Bidirektionale SAP-Anbindung. Bidirektionale Anbindung an CASQ-it. Eigenständige Skalierung durch den Kunden. "Schnelle Umsetzung in nur 6 Monaten auf alle 6 Werke."

Carcoustics (Automotive, 500+ Anlagen): Ablösung einer Bestandslösung. "Einstieg mit einem POC im Werk Haldensleben. Ablösung einer Bestandslösung in Polen und Haldensleben. Skalierung innerhalb von 6 Monaten auf 500+ Anlagen in allen Werken." OT-Integration über IXON IoT-Gateways und MQTT in Microsoft Azure. Eigenständige Skalierung durch den Kunden. Das zeigt die Composable-Stärke: Eine bestehende monolithische Lösung wird nicht migriert, sondern durch ein cMES ersetzt, Werk für Werk.

Neoperl (Building, Montageautomaten): Schrittweise Erweiterung der Use Cases. Start mit 4-wöchigem Proof of Concept an einer Anlage. Nach erfolgreichem PoC: Vertragsabschluss und Integration der ersten drei Anlagen. Seitdem: kontinuierliche Erweiterung durch den Anschluss weiterer Anlagen. "Eigenständige Erweiterung durch modularen SYMESTIC-Baukasten." Jede Anlage wird unabhängig angebunden, jeder Use Case schrittweise ergänzt.

Häufige Fragen zu Composable MES

Ist cMES nur ein Buzzword für "modulares MES"?

Teilweise. Viele Anbieter labeln ihre bestehenden Systeme als "composable", ohne die Architektur dahinter zu ändern. Der reale Unterschied: Bei einem echten cMES sind Module technisch entkoppelt (eigenständige Microservices mit eigenem Lifecycle), nicht nur kommerziell getrennt (separate Lizenzen für dieselbe Codebasis). Die Prüffrage: Kann ich ein einzelnes Modul aktualisieren, ohne das Gesamtsystem neu zu deployen?

Ersetzt cMES Standards wie MESA-11 oder ISA-95?

Nein. cMES adressiert die Architektur-Frage (wie wird das System gebaut und bereitgestellt?). Die fachlichen Funktionen orientieren sich weiterhin an MESA-11 (was soll das MES tun?) und ISA-95 (wie werden Systeme technisch gekoppelt?). Die 11 MESA-Funktionen werden in einem cMES genauso abgedeckt, nur als unabhängige Module statt als eng gekoppelte Teile eines Monolithen.

Für wen lohnt sich cMES besonders?

Für Unternehmen mit mehreren Werken und unterschiedlichen Anforderungen, die schnell und iterativ digitalisieren wollen. Für Unternehmen, die heute mit MDE und OEE starten und in 12 Monaten Traceability, Auftragssteuerung oder Qualität ergänzen wollen, ohne das System neu aufzusetzen. Für Unternehmen, die eigenständig skalieren wollen, ohne für jede neue Maschine oder jedes neue Dashboard einen Berater zu beauftragen.

Was kostet ein Composable MES im Vergleich zu einem klassischen?

Bei einem klassischen On-Premise-MES fallen hohe Investitionskosten an (Lizenzen, Server, Implementierung). Bei einem Cloud-native cMES wie SYMESTIC: monatliche SaaS-Gebühr, keine Server, keine Investitionskosten. Die Total Cost of Ownership ist in der Regel niedriger, weil Updates, Wartung und Hosting in der SaaS-Gebühr enthalten sind und keine IT-Infrastruktur beim Kunden betrieben werden muss.

Kann ich von einem monolithischen MES auf ein cMES wechseln?

Ja. Der typische Weg: Nicht Big-Bang-Migration, sondern paralleler Aufbau. Das cMES wird zunächst für einen Use Case (z. B. OEE-Monitoring) parallel zum bestehenden System eingeführt. Dann werden schrittweise weitere Funktionen auf das cMES verlagert, bis das alte System abgeschaltet werden kann. Bei Carcoustics wurde eine bestehende Lösung in Polen und Haldensleben durch SYMESTIC abgelöst, Werk für Werk, innerhalb von 6 Monaten.

Über den Autor:

Mark Kobbert

CTO der symestic GmbH. Verantwortet die Cloud-MES-Architektur seit 2014. B.Sc. Wirtschaftsinformatik.
LinkedIn