Vibe-Coding im Shopfloor: MES-Anwendungen selbst bauen ohne Systemintegrator

Vibecoding in der Fabrik – wie generative künstliche Intelligenz ganze MES-Systeme ersetzen kann. Zu Gast haben wir die Firma United Manufacturing Hub, kurz UMH. Das ist eine Firma, die ihre Lösung kostenlos als sogenannte Open Source zur Verfügung stellt und damit eine stark wachsende Community an begeisterten Nutzern hat. Wie man dann trotzdem noch Geld verdient und was noch alles mit KI in der Fabrik möglich ist, das erfahrt ihr heute. Viel Spaß dabei.

Hallo, liebe Freunde des IoT. Willkommen beim IoT Use Case Podcast. Heute sprechen wir über ein Thema, das gerade in vielen Werken mehr und mehr relevant wird. Was passiert, wenn generative KI plötzlich nicht nur Texte schreibt, sondern auch Produktionsanwendungen baut? Dazu habe ich als Gast Alexander Krüger von United Manufacturing Hub, kurz UMH. UMH positioniert sich als Open-Source-Plattform für industrielles Datenmanagement. Alexander ist dort CEO und Managing Director. Alexander, lass uns gleich reinsteigen.

Welches Problem beim Kunden löst ihr denn?

Alexander

Danke, Peter. Ich glaube, nicht nur für AI, sondern grundsätzlich haben unsere Kunden das Problem, dass sie nicht in ihre Daten reinkommen. Das heißt, die haben irgendwo Produktionsdaten im MES, im ERP, gegebenenfalls in den verschiedenen Systemen wie im Warehouse-Management, auf den SPSen, im SCADA, im Historian. Aber die sind nirgendwo wirklich einfach und konsistent zugänglich. Und genau das wollen wir lösen – dass man quasi die ganzen Daten, die man hat, schön strukturiert und verfügbar macht, dann beispielsweise super tolle Frontends drüber zu Vibe-coden. Darum geht es ja heute.

Freut mich sowieso extrem, gerade über Vibe-Coding zu sprechen, weil das hat sich super dynamisch entwickelt und entwickelt sich immer weiter. Mein Hintergrund gerade ist ja auch ganz intensiv generative KI. Es hat ja im Fertigungsumfeld schon Herausforderungen – Halluzination und Ähnliches. Die ersten Anwendungsfälle, die man für generative KI im Shopfloor gehört und gesehen hat, sind so Themen wie Dokumentation – das benutzte Handbuch verfügbar zu machen und da Fragen stellen zu können. Ihr geht jetzt deutlich einen Schritt weiter. Gleichzeitig ist euer Fokus ja gar nicht Vibe-Coding selbst, sondern die Grundlage dazu. Kannst du das mal ein bisschen ausführen?

Alexander

Vor 18 Monaten war AI in Manufacturing offensichtlich ein Thema, aber keiner wusste ganz genau, wie man da rangeht. Es wurde quasi GPT in irgendeiner Form mit den Daten integriert und dann gesagt: „Ask your AI" oder „Ask your Factory." Und dann hat die dir gesagt, warum deine OEE schlecht ist oder warum Maschine 5 eine höhere Downtime hat als Maschine 2. Und ich glaube, das ist eigentlich nicht das Problem. Das sind ja meistens Sachen, die entweder sehr offensichtlich sind oder wenig hilfreiche Tipps: „Du hast offensichtlich technische Verfügbarkeitsprobleme, erhöhe mal deine Wartung" oder „Versuche öfter oder schneller zu reagieren, wenn deine Maschine stillsteht." Das ist jetzt ja nicht wirklich hilfreich.

Und deswegen hat man sich eigentlich eher auf andere Sachen fokussiert – eigentlich nichts neu gemacht, sondern nur Sachen, die man schon machen wollte, viel einfacher und schneller. Und das löst, finde ich, ein sehr cooles Problem in Manufacturing – dieses ganze Thema mit den Fähigkeiten. Das heißt, unsere Kunden hatten eigentlich ganz viele Use Cases, die technisch schon vorher umsetzbar waren. Sie wollten Transparenz über Maschinenauslastung, über Werkzeugeinsätze, über Ressourcenverbräuche – runtergebrochen auf verschiedene Analysen und Segmente und Maschinen. Und jetzt haben sie einfach ein Tool in der Hand, was unfassbar einfach Frontends bauen kann.

Das ist quasi das Coole an AI. Es gibt noch kein Weltmodell, wo du deine Fabrikdaten reinschraubst und die sagen dir: „Dreh mal den Prozessparameter von 5 mm/s auf 6 mm/s, dann hast du einen höheren Yield." Leider noch nicht. Aber du kannst jetzt sagen: „Bau mir bitte mal ein Frontend, das dem Werksleiter Peter ganz einfach darstellt, wo meine Top-6-Verfügbarkeitsprobleme auf Basis der Echtzeit in der Fabrik sind." Das macht es einfach echt cool, dass viel mehr Leute Applikationen bauen können als vor zwei Jahren. Also Faktor 10, 100 mehr Applikationen. Und das sehen wir gerade bei vielen unserer Kunden.

Das würde mich ein bisschen interessieren – bei welchen Kunden das gerade funktioniert. Viele haben ja noch klassische HMIs, also Human-Machine-Interfaces, die fix in die Maschine integriert sind, vom Anbieter vorgegeben, was man gar nicht ändern kann. Dann gibt es die Büros, wo dann schon was gebaut werden kann. Kannst du das mal an einem Kundenbeispiel klar machen? Haben die dann extra Bildschirme für solche Frontends ins Werk gehängt, oder welche Anwendungen gibt es da?

Alexander

Unser Beispiel, mit dem wir jetzt auch schon öffentlich kommunizieren können, ist HiPP. Das ist ein Babynahrungshersteller – die machen die kleinen Gläschen und auch die Muttermilch und so weiter, kennt man vielleicht. Und die haben tatsächlich jede Menge Vibe-gecoded-Frontends gebaut, jetzt glaube ich auch schon auf einem höheren vierstelligen Betrag an extra Claude-Usage pro Nutzer pro Monat, einfach diese Frontends zu bauen. Wir haben überall schon Bildschirme in den Fabriken aufgehängt. Das heißt, in den verschiedenen Hallen hängen Dashboards für verschiedene Top-KPIs, die dann immer „Goal versus Actual" anzeigen.

Und die haben sich jetzt tatsächlich für verschiedene Probleme, die sie hatten, Frontends gebaut. Das fängt an mit Asset-Management aufzubauen für verschiedene Produkte, die sie im Einsatz haben – sowas wie Zubehör, was in der Produktion laufen sollte und was man sich auch im Unified Namespace nachher trackt. Verschiedene Auswertungen über beispielsweise Druckluftverbräuche – was dann viel granularer und auch viel nutzerfreundlicher Eingaben ermöglicht in den Unified Namespace. Und so haben sie halt Stück für Stück erst mal für sich selbst Dinge gebaut und teilen diese dann in einer Plattform auch für andere Nutzer, so dass die auch auf Monitoren in der Produktion, auf dem Handy oder wo auch immer verfügbar sind. Und das sind immer ganz viele kleine Probleme, die man dann mal mit ein paar Tokens quasi bewirft.

Zur Einordnung: Tokens – das ist die Einheit für generative KI. Input-Tokens sind Bruchstücke von Wörtern, Teile von Wörtern – so rechnen diese Large-Language-Modelle. Weil das auch etwas ist, was ich gemerkt habe: Viele in der Industrie sind etwas verwirrt, da wird immer über KI gesprochen, und da gibt es die klassischen KI-Modelle, die Vorhersagen auf Basis von Maschinendaten machen – das sind ganz spezielle Modelle, die dafür trainiert werden. Und dann haben wir generative KI – das sind diese großen Modelle, die schon verfügbar sind.

Du hast noch ein Thema angesprochen, das wir vielleicht klären müssen: Unified Namespace – in der Industrie deutlich bekannter, aber vielleicht nicht allen. Kannst du das noch mal kurz ausführen, welche Rolle das hier spielt?

Alexander

Die Idee dahinter ist zu sagen: Man hat per se erst mal ein Strukturierungsproblem. Das heißt, ich hätte gerne Daten, aber ich habe sie nicht einfach verfügbar. Und der Unified Namespace nimmt das als Problemlösung an. Zwei Sachen: Es ist eine eventbasierte Architektur. Das heißt, alle Informationen aus meiner Fabrik kommen jetzt als Events und als Updates in Echtzeit in eine zentrale Datenplattform.

Zweitens – in einer Semantik, also in einer Struktur, in der ich die Daten auch verstehen kann. Das heißt, entlang meiner Ontologie oder meiner hierarchischen Struktur – meinem Standort, meiner Produktionsareas, meiner Linien, meiner Maschinen – habe ich das herunterstrukturiert. Dann habe ich innerhalb dieses Modells definiert, was die Attribute sind, die ich gerne hätte. Und so baue ich mir funktional und systemisch eine Datenstruktur auf. Und dann gibt es auch kompatible, vermeintlich sogar auch konkurrierende Standards – in der Chemie- und Pharmaindustrie wie die Asset Administration Shell oder das Module Type Package oder industriespezifische Standards. Aber das ist total kompatibel. Es ist eher ein High-Level-Konzept, dass man Daten zentralisieren, strukturieren und eventbasiert verarbeiten soll. Das kann man auch super kombinieren mit den verschiedenen Asset-Modellen, die es schon gibt.

Ich glaube, das ist total relevant für jeden, der in diese Richtung unterwegs ist, zu verstehen, wie wichtig die Semantik der Daten ist. Manche haben angefangen, Daten zu sammeln und in irgendwelchen Blob-Storages abzuspeichern. Aber wenn man nicht weiß, wofür ein Datenpunkt steht, wenn er keine Semantik hat, keine Beschreibung – wann, warum, zu welchem Asset er gehört –, dann kann man mit den Daten einfach nichts anfangen. Dann ist es letztendlich Müll. Und daher ist es umso wichtiger, sich eine saubere Struktur zu geben.

Alexander

Das gilt fundamental für Menschen wie für AI. Die Idee, dass AI komplett antizipieren kann, was die Daten bedeuten, ist falsch. Die AI braucht genau den gleichen Kontext, wie das ein Produktionsleiter oder ein Instandhalter bräuchte, um zu verstehen, was da gerade an Daten publiziert wird – ob das ein Instandhaltungsauftrag ist, ein Workorder oder ein Maschinenzustand. Genau wie für den Menschen müssen die Daten auch für die AI – weil die über Natural Language funktioniert – genauso verständlich sein. Dementsprechend ist es die gleiche Grundlage für beide.

Ich komme gerade aus einem KI-Training raus, wo ich immer das Thema vom Werkstudenten bringe, dem man dann erklären muss, was zu tun ist. Weil viele generative KI noch so wie einen Taschenrechner oder eine Google-Eingabe nutzen – sehr punktuell – und dann erwarten, dass Magie passiert. Und tatsächlich, wenn man versteht, wie ausführlich man jemanden etwas erklären müsste, damit ein gutes Ergebnis möglich ist, dann wird einem klar, dass es um gute Kommunikation geht, saubere Kommunikation, letztendlich Semantik.

Wenn du jetzt nochmal beschreibst – Thema Semantik verstanden, man hat eine saubere Datenstruktur und kann eine App drüber Vibe-coden –: Was genau macht ihr jetzt bei UMH?

Alexander

Nur weil man die Daten hat, heißt das nicht, dass es schon ein super Backend für eine Vibe-Coding-Applikation ist. Zur Aufdröselung: Die Vibe-Coding-Plattform ist quasi nur Frontend. Das heißt, man hat eine Applikation, die lebt in deinem Browser oder wo immer du sie installierst, und die greift dann auf unser Daten-Backend zu. Das heißt, wir versuchen der AI alle Daten und Funktionen via APIs anzubieten – also Funktionsschnittstellen –, über die man entweder Daten abrufen oder zurückspielen kann. So dass die AI sich rein auf die Visualisierung und das Nutzerinterface konzentrieren kann.

Bei uns haben wir funktional gesehen eine Plattform gebaut, die sich mit dem Auslesen von Daten aus verschiedenen Maschinen und Prozessen beschäftigt. Ich kann meine Daten aus einer Siemens-Steuerung ziehen, aus einer Rockwell-Steuerung, aus einer Beckhoff-Steuerung oder anderen – also verschiedenste Protokolle, die wir in den letzten Jahren gebaut haben. Kann sie dann in unserer Plattform normalisieren und via verschiedener APIs anbieten.

Wir haben eine API, die historische Daten anbietet – was super relevant ist für Frontends, dass man sich die Daten über die letzte Woche, Schicht, Monat, Tag anschauen kann. Und gleichzeitig auch eine Echtzeit-API für die Events – damit man direkt lesend oder schreibend auf den Echtzeitstream der Daten zugreifen kann. Und so kann ich Datenvisualisierungen oder auch Funktionen bauen – also beispielsweise: „Leg bitte eine Workorder an" oder „Ich melde jetzt einen Störgrund zurück." Klassische Mitarbeitereingaben, die man manchmal noch am HMI einfordert, können wir auch funktional anbieten, so dass die AI sich rein auf die Knöpfe, Farben und Diagramme konzentrieren kann, die von unserem Backend dann bespielt werden.

Ich glaube, das ist auch ein wichtiger Teil – zu verstehen, dass AI, wenn die Daten sauber sind, dann auch zuverlässig arbeiten kann. Die darf halt nicht mit unklaren Daten konfrontiert werden, sonst fängt sie an zu halluzinieren. Aber wenn die Daten sauber zur Verfügung gestellt werden, ist das so flexibel anzubauen – ich baue da auch immer wieder Vibe-Coding-Apps, das ist total beeindruckend, wie schnell und einfach das geht, wenn man ein paar Tokens danach wirft.

Da gibt es ja alle möglichen Standards. Du hast von APIs gesprochen, MCP und Ähnliches. Habt ihr da auch schon in die Richtung gedacht?

Alexander

Genau, es gibt verschiedene Strömungen gerade in der AI-Bubble. Wir setzen tatsächlich gerade eher auf eine CLI. Das heißt, man kann die verschiedenen Funktionen unseres Produktes und der Plattform via einer CLI anbieten, weil das eine Sache ist, mit der man total toll interagieren kann – das kennt man aus dem Programmieren. Und die APIs, die wir zum Konsumieren der Daten anbieten, sind ganz klassische REST-APIs. MCP löst halt so ein paar Sachen wie Security und Access. Aber da wir meistens mit relativ komplizierten Autorisierungsmechanismen innerhalb der Firma zu tun haben, hilft das uns gar nicht so viel, wie man vielleicht meinen sollte. Das heißt, wir entscheiden uns gerade bewusst ein bisschen gegen MCP, setzen auf CLIs und APIs, die Funktionen bereitstellen oder Daten konsumierbar machen.

Das habe ich auch schon gehört – dass MCP nicht so das Allheilmittel ist. Es ist ja auch ein Standard, der sich entwickelt, und daher muss man schauen, wo sich der in welcher Art und Weise durchsetzt und relevant ist.

Alexander

Das wird sicher noch besser werden. Aber was wir eigentlich in unserer Produktentwicklung immer gedacht haben: Was ist denn jetzt eigentlich schon „old and boring"? Und mal darauf setzen. Es ist halt nicht so, dass jede neue Technologie immer neue Technologie bedingt. Gegebenenfalls gibt es für einen Unified Namespace schon sowas wie Kafka oder Postgres, wo man total langweilig, aber hoch verfügbar Sachen abspeichern kann. Und genauso gibt es für das Interagieren mit Daten Technologien, die schon seit 10, 15, 20 Jahren klappen. Ein fun fact: GitHub – da interagiert die AI auch mit einer CLI, weil das einfach total toll, bekannt und dokumentiert ist. Das ist auch genau unsere Idee dahinter.

Da sind wir jetzt ein bisschen tiefer eingetaucht in die Schnittstellen-Thematik. Lass uns mal einen Schritt wieder nach oben kommen und überlegen: Wie kann man das alles einsetzen? Wir hatten über Dashboards gesprochen. Aber da geht es ja auch noch ambitionierter weiter. Ich denke gerade an MES-Systeme, wo ja viele mit der Komplexität kämpfen. Wo siehst du da die Grenzen von so einem Ansatz – und auch die Möglichkeiten?

Alexander

Viele Technologien oder Produkte, die man jetzt schon nutzt, sind eigentlich immer ein bisschen Frontend, Datenbank und Business-Logik. Ob ich jetzt ein Tool für Feinplanung habe, ein Tool fürs Dispatching meiner Arbeitsaufträge, ein Tool für Rückmeldung von Maschinenstunden oder von Mitarbeitern – das ist meistens immer irgendeine Frontend-Applikation, die logischerweise auf einer Datenbank läuft, aber dann extrem stark an die Business-Prozesse des Kunden angepasst wird. Es gibt kein MES-System, das industrieübergreifend und selbst innerhalb einer Industrie für jeden Kunden funktionieren würde. Und deswegen wirft man einen Systemintegrator drauf oder bezahlt dem Hersteller des MES-Systems nochmal ganz viel Geld.

Und was ich jetzt da so cool finde: Die Business-Prozesse sind dem Unternehmen ja sehr klar. Man kann extrem gut beschreiben, wie ein Rückmeldevorgang stattfindet oder ein Interlocking oder eine Prozessverriegelung oder eine Störgrundmeldung. Und jetzt kann die AI quasi Frontends gegen ein standardisiertes Backend bauen, um genau diese Sachen abzubilden. Meine Standard-MES-Anwendungen – sowas wie: Ein Mitarbeiter sagt, Arbeitsauftrag ist fertig, macht dreimal „OK" und einmal „NOK" – das ist ja irgendwie drei Buttons und vielleicht ein Unterschriftfeld. Und da kann die AI extrem gut diese kleinen Business-Prozesse bauen. Das sehe ich als riesige Chance, auch die Kosten und die Zeit massiv runterzubekommen für die Implementierung neuer Software.

Also gerade MES – wenn man das in der Form gelöst bekommt, bringt das viele im Markt: Die einen ins Schwitzen, die anderen in Begeisterungsstürme. Weil das kein einfaches Thema ist, das noch keiner in der Breite geknackt hat, und es immer sehr komplizierte Projekte sind.

Alexander

Da verschiebt sich fundamental fast alles. Du hast immer noch die Situation Build versus Buy – das war auch schon vor zwei, drei Jahren so. Was jetzt aber gerade passiert: Man verschiebt fundamental den Kostenhebel massiv runter für diese Build-Entscheidungen. Ich habe jetzt nicht mehr ein 500.000-Euro-Projekt, sondern ich kann das intern machen mit zwei, drei wirklich talentierten Entwicklern und die machen mir das in ein paar Wochen fertig für 20.000, 30.000 Euro in Tokens.

Das haben wir jetzt auch schon. Ich kenne Unternehmen – beispielsweise dieses Bauunternehmen – die haben ihr gesamtes MES-System vibe-coded. Und das ist tatsächlich auch produktiv in dutzenden Werken weltweit schon im Einsatz. Ja, das ist echt nur eine Frage von Wollen. Aber eigentlich ist es die gleiche Dynamik – nur der Kostenpunkt der Build-Entscheidung hat sich verschoben.

Es ist auch spannend – wir hatten bei IoT-Plattformen damals auch immer so Build versus Buy. Ich denke, wenn es jetzt Richtung Bauen geht, hängt da natürlich schon viel dran. Weil Bauen war immer die Schwierigkeit – wenn ich es gebaut habe, muss ich es auch maintainen. Und die Wartung ist dann schon ein Riesending, außer – und so verstehe ich dich jetzt auch – wenn man dann mit sauberen Schnittstellen zusammenarbeitet und das Frontend so flexibel und schnell anpassbar ist, dass der Maintenance-Aufwand zurückgeht. Wo siehst du da die größten Herausforderungen in dem Ansatz?

Alexander

Genau richtig. Die Frage, was muss man warten und was wird von wem gewartet, ist quasi immer der Regler, den man verschieben möchte. Was wir ganz konkret sagen: Vibe-Coding ist A nicht für jeden was. Wenn ich auf eine tiefe Integration in mein ERP-System ganz viel Wert lege, dann kann man gegebenenfalls auch SAP DM kaufen und sich die Arbeit ersparen. Oder ich habe einen tollen Business-Prozess, der genau one-to-one da schon so liegt – dann muss ich mir gar keine Gedanken mehr machen.

Aber wo ich Wartungsaufwände erzeuge, sind wirklich nur die Frontends. Ich habe diese Dateninfrastruktur im Hintergrund – die Schnittstellen muss ich warten, aber die muss ich sowieso warten, egal welches System ich habe. Und die gibt mir Daten in einem standardisierten, versionierten, auditierbaren Format. Jetzt muss ich quasi nur noch überlegen: Kommt der Graph grün oder blau, Knopf in rot, oben oder unten. Und die Wartung von solchen Frontend-Applikationen ist dann deutlich einfacher.

Klar muss man sich überlegen, wie man das Konzept für Dependencies, Updates und Security handhabt. Aber man hat jetzt nicht mehr diese Business-Logik, die da irgendwo versteckt ist und die nur noch der Martin, der vor drei Jahren aus dem Unternehmen ausgeschieden ist, weiß, wie sie gebaut wurde. Das hat man explicit nicht mehr. Man hat nur noch die Visualisierungsfrage, die auch gut von Scratch nochmal gemacht werden könnte. Und ich glaube, das ist der wichtige Punkt: Nicht alles zu Vibe-coden, sondern halt nur die Sachen, die quasi als Single-Use-Code innerhalb von wenigen Minuten reproduziert werden könnten.

Das verschiebt sich ja auch zunehmend. Vor einem halben Jahr hätte man alles, was Vibe-gecoded wurde, noch von Entwicklern neu bauen lassen müssen. Inzwischen sind es wirklich produktionsfähige Applikationen. Was mir in der Vorbereitung gut gefallen hat, ist dieser Begriff „Infrastructure as Code". Kannst du das nochmal in dem Kontext ein bisschen erklären?

Alexander

Es gibt zwei Wege, mit denen man AI in der Produktion besser einsetzen kann. Die eine Richtung geht Richtung Nutzer – also Richtung Applikation –, da kann man mit Vibe-Coding rangehen. Und der andere massive Aufwandstreiber ist eigentlich die Einrichtung dieser Daten-Infrastruktur. Man sieht: Die Welt ist eine ganz andere, wenn ich endlich meine Daten glatt habe – das ist quasi der Claim. Dann wird alles viel einfacher.

Und auf der Kontra-Seite steht vermeintlich dieses riesige Projekt über Monate, Jahre, in dem ich jetzt alle meine Datenpunkte sortiere und alle meine Maschinen anbinde. Das ist ja immer noch das Gegenargument, überhaupt so ein Projekt zu machen. Und genau da kann man mit Infrastructure as Code nochmal ganz viel rausstreichen, indem man sagt: Ich lasse jetzt meine Infrastruktur nicht über neun Monate pro Werk zusammenklicken, indem man jedes Mal in Dropdown-Menüs Konfigurationen zusammenklickt, sondern: Unsere gesamte Infrastruktur ist quasi eine riesige Konfigurationsdatei. Die ist für die AI als Konfigurationsdatei verfügbar.

Und was macht das viel einfacher? Jetzt habe ich mein Janitza-Modbus-Gateway, was überall meine Stromwerte ausliest – hat dann irgendwie 800 Registereinträge, die keiner versteht, auf 800 Seiten PDF. Und die kann ich jetzt einfach in die AI reinwerfen und daraus mit unserem UMH-Skill eine valide Konfigurationsdatei für den UMH rauslassen, der diese Janitza-Zähler ausliest. Und genau da nehme ich jetzt fünf Stunden Lesen raus, drei Stunden Zusammenklicken im Tool – und habe innerhalb von 15 Minuten was umgesetzt, was sonst einen Tag gedauert hätte. Das ist der große Hebel von Infrastructure as Code: Die AI kann total gut mit Code arbeiten, und jedes Tool, das als Code funktioniert, wird dadurch viel schneller und einfacher zu nutzen.

Das entwickelt sich ja auch immer weiter – die ganzen neuen Sensoren und Maschinen werden ja immer besser beschrieben. Wie ist da eure Erfahrung aus der Praxis? Wo gibt es Grenzen, wo ihr sagt: Das funktioniert immer noch nicht?

Alexander

Das ist eigentlich immer eine Funktion davon, wie gut die Dokumentation ist. Wie jeder Entwickler sagen würde: Die Schnittstelle ist nur so gut, wie sie dokumentiert ist. Das gilt natürlich auch für die AI. Das heißt, wenn die AI gar keinen Kontext hat – also es ist jetzt irgendwie ein komplett selbst entwickeltes Projekt eines Maschinenherstellers, der gar nichts dokumentiert hat –, dann wird es gegebenenfalls schwierig. Man kann sogar einfach die TIA-Portal-Projektdatei hochladen und trotzdem mal die Datenpunkte rausziehen lassen. Das geht schon.

Aber genau das sind die Grenzen: Umso weniger Kontext ich der AI zur Verfügung stellen kann, umso weniger effektiv wird das, umso mehr muss ich E-Mails schreiben und hinterher telefonieren. Da gibt es ganz, ganz viele Standardisierungen, die stattfinden. Beispielsweise bei neuen Maschinen im Food-and-Beverage-Bereich – zumindest im Weihenstephan-Standard. Und im Spritzguss-Bereich gibt es EUROMAP – da kann man sich super dran lehnen. Und da passiert schon sehr, sehr viel.

Im IoT-Anwenderkreis hatten wir die spannende Diskussion, wie man an die Daten rankommt. Ein Teilnehmer hat erzählt, dass er kürzlich eine neue Maschine gekauft hat und die Datenverfügbarkeit überhaupt nicht mit berücksichtigt hat. Wo ich total baff war, dass das immer noch der Fall ist. Das ist so einfach und naheliegend: Wenn man sich eine neue Maschine kauft, schreibt man in die Ausschreibung auch rein: „Übrigens, wir wollen auch alle Daten haben."

Ja, wenn man am längeren Hebel sitzt – weil wenn man die Maschine erst gekauft hat und dann an die Daten ran will, wird es schwierig. Das hatte ich damals bei Siemens schon immer gesagt: Bitte alle auf jeden Fall in die Ausschreibung reinschreiben, dass man auf die Daten zugreifen kann. Siehst du da noch weitere Eingrenzungen? Siehst du das industriespezifisch, oder seid ihr in bestimmten Industrien mehr aktiv als in anderen?

Alexander

Es gibt immer Industrien, die grundsätzlich einfacher sind – die auch innovativer oder dynamischer auf Veränderungen reagieren. Und es gibt Industrien, die durch einen hohen regulatorischen oder projektgetriebenen Ansatz eher nicht die First Mover sein wollen. Als Beispiel: Die Pharmaindustrie hat hohe Qualitätsanforderungen. Man geht da eher über „Never change a running system". Also die verändern sich auch, und dann gibt es auch innovative Unternehmen und Vorreiter. Aber per se würde ich sagen: erstmal schwieriger, weil jetzt jedes Vibe-gecoded-Frontend noch abgenommen werden muss. Das ist dann natürlich auch nicht so schön.

Und dann gibt es Industrien wie Food and Beverage, die ich relativ stark finde. Da hat man klar auch Auflagen zum Thema kritische Infrastruktur. Aber die haben eigentlich ein relativ gutes Konnektivitätsprofil und auch meistens – weil die halt große Anlagen haben – tatsächlich schneller zu connecten als jetzt ein Hersteller mit ganz, ganz vielen Werkzeugmaschinen, wo man mit 15 verschiedenen Herstellern kommunizieren muss. Ich würde sagen: Umso weniger reguliert, umso besser. Und umso größere Anlagen, umso einfacher.

Du konntest ja ein Beispiel schon nennen von HiPP, die jetzt viele Vibe-Coding-Applikationen auf ihren Dashboards haben. Hast du da auch Vergleichswerte, KPIs, irgendwelche Schlüsselkennzahlen, die man nutzen kann zu begründen: „Hey, lass uns mal in diese Richtung gehen"?

Alexander

Wir haben letztens eine Studie gemacht mit einigen unserer Kunden zusammen mit Forrester, einer Analysten-Agentur. Die haben sich mal ganz top-down damit beschäftigt, was Kunden für einen Benefit haben – nicht im Sinne von höher, schneller, weiter, sondern wirklich: Wie viele Euros kommen am Ende raus? Entlang unserer Kunden gab es im Schnitt 5 % Energieeinsparung – durch eine höhere Transparenz auf Verbräuche und Prozesse. Und ich glaube, 14 % weniger ungeplante Stillstände.

Das hat tatsächlich am Ende zu einer Composite-Organisation aus verschiedenen Kunden von uns einem ROI von über 400 % und ein paar Millionen Euro an Benefits geführt. Und das ist extrem cool, weil durch das Vibe-Coding wird es jetzt noch schneller. Das heißt, Kunden, die das auf dem traditionellen Weg gebaut haben – also mit klassischen Frontends oder in Grafana –, die werden durch das Vibe-Coding nochmal deutlich, deutlich schneller an diese Benefits kommen. Wir haben da also schon echt belastbare Zahlen entlang unserer Kunden generiert.

Das ist auch spannend – ob das überhaupt noch „Vibe Coding" weiterhin heißen wird oder ob das sich einfach weiterentwickelt. So richtig im Vibe ist man dann ja nicht mehr – man kann da ganz klare Anforderungen definieren und stellen, und das wird dann entsprechend passend umgesetzt. Das ist inzwischen super zuverlässig.

Das mal so zusammenzufassen: Wenn jetzt jemand bei euch einsteigen will – wie fängt man da an? Was waren so Kundenprojekte vom Ablauf? Erster Schritt, zweiter Schritt – und vielleicht kannst du da auch gleich einbauen, was es da an Fehlern gibt, die man vermeiden könnte.

Alexander

Wir haben ein bisschen eine besondere Ausgangssituation dadurch, dass wir Open Source sind. Das heißt, unser Kernprodukt – das kann jetzt quasi jeder auf unsere Website gehen, runterladen und damit sich die ersten Maschinen anbinden und die Applikation Vibe-coden, die er gerne bauen möchte. Das heißt, viele unserer Kunden fangen sich erst mal in einem Lösungsraum an, wo wir gar nicht existieren. Es gibt keinen Sales-Mitarbeiter, der einen nervt, sondern einfach nur ein Produkt – und die Person kann erst mal validieren für sich, ob das überhaupt spannend ist. Und das ist, ich glaube, einer der ersten wichtigen Schritte: sich erst mal wirklich intensiv mit dem Produkt auseinanderzusetzen, mit dem Problem, das man lösen möchte, und schauen: Kann das Produkt das Problem lösen?

Und dann fangen sie meistens mit einem Werk an oder mit ein bis drei Werken, um Stück für Stück Templates zu bauen. Denn diese Unified-Namespace-Instanz besteht ja auch aus vielen Hausaufgaben. Ich muss mal definieren: Wie sieht eine CNC-Maschine bei mir aus? Wie sieht eine Spritzgussmaschine bei einem Böllhoff aus? Oder wie sieht eine Furnace bei einem anderen Unternehmen aus? Daraus leite ich Standards ab, die ich in den ersten ein, zwei, drei Werken etabliere, teste – klappen die auch für Japan, werden die für Brasilien klappen und umgekehrt. Und dann schaffe ich in diesem ersten Batch an Standards entlang von Semantik und Hierarchie und rolle das Stück für Stück aus.

Entlang dessen baut man dann sogenannte Kompetenzzentren auf – meistens nach Regionen geteilt –, wo dann Power-User sitzen, die die anderen Regionen und Standorte mit aufbauen. Ein sehr organischer Ansatz, aber der hat immer ganz viel damit zu tun, sich intensiv mit Produkt und Problem auseinanderzusetzen und dann iterativ weiterzukommen.

Bei Open Source ist jetzt natürlich spannend – da ist ja immer die Problematik für den Anbieter: Was ist denn mein Geschäftsmodell, wenn ich das kostenlos hergebe? Das würde mich interessieren. Ihr unterstützt ja dann schon auch, wenn es schwieriger wird – oder wie genau verdient ihr euer Geld?

Alexander

Ja, das ist erst mal kontraintuitiv. Ein Unternehmen aufzubauen – dafür muss man ja auch Geld verdienen. Und Geld verdienen tut man erst mal nicht mit kostenloser Software, das stimmt schon. Ich nenne es mal Open Source 1.0, wo quasi diese Red-Hat-Modelle existierten, wo du für ein Enterprise-Produkt – das hat das gleiche Produkt wie das Open-Source-Produkt – eine Fee bezahlt hast, wenn was kaputtgeht, damit du jemanden anrufen darfst.

Das hat natürlich einen ganz tollen Zielkonflikt: Wenn du dein Produkt so gut machst, dass du niemanden mehr brauchst – was der Zielzustand sein soll –, dann brauchst du ja nicht diese Enterprise-Lizenz. Dann gab es die zweite Welle von Open-Source-Produkten – das ganze Thema as-a-Service. Ich habe Datenbanken wie MongoDB oder PostgreSQL as-a-Service bekommen können. Und weil wir insbesondere eigentlich in der Fabrik des Kunden installiert werden und dementsprechend gar nicht as-a-Service anbieten können, haben wir ein anderes Lizenzmodell gemacht.

Wir haben zusätzliche Komponenten eingeführt – wir nennen das die Management-Konsole –, die insbesondere das Skalieren einfacher macht. Die hat ein tolles Management- und Rechtekonzept, Multi-User-Kollaboration, Audit Trails und auch Versionierung und vieles mehr. Also alles, was man nicht zwangsläufig braucht, um an einem Standort erfolgreich zu sein – aber alles, was man braucht, wenn man in einer großen Organisation skalierbar und in guter Governance arbeiten will, das ist bei uns dann proprietär. Das versuchen wir als fairen Kompromiss zu bauen: Wir wollen niemanden zurückhalten und auch die Community, die wir uns aufgebaut haben, nicht bestrafen. Aber gleichzeitig in der Situation, wo Großunternehmen anfangen, uns zu skalieren, noch einen signifikanten Mehrwert anzubieten, der dann kommerziell ist. Und so verdienen wir unser Geld.

Spannender Ansatz. Finde ich ganz toll, dass man da erst mal kostenlos anfangen kann. Du hast gerade die Community angesprochen – das wäre auch nochmal ganz spannend. Weil einfach mal anzufangen, da braucht man ja viel – auch Unterstützung, Dokumentation, Austausch. Wie habt ihr die aufgebaut und was läuft da so?

Alexander

Das war so ein weiteres Thema, was uns eigentlich sehr gestört hat. Weil normalerweise Software in Manufacturing gekauft wurde – das war halt meistens ein sehr manueller Prozess. Dann hat man irgendeine Datei bekommen oder irgendeinen Lizenzschlüssel, lokal validiert, die Software heruntergeladen, entpackt, installiert. Und hat dann als Nutzer – beziehungsweise auch als Anbieter – nie wieder Feedback von den Produkten bekommen. Als kleinerer Anbieter hat man dann irgendwie 20, 30, 40 Kunden. Das heißt, man bekommt meistens erst Feedback, wenn es so richtig schlimm läuft – wenn das dann über den Sales-Mitarbeiter ins Dev-Team eskaliert wird.

Das war uns anfangs klar: Das können wir so nicht machen, weil A das viel zu wenig Nutzer sind, um wirklich ein gutes Produkt zu bauen, und B wir ganz, ganz nah am Nutzer bleiben wollen. Und da ist die Community eine super Sache. Wir haben jetzt ungefähr 1.000 Community-Mitglieder, die aktiv mit dem UMH gerade überall auf der Welt Sachen bauen. Und durch die kriegen wir signifikant mehr Feedback, als wir bekommen könnten, wenn wir nur ein geschlossenes Produkt wären.

Und die bauen dann gegebenenfalls sogar neue Features ein. Die bauen eigene Protokolle für Maschinenhersteller ein, die denen besonders wichtig sind. Die bauen Templates für Use Cases oder für Integrationen auf, die andere auch nutzen können. Und sie geben vor allem Feedback zu Sachen, die nicht klappen – so dass alle anderen auch von diesem Edge Case profitieren können. Den können wir dann trotzdem fixen, weil wir so viele Leute draußen haben, die unser Produkt täglich nutzen.

Ja, das war eine starke Design-Entscheidung: Wenn wir ein Manufacturing-Produkt bauen wollen, dann wollen wir es auch mit einer großen Menge Nutzer bauen. Das geht ja eigentlich nur mit Open Source. Und vor allem, wenn wir wirklich was verändern wollen – uns hat fundamental gestört, wie wir aktuell in der Industrie mit Daten umgehen. Und das können wir nur strukturiert verändern, wenn wir möglichst viele Nutzer haben. Das geht am einfachsten mit Open Source. Deswegen war es uns eine sehr, sehr offensichtliche Wahl.

Finde ich stark, sehr mutiger Weg auf jeden Fall. Und jetzt eine etwas gemeine Frage – weil ihr seid mit Vibe-Coding ganz vorne dabei und mit Open Source auch noch mit einem sehr innovativen Geschäftsmodell: Wie geht es denn danach weiter? Was sind so die Entwicklungsschritte, die ihr jetzt tätigt, um weiterhin innovativ zu sein?

Alexander

Wir haben das Glück, noch nicht so alt zu sein. Wir sind nicht gestern gegründet, sondern vor fünf Jahren. Aber wir haben jetzt die große Chance, ohne 10, 15 Jahre technische Schulden unser Produkt ganz nah an den aktuellen Herausforderungen der Zeit zu bauen. Das ist zum Beispiel eine CLI. Ein Produkt, das vor 15 Jahren gebaut worden wäre, würde das jetzt sehr schwierig machen. Wir können tatsächlich verschiedene APIs anbieten und Interfaces, die das Interagieren mit AI-Applikationen noch vereinfachen. Man könnte auch noch ein Graph-Interface anbieten, mit dem man Daten noch viel einfacher mit der AI erforschen kann.

Das ist natürlich auch die mittelfristige Vision: Das beste Produkt zu bauen, um Daten in der Fabrik zu konsumieren und zu nutzen. Und ich glaube, das ist erst mal ein groß genug Problem, das so zu lösen – weil noch keiner das gelöst hat. Und daraus heraus werden sich noch ganz viele tolle Geschäftsmodelle ergeben, die man auch noch angreifen könnte. Das ist immer die Herausforderung für die nächsten Jahre – das richtig gut zu machen.

Alexander, vielen Dank. Für mich war das super spannend. Ich hoffe, dass wir alle Schlagwörter auch ausreichend erklärt haben – sonst kann man das ja sicherlich im Nachgang nochmal nachschauen. Keine weiteren Fragen mehr. Was würdest du den Zuhörerinnen und Zuhörern noch mitgeben wollen?

Alexander

Wenn ich jetzt so viele Fachbegriffe genutzt habe, tut mir das leid – ihr könnt mich aber gerne auf LinkedIn fragen, was das bedeutet. Da könnt ihr gerne einen Outreach starten. Und ich glaube, Loslegen wäre natürlich jetzt toll. Das heißt, wir haben eine große Lernplattform – unabhängig vom Produkt –, die sich gerne alle mal anschauen können, insbesondere was Jeremy da geschrieben hat. Loslegen ist der nächste wichtige Schritt.

Super – ist generell mit generativer KI gerade das Gebot der Stunde, würde ich auch sagen. Daher vielen Dank für den spannenden Austausch. Da hat sich auf jeden Fall nochmal ein sehr signifikanter Anwendungsfall in meine Liste von Themen eingereiht, die man mit generativer KI jetzt im Shopfloor machen kann. Vielen Dank an die Zuhörer und Zuhörerinnen, dass ihr bis hierher zugehört habt, und bis zum nächsten Mal.

Alexander

Danke, Peter.