IoT-Low-Code auf dem Shopfloor: Maschinendaten per OPC UA ins ERP

Heute im IoT Use Case Podcast: IoT Low-Code für Blue-Collar. Oder besser gesagt: eine konfigurierbare Plattform für das Internet der Dinge, die auch, beziehungsweise insbesondere, von Mitarbeitenden in der Fabrik angewendet werden kann. Zu Gast haben wir die Peakboard GmbH und die Firma GIESSER Messer. Wir lernen, wie man klein anfängt und sinnvoll skaliert. Und heute zerlegen wir unseren Anwendungsfall messerscharf. Viel Spaß dabei.
Hallo und herzlich willkommen zum IoT Use Case Podcast. Ich bin euer Podcast-Co-Host Dr. Peter Schopf. Mit mir heute im Studio sind Thilo Brosinsky, der Entwicklungsleiter bei Peakboard, und Björn Mutschler, Produktionsleiter bei GIESSER Messer. Thilo, fangen wir mit dir an. Stell dich doch mal kurz vor. Was wollen wir heute Spannendes besprechen?

Thilo

Hallo Peter, mein Name ist Thilo Brosinsky. Ich bin bei Peakboard für Software- und Produktentwicklung zuständig. Wir schauen uns heute an, was Peakboard ist und wie es in diesem Fall bei GIESSER Messer eingesetzt wird, was man mit Peakboard machen kann.

Und wo sitzt ihr mit Peakboard?

Thilo

Wir sitzen in Stuttgart, wobei wir grundsätzlich sehr homeoffice-lastig unterwegs sind. Spätestens seit Corona sind wir sehr verteilt. Wir haben ein Office in Stuttgart, in Leipzig und in Chicago. Das heißt, ich persönlich bin, wenn ich im Büro bin, typischerweise in Stuttgart. Aber so wie auch jetzt arbeiten wir oft von zu Hause aus.

Sehr schön. Björn, du bist Produktionsleiter bei GIESSER Messer. Wie lange bist du da schon mit dabei? Erzähl mal ein bisschen über dich und deine Firma.

Björn

Ich bin seit 2011 bei der Firma Johannes Giesser Messerfabrik GmbH in Winnenden. Wir gehören zu den führenden Herstellern von Berufsmessern. Unter „Berufsmesser“ versteht man alles, wo Profis mit Messern arbeiten: vornehmlich die fleischverarbeitende Industrie oder das Handwerk, aber natürlich auch Bäcker, Köche, Konditoren – alles, was mit Messern arbeitet. Wir stellen unsere Messer hier am Standort in Winnenden her, nicht unweit von Stuttgart. Darüber kam auch der Kontakt zustande, durch einen Freund, der bei Peakboard arbeitet. Wir sind ziemlich am Anfang bei Peakboard mit aufgesprungen, schon in der ersten Version. Wir gehören eigentlich schon fast zu Kunde 1. Thilo, du kannst mich da unterbrechen, wenn das nicht ganz stimmt, aber zumindest waren wir unter den ersten Usern und waren auch teilweise beteiligt an Ideen und Entwicklungen von Peakboard.

Thilo

Absolut. Es gab nicht viele Kunden davor. Wie gesagt, das ist auch aus einem persönlichen Kontakt entstanden, also mindestens im ersten Jahr des Bestehens von Peakboard. Peakboard gibt es jetzt seit zehn Jahren, also ist GIESSER Messer schon einige Tage mit bei uns an Bord.

Da sind wir ja hier in der Schwabenrunde. Ich bin in Schwäbisch Gmünd aufgewachsen und groß geworden, jetzt allerdings ausgewandert nach Bayern, nach Erlangen. Daher kommen auch die Beziehungen und Kontakte. Gerade in der Anfangsphase ist es für viele neue Firmen natürlich wichtig, einen Friendly Customer, einen Pilotkunden zu haben, mit dem man so etwas aufbauen kann. Wie ist das bei euch losgegangen? Hattet ihr ein konkretes Problem? Zehn Jahre her – weißt du noch, wie der Anfangszustand war und was sich daraus entwickelt hat?

Björn

Die Firma Peakboard hatte die Idee von einem Welcome-Board, also im Endeffekt eine konfigurierbare Anzeige im Willkommensbereich bei Parkplätzen und so weiter. Ich komme allerdings aus der Technik und dadurch, dass ich mit einem der Chefentwickler von Peakboard Kontakt hatte, habe ich gesagt: Ich brauche das technischer. Dann haben wir ein paar Anwendungsbeispiele definiert. Da ging es relativ schnell um Schnittstellen wie OPC UA, Maschinenschnittstellen, um Maschinendaten auszulesen, und darum, Daten aus einem ERP-System herauszuziehen. Dadurch, dass das auch ein Spezialgebiet vom Peakboard-Gründer war, bin ich gleich auf offene Ohren gestoßen. Die Ideen wurden aufgegriffen. Dann haben wir mit dem Peakboard 1 angefangen. Preislich war das für den einen oder anderen am Anfang so eine Sache: „So eine kleine Box …?“ Da kam auch die Skepsis her, wie wir im Einführungsgespräch schon hatten, gegenüber dem Geschäftsführer. Ein anderer Mitarbeiter hatte alles über einen kleinen Raspberry gelöst. Das ist natürlich ein anderes Preissegment, aber da stehen natürlich auch ganz andere Funktionen dahinter. Wir haben mit dem ersten Board angefangen, mit einer relativ breiten Skepsis. Ich bin allerdings jemand, für den das Machen im Vordergrund steht. Ich bin nicht so unfassbar theorielastig in der Produktion, sondern schaue als Macher: ausprobieren. Wenn es nichts ist, hätte ich es gleich über Bord geworfen. Peakboard hat sich dann zu einer Erfolgsstory entwickelt bei uns im Betrieb. Nach dem ersten Board sind die Ideen nur so gesprießt, und die Skeptiker sind mittlerweile die Power-User bei uns im Betrieb. Mittlerweile sind wir bei 14 Boards. Wir sind ein kleines mittelständisches Unternehmen: 100 Mitarbeiter, zwei Werke. Inzwischen hängt an jeder Maschine, in jedem Fertigungsbereich Technik. Ich habe erst vor sieben Tagen ein ganzes Template installiert und in die Anwendung gebracht. Da ging es um Arbeitszeit und Fertigzeiterfassung auf Mitarbeiterebene, dass man kommunizieren kann, wie die Fertigzeiten protokolliert werden. Wir sind unfassbar flexibel mit dieser Anwendung und man kann nahezu alles abbilden.

Das hört sich super vielversprechend an.

[05:59] Herausforderungen, Potenziale und Status quo – So sieht der Use Case in der Praxis aus

Wie definiert sich denn ein Board, ein Peakboard sozusagen? Wie sieht das aus, was tut man damit, was könnte man damit tun? Dann kommen wir nochmal zurück zu Björn, was er tatsächlich damit anstellt.

Thilo

Peakboard besteht im Kern aus drei Bestandteilen. Das ist zum einen die Peakboard Box, wie Björn gerade schon gesagt hat. Das ist im Prinzip ein kleiner Rechner. Den schließt man über ein klassisches HDMI-Kabel an ein Display an. Dann gibt es den Peakboard Designer, der ist eigentlich der Kern des Ganzen. Das ist die Software, mit der man sich eigene Anwendungen erstellen kann. Das ist eine Low-Code-Plattform, mit der man ganz unterschiedliche Applikationen erstellen kann. Wir kommen aus dem Visualisierungsbereich für Dashboards, für Anzeigen von Daten. Das war der Start von Peakboard vor einiger Zeit. Inzwischen hat sich das dahin entwickelt, dass man komplette Anwendungen machen kann. Im Prinzip kann man sich sein gesamtes MES-System Stück für Stück mit Peakboard aufbauen, aber ohne sich ein riesiges Systemhaus zu holen, sondern genau die Applikationen, die relevant sind, individuell umzusetzen. Man beginnt typischerweise mit einem weißen Display und kann Datenquellen anschließen: ein ERP-System, eine Maschine, auch eine Excel-Datei, irgendeine Datenbank, was auch immer. Man kann diese Daten darstellen, Terminals erschaffen für die Werker, um Daten einzugeben oder Daten zurückzuspielen ins ERP-System etc. Diese Anwendungen lädt man dann auf eine Peakboard-Box. Auf der Box läuft dann die Anwendung. Die wird einfach an ein Display gehängt, zum Beispiel einen Touchscreen beim Werker, um solche Anwendungen den Werkern, den Mitarbeitenden im Feld, zur Verfügung zu stellen.

Low-Code ist total spannend. Low-Code bedeutet ja, dass man nicht jemanden braucht, der Programmieren gelernt hat, sondern dass man sich das selber zurechtbasteln kann. Manchmal klaffen bei anderen Anbietern Anspruch und Wirklichkeit auseinander, da wird es dann doch relativ komplex. Wie ist das bei euch? Wer „programmiert“ denn wirklich diese Peakboard-Boxen?

Thilo

Low-Code wird heute tatsächlich sehr inflationär eingesetzt. Jeder, der ein bisschen weniger klassisch programmieren will, nennt seine Software heute Low-Code. Bei Peakboard ist der Ansatz, dass man alles umsetzen kann, ohne programmieren zu müssen. Man kann Datenquellen anbinden, dann visuelle Elemente – ein Chart, ein Button, eine Textbox etc. – auf seinen Screen ziehen und Logiken erstellen, um Daten zurückzuspielen. Da gibt es ein Puzzle-Prinzip, wo man seine Logiken zusammenpuzzeln kann. Beispiel: Wenn jemand auf den Button klickt, dann schreibe ich diesen Wert in das MES-System zurück. Das Ganze ist inzwischen auch KI-unterstützt, sodass man dem Peakboard Designer sagen kann, was man gerne machen will, und dann erstellt er die Logik komplett automatisch. Das heißt, das ist wirklich an Personen gerichtet, die ihre Probleme lösen können – nicht zwingend an jemanden aus der IT. Wir haben heute das beste Beispiel dabei: jemanden, der in der Produktion verantwortlich ist und die Probleme lösen muss.

Du hast KI angesprochen, da bin ich natürlich interessiert. Unterscheidet ihr zwischen klassischer KI, wo man Modelle auf Daten trainiert, und generativer KI, die die Flows und Anwendungen konfigurieren kann?

Thilo

Genau so ist es.

Björn, ist es denn auch alles so? Bist du als Produktionsleiter aktiv und „programmierst“ deine Dashboards von den Maschinen? Wer macht das bei euch?

Björn

Nicht nur manchmal, sondern tatsächlich gehöre ich zu einem von zwei, die Thilo immer „Power User“ nennt. Da fühle ich mich geehrt, weil es stimmt: Ich komme nicht aus dem Programmierbereich. Ich hatte 0,0 Vorerfahrung, was das Betreiben oder Programmieren solcher Dashboards angeht. Aber wenn man Lust drauf hat, ist es selbsterklärend und man kommt sehr gut rein. 80 bis 90 Prozent der Anwendungen kann ich über Drag-and-drop und vorgefertigte Felder umsetzen. Das ist sehr einfach. Ich habe aber auch die Möglichkeit, richtiges Scripting im Hintergrund zu implementieren. Wir haben mittlerweile die komplette Maschinenanbindung. Das machen wir fast alles über OPC UA, es geht aber auch Modbus. Man kann direkt die Siemens-Steuerung anbinden. Wir haben die ersten BACnet-Controller in der Hausteuerungstechnik. Wir machen unser Energiemanagementsystem in der Visualisierung. Unsere Qualitätsaufzeichnungen schreiben wir im Hintergrund in den SQL Server, den Peakboard im Hub gleich mitliefert. Damit sind wir relativ breit aufgestellt, ziehen Daten quer aus dem ERP-System und übertragen sie in andere Ansichten auf dem Board, sodass man das benutzerdefiniert an der Maschine hat. Das ist uns sehr gut gelungen. Das erste Board hatte Produktionsdaten: die Tagesmenge, die produziert wurde, im Verantwortungsbereich. Das war das erste Mal bei GIESSER, dass man eine Zahl überhaupt tagesaktuell transparent in der Fertigung visualisiert hat. Die ersten sagten: Das interessiert niemand. Dann ist etwas passiert: Der älteste Mitarbeiter, von dem ich gedacht habe, das interessiert ihn nicht mehr – der noch ein Dreivierteljahr Restarbeitszeit hat – der kam nach drei Tagen. Davor war die Anzeige immer schön grün, dann wurde die Tagesmenge unterschritten, die Anzeige ging auf rot, mit der Stückzahl. Er war der Erste, der herkam und sagte: „Warum haben wir unsere Stückzahl heute nicht geschafft?“ Das hat mir signalisiert: Wenn man die richtigen Daten – nicht überfüllen – ins Feld gibt, hat das einen unglaublich motivierenden Faktor. Nicht nur „ihr müsst mehr produzieren“, sondern echtes Interesse daran, dass es wichtig ist, was einer macht, wie er es macht und in welcher Stückzahl – und was gefordert ist, um wirtschaftlich arbeiten zu können. Da hängt ja letztendlich jeder einzelne Arbeitsplatz dran. Das war ein Schlüsselmoment, auch für den Geschäftsführer. Der hat gesagt: Super, dann machen wir das in der Abteilung noch, und dann brauchen wir die Zahlen. Dann ist es relativ schnell gewachsen. Wir haben Maschinenhersteller getrieben, gerade beim Thema OPC UA: Wir brauchen OPC-UA-Schnittstellen in der Maschine. Am Anfang hieß es: „Kein Problem, das können wir.“ Dann konnten sie es doch nicht so. Mittlerweile ist das Standard. Bei Maschinenherstellern wird schon vom „GIESSER-Standard“ gesprochen, wenn sie neue Maschinen ausliefern. Die wissen genau, worauf es ankommt. Dann haben wir an allen Maschinen diese Boards installiert: Prozessdaten, Temperaturen von Medien, wichtige Parameter von Soll zu Ist, Stückzeiten, weil das auch wieder Qualitätsorientierung ist. Darum ist sehr viel entstanden. Das zweitwichtigste Thema ist mittlerweile Energiemanagement. Auch hier hängen Boards in der Produktion, die den Energiewert anzeigen. Wir gehen mit der Steuerung so weit, dass man Maschinen runterschaltet. Dann wird visualisiert, warum man das abschaltet, damit erst gar keine Frage aufkommt. Auch dafür ist es wichtig.

Superspannend. Du hast eine ganze Reihe von Themen angesprochen. Gerade die ziehende Fertigung: Nur dass ich das richtig verstehe – der nächste Fertigungsschritt sagt dann: „Das brauche ich von euch, vom vorherigen.“ Damit wissen die immer genau, was erwartet wird und wohin es geht. Ist das eure Definition von ziehender Fertigung?

Björn

Das ist die Definition, ganz genau. Wir arbeiten speziell im Wochenrhythmus. Man sagt: Alles, was in der Woche fertig werden muss. Die nächste Woche wird dann angezeigt, sodass man im Endeffekt immer vor der Zeit ist. Ich persönlich bin auch wieder sehr „feuerwehraktiv“; da spricht man davon, dass man vor der Lage sein muss. Das kann man auch ins Industrielle überführen, dass der Ablieferzeitpunkt nicht unterschritten wird. Das haben wir damit hervorragend geschafft, dass wir eigentlich komplett papierlos wurden. Die Anzahl an Begleitpapieren konnten wir auf nahezu null reduzieren. Nur noch das Notwendigste, sodass, wenn mal ein System – und auch das beste System kann mal einen Aussetzer haben – keiner sagen kann: „Jetzt produziere ich nicht mehr weiter.“ Dann haben wir eine kleine Rückfallebene von ein, zwei Tagen. Danach brauchen wir wieder aktuelle Daten. Wenn ich heute einen Auftrag eingebe, der eilig wäre, würde der in derselben Sekunde, wie ich ihn einplane, bis zum ersten Fertigungsschritt die Unterdeckung anzeigen, und die Werker wüssten sofort: Alles klar, das Material muss jetzt auf den Laser, und wir fangen jetzt bei den Rohlingen an bis zur Endfertigung.

Thilo

Ich würde den Faden zur Ausfallsicherheit aufnehmen. Das ist für uns ein relevanter Punkt. Wenn man so ein System einführt, um seine Werke zu steuern und Daten zu visualisieren, ist das wichtig: In der Produktion kann man sich nicht erlauben, dass ein produktionskritisches System ausfällt. Deswegen haben wir bei Peakboard alles dezentral aufgebaut. Die gesamte Anwendung läuft auf dieser Peakboard-Box, die sich neben dem Display befindet. Es gibt andere Systeme, die zentral aufgebaut sind: Man hat einen Server, und überall anders wird es nur angezeigt. Wenn so ein Server ausfällt oder eine Netzwerkverbindung weg ist, liegt die Produktion im schlimmsten Fall brach, wenn das System produktionskritisch ist. Bei Peakboard ist der Fokus, ein dezentrales System zu bauen. Im Peakboard Designer baut man die Anwendung, lädt sie auf die Peakboard Box, und anschließend läuft alles autark weiter. Natürlich: Wenn ich auf ein SAP-System zugreife, brauche ich eine Verbindung zum SAP-System. Aber die Anwendung selbst läuft dezentral. Man kann im Idealfall ein, zwei Boxen auf Reserve bereitlegen. Dann hat man den Ausfall nur an einer Stelle und nicht unternehmensweit. Ein zweiter wichtiger Punkt: Viele zwingen einen heutzutage in die Cloud. Bei uns kann der Nutzer entscheiden. Wir bieten eine Cloud-Möglichkeit, aber wir bieten das klar auch komplett on-prem an. Denn: Sobald ich eine Verbindung in die Cloud habe, ist das in der Produktion kritisch. Wenn die Internetverbindung ausfällt, weil draußen jemand das Kabel durchbohrt, ist die Cloud weg, egal wie sicher das alles aufgebaut ist.

Zum Thema zentral und dezentral: Seid ihr da eher zufällig hingekommen, weil ihr über die Boxen gestartet seid, oder war das eine bewusste Entscheidung? Wie seid ihr dazu gekommen?

Thilo

Das war eine bewusste Entscheidung. Wir wollen den Nutzer nicht zu einer Server-Client-Architektur zwingen, weil man immer diesen Single Point of Failure hat. Wenn der Server ausfällt, hat man ein Problem. Der zweite Vorteil: Man kann klein anfangen. Wenn ich ein Projekt starten will, muss ich nicht erst meine IT beauftragen und einen Server aufsetzen lassen. Ich kann mit einer Peakboard-Box anfangen, die Anwendung dafür erstellen und damit direkt loslegen. Mit einem geringen Invest kann man die ersten Probleme lösen.

Das finde ich spannend. Häufig haben Kunden Schwierigkeiten, den Anfang zu finden, weil man erst Datentransparenz herstellen muss, Lieferanten klären, Leute schulen – das ist immer ein großer Hub. Und hinten raus gibt es selten diesen einen Killer-Anwendungsfall, der alles bezahlt. Ich fand es bei euch anschaulich: Es gibt zwar die ziehende Fertigung als einen Anwendungsfall, aber ich habe den Eindruck, ihr habt viele kleinere Erfolge gefeiert. Viele suchen den dicken Goldbarren, tatsächlich sind es oft viele kleine Nutzen – Goldkörnchen – und in Summe hat man dann eine Handvoll Gold. Das lässt sich im Vorfeld schwer verkaufen, weil die Geschäftsleitung oft nach dem Goldbarren sucht. Passt das als Bild zu eurer Reise, Björn?

Björn

Ich liebe dieses Bild und nenne es „skalierende Systeme“: immer mit irgendetwas anfangen, das Eis brechen gegenüber Mitarbeitern, gegenüber dem Geschäftsführer, gegenüber Entscheidungsträgern. Bei uns sind die Strukturen relativ flach, ich brauche nicht so viel Überzeugungsarbeit. Aber oft ist es das Problem: Ein System ist sehr groß, dann ist es schwieriger, jemanden für 50.000 oder 100.000 Euro zu überzeugen. Und du hast recht: Es gibt nicht den einen Faktor, den ich gegenrechnen kann und sage: „Ja klar, ich spare so und so viel.“ Ich muss erst mal Akzeptanz aufbauen. Da bietet sich das hervorragend an, dass ich mit dem ersten Board schon eine Anwendung schaffen kann, die einen großen Teil von Problemen löst. Damit ebne ich mir den Weg – und habe dann ein System, das ich nicht wegwerfen muss. Es ist ein Baukastensystem, das sich zusammensetzt. Ich muss auch nicht gleich von vornherein den Hub haben. Aber wenn ich das dritte, vierte, fünfte Board installiert habe, dann komme ich an den Hub. Und dann sind wir wieder beim Zentralelement: Die vielen Inseln werden durch eine zentrale Einheit verwaltet, überwacht, Update-Management und so weiter. Das findet dann zentral und überschaubar statt: Ausfallsicherheit, Rückmeldungen, wenn ein Board aussteigt. Wenn ein Board ausfällt, packt man es in den Karton, der noch im Regal liegt, schickt es zurück und hat im Normalfall am nächsten oder übernächsten Tag – mit dem richtigen Servicelevel – die nächste Box wieder am Start. Wenn man wie bei uns 13 oder 14 Boxen hat, kann man eine Box im Regal haben und ist so weit sicher, dass man innerhalb kürzester Zeit einstecken, Visualisierung hochladen, und dann ist das Ding wieder am Start. Man ist ausfallssicher. Wichtig ist, dass man skalieren kann und nicht immer alles neu denken muss und nicht alles komplett über Bord wirft, sondern dass es darauf aufbaut. Das finde ich charmant.

„Skalierende Systeme“ ist ein guter Begriff. Thilo, ihr habt jetzt viel über GIESSER Messer gesprochen. Wo seid ihr denn noch aktiv, und wo gibt es vielleicht auch Grenzen? Siehst du Grenzen, wo es nicht mehr zum Einsatz kommen kann? Nenn ein paar Beispiele.

Thilo

Ich beantworte erst eine kurze andere Sache, weil Björn den Hub erwähnt hat. Ich hatte vorher gesagt, es gibt drei Elemente bei Peakboard: die Peakboard Box und den Designer. Wer genau aufgepasst hat, merkt, da fehlt einer: der Peakboard Hub. Das ist eine Server-Applikation, die man in-house oder als Cloud-Variante nutzen kann. Da hat man eine zentrale Instanz, in der man alle Geräte sieht und verwalten kann. Uns ist wichtig: Selbst wenn der Hub ausfällt, läuft alles autark weiter. Die Logik läuft auf den Boxen. Aber man hat die Vorteile einer zentralen Verwaltung. Zurück zur Frage: Branchenmäßig sind wir nicht eingeschränkt. Wir sind in sehr vielen Bereichen unterwegs, egal ob Maschinenbau, Messerfertigung, Lebensmittelindustrie, Automobil. Wir sind breit aufgestellt. Bei den Anwendungsfällen kann man im Prinzip alles machen, das ist aber schwer zu greifen. Ein Bereich, in dem wir sehr viel tätig sind, ist das Digitalisieren von Shopfloor-Meetings. Das geht gut, weil man die verschiedenen Datensysteme anbinden kann, in denen relevante Daten liegen, und weil man direkt zurückspielen kann. Dann Downtime-Tracking: Stillstandszeiten reduzieren, Betriebsdatenerfassung, Terminals für Werker, wo sie Ist-Zeiten stempeln können, Maschinendatenerfassung. Im Prinzip ist man offen. Von der Unternehmensgröße fängt es so an, wie wir es hier heute haben, und geht bis in Konzernbereiche. Große Kunden sind zum Beispiel Bosch oder Würth, die Peakboard flächendeckend im Einsatz haben.

Und von der weiteren Entwicklung: Wo geht das System hin? Was sind die nächsten Schritte in der Produktentwicklung?

Thilo

Die Vision ist, dass Peakboard das Tor zum Werker, zum Logistikmitarbeiter ist. Alles, was an Daten im Unternehmen vorherrscht, und alles, was zum Werker muss – zu den Blue-Collar-Workers im Feld –, soll über Peakboard stattfinden. Typischerweise reden wir über grafische Oberflächen beim Werker. Peakboard soll die zentrale Einheit sein, die Daten aus Systemen holt, den Mitarbeitenden zur Verfügung stellt, weiterverarbeitet oder zurückspielt. Heutzutage ist auch wichtig: KI-basiert. Dass Daten von der KI weiterverarbeitet und dem Mitarbeiter zur Verfügung gestellt werden können. Und auch umgekehrt: Der Mitarbeiter trägt etwas ein, das wird von der KI verarbeitet und in ein System zurückgespielt.

Björn, aus deiner Sicht: Wie siehst du deine Produktion? Wo willst du das hin entwickeln? Bleibt es bei der ziehenden Fertigung? Was sind die nächsten Schritte?

Björn

Der Schwerpunkt, der jetzt kommt, ist ganz klar Energiemanagement. Da haben wir begonnen. Das ist aber ein unfassbar komplexes Thema, weil sehr viele Akteure mitspielen: verschiedene Steuerungen, Informationen. Wir kaufen Strom im Spotpreis ein. Das geht bis runter auf stundenaktuelle Preise, Energiespeichersysteme, alles rund um Energiemanagement und Energieeinsparung, also Ressourcenmanagement. Wichtig für alle Zuhörer: Da braucht man Atem. Wenn jemand meint, man kann das innerhalb von Tagen, Wochen oder Monaten oder einem halben Jahr umsetzen in einem Betrieb mit gewachsenen Strukturen – das ist etwas anderes. Wenn ich eine neue Halle baue, kann ich das von vorne herein mitplanen. In jedem Werk, jeder Bau-Epoche gibt es andere Techniken. Da sind wir auf einen Allrounder wie Peakboard angewiesen, der dieses große Spielfeld an Schnittstellen anbietet. Das funktioniert, aber es ist kein Sprint, eher ein Marathon. Vor allem, wenn man am Werk, am Mitarbeiter etwas klarmachen muss: warum vielleicht der Heizkörper kalt ist. Wenn man sieht, dass man gerade einen Spitzenwert erreicht hat, und wir noch elektrisch zuheizen, dann schaltet man die Heizung vielleicht mal für eine halbe Stunde aus, weil da keiner erfriert. Es geht darum, die Leute für diese Themen empfänglich zu machen. Da ist Visualisierung ein ganz wichtiger Baustein.

Das ist fast schon ein schönes Ende, wie du das zusammengefasst hast. Thilo, gibt es aus deiner Sicht noch etwas mitzugeben?

Thilo

Ich würde jedem mitgeben: einfach mal anfangen. Mit Peakboard hat man die Chance, etwas auszuprobieren. Man muss kein riesiges Projekt machen. Man kann sich die Software, den Peakboard Designer, kostenfrei bei uns runterladen und im vollen Funktionsumfang ausprobieren, ohne einen Euro investieren zu müssen. Dann austesten, ob es so funktioniert, wie hier erzählt wurde. Einfach machen, keine Angst davor haben, nicht denken, das sei ein gigantisches Projekt, das zehn Mitarbeitende ein Jahr bindet. Man kann klein starten und kommt ziemlich weit.

Björn, nochmal letzte Worte?

Björn

Ich muss immer aufpassen. Mir wird immer unterstellt, dass ich provisionsabhängig bin bei Peakboard. Das ist nicht der Fall. Aber manche Sachen kann man nur in seinem eigenen Dialekt ehrlich rüberbringen. Ich könnte kein minderwertiges Produkt verkaufen. Genauso wie unsere Messer der Spitzenklasse angehören, gehört auch Peakboard definitiv dazu. Wir haben schon Veranstaltungen zusammen gemacht, auch bei unserem Arbeitgeberverband Südwestmetall. Da kommt schnell der Verdacht auf: „Der muss ja provisionsbeteiligt sein, so wie er davon schwärmt.“ Thilo hat es auf den Punkt gebracht: einfach mal machen. Wenn man sagt, ich habe da eine Anwendung. Wir hatten dieses Jahr den Programmierertag. Da waren die Programmierer bei uns im Werk und haben das Produkt mal gesehen, wie es wirklich lebt. Oftmals sind die Programmierer tief im Code verfangen und konnten dann die Anwendungen sehen. Peakboard ist ein junges Team, kurze Wege, toller Support. Wenn man eine Idee hat: Kontakt aufnehmen, ausprobieren. Mich würde es wundern, wenn der eine oder andere nicht die gleiche Euphorie entwickelt und das Produkt dann gerne einsetzt. Zum Schluss ist das der Schlüssel: Man muss etwas gerne einsetzen. Es muss in der Anwendung sein und den Benefit fürs Unternehmen bringen. Das sind für mich die Schlüssel zum erfolgreichen Produkt, und da gehört Peakboard klar dazu.

Da fällt es mir schwer: Es soll hier wirklich keine Marketingveranstaltung sein. Da springt die Begeisterung geradezu über. Hätte ich eine Fertigung, würde ich loslegen. Nächstes Mal überlege ich mir noch kritischere Fragen, um ein Gegengewicht zu machen.

Björn

Aber jetzt mal eine kurze Frage: Hast du mit Peakboard schon mal etwas gemacht oder es live gesehen?

Ich selber nicht, nein. Das ist auch schade. Podcast ist ja nur Ton und Audio, sonst wäre es super, so etwas gleich zu zeigen. Den Designer würde ich mir gerne mal anschauen.

Björn

Du kannst jederzeit mit Thilo mal vorbeikommen und anschauen, wie das Projekt bei uns lebt. Das Einzige, was ich von Peakboard bekomme, ist einmal im Jahr, wenn ich Glück habe, eine Tasse.

Das muss eine tolle Tasse sein.

Björn

Das ist eine wirklich tolle Tasse. Ansonsten bin ich unbefangen.

Vielen Dank für die Einladung. Wenn ich das einrichten kann, machen wir das auf jeden Fall. Ich gehe super gerne in Werke und schaue mir das an. Jedes Werk tickt anders, und die Anwendungsfälle sind auf unterschiedlichen Stufen. Das Credo „einfach mal machen“ ist ganz stark. Vielen Dank euch für eure Zeit und für das, was ihr erklärt und erzählt habt. Vielen Dank an die Zuhörerinnen und Zuhörer, die bis zum Schluss zugehört haben. Bis zum nächsten Mal. Danke.

Thilo

Vielen Dank auch von mir.

Björn

Vielen Dank.