In dieser Episode des IoT Use Case Podcasts spricht Gastgeber Dr. Peter Schopf mit Lukas Schattenberg, Vertriebsleiter bei IXON, Alexander Engels, CEO von aiXbrain, und Jörg Halladin, Entwicklungsleiter bei SPALECK. Im Fokus: Wie Maschinenbauer mit IoT-Plattform, Edge-Anbindung und integrierter KI ein skalierbares Condition-Monitoring- und Predictive-Maintenance-Serviceangebot für Betreiber umsetzen.
Folge 206 auf einen Blick (und Klick):
Podcast Zusammenfassung
SPALECK, ein Maschinenbauer für Schwingförderer und Schwingsiebe in Recycling-, Chemie- und Lebensmittelanlagen, baut Condition Monitoring in seine langlebigen Maschinen ein, um Stillstände in verketteten Prozesslinien zu vermeiden. Die Herausforderung lag weniger in der Datenerfassung als in der Reaktionsfähigkeit im Betrieb: lokale Ampelanzeigen wurden übersehen, und starre Grenzwerte reichen bei wechselnden Produkten und Betriebsweisen nicht für verlässliche Vorwarnungen. Um aus Maschinendaten rechtzeitig Serviceentscheidungen abzuleiten, wurden Maschinen über IXON per Edge-Router schnell angebunden und Daten in der Cloud verfügbar gemacht. aiXbrain ergänzte als integrierte App (Dataray) ML-Modelle für Predictive Maintenance – inklusive Labeling in der Plattform, Modellvergleich (False Positives/Negatives) und automatisiertem Nachtrainieren. Die Lösung bleibt bewusst offen über Schnittstellen wie OPC UA, PROFINET und API, sodass Betreiber Daten in eigene Werk-Dashboards integrieren können. Nutzen für IT/OT-Entscheider: schneller Rollout, sichere Remote-Zugriffe, skalierbare Datenpipeline, frühere Fehlererkennung (mehrere Tage Vorlauf) und servicefähige Prozesse mit klaren Alarmen statt zusätzlichem Tool-Overhead.
Podcast Interview
Heute im IoT Use Case Podcast schauen wir auf eine Konstellation, die wir immer häufiger sehen und die für viele Industrieunternehmen strategisch relevant wird: Eine IoT-Plattform, eine spezialisierte KI-Lösung und ein Maschinenbauer, die gemeinsam ein neues Serviceangebot für den Endkunden schaffen. Zu Gast sind die Firmen IXON, aiXbrain und SPALECK. Wir sprechen darüber, wie aus Maschinendaten konkrete Entscheidungen entstehen – nicht im Labor, sondern im realen Betrieb. Viel Spaß dabei.
Hallo und herzlich willkommen zum IoT Use Case Podcast. Mein Name ist Dr. Peter Schopf, und in dieser Folge adressieren wir ein Thema, das viele Maschinenbauer beschäftigt: Wie kann man datenbasierte Services an Endkunden anbieten? Ist es tatsächlich so, dass viele dabei an technischer Komplexität, Sicherheitsanforderungen oder fehlender KI-Expertise scheitern? Manche Firmen zeigen aber auch, wie es funktioniert. Und dazu freue ich mich sehr auf unsere Gäste. Zum einen haben wir Lukas Schattenberg, Vertriebsleiter bei IXON, die mit ihrer IoT-Plattform das Fundament liefern. Dann haben wir Alexander Engels, CEO von aiXbrain, die mit ihrer KI-Lösung die passenden Erkenntnisse liefern. Und schließlich Jörg Halladin, Entwicklungsleiter von SPALECK, die als Maschinenbauer das Ganze konkret bei ihren Kunden einsetzen. Schön, dass ihr alle da seid. Jörg, ich würde gerne mit dir anfangen, um mehr über dich und insbesondere auch SPALECK zu erfahren. Wo seid ihr anzutreffen, und was kannst du über dich und SPALECK erzählen?
Jörg
Guten Tag. Die Firma SPALECK ist im Münsterland angesiedelt, ein klassisches KMU, komplett inhabergeführt. Wir haben mehrere Bereiche, und einen Bereich, in dem wir eigene Maschinen bauen, die wir komplett selbst entwickeln. Das sind Schwingförderer und Schwingsiebe für Schüttgüter verschiedenster Art. Wir sind spezialisiert auf alles, was im Bereich Recycling arbeitet, aber auch zunehmend im Bereich Lebensmittel und Chemie.
Super. Kannst du ein, zwei Kunden nennen? Sind da welche größer und bekannt oder eher Spezialisten im Recycling-Bereich?
Jörg
Einfach mal auf die Mülltonne gucken, die man hat, und auf die Wagen – da steht ja oft drauf, wer das macht.
Da sind wir eigentlich sehr stark vertreten, weltweit.
Und was sind die Probleme, die eure Kunden in dem Kontext haben, gerade bei Schüttgütern, Recycling und Ähnlichem?
Jörg
Es sind verfahrenstechnische Anlagen, die funktionieren müssen, weil sie zum Beispiel Brennstoff liefern für Kraftwerke. Geht es um energetisches Recycling, wird das so genannt. Oder es geht um chemische Prozesse, bei denen Unterbrechungen wirklich sehr kostspielig sein können. Was ist die Herausforderung bei uns? Unsere Maschinen sind zum einen Teil von verketteten Anlagen. In dieser langen Prozesskette ist es eine Maschine, die darüber hinaus sehr zuverlässig ist. Es ist durchaus üblich, dass unsere Kunden gar nicht wissen, wo unsere Maschine steht und was sie macht, weil sie jahrelang nichts damit zu tun haben. Deswegen haben sie das häufig gar nicht im Blick bei ihrer täglichen Wartung und Instandhaltung. Während andere Maschinen sehr häufig, teilweise schichtweise, überprüft werden, weil man weiß, es ist nötig, um sie instand zu halten, ist es bei uns eher so, dass man sie vergisst. Das finde ich auch sehr schön, denn das ist unsere Arbeit: diese Zuverlässigkeit zu erreichen. Aber das macht es natürlich umso wichtiger, wenn mal etwas ist, dass das auch mitbekommen wird. Deswegen ist Condition Monitoring für uns schon ein Thema.
Und was ist deine Rolle?
Jörg
Als Entwicklungsleiter: Wir machen Condition Monitoring schon seit bestimmt 14 Jahren. Unser erstes Problem war früher, dass eine LED fünf Jahre grün ist, dann gelb wird, monatelang gelb bleibt, ein paar Wochen rot ist, und dann ist der Schaden da – und keiner hat es gesehen. In den Logs haben wir immer gesehen: An sich hat alles funktioniert, aber es hat niemand reagiert. Deswegen haben wir das irgendwann auf eine Cloud-Plattform gehoben, damit wir als Experten für diese Maschinen das mitkriegen und dann die Dinge passieren lassen können, die nötig sind, damit aus einer Reparatur, die vielleicht nur zehn Minuten dauert, auch wirklich so eine wird – und nicht ein kompletter Stillstand für ein, zwei Tage.
Das ist super anschaulich. Was ist der Auslöser? Warum geht man in die Cloud, wie du das gerade beschrieben hast? Da gibt es Erkenntnisse, aber es geht darum, die zur richtigen Zeit verfügbar zu machen. Und ihr habt dann einen Auswahlprozess gestartet und Partner gesucht. Wir haben Lukas hier: Wie seid ihr zusammengekommen?
Jörg
Wir hatten zuerst den klassischen Fehler gemacht: Wir haben Daten und Erfahrungen, wir haben eine Idee von unserem digitalen Geschäftsmodell und dem Service, wie er laufen soll, und haben erst mal eine sehr große Lösung gesucht und uns Sachen angeguckt. Wir haben festgestellt, was viele wissen: Wenn man Softwareprojekte scheitern lassen will, muss man sich einfach super viel vornehmen. Wir sind mit unserem ersten Partner auch ein bisschen auf die Nase gefallen. Dann mussten wir uns sehr schnell neu orientieren. Eine Messe stand vor der Tür, wir mussten das neu aufbauen. Dann haben wir durch eine Internetrecherche IXON gefunden. Wir haben uns vorgestellt und erklärt, was wir machen wollen, und uns wurde einfach ein Router zugesendet. Der war zwei Tage später da, und ein paar Stunden nachdem ich den hatte, hatte ich mein Dashboard mit 90 Prozent der Funktionen, die ich haben wollte, fertig. Das hat in dem Moment sehr überzeugt. Wir hatten viele Router auf dem Tisch und ausprobiert, und die Einrichtung dauert normalerweise sehr lange. Hier hatten wir wirklich schon Dashboards fertig. Dann war relativ schnell klar, dass wir sehr schnell an den Markt kommen und den Kunden liefern können, was wir uns vorgestellt hatten. Das ist auch eingetreten.
Lukas, das ist eine schöne Überleitung zu dir. Der Router war nach zwei Tagen da. Wie macht ihr das? Was ist euer Fokus und was ist dein Teil daran?
Lukas
Meine Rolle als Vertriebsleiter für die DACH-Region bei IXON ist es sicherzustellen, dass Kunden wie Jörg schnellstmöglich durch mein Team unterstützt werden. Das Team ist cross-funktional aufgestellt: technische Seite, Vertrieb, aber auch Vermarktung. Wir helfen Kunden generell mit vier Produkten, die wir anbieten. Das Thema Edge-Geräte ist etwas, das wir von Haus aus anbieten. Das Thema Fernwartung bieten wir an. Maschineneinblicke zu kreieren ist ein weiteres Produkt, und schlussendlich ist das Thema Kundenportal etwas, das wir liefern können. Wie Jörg schon gesagt hat, ist dabei ein Thema immer zentral: Usability und Time-to-Market. In unserer Erfahrung hat der Maschinenbauer ein unglaubliches Know-how über seine eigenen Maschinen. Diese Verbindung herzustellen zwischen Maschinenbauern und produzierenden Unternehmen und eine konstante Verbindung über den kompletten Lebenszyklus einer Maschine zu haben, ist das, was wir uns als Aufgabe gesetzt haben – und womit wir recht erfolgreich sind und Kunden unterstützen dürfen.
Und wo sitzt ihr? Wie groß seid ihr als Anbieter?
Lukas
Ich bin mittlerweile seit fünfeinhalb Jahren bei IXON. Als ich angefangen habe, waren wir knapp 40 Leute. Ende dieses Jahres sind wir, denke ich, bei etwa 130. Wir sind in den letzten fünf Jahren stark gewachsen – nicht nur im Personal, sondern auch in der Anzahl der Connected Machines. Wir haben mittlerweile mehr als 60.000 Maschinen mit der IXON Cloud verbunden.
Das ist stark, weil der IoT-Markt nicht einfach ist. Da so zu wachsen und erfolgreich zu sein, ist nicht selbstverständlich.
[08:46] Herausforderungen, Potenziale und Status quo – So sieht der Use Case in der Praxis aus
Du hattest von euren Lösungen gesprochen. Spezialisierte Lösungen und Applikationen haben wir hier auch im Einsatz – Richtung Alexander gedacht. aiXbrain: Wie passt das ins Bild? War das eine App im Marketplace, oder wie ist Alexander ins Bild gekommen?
Alexander
Tatsächlich ja: Wir sind mit unserer Applikation, die heißt Dataray, als App im Marketplace der IXON Cloud. Ich erinnere mich nicht mehr genau, ob das schon der Fall war, als wir mit SPALECK in Kontakt gekommen sind. Ich glaube, es war klassische Kaltakquise, wie wir zusammengekommen sind. Damals war es auf jeden Fall so, dass wir schon eine Integration in die IXON Cloud hatten. Ob das im Marketplace war oder nicht, weiß ich nicht. Aber die Vorteile, die eine bestehende Integration bietet, hatte man sich damit gespart. Jörg ist dann hellhörig geworden und hat gesagt: Moment, IXON haben wir ja schon, ihr seid integriert – lasst uns mal schauen, ob ihr uns in dieser Vorausschau unterstützen könnt, um solche Probleme, wie er sie beschrieben hat, frühzeitig zu erkennen. So ist das zustande gekommen.
Erzähl mal ein bisschen über deine Firma. Du bist CEO von aiXbrain.
Alexander
Ich bin Mitgründer von aiXbrain. Uns gibt es seit 2019. Wir sind ein Spin-off der RWTH Aachen, sitzen auch noch in Aachen und sind Spezialisten für Künstliche Intelligenz im industriellen Einsatz. Wir machen das mit verschiedenen Softwareprodukten und Softwareleistungen. Dataray ist die Produktlinie, mit der wir klassisches Machine Learning im Bereich Predictive Maintenance und Predictive Quality bedienen – auf Zeitreihendaten, aber auch Bilddaten. Und dann gibt es ein zweites großes Standbein: agentische KI, aufgesetzt auf Sprachmodellen, Agent-Frameworks und Ähnlichem. Das treiben wir in den letzten zwei Jahren sehr stark voran. Wir kommen langsam an den Punkt, an dem sich diese beiden Themen sinnvoll ergänzen können. Ich glaube, das ist auch das, worauf die KI-Welt im Industriebereich schaut. Wir sind zehn Leute, also eher klein. Das ist aber eine gute Größe, um schlagkräftige Lösungen mit KI zu bauen.
Ich finde es auch gut, dass ihr das in zwei Produktlinien unterteilt: klassische KI, die schon lange eine Rolle spielt, aber nicht immer einfach umzusetzen ist, und dann die neue generative KI. Ganz konkret für SPALECK: Was macht ihr da in den Projekten, und was ist das Ergebnis aus euren KI-Modellen?
Alexander
Diese Maschinen, die SPALECK herstellt und die bei den Endkunden verbaut werden, sind Teil solcher Linien. Ein wichtiger Teil: Wenn das Ding ausfällt oder steht, passiert auf der Linie nichts mehr. Damit ist es per Definition eine kritische Maschine. Die Frage ist: Wann wird es kritisch auf so einer kritischen Maschine – also das, was Jörg als gelbes Lämpchen beschrieben hat – und wie lange dauert es dann noch, bis es rot wird? Das ist eine Fragestellung, bei der man Daten heranziehen und mit maschinellem Lernen Modelle trainieren kann, die frühzeitig Trends erkennen, bewerten und dann automatisch das entsprechende Personal alarmieren.
Gerade bei klassischen KI-Modellen braucht man dafür Daten, weil man die Modelle selbst trainieren muss; da muss die Maschine ja ab und zu ausfallen.
Jörg, vielleicht kannst du noch mal beschreiben: Eure Maschinen laufen sehr zuverlässig. Wie habt ihr überhaupt die Daten erfasst und aiXbrain zur Verfügung gestellt, um Ausfälle vorhersagen zu können? Da braucht man ja viele Daten.
Jörg
Das ist tatsächlich die größte Herausforderung. Ein Vorteil ist: Obwohl unsere Maschinen sehr stark auf die individuellen Bedürfnisse der Kunden zugeschnitten sind – Stückzahl 1 ist bei uns eher Standard – verwenden wir auf allen Maschinen ein gleiches Datenmodell. Das macht die Daten vergleichbar. Im Standard gehen die Maschinen mit „gelernten“ Grenzwerten raus, mit denen sie sich selbst antrainieren. Das reicht aber nicht aus, um eine richtige Vorhersage zu machen, weil das Betreiberverhalten – welches Produkt fährt er, wie oft wechselt er das – dazu führt, dass man den Schwellwert nicht so setzen kann, dass er nah an einem möglichen Fehler liegt, den ein Mensch erkennen könnte. Da sparen wir dann schon vier, fünf Tage, wenn wir ein trainiertes Datenmodell anwenden. Das klingt nicht nach viel, aber ob es ein Freitag oder ein Dienstag ist, an dem man weiß, dass man wirklich etwas tun muss, ist ein Unterschied. aiXbrain hat uns dann auf der IXON-Cloud-Plattform in einer integrierten App – man merkt gar nicht, dass man nicht unser Dashboard verwendet – eine Möglichkeit geschaffen, die Daten zu labeln. Dann haben wir besprochen, was man damit machen kann. aiXbrain hat verschiedene Modelle ausprobiert und entwickelt, und wir haben geschaut: Wie gut stimmen die überein? Erkennen sie einen Fehler korrekt? Wie oft erkennen sie einen nicht vorhandenen Fehler als Fehler? So haben wir uns rangetastet.
[15:22] Ergebnisse, Geschäftsmodelle und Best Practices – So wird der Erfolg gemessen
Mich interessiert das Geschäftsmodell. Diese vier, fünf Tage können total kritisch sein. Wie habt ihr das umgesetzt bei euren Kunden? Ist das ein Service-Modell?
Jörg
Wir hatten verschiedene Überlegungen. Was sofort rausgefallen ist, ist Value-based Pricing: zu sagen, diese vier Stunden kosten dich eine bestimmte Summe, und wir nehmen einen Anteil davon. Wir erheben eher einen Preis, der ausreicht, um das System zu betreiben und weiterzuentwickeln. Wir haben über ein klassisches Abo-Modell nachgedacht, das kam am Markt nicht so gut an. Wiederkehrende Zahlungen macht keiner gern. Außerdem wechseln Betreiber über die Jahre auch mal. Wir haben zum Beispiel den Übergang von Anlagenbauer zu Endkunde, der gehandhabt werden muss. Inzwischen ist es integraler Bestandteil der Maschine: Wenn man eine Maschine kauft, ist es dabei – für einen Zeitraum, der der Lebensdauer der Maschine entspricht. Das funktioniert gut für uns.
Das ist wirklich ein Kernproblem für digitale Services in der Industrie, weil man dort gewohnt ist, Investitionsgüter zu kaufen.
Lukas, ihr seid Plattformanbieter und arbeitet wahrscheinlich mit Subscriptions. Wie ist euer Geschäftsmodell, und wie gehen die Maschinenbauer, die eure Plattform integrieren, damit um?
Lukas
Das ist richtig: Wir sind kein Investitionsgut. Wir arbeiten selbst mit Subscriptions für unsere verschiedenen Produkte. Wir haben aber auch – wenn man zum Beispiel nur auf Fernwartung schaut – ein Modell ohne laufende Kosten: Man kauft Hardware und ist in der Lage, global und cybersicher Fernwartung anzubieten. Für die anderen Produkte, Richtung Kundenportal und Maschineneinblicke, arbeiten wir mit Subscriptions. Maschinenbauer beliefern ein sehr heterogenes Kundenfeld, von Konzern bis Kleinstbetrieb. Ich glaube nicht, dass ein Maschinenbauer das gleiche Produkt eins zu eins für verschiedene Kundentypen anbieten kann. Es gibt eine Phase, in der er lernen muss: Wie nutzt mein Kunde meine Maschine oder Anlage? Darauf basierend kann er Produkte entwickeln, maßgeschneidert für die Anforderungen der verschiedenen Kunden. Nicht alle Kunden machen es als integralen Bestandteil der Maschine. Es gibt Kunden, die Abo-Modelle verwenden. Andere integrieren es in bestehende Wartungsverträge und versuchen, mehr Wartungsverträge abzuschließen oder den Umfang zu erhöhen. Gerade am Anfang ist es aus Erfahrung ein erfolgreiches Modell, es zunächst für die Garantiephase anzubieten: um selbst guten Support leisten zu können und um dem Kunden anhand der Daten zu zeigen, wie man geholfen hat – durch Daten oder Zugriff auf die Maschine. Daraus leitet man dann weitere Produkte ab.
Ein anderes Grundsatzthema im IoT-Bereich: Verbinde ich jede einzelne Maschine oder habe ich eine IoT-Cloud für mehrere Maschinen? Der Maschinenhersteller will seine Lösung platzieren, während der Betreiber am liebsten eine App für das ganze Werk hätte. Wie siehst du diese Spannung?
Lukas
In meinen Augen ist das keine Entweder-oder-Frage. Das ergänzt sich. Nicht jeder Maschinenbauer kann mit seinem Dashboard die Anforderungen eines produzierenden Unternehmens treffen – muss er vielleicht auch gar nicht. Es geht um die Frage: Wenn ich einem produzierenden Unternehmen helfen kann, indem ich Daten weiterleite in ein übergeordnetes IoT-System, zum Beispiel über ein IXON-Edge-Gerät, ist das genauso möglich, wie wenn ich es in einem eigenen Dashboard visualisieren möchte. Der Maschinenbauer braucht Daten, um von der Maschine zu lernen, um dann Beratungsleistung anbieten zu können: Wie betreibe ich die Maschine effektiver? Dafür braucht er nicht die Kennzahlen, an denen Fabriken typischerweise interessiert sind – Stückzahlen, OEE-Auswirkungen, Qualitätszahlen –, sondern maschinenspezifische Werte wie: Welche Temperatur hatte der Motor, bevor er ausgefallen ist? Wenn es diesen Dialog und eine permanente Verbindung gibt, ist beiden Seiten geholfen.
Alexander, wie bringt ihr euch beim Geschäftsmodell ein? Eure Lösung ist im Marketplace, wahrscheinlich subscription-basiert. Erfolgsbeteiligung wäre spannend, aber wahrscheinlich schwierig. Wo steht ihr da?
Alexander
Revenue Share ist der große Traum. Das ist aber die große Frage: Wie wird der Revenue oder das Delta bemessen? Wir sind im Marketplace. Es gibt bei uns zwei Phasen. Das eine ist die Konfigurationsphase – um die kommt man nicht herum. Plug-and-Play gibt es bei solchen Daten meines Wissens nach noch nicht. Da gibt es Anpassungsaufwand. Dann wird es ein Laufzeitservice, und dafür wird bei uns eine Gebühr fällig. Ob man das Subscription nennt oder Lizenz, ist an der Stelle egal. Wir haben ein Preismodell gefunden, das akzeptiert wird. Das ist ein Stück weit „reverse engineered“: Man schaut, was der Markt hergibt, und irgendwann konvergiert das. Bei generativer KI und LLMs ist es ähnlich: Man findet wenige, die 1.000 Euro im Monat kosten; man ist sich einig, dass es eher im zweistelligen Bereich liegt.
Bei euch wird es ja immer wieder zum Nachtrainieren kommen, wenn sich Muster verschieben. Wie geht ihr damit um?
Alexander
Das ist der große Vorteil der Applikation beziehungsweise des Frameworks dahinter, das wir Dataray nennen. Für den Nutzen aus der konkreten Applikation ist es egal, aber das, was dahinter steckt, ist eine hochgradige Automation dieser Vorgänge. Wenn man einmal das Modell hat – inklusive Konfiguration der Eingangsdatenkanäle, von Abtastrate bis Bedeutung der Daten –, und das Ding läuft, dann ist Nachtrainieren auf neuen Daten mehr oder weniger ein Knopfdruck. Dann ist der Aufwand gering. Der Aufwand liegt in der Ersterfassung: Welche Daten, welche Bedeutung? Und man vertraut dem nicht blind – da muss ein Experte oder eine Expertin draufschauen, nachjustieren, bis es passt. Einmal Aufwand am Anfang, aber weitere Daten erzeugen und darauf nachtrainieren ist dann sehr einfach.
[24:26] Übertragbarkeit, Skalierung und nächste Schritte – So könnt ihr diesen Use Case nutzen
Für viele Maschinenbauer ist diese Reise spannend. Jörg, worauf sollte man achten, um typische Fehler zu vermeiden?
Jörg
Der Hauptpunkt ist, dass man sich vorher wirklich Gedanken darüber macht, was dem Kunden am Service wichtig ist. Wenn man meint, tolle Dashboards oder Webshops für Ersatzteilbestellungen seien wichtig, sollte man mit den Kunden reden, ob sie das überhaupt verlangen. Wir haben festgestellt, dass unsere Dashboards viele gar nicht interessieren – die haben ihre eigenen. Wir bieten eine OPC-UA- und eine PROFINET-Schnittstelle auf der Edge an. Das können wir mit IXON auch machen, weil die Hardware offen genug ist. Wir haben erste Kunden, die API-Zugriffe direkt auf die Cloud haben, weil sie komplett eigene Lösungen anwenden. Da würde ich darauf achten, dass die Plattform offen ist und gut mit anderen Produkten zusammenarbeitet. Bei uns ist Telefon und E-Mail immer noch der bevorzugte Weg. Die Maschinen fallen sehr selten aus und brauchen dann Spezialwissen. Der Support ist auf unsere Servicetechniker und Prozesse zugeschnitten. So funktionieren unsere Prozesse besser, und das wird zunehmend geschätzt. Bei uns kommt vom System eine E-Mail, dann schauen wir in die Daten. Es ist egal, ob es ein Grenzwert war oder die KI, die gemeldet hat. Ein Servicetechniker kann schnell prüfen: Welche Maschine ist das, was ist los? Der Kunde hat sein eigenes Dashboard, wir haben Zeitstempel, die Daten sind benannt. Dann spricht man, man guckt auf unterschiedliche Dashboards in unterschiedlichen Systemen und weiß trotzdem sicher, dass man über die gleiche Sache spricht. Wenn wir ein Ticketsystem, Self-Service, Webshop und so weiter alles von Anfang an hätten integrieren wollen, wären wir nicht da, wo wir jetzt sind. Meine Empfehlung ist: Schauen, wo man möglichst direkt Nutzen für Kunden und eigene Prozesse generiert – und dass das Thema nicht irgendwo in der Cloud schwebt, sondern für die Leute sichtbar ist.
Bist du jetzt zufrieden, also fertig? Oder gibt es nächste Schritte?
Jörg
Es gibt auf jeden Fall nächste Schritte. Auf der IFA, der Leitmesse für die Schüttgutaufbereitung in München im Mai, werden wir neue Sachen vorstellen. Ich will da nicht vorgreifen – am besten einfach vorbeischauen. Wir erweitern definitiv den Nutzen der Cloud, damit die Vorhersage noch einmal deutlich besser wird. Wir bewegen uns weg von „nur Fehler erkennen“ hin zu „Prozess-Know-how erlangen“. Dahin soll es weitergehen.
Lukas, wo geht es bei euch weiter?
Lukas
Bei uns liegen die Schwerpunkte weiter auf Security, Datenverfügbarkeit und dem Ausbau der Kundenportale, um größeren direkten Nutzen für unsere Kunden zu schaffen. Auf der anderen Seite gibt es Add-ons zu unserer Plattform: Jörg hat Ticket-System und Webshop genannt. Da werden wir unser Partnernetzwerk in den nächsten Jahren weiter ausbauen, um bessere Integrationen zu bieten, die für unsere Kunden eine schnellere Time-to-Market ermöglichen. Und das große Thema KI wird stärker in unsere Plattform integriert: der IXON KI-Assistent, der mehr und mehr Funktionalität erhält. Auf der SPS letztes Jahr, 2025, haben wir eine erste Version gezeigt: eine Möglichkeit, wie bei ChatGPT mit Dokumenten zu interagieren und schneller zu Ergebnissen zu kommen. Wenn ich über die IXON Flow Plattform nachdenke, sehe ich viele weitere Möglichkeiten, wie der KI-Assistent das Leben für unsere Kunden deutlich einfacher machen kann.
Alexander, du bist beim KI-Assistenten direkt gefragt: Was macht ihr da, welche Schritte unternehmt ihr?
Alexander
Beim IXON KI-Assistenten sind wir tief involviert, das machen wir gemeinsam. Der Unterschied zu dem, was im Marketplace passiert – also Applikationen als On-top-Anwendungen – ist, dass das tief in der Plattform steckt. Die erste Applikation, so etwas wie ein Document Chat, war eine Testapplikation, um zu zeigen, dass das Gesamtsystem funktioniert. Das wird weitergehen, und der Assistent wird immer mehr Funktionalitäten bekommen. Um das auszudrücken: Es gibt Funktionen wie Predictive Maintenance, Predictive Quality und Vorhersage mit KI. Aber man möchte diese Funktionen – und nicht nur KI-Funktionen, sondern auch andere – intelligent zusammenschalten. Das tun wir jetzt auf dem Weg des IXON AI Assistants. Unser Zielbild ist die „sprechende Maschine“: eine Maschine, die weiß, in welchem Zustand sie ist, die weiß, was zu tun ist – vielleicht gar nichts, vielleicht proaktiv etwas –, und die Personen informiert oder sogar Schritte unternimmt. Dafür braucht es viele Werkzeuge, die intelligent verschaltet sind und zusammenwirken. Das ist das Zielbild, das uns vorschwebt und das wir bei IXON integrieren möchten. Aus meiner Perspektive führt der Weg zum Endkunden und Betreiber in fast allen Fällen über die Serviceabteilung des Maschinen- und Anlagenbauers. Dort ist das Know-how, und dort muss man zuerst Wert schaffen und Vertrauen aufbauen. Bevor das eine Stufe weitergeht, muss es dort funktionieren. Wenn man sich das Leben eines typischen Service-Mitarbeitenden vorstellt: Da ruft jemand an und sagt, meine Maschine steht wieder. Dann kann man automatisch nachschauen oder weiß es schon aus dem Assistenten: Was ist der aktuelle Status? Haben sich Dinge geändert seit dem letzten Zeitraum, in dem es funktioniert hat? Man kann in Handbüchern oder Wartungsprotokollen nachschauen, Informationen zusammentragen und eine qualifizierte Voranalyse liefern: „Folgende Fehler habe ich gesehen. Folgende drei Ursachen können es sein. Stell folgende zwei Rückfragen.“ Dann kommt man schnell zum Kern. Vielleicht gibt es sogar proaktiv einen Vorschlag: welche Einstellung sinnvoll ist oder was gereinigt werden muss. Das macht das Leben eines Service-Mitarbeitenden deutlich einfacher, und genau das soll der IXON AI Assistant leisten.
Wenn andere Maschinenbauer oder Serviceanbieter Kontakt aufnehmen wollen: Wo erreicht man euch am besten? LinkedIn, E-Mail, Homepage? Wir verlinken natürlich auch auf der Seite von IoT Use Case.
IoT Use Case ist eine tolle Seite, wo die Lösungen der Partner und Netzwerkmitglieder mit aufgeführt sind. Danke euch ganz herzlich. Und wer mit mir über generative KI für Organisationsentwicklung sprechen will – das ist auch mein Fokusthema – kann mich gerne auf LinkedIn kontaktieren. Bis zum nächsten Mal.


