00:00:00
00:00:01
#110 - Low-Code Apps in der Fabrik - mit Patrick Theobald
238 Plays4 months ago
Patrick ist der Gründer von Peakboard - einem in Stuttgart ansässigen Unternehmen, welches die Digitalisierung der Industrie vorantreibt. Wie? Mit Low-Code. Und wieso mit Low-Code? Das erklärt uns Patrick in dieser Folge.
Außerdem erzählt er uns, wie er damals auf die Idee für Peakboard kam und was er aus vielen Jahren in Fabriken und Produktionsunternehmen gelernt hat. Unter anderem, wie sich Low-Code auf das Mindset und die Kultur in solchen Unternehmen auswirkt.
Links zur Folge
Peakboard website: https://peakboard.com/
Patrick’s LinkedIn: https://www.linkedin.com/in/zuteilungsreif/
**////////// Gefällt dir unser VisualMakers Content? Werde selbst zum VisualMaker mit einem unserer vielen kostenlosen Kurse. Starte jetzt durch und werde No-Code Profi https://www.visualmakers.de/academy**
**////////// Folge uns auf: LinkedIn: https://bit.ly/3SfL6oOYoutube: https://bit.ly/3OF5jBjInstagram: https://bit.ly/3cMYH6NSlack: https://bit.ly/vm-slack**
**////////// Jetzt Newsletter abonnieren und keine No-Code News mehr verpassen! https://bit.ly/3cMYNeF**
Transcript
Die Akzeptanz komplexer Excel-Formeln gegenüber mehrzeiligen Skripten
00:00:00
Speaker
Komplexe Excel-Formel, die in eine Zeile reinpassen, ist etwas, was irgendwie noch akzeptiert wird. Und alles, was mehrzeilig ist, wird von den Leuten abgelehnt. Das heißt nicht, dass es nicht können, sondern wird von den Leuten abgelehnt. Und dann sind wir relativ schnell eben auf den Trichter gekommen. Wir müssen hier eine Lockout-Lösung zur Verfügung stellen, die die Leute von diesem mehrzeiligen Skripten entbindet. Und deshalb haben wir das gemacht. Das war aber an Learning kein
00:00:29
Speaker
Initialer Plan.
Vorstellung von Patrick Theobald und seiner beruflichen Reise
00:00:38
Speaker
Herzlich willkommen zum Visual Makers Podcast. Heute spreche ich mit Patrick Theobald, dem Gründer von Peakboard. Peakboard ist eine auf industrielle Anwendungen spezialisierte Low-Code-Plattform, also eine Low-Code-Plattform, die es erlaubt, Anwendungen zu bauen für Produktionsunternehmen.
00:00:56
Speaker
Und das ist quasi alles, was ich dazu sagen kann. Wer natürlich mehr dazu sagen kann, ist eben Patrick, der Gründer selbst. Und Peakboard ist logischerweise auch unser Tool der Woche. Und alles weitere wird euch Patrick im Verlauf dieses Gesprächs sagen. Los geht's. Herzlich willkommen, Patrick. Schön, dass du da bist. Wie geht's dir? Ja, schönen guten Tag. Mir geht's hervorragend und vielen Dank für die Einladung.
00:01:21
Speaker
Ja, sehr gerne doch. Ich hab's im Intro schon angekündigt. Heute geht es um das Tool oder sozusagen um das Unternehmen, was du gegründet hast, nämlich PeekBoard. Genau, vielleicht kannst du dich einmal kurz vorstellen, bevor wir dann eben auf PeekBoard eingehen. Also wer bist du? Wo sitzt du gerade? Was ist alles noch wichtig zu deiner Person? Ja, grundsätzlich Patrick Theobald ist mein Name, ganz offensichtlich. Ich bin Gründer und aktuell Geschäftsführer bei PeekBoard.
00:01:51
Speaker
und habe insbesondere einen technischen Background. Das heißt, ich bin eigentlich mal im Original Physiker und dann Software-Entwickler und bin jetzt eben als Gründer von Peekbot hier in meiner Rolle heute mit dabei und freue mich auf das Gespräch. Sehr schön. Physikers hast du gerade gesagt. Das heißt, das ist dein, bevor du Software-Entwickler geworden bist, warst du erst Physiker oder kam das irgendwie zusammen?
00:02:21
Speaker
Ja, das ist ein bisschen gleichzeitig passiert. Also grundsätzlich mal habe ich Physik studiert und bin dann aber noch während des Studiums eigentlich in die Softwareentwicklung eingestiegen. Das war mehr oder weniger ein Versehen und seitdem dort hängen geblieben. Und seitdem ist das Ende des Physikstudiums auch noch eine offene Baustelle, um ehrlich zu sein.
Der Weg zur Gründung von Peakboard
00:02:44
Speaker
Aber spannend. Was hat dich an Software mehr begeistert als an Physik, wenn man das so sagen kann? Also das kann man so nicht sagen, dass es mich mehr begeistert. Aber was mich begeistert ist auf jeden Fall dieses Bauen von Dingen, also sich irgendwas ausdenken, insbesondere ein Prozess, der dann eben auch tatsächlich physisch funktioniert in einem Lager oder irgendwo. Und dann zu sehen, dass der wirklich benutzt und eingesetzt wird. Das empfinde ich doch als nach wie vor sehr, sehr befriedigendes Gefühl. Und das ist auch durchaus das, was mich jetzt über die ganze
00:03:14
Speaker
Karriere in Anführungsstrichen immer angetrieben hat. Das heißt, du hast dann nach dem Physikstudium oder währenddessen irgendwie noch IT gemacht oder oder Entwicklung studiert in die Richtung? Nicht studiert, sondern ich bin eigentlich direkt eingestiegen, damals bei Wirt. Das kennt man, Schraubenwirt, also Deutschland kennt man den zumindest eigentlich überall. Und das war schon während des Studiums als Freiberufler und dann
00:03:43
Speaker
musste ich da ein Projekt fertig machen. Und dann sagte der damalige Geschäftsführer von Wirt, der sagte, komm, wir stellen dich ein halbes Jahr fest an, du machst das fertig und dann gehst du zurück auf die Uni. Das mit der Zurück auf die Uni hat natürlich nicht geklappt und aus dem halben Jahr sind dann fünf geworden. Und so bin ich praktisch eigentlich hier in die Vollblut- und Vollzeit-Software-Entwicklung eingestiegen. Und die Zeit bei Wirt, die prägt mich eigentlich bis heute.
00:04:09
Speaker
Okay, spannend. Und zwischen Wirt und PeekBoard lag aber ja auch einiges. Habe ich auch ein paar Fragen zu, die, glaube ich, dann später nochmal spannend werden. Aber das heißt, du bist damals in die Software eingestiegen und bist dort geblieben, bis du dann PeekBoard gegründet hast, was ja auch Software ist. Ja, bin ich eigentlich bis heute geblieben. Also natürlich sind die Aufgaben als Gründer oder als Geschäftsführer sehr viel.
00:04:35
Speaker
Es ist ja vielfältiger, da geht es ja nicht mehr nur um Programmieren, aber dieser Fokus auf Technik, dass Technik funktioniert und dass Technik praktisch dazu dienen muss, Prozesse anzutreiben, der ist bis heute geblieben und der ist auch der größte Teil meiner Arbeit heute eigentlich, wenn ich mit Kunden kommuniziere. Alles andere ist eigentlich nicht so wichtig wie diese eine Sache.
00:04:58
Speaker
Okay, cool. Das klingt auf jeden Fall nach einer guten Philosophie, wofür Technik halt auch am Ende da sein sollte.
Entwicklung und Ziel von Peakboard als Plattform
00:05:06
Speaker
Ja, dann lass uns über Peakboard sprechen. Das ist genau dein Unternehmen jetzt gerade. Das hast du vor einigen Jahren tatsächlich schon gegründet, richtig? Das ist auch nicht mehr ein kleines, junges Startup, sondern schon ein paar Jahre drauf. Wie alt ist es schon? Wie kam es damals dazu?
00:05:24
Speaker
Genau, also eigentlich sind wir doch schon stramme sieben oder siebeneinhalb Jahre alt, also 2016 gegründet, gehen jetzt eigentlich fast schon auf die Acht zu. Und das ist damals eigentlich als Hobbyprojekt oder als Tochtergesellschaft der damaligen Firma entstanden, im Übrigen auch nicht Vollzeit. Deshalb hat das jetzt doch relativ lang gedauert und wir arbeiten eigentlich schon relativ lang an dem Projekt.
00:05:50
Speaker
Aber eigentlich seit zwei Jahren dann so richtig Vollzeit. Ja, das kann man so sagen. Okay, das heißt, eine Weile war das wirklich ein Side-Project, was sich dann eben zu dem Unternehmen entwickelt hat, was es heute ist? Ja, für mich zumindest. Also es gab natürlich schon während der Zeit des Side-Projects gab es schon Vollzeitmitarbeiter, die für PeekBoard gearbeitet haben. Aber für mich war es eigentlich doch eher ein Seitenthema und die
00:06:19
Speaker
finanziert durch die damalige Muttergesellschaft und nachdem sich Peekbot von der damaligen Muttergesellschaft abgelöst hat, das ist jetzt relativ genau zwei Jahre her, bin ich eben Vollzeit dabei und jetzt geht die ganze Sache auch mit größerer Geschwindigkeit und mit mehr Mitarbeitern voran. Das heißt, die Gesamtzeit, die Peekbot jetzt schon am Markt gibt, diese siebeneinhalb Jahre, die reflektieren eigentlich nicht hundertprozentig korrekt den Entwicklungsstand, weil es eben am Anfang aus logistischen Gründen etwas zäh losgeht.
00:06:49
Speaker
Okay. Und dann, ja, erzähl uns doch jetzt einmal, was Peekbot ist. Ja, total gern. Also, die Idee ist eigentlich eine Plattform zu schaffen, auf der unsere Kunden aus dem Bereich Fertigung und Logistik eben Applikationen bauen können, die die Leute, die dort tatsächlich arbeiten, in ihren Prozessen unterstützen. Das hört sich jetzt erst mal relativ abstrakt an. Die Einsatzvariante wäre zu sagen,
00:07:19
Speaker
Man kann damit eine Applikation bauen, mit der man eine Fabrik so einfach steuern kann wie ein iPhone. Das ist eigentlich schon die Idee.
00:07:29
Speaker
Wenn man sich überlegt, wie kompliziert Software in der Fertigung oder in der Maschinensteuerung heute ist, also dass die Leute, die in der Fertigung was produzieren, die Maschinen bedienen, die SAP bedienen, die MES-Systeme bedienen, die sind ja praktisch konfrontiert mit einer unglaublichen Reihe an wirklich schlechter, ineffizienter und fehlträchtiger Software und
00:07:53
Speaker
Wenn Sie Feierabend haben, dann machen Sie Ihr Handy auf und bedienen Software, die ähnlich komplex ist, völlig mit der sehr steilen Lernkurve, völlig sicher und relativ fehlerfrei oder fehlertolerant. Und unsere Vision ist es eigentlich schon, diese Idee der völlig einfachen und fehlerfreien Bedienung oder fehlertoleranten Bedienung bis in die Fertigungen in die Fabriksteuerung zu bringen.
00:08:21
Speaker
Und da ist Pickboard eben die nötige Plattform, um das für Kunden zu tun.
Herausforderungen und Lösungen in industriellen Softwareprozessen
00:08:26
Speaker
Wie kamst du denn damals dann auf die Idee? Weil, wie ich jetzt auch verstehe, ist es ein offensichtlich sehr naheliegendes, aber großes Problem. Und wie du auch schon gut gesagt hast, ich glaube, das ist oft gar nicht das Problem, dass man mit Software nicht umgehen kann, sondern man kann einfach nicht mit intuitiver Software umgehen. Und das kennt man ja dann irgendwie. Und das Problem versucht ja sozusagen zu lösen, dass sich
00:08:48
Speaker
eine intuitive Software sozusagen selber zu bauen. Aber ja, wie kam wieder damals die Idee zu sagen, okay, vielleicht muss ich, weil du hast ja auch gerade gesagt, du warst damals noch in einem anderen Unternehmen. Wie kam es dazu, dass du gesagt hast, ich will da jetzt was was bauen und ein Problem lösen? Genau. Also die eigentliche Idee geht ja noch wirklich viel, viel länger zurück bis bis zu der Wirtzeit. Also schon bei der Wirtzeit habe ich ja eigentlich Lagersoftware gebaut.
00:09:14
Speaker
Das heißt, ich war mit den Leuten, die tatsächlich was arbeiten in so einer Firma, also physisch arbeiten, relativ nah beieinander. Das heißt, ich kenne diese ganzen Schwierigkeiten, die die Leute haben. Und schon damals ist das entstanden, insbesondere eben die Tatsache, dass es eben wahnsinnig aufwendig ist, solche Anwendungen zu bauen. Und das ist auch der Grund, warum man den Leuten so viel SAP-UI zum Beispiel zumutet.
00:09:41
Speaker
Also dieser Aufwand, das war mir damals schon klar, dass das ein zu lösendes Problem ist. Das kannte ich noch aus Wirtszeiten. Dann kam eben die relativ lange Zeit der ersten Firma, die sich mit einem anderen Thema beschäftigt hat. Und irgendwann 2016 kam das dann eben wieder auf die Platte, dass man sagen müsste, eigentlich sind jetzt hier 15 Jahre vergangen und eigentlich hat sich an diesem Problem überhaupt nichts getan. Und jetzt wird es aber mal Zeit, dass sich jemand drum kümmert.
00:10:08
Speaker
Und das war eigentlich die Idee, mit der wir damals ins Rennen gegangen sind. Und dann ist eben die Version 1.0 von Peapod entstanden. Du hast ja auch gerade schon SAP erwähnt. Haben die nicht solche Lösungen dafür? Oder warum sind die existierenden Lösungen, sei es jetzt SAP oder andere, nicht wirklich die Lösung dafür?
00:10:32
Speaker
Also grundsätzlich ist SAP natürlich eine sehr umfangreiche, oft eingesetzte Software, die ganz viele Probleme löst. Es ist aber natürlich so, dass SAP als ERP-System ja eben nur einen Berührungspunkt in so einem Fertigungsprozess hat. Wir haben ja noch viel mehr. Wir haben ja noch Maschinen, die bedient werden wollen. Wir haben noch ein MES-System, um die Produktion zu überwachen.
00:10:54
Speaker
Und wir haben natürlich typischerweise noch mindestens eine Excel-Tabelle irgendwo unterm Schreibtisch bei irgendjemand, die den ganzen Laden zusammenhält. Und eigentlich sind alle Leute, die mit IT-Artefakten interagieren, immer mit ganz vielen dieser Artefakte zugange. Das ist ja niemals nur SAP, sondern das sind immer mindestens drei, vier oder vielleicht sogar noch mehr.
00:11:20
Speaker
die in der Regel auch von der rein von der Oberfläche her incompatibel zueinander sind. Es ist jetzt nicht so, dass SAP das nicht kann, aber sie sind halt einfach nur ein Player in diesem Spiel aus Sicht eines Produktionsmitarbeiters.
00:11:37
Speaker
Jetzt nimm mal die Zuhörenden oder inklusive mich natürlich auch einmal mit in so eine Produktion. Das ist ja dann meistens eine Fabrik oder ähnliches, egal jetzt wie groß und klein, aber du hast ja auch gesagt, es gibt verschiedene Maschinen, die ja auch mittlerweile eigentlich alle irgendwie mit Software bedient werden. Dann müssen die irgendwie auch an die Computer angebunden werden. Das heißt, diese Schnittstellen sind da, wo die Probleme irgendwie auftreten, wo PeekBoard ansetzt oder
00:12:04
Speaker
Genau, also um jetzt mal zum Beispiel ein einfaches Beispiel zu machen. Wenn ich jetzt so einen typischen, so eine typische Einzelfertigung habe, dann läuft da das Werkstück zu dem Werker hin und dann macht er irgendwas damit. Der bringt irgendetwas an. Das heißt, da braucht er erst mal die nötige Information dazu. Wie funktioniert das überhaupt? Wo kommt der Bauplan her? Das muss dem angezeigt werden. Dann
00:12:33
Speaker
funktioniert da vielleicht irgendwas nicht. Er braucht Hilfe. Er muss um Hilfe rufen. Das ist mit Sicherheit mit dem ersten System nicht machbar. Dann geht ihm die Ware aus. Das heißt, er braucht eine bestimmte Schraube, um da was anzubringen. Jetzt ist aber natürlich das Kestle gerade leer, dieses Kanban-Kestle. Also ich hoffe, dass die Leute außerhalb von Schwaben das Wort Kestle verstehen. Also ihr wisst schon, diese Box mit den Schrauben.
00:12:59
Speaker
So, das ist leer. Das heißt, er muss das nach bestellen und idealerweise hier auch nochmal um Hilfe rufen. Und dann, wenn er fertig ist mit dem, was er da macht, mit dem Werkstück, dann muss er diesem Förderband oder dieser Förderanlage sagen, dass dieses Werkstück jetzt bitteschön zum nächsten Arbeitsplatz weiter transportiert werden soll. Das heißt, er muss dann irgendwie mit der Maschine oder mit dem Materialfluss kommunizieren. Das für sich alleine wäre jetzt erst mal ein ganz einfaches Beispiel, wo ein ganz normaler Werker eben mit multiplen Systemen
00:13:28
Speaker
interagieren muss und das idealerweise möglichst fehlertolerant. Und dann, das nimmt aber in der Komplexität ja dann wahrscheinlich zu, je größer so eine Produktion dann halt ist, richtig? Ja, das ist, wenn ich es mir jetzt recht überlege, bin ich mir jetzt gar nicht so sicher, ob die Komplexität eigentlich mit der Größe der Produktion steigt. Ich könnte mir vorstellen, dass auch in sehr kleinen produzierenden Unternehmen eine gewisse Komplexität da ist.
00:13:56
Speaker
und dass die da unter Umständen vielleicht sogar größer ist. Also ich würde dem jetzt nicht pauschal zustimmen, dass die Komplexität mit der Produktionsgröße wächst. Und mit PeekBoard kann man jetzt also Anwendungen bauen über einen Low-Code-Bilder, richtig? Das ist die Lösung dann? Ganz genau. Das ist also die Lösung zum Beispiel für dieses Problem, das wir jetzt gerade diskutiert haben, dass ich sage, ich mute diesen
00:14:24
Speaker
diesem Mitarbeiter gar nicht mehr den Zugang zu allen diesen IT-Artefakten zu der Maschine zu, sondern ich gebe dem einfach nur ein Touchscreen, das ihn perfekt dahingeidet, wo er hin will, das ihn bei diesen Aufgaben unterstützt und diese Applikation wiederum kapselt die komplexe, die komplette Komplexität dieser IT-Landschaft eben weg und erledigt das für ihn.
00:14:52
Speaker
Wie kann man sich Peekbot als als Software oder als Plattform vorstellen? Also es ist dann dann eine Web App oder eine App zum Downloaden, in der man dann anfängt, verschiedene Datenquellen anzubinden oder?
Das Peakboard Box Konzept und seine Vorteile
00:15:07
Speaker
Also generell ist es so, dass diese Applikation mit einer normalen Desktop App gebaut wird. Das heißt, das kann man sich diesen Peekbot Designer, das kann man sich vielleicht ein bisschen vorstellen, wie eine wie eine Mischung aus
00:15:20
Speaker
PowerPoint, Excel und Access. Das heißt, ich habe eine visuelle Komponente, baue diese Anwendung eben schon mal rein visuell auf, so wie sie hinterher bedient werden soll. Und dann muss ich da natürlich Logik dahinter klemmen. Diese Logik hat in der Regel irgendwas mit Daten zu tun. Das heißt, ich muss mit den verbundenen Systemen kommunizieren, entweder Daten abrufen oder dorthin schicken.
00:15:44
Speaker
Und diese Logik, die baue ich eben über eine Low-Code-Anwendung, die in den Designer integriert ist. Und am Ende ist diese Mischung aus Low-Code-Logik plus die Visualisierung plus eben den Zugang zu den einzelnen Datenpunkten, das deploye oder installiere ich auf einer sogenannten Peakboard-Box. Und diese Peakboard-Box ist tatsächlich ein physisches Stück Hardware, das
00:16:14
Speaker
an dem Arbeitsplatz des Verkost direkt hinter dem Touchscreen hängt und eigentlich den PC ersetzt. Also da wo vorher der alte PC mit dem Röhrenmonitor stand, hängt jetzt eben ein Touchscreen und an den Touchscreen ist die Peekbot Box montiert und ersetzt den PC. Und darauf läuft die eigentliche Anwendung. Und das beantwortet dann auch die Frage, ist das eigentlich web? Und die Antwort ist nein, ist es nicht.
00:16:39
Speaker
Weil es läuft tatsächlich auf der Box und es läuft tatsächlich eher wie eine App auf einem Handy, die ja eigentlich in der Regel auch keine Web-Oberfläche hat.
00:16:48
Speaker
Ja, exakt. Spannend, das mit der Box, war das von Anfang an ein Teil der Lösung, also als du gedacht hast, okay, das muss man jetzt, dieses Problem, was wir eben besprochen hatten, muss gelöst werden, ich baue das jetzt selber, war das von Anfang an auch die Idee dann, dass du sowas brauchst, oder hat sich die Box aus einem Need entwickelt, zu sagen, okay, ich muss sicherstellen, dass jeder Bildschirm dann irgendwie mit der Software kompatibel ist?
00:17:16
Speaker
Die Box war von Anfang an mit dabei, die kam nicht später, sondern die war tatsächlich von Anfang an mit dabei. Und der Grund dafür war eben, dass wir es den Leuten, die diese Anwendung oder den Prozess designen, so einfach wie möglich machen wollen. Wir wollen denen eben nicht zumuten, dass die IT dort erst einen PC installieren muss, auf dem PC muss dann diese runtime laufen, die stört sich dann mit dem Virenscanner und so weiter.
00:17:42
Speaker
sondern wir wollen, dass eben nur die Anwendung auf der Box läuft und dass daraus eine maximal smoothe Experience entsteht für denjenigen, der die Anwendung baut und eben deployen muss. Jetzt ist es aber so, dass dann natürlich schon auch Kunden um die Ecke kamen und sagen, unsere Organisation erlaubt es eigentlich nicht, dass ihr als damals noch Start-up hier einfach mit eurer Hardware in unsere Produktion reinmarschiert und ihr das dann einfach anklemmt.
00:18:11
Speaker
Also insbesondere in der pharmazeutischen Industrie oder sonst auch in stark regulierten Umgebungen ist es richtig schwierig mit der eigenen Hardware. Nicht unmöglich, aber schwierig. Und für diese speziellen Fälle würden wir auch eine Bring your own device Lizenz zur Verfügung stellen. Das heißt wer Part 2 die Box als Hardware nicht will, dafür haben wir eine Lösung. Ich würde aber sagen, dass sich 80 bis 90 Prozent der Kunden aktuell für die Box Lösung entschieden haben, um diese
00:18:41
Speaker
diesen smoothen Übergang hinzubekommen. Als du damals dann die ersten Kunden dazu bewegen musstest, sozusagen die Peekbot Box anzubringen, du hast ja auch gerade gesagt, das ist gerade bei den stark reglementierten Unternehmen wahrscheinlich schwieriger. Haben sich von denen die meisten mittlerweile dazu entschieden, die zu nutzen? Oder kam dann wirklich dieses Nee, ich würde gerne die Software nutzen, aber ohne die Box?
00:19:09
Speaker
Darg-reglementierten, die tun sich tatsächlich leichter mit der Selbstinstallation. Aber das gilt wirklich nur für die. Also bei allen anderen überwiegt schon der Vorteil der Box, der da mitkommt. Und letztendlich sind wir beispielsweise auch in der Lage, eben ordentliche Lösungen für die Administration anzubieten. Das heißt, die sehen die Box in ihrer
00:19:33
Speaker
in ihren Administrationsoberflächen, wie jeden anderen Rechner, kann auch in die Domäne eingebunden werden. Es gibt Administrationstools dazu, den Peek Board Hub. Ich meine, man muss sich das vorvorstellen, wir haben Kunden, die haben, ich glaube, der größte Kunde hat weit über 300 dieser Boxen. Das heißt, mit einer gewissen Wahrscheinlichkeit fällt da hin und wieder eine aus. Ich meine, das ist ja schon alleine Frage der Statistik.
00:19:57
Speaker
Und dann muss natürlich auch eine ordentliche Lösung her. Wie administriere ich das? Wie mache ich Updates? Wie stelle ich Sicherheit sicher? Und wie deploye ich die Anwendungen massenhaft darauf? Das muss dann natürlich schon geregelt sein. Wir reden ja nicht nur über einen, sondern eben über in der Regel hunderte von Arbeitsplätzen.
00:20:17
Speaker
Das heißt, also kurz gesagt, die Peekbot Box ist ein kleiner Computer, der an jeden gängigen Produktionsbildschirm angeschlossen werden kann, damit am Ende dann wirklich die Software oder die Apps, die sie damit gebaut haben, angezeigt werden.
00:20:33
Speaker
Ganz genau. So würde ich das sagen, ja. Spannend. Spannend. Coole Lösung auf jeden Fall, also eine Hardware-Komponente da noch hinzufügen zu müssen. Das hatte ich auf jeden Fall bei den bisherigen NoCo Logo-Tools, die wir so interviewt haben oder sonst so behandeln, noch nicht. Aber macht natürlich in dem Produktionsumfeld wahrscheinlich auch total Sinn. Vielleicht noch ein letzter Hinweis. Ja, bitte.
Vorteile der Non-Cloud Architektur in regulierten Industrien
00:21:00
Speaker
Diese Architektur erlaubt es natürlich auch völlig frei von Cloud zu arbeiten. Also das ist natürlich auch ein Vorteil, den wir mitbringen. Wenn wir beispielsweise Wettbewerber angucken, die die ganze Sache webbasiert und eben als SaaS Cloud Service anbieten, was mit Sicherheit auch eine valide Architektur ist, dann brauche ich natürlich immer ein Loch in meiner Firewall zu meinem Produktionsnetzwerk. Das heißt,
00:21:33
Speaker
in bestimmten, eben auch stark reglementierten Umgebungen ist es nahezu unmöglich. Und da können wir natürlich auch helfen. Das wollte ich nur. Aber sehr guter Punkt, weil ich hätte mich jetzt nämlich auch gefragt, ob die Peekbot-Boxen miteinander verbunden sind. Oder ist das gar nicht notwendig? Ja, das kommt drauf an, ob man das braucht oder nicht. Also grundsätzlich mal haben wir
00:21:57
Speaker
Die eine Kundenkohorte, die praktisch sagt, eigentlich benutze ich diese App, die ich da drauf baue, als reine Fassade für eine gewisse Komplexität der IT-Systeme, die dahinter liegen. Es gibt aber durchaus auch andere Kunden, die sagen, na ja, eigentlich kann ich mir da sogar ein anderes System sparen. So der Klassiker wäre einfache MES-Anwendungen. Also wenn es zum Beispiel darum geht, ich möchte nur etwas tracken, die Maschine beispielsweise, den Output der Maschine über die Zeit.
00:22:27
Speaker
Das könnte ich ja einfach direkt mit der Box machen und dann schreibe ich einfach die Historie in einen Server oder in den Peekbot Hub weg und habe dann so eine Art Mini MES Funktionalität. Dann geht natürlich die Anwendung über diese reine Fassadenfunktion deutlich hinaus.
00:22:45
Speaker
Und wenn jemand jetzt, ich komme auch gleich nochmal dazu, wer sozusagen die User letztendlich sind und die Kunden, aber wenn jemand jetzt über die Peekbot Desktop App eine neue Anwendung baut, um die auf die Peekbot Box zu spielen, muss man die sozusagen immer an den PC anschließen oder kann man die auch rüber schicken oder aktualisieren über das Netzwerk? Nein, nein, wir brauchen lediglich eine Netzwerkverbindung.
00:23:13
Speaker
In der Regel sind die Boxen an den Arbeitsplätzen oder vielleicht sogar overhead so verbaut, dass ich da physisch nicht so einfach rankomme. Letztendlich ist ja auch eines unserer Versprechen und auch im Übrigen eines der Versprechen von Low-Code im Allgemeinen ist ja dieser Agilitätsgedanke, das ich eben sage.
00:23:31
Speaker
dass ich eben sage, mein Prozess, der muss flexibel sein. Das heißt, auch die Anwendung muss flexibel sein. Dann kann ich niemand zumuten, dass er die Box jedes Mal abschrauben findet, dann eine neue Version davon. Das ist ja selbstverständlich.
00:23:45
Speaker
Okay, dann genau zu der Frage, wer sind die User und zwar einmal diejenigen, die dann über die Desktop-App die Anwendungen bauen und das sind da wahrscheinlich ganz andere als diejenigen in der Produktion oder bauen sich die Leute da teilweise ihre eigenen Anwendungen, wenn sie meinen, okay, in meiner Produktionsabteilung brauche ich das und
Die Entwicklung und Notwendigkeit von Low-Code Lösungen
00:24:06
Speaker
das? Ja, also es ist so, dass
00:24:11
Speaker
In der Produktion ja oft diejenigen Rollen, die am Ende die Prozesse bauen, sind ja diejenigen, die sich den Need für so eine App normalerweise ausdenken. Und das sind relativ häufig auch die, die die Anwendungen bauen, entweder mit oder ohne Zusammenarbeit der jeweiligen IT. Wir sehen beides unter unseren Kunden.
00:24:38
Speaker
Und auch mit oder ohne Hilfe von uns. Also grundsätzlich mal sind wir ja eine Produktcompany. Wir würden aber Kunden natürlich schon auch so ein bisschen zur Verfügung stehen. Was wir gerne machen, sind zum Beispiel so Workshops, dass man sagt, komm, wir bauen den ersten Prototyp mal zusammen. Wir versuchen das dann aber relativ schnell an den Kunden abzugeben. Und dieses Abgeben passiert in der Regel tatsächlich an IT-Fremdeleute.
00:25:08
Speaker
Also, ich würde sagen 70, 75 Prozent IT-fremde Leute, aber sophisticated IT-User, das sind so typische Leute, die auch diese Excel-Geschichten sich zusammenbauen. So beliebiger Komplexität. Und der Rest, also vielleicht so 30 Prozent, da ist es dann rein in der IT verortet, solche Anwendungen zu erstellen.
00:25:35
Speaker
IT heißt jetzt aber nicht zwingenderweise, dass da Programmierer sitzen. Das heißt, Low-Code ist für beide Gruppen absolut interessant. Genau, weil das ist ja das Tolle an Peekbot eben, dass es ja eine Low-Code-Lösung ist. Und um genau eben dieses Problem zu lösen, dass das, wie du auch schon gesagt hast, 70-75% von Nicht-ITler dann sagen, hey, ich habe ein Problem und ich baue mir jetzt irgendwie meine eigene Anwendung.
00:26:06
Speaker
Wie kam es so damals darauf, das als Low-Code-Lösung zu bauen? Hattest du vorher schon Erfahrung mit Low-Code und Low-Code-Tools? Wie sieht es da aus? Im Gegensatz zu dieser Box-Hardware-Komponente war das Thema Low-Code nicht von Anfang an auf dem Radar. Eigentlich haben wir gesagt, wir wollen
00:26:28
Speaker
eben den Zugang zu Daten ermöglichen. Das ist natürlich total wichtig. Also die Knotenpunkte, diese Datenpunkte, die mit dem Quellsystem kommunizieren. Wir wollen eine wirklich gute visuelle Oberfläche und für die komplexe Logik implementieren wir eine Skript Sprache. In dem Fall war das Lua bei uns und komplexe Logik kann ich eben über Lua kodieren, wenn ich das möchte. So sind wir mal ursprünglich ins Rennen gegangen.
00:26:56
Speaker
weil auch alles andere für uns technisch nicht machbar war. Und dann sind wir aber relativ schnell drauf gestoßen, dass Kunden eben Angst vor diesem Scripting haben. Also das ist so ein Wesen von Nicht-Programmierern, dass Leute dieses Scripting gar nicht erst anfassen wollen. Eigentlich ist es ja gar nicht so schwer.
00:27:22
Speaker
Also ich als, zumindest für mich als Programmierersicht. Aber das ist ein totaler Hemmschuh. Die Leute haben total Hemmungen, Skripten. Also alles, was das Tippen von Code angeht, also komplexe Excel-Formel, die in eine Zeile reinpassen, ist etwas, was irgendwie noch akzeptiert wird. Und alles, was mehrzeilig ist, wird von den Leuten abgelehnt. Das heißt nicht, dass es nicht können, sondern wird von den Leuten abgelehnt.
00:27:51
Speaker
Und dann sind wir relativ schnell eben auf den Trichter gekommen. Wir müssen hier eine Lockout-Lösung zur Verfügung stellen, die die Leute von diesem mehrzeiligen Skript entbindet. Und deshalb haben wir das gemacht. Das war aber ein Learning, kein initialer Plan.
00:28:08
Speaker
Wie war deine Erfahrung mit Logo Tools davor? Also, hast du schon mal damit gearbeitet? Kanntest du ein paar, an denen du gesagt hast, hey, so eine Lösung wäre irgendwie dann cool? Ja, also was ich kannte, ist auf jeden Fall Power Automate, weil wir das selber viel damit machen. Und ich persönlich muss sagen, also das sind vielleicht sehr frühe Versionen von Power Automate, dass das eine ganz schön komplizierte Angelegenheit ist. Also Power Automate da komplexe Sachen zu bauen,
00:28:37
Speaker
Ohne ein Entwicklermindset, dass beispielsweise diese JSON-Strukturen und überhaupt komplexe Datenstrukturen versteht, das ist ganz schön tricky. Deshalb wollten wir uns eigentlich explizit daran nicht orientieren, sondern haben von Anfang an gesagt, wir gehen mit einfacheren Konzepten ins Rennen. Aber das war das, was ich konnte, um die Frage zu beantworten.
00:29:04
Speaker
Und es ist, also Peekbot ist eine Low-Code-Lösung, weil da wirklich auch gezwungenermaßen noch irgendwie gecoded werden muss an manchen Teilen oder einfach weil die Komplexität nochmal größer ist als jetzt eine leichte Low-Code-Lösung. Die Komplexität ist unter Umständen schon ganz schön hoch, das muss man sagen. Insbesondere, wenn man Daten aus unterschiedlichen Quellen so abmischen will, dass was Vernünftiges dabei rauskommt. Tatsächlich Coden ist aber zu keinem Zeitpunkt zwingend notwendig.
00:29:34
Speaker
Also die Low-Code-Komponente erlaubt, sehr komplexe Prozesse zu bauen. Die Frage ist, eigentlich ist das eher limitiert, dass ich halt irgendwann selber nicht mehr blicke, was ich da gebaut habe. Also letztendlich ist ja Low-Code, da geht es ja immer um das Zusammenbauen von Blöcken und von Abläufen. Aber das entbindet mich ja nicht von dem Verständnis dafür, was mache ich eigentlich mit den Daten.
00:30:01
Speaker
Welche Cases gibt es? Welche Ausnahmen gibt es? Das muss ich ja alles trotzdem verstehen. Das kann mir das System nicht bis zu einem beliebigen Level abnehmen. Und ich glaube, das ist die Glaswand, wo die Leute dran stoßen, ist die Komplexität und nicht das Tool.
00:30:19
Speaker
Ja, exakt. Ich glaube, jeder, der schon mal mit komplexeren No-Codes oder Logo-Tools gearbeitet hat oder selbst mit den simplen, aber irgendwann stößt man an so einen Punkt, wo man merkt, okay, die Oberfläche ist schön, ich verstehe relativ leicht, wie ich was hin- und herschicke, aber jetzt habe ich irgendwie einen Fehler und ich kann nicht nachvollziehen, warum. Und dort ist ja meistens dann
00:30:42
Speaker
wenn man eben so ein Entwicklermindset hat, selbst wenn man kein Entwickler oder Entwicklerin ist, hilft es halt total einfach zu wissen, naja, der Fehler liegt daran, dass ich ja erstmal irgendwie auf etwas zugreifen muss, bevor ich dann den nächsten Step gehe und dass vielleicht die Datensstruktur nicht die richtige ist und da irgendwo ein Fehler ist.
00:31:03
Speaker
Aber ja, das, ich glaube, das lernt man dann auch mit der Zeit, je länger man eben mit solchen Tools arbeitet. So war es jedenfalls bei mir, dass man, man kommt in diese Entwicklerdenke dann rein und merkt so, okay, ja, das ist einfach nur leichter, das dann zu bauen, weil ich keine Zeilen schreiben muss. Aber die Denke verändert sich da nicht. Absolut nicht. Das ist, das ist völlig richtig. Aber was natürlich
00:31:27
Speaker
definitiv der Fall ist, und das merken wir auch immer wieder, wenn wir zum Beispiel Leuten zuschauen, die mit PeekBoard was bauen, womit sich zum Beispiel viele schwer tun, ist das Thema Datentypen. Also ich kann als Programmierer, verstehe ich natürlich sofort, was ist eigentlich der Unterschied zwischen einem Integer, einem String, einem Datum und einer Bullion-Variable? Dieses Wissen bringt einen Non-Entwickler erst mal nicht mit. Und das ist auch erst mal nicht ganz einfach, überhaupt dieses Prinzip zu verstehen.
00:31:57
Speaker
Und was die Umgebung jetzt aber machen kann ist, sie kann das antizipieren. Sie kann sagen, oh, wenn hier aber der Typ versucht, mit dem String was auszurechnen, dann könnte ich sagen, nee, das ist nicht zulässig, weil mit dem String kann ich nicht rechnen. Oder ich kann sagen, lass uns das doch mal probieren, ob wir den String nicht irgendwie halbautomatisch konvertieren können, um dann halt doch was zu rechnen. Das heißt,
00:32:26
Speaker
Ich kann das schon als Umgebung antizipieren und den User dabei unterstützen.
00:32:33
Speaker
Stark. Ich kenne ähnliche Funktionen, kenne ich bisher eigentlich nur von OutSystems. Damit habe ich in meiner Masterarbeit dann eine Handy-App machen müssen. Und da kam ich das erste Mal so richtig an meine Grenzen von dem Verständnis von solchen Sachen. Und da hatten die eben auch dieses Feature zu sagen, wenn ich irgendwas eingestellt habe, so hey, es ist zwar noch kein Fehler, weil noch nichts ausgeführt wurde, aber wahrscheinlich wird es einen Fehler geben. Dein Datentyp sieht mir nicht richtig aus. Und das ist extrem hilfreich. Selbst wenn du noch nicht exakt weißt,
00:33:03
Speaker
welcher dann der richtige ist, weiß einfach schon mal, okay, Moment, bevor ich jetzt hier irgendwie alles baue und auch Fehler stoße, was soll dich da mir vielleicht erstmal aneignen? Ja, genau. Ich meine, da kann man sich zum Beispiel mal angucken, wie hat Microsoft das eigentlich gemacht? Also, die Älteren unter uns erinnern sich zum Beispiel noch an VBA, Visual Basic for Applications. Das gab es in den 90ern schon. Da konnte ich schon so Geschichten programmieren in Excel. Und das war auch
00:33:29
Speaker
unheimlich, eine unheimlich schmutzige Angelegenheit aus Entwicklersicht. Weil dieses Visual Basic, das hat einfach alles miteinander vermischt und dann versucht, irgendwie auszuführen, was da rauskam. Und es führt dazu, dass vieles funktioniert und dass dann aber halt am Ende auch zu zehn Prozent auf der Strecke bleiben, wo keiner so richtig weiß, warum, warum rechnet er jetzt so und nicht anders? Ja, also
00:33:55
Speaker
Diese Datentypsicherheit, die wir Programmierer ja eigentlich schon gerne haben, die gibt's, die fällt nicht ohne Grund vom Himmel. Die hat schon seine Daseinsberechtigung und da muss man einen guten Mittelweg finden. Wie sehen denn ähnliche Lösungen aus, die es vielleicht vorher schon auf dem Markt gibt oder jetzt auf dem Markt gibt in Bezug auf zum Beispiel der Low-Code-Komponente? Ist das etwas, wo ihr auf jeden Fall so eine Unique Selling Proposition habt?
00:34:26
Speaker
Also ich denke, über die letzten Jahre hat sich Low-Code definitiv vom USP zum Must-Have gewandelt. Also wenn ich mir vergleichbare Wettbewerber angucke, ist Low-Code eigentlich schon immer ein Muss. Das ist da irgendwie, das muss mit dabei sein. Der Unterschied liegt im Detail. Ist diese Low-Code-Plattform wirklich etwas, mit dem der
00:34:55
Speaker
der Entwickler wirklich was Cooles bauen kann, ohne daran zu verzweifeln? Oder ist es halt ein Low-Code-Etikett, am Ende muss ich aber tiefer reingehen, als bei der normalen Entwicklung überhaupt erst mal diese Low-Code-Layer zu verstehen? Da gibt es relativ große Unterschiede, Low-Code-Label hat aber jeder.
00:35:18
Speaker
Okay, spannend. Aber das hätte ich jetzt auch so mir gedacht, weil die Entwicklung geht ja ganz stark in die Richtung. Auch für No-Code natürlich an sich. Immer neue Tools und immer mehr so Citizen-Developer, aber auch Low-Code, um eben existierenden Entwickler und Entwicklerinnen sagen zu können, hey, ihr könnt das zwar alles, aber durch Low-Code könnt ihr das halt schneller. Aber wie du schon sagst, es ist halt sehr kritisch, diesen Unterschied dann zu haben zwischen
00:35:46
Speaker
Oh ja, das ist wirklich eine gute Low-Code-Lösung und ich als Developer kann jetzt einfach viel schneller Sachen entwickeln oder es ist einfach nur so ein Stempel und irgendwie ist es aber am Ende doch noch komplizierter und dann greife ich einfach zurück auf Code, weil ich das halt schon kann, weil ich damit im Zweifel schneller bin. Ja, ja, völlig richtig. Völlig richtig. Die Frage ist eigentlich, was kommt eigentlich danach? Also, wo stehen wir eigentlich in fünf Jahren? Ja, ja.
00:36:14
Speaker
Ist das bei euch gerade auch schon ein großes Thema?
Einführung von KI-Funktionen zur Verbesserung der Benutzererfahrung
00:36:18
Speaker
So AI-Assistants für die App? Absolut. Absolut ist das ein Thema. Also wir werden mit der nächsten Peekbot-Version, die irgendwann in den nächsten paar Wochen rauskommt, das ist glaube ich die 3.9 oder so, werden wir zum ersten Mal direkt eingebaute AI mitliefern, die dem User noch weiterhilft voranzukommen. Das heißt, ich kann dann eigentlich so, wie man das von Copilot oder von JetGPT direkt
00:36:44
Speaker
erkennt Kontext, spezifische Fragen stellen. Und dann kriege ich auch eben eine Antwort, die mich idealerweise davon entbindet, in der Hilfe nachgucken zu müssen. Also die AI macht eigentlich nichts anderes als im Handbuch nachgucken. Aber die nächste Stufe ist definitiv eigentlich zu sagen, warum lassen wir den Anwender nicht in natürlicher Sprache erklären, was er gerne haben will und bauen idealerweise weite Teile der Anwendung.
00:37:14
Speaker
Das gilt im Übrigen nicht nur für die Logik, das gilt auch für die reine Visualisierung. Das gibt keinen Grund, warum man das aussparen muss. Und das gilt auch für den Zugriff auf die Zugriff und die Interpretation der Quelldaten. Alle diese Dinge kann ich mit AI deutlich beschleunigen. Und das wird der neue USP in den nächsten zwei bis drei Jahren. Da bin ich mir sehr sicher. Also wir glauben da fest dran und wir arbeiten da dran.
00:37:39
Speaker
Ja, keine Frage. Wir sind da auch total on board, was das angeht. Wir beobachten jede Woche neue Tools. Und existierende Tools haben halt jetzt gefühlt auch wöchentlich ein Update mit, hey, du kannst jetzt mit natürlicher Sprache deinen ersten Entwurf bauen lassen. Und es kommen neue Tools auf Markt, die nur so funktionieren. Welche jetzt am Ende sich durchsetzen werden oder nicht, das wird es dann zeigen. Aber ich glaube,
00:38:06
Speaker
Das wird auf jeden Fall diese Hürde für diejenigen, die, klar, no good, macht es schon total einfach, irgendwelche Sachen zu bauen, aber jeder, der schon mal versucht hat, mit Bubble oder Weweb eine komplexere App zu bauen, merkt halt, okay, ich muss nicht programmieren können.
00:38:21
Speaker
Aber ich muss trotzdem ziemlich gut verstehen können, wie funktioniert die Datenbank, wie funktioniert die Logik, was mache ich hier eigentlich. Und so einen ersten Entwurf über natürliche Sprache ist natürlich schon sehr hilfreich, was aber einen nicht davon entbindet zu sagen, ich muss ja trotzdem dann das Tool verstehen, weil wenn da irgendwas nicht so ist, wie ich es möchte, muss ich ja auch nochmal eingreifen. Ja, aber das ist die Frage, ob man eigentlich diesen Einsatz nicht tatsächlich dann nochmal weiter denken kann und zu sagen,
00:38:49
Speaker
Eigentlich haben wir mit AI die Chance, genau dieses latente Problem, das Low-Code nicht gelöst hat, tatsächlich final zu lösen. Also wir sind uns ja jetzt einig darüber, dass Low-Code den Designer, also die Designrolle nicht davon entbindet, am Ende zu verstehen, was will ich überhaupt und wie kommt das zustande. Das muss er immer noch selber mitbringen.
00:39:16
Speaker
Und ich halte das durchaus für eine valide Hypothese zu sagen, wenn sich AI weiterentwickelt, dass genau das der Punkt ist, den AI durchaus ersetzen kann.
00:39:29
Speaker
Das halte ich für valide. Ich glaube, ich glaube auch. Also einfach dieses Verständnis dafür, was dann zum Beispiel ein Produktdesigner halt haben möchte, wird sich verbessern. Die Art und Weise, wie man der AI das mitteilen kann und dann auch der iterative Prozess dahin zu kommen, also dass dann vielleicht wirklich irgendwann mal so ist.
00:39:48
Speaker
Dass du halt einfach in einer Art Chat dann einfach sagst, okay, das ist ein erster Guteinwurf. Das soll aber so aussehen. Das muss sich noch so verändern. Das meinte ich eigentlich so. Dann schickt man da ein paar Screenshots von ähnlichen Tools, wie man sich das vorstellt. Und ich glaube, da steht dem irgendwie außer vielleicht ein paar Monate oder weniger Jahre nichts mehr im Weg, um ehrlich zu sein. Glaub ich auch. Glaub ich auch. Absolut. Wenn wir's sehen.
00:40:17
Speaker
Ja, ich bin gespannt. Du hast ja vorhin auch erwähnt, wenn ihr so beobachtet, wie dann manche mit PeekBoard umgehen und arbeiten. Was sind sonst so Sachen, die ihr von euren Kunden oder über eure Kunden gelernt habt, aus der Arbeit mit Low-Code? Ja, also ich glaube, ein Learning, das jetzt mal rein über die
00:40:45
Speaker
über die Technik hinausgeht, ist auf jeden Fall dieser Need für zunehmende Agilität. Also diese Idee zu sagen, wir bauen ein Stück Software, das die nächsten 15 Jahre hier läuft, das gibt es nicht mehr. Also eigentlich muss ich heute, wenn ich einen Softwareentwicklungsprozess, egal ob mit oder ohne Low-Code betrachte, muss ich den konsequent auf
00:41:13
Speaker
Agilität, also auf eingebaute Veränderungen ausrichten. Das ist eine Sache, die zieht sich total durch, weil das eben nicht nur eine reine Technik, sondern auch eine Mindset-Frage ist. Locode ist da eigentlich nur ein Tool dazu.
00:41:28
Speaker
Das finde ich jetzt als nächstes spannend zum Thema Mindset. Konntet ihr beobachten oder irgendwie mitbekommen, dass bei Kunden, die Peekbot schon eingesetzt haben, sich dahingehend irgendwas verändert? Also dieses agilere Mindset, dieses Hey, ich baue mir jetzt meine eigene Lösung zu meinem Problem Mindset? Absolut, absolut.
00:41:50
Speaker
wenn wir jetzt praktisch mal in so eine richtige konservative Firma mit einer relativ langen Historie reingehen, also es ist jetzt egal, ob Fertigung oder Logistik, also wird zum Beispiel mein ehemaliger Arbeitgeber, würde ich jetzt tatsächlich als eigentlich konservativ betrachten, auch hier sehen wir, dass
00:42:13
Speaker
diese ständige Iteration, diese ständige Verbesserung, die vor allem bis in die IT reingeht, dass das einen ganz wesentlichen Beitrag leistet. Es gilt jetzt nicht nur für Wirt, es gilt tatsächlich für fast alle Kunden. Das muss man hier schon sagen. Das Problem war in der Vergangenheit oft nur dieser limitierende Faktor dessen, dass die eigentliche Erstellung von Applikationen
00:42:40
Speaker
eben einem ganz elitären Kreis vorenthalten war, der nach dem klassischen Wasserfall Prinzip, also wir machen jetzt Lastenheft, dann ziehen wir uns sechs Monate in den Elefantenturm zurück und dann ist das Ding fertig und dann gehen wir in das nächste Projekt. Ja, also so laufen ja traditionell IT Projekte und das sehen wir, dass sich das total aufweicht.
00:43:06
Speaker
Und um ehrlich zu sein, habe ich jetzt die Originalfrage vergessen. Wie war die noch? Das ist schon eine sehr gute Antwort darauf, ob ihr eben gemerkt habt, dass sich das Mindset und dann auch so ein bisschen die Kultur, was das angeht, bei dem Kunden verändert. Ja genau, die Kultur ändert sich. Und die Kultur ändert sich im Übrigen auch in der IT-Abteilung. Also das ist ein ganz klarer Mindset-Shift, den wir auch eben in konservativen Firmen sehen. Dass wir uns das heutzutage im Zuge von
00:43:35
Speaker
Globalisierung und Deglobalisierung eben nicht mehr leisten können, in derartigen Zyklen zu denken. Absolut. Stößt ihr bei dem Implementierungsprozess aber auch dann auf so Roadblocks oder irgendwelche Gründen oder vielleicht sogar Personen in der Belegschaft, die dann sich schwer damit tun, das zu implementieren?
Kulturelle Widerstände und Transparenz in IT-Prozessen
00:43:55
Speaker
Klar. Stößt mal die ganze Zeit. Also so ein typischer Punkt des Transparenz.
00:44:03
Speaker
Also Transparenz in einen Prozess zu bringen, beispielsweise durch Datenerfassung oder einfach durch Anzeigen bestehender Daten ist etwas, was von vielen erstmal oder was von manchen eben nicht geliebt wird. Also fehlende Transparenz schützt auch viele Leute in ihrer Komfortzone. Das ist ein Nummer eins Punkt, den wir sehen. Dann ist es so, dass diese
00:44:30
Speaker
ständige Veränderung auch etwas ist, was potenziell vielleicht den Menschen im Allgemeinen ein bisschen zuwiderläuft. Also Veränderung ist immer mit Schmerzen und mit Aufgeben des liebgewonnenen verbunden. Ich denke, dass das in Menschen drinsteckt, sowas nicht haben zu wollen. Habe ich auch Verständnis dafür.
00:44:57
Speaker
Ja, absolut. Genau. Ich glaube, das kennt ja jeder irgendwie aus verschiedenen Bereichen im Leben. Aber das funktioniert am Ende dann meistens trotzdem, dass ihr dann PeekPort irgendwie umgesetzt bekommt, gehe ich mal von aus. Weitestgehend klappt das in der Regel schon, weil oft die Vorteile recht deutlich sind. Es ist jetzt nicht so, dass wir 100 Prozent unserer Projekte am Ende zum Erfolg führen.
00:45:24
Speaker
Das funktioniert, glaube ich, mit keinem Tool. Das ist möglicherweise auch gar nicht abhängig vom Tool. Aber weitestgehend, wenn die, sagen wir mal, wenn der Wille der Geschäftsleitung oder wenn der Wille von oben tatsächlich da ist, dann klappt das immer, würde ich schon sagen. Sehr gut.
00:45:43
Speaker
Und nochmal zum Thema Kultur, war jetzt so ein bisschen in Peekbot, also in das Unternehmen selbst reingeguckt. Wie ist das da bei euch dadurch, dass ihr ja selber ein Low-Code-Tool baut? Ist dieses agile Mindset da auch so prominent und nutzt ihr auch andere Low-Code, Low-Code-Tools im Alltag, wo ihr aber arbeitet?
Interne Nutzung von Low-Code Tools bei Peakboard
00:46:04
Speaker
Ja, also natürlich ist das präsent. Als relativ junges Tech-Startup, ich glaube, da hat man keine Berührungsängste vor.
00:46:13
Speaker
vor Veränderung und wenn man welche haben, dann muss man sie so schnell wie möglich ablegen. Ich meine, das ist ja quasi ein Todesurteil, wenn man sich gegen Veränderung stimmt. Was wir an Low-Code-Plattformen benutzen, das hatte ich schon erwähnt, ist natürlich Power Automate. Wir kommen traditionell aus der Microsoft-Welt Office 365, da spielt Power Automate eine relativ große Rolle. Dann der Workflow Designer von HubSpot.
00:46:39
Speaker
falls man das als Low-Code betrachten will, ist etwas, was wir natürlich für alle Themen rund um Marketing, Sales, Automatisierung benutzen. Das sind eben so die beiden, die mir gerade einfallen.
00:46:52
Speaker
Und dann bauen wir natürlich sehr viel mit unserem eigenen Peakboard Designer. Das wäre dann das drittwichtigste Tool im eigenen Unternehmen. Das sind die drei, die mir jetzt gerade anfallen. Okay, sehr schön. Ja, und jetzt Richtung Ende. Was steht bei Peakboard gerade so an? Was sind Sachen, an denen ihr gerade arbeitet? Irgendwas Spannendes, irgendwas Neues, was gerade angegangen wird?
00:47:19
Speaker
Ja, also woran wir gerade arbeiten, ist eben, also es ist ja so, ich sagte vorher schon, wir haben dieses Verwaltungstool für die Boxen, den Peekbot Hub, das gibt es als SaaS Service und eben lokal on-prem, je nachdem, wie reguliert wir unterwegs sind. Und ein ganz hottes Thema ist praktisch diesen Hub nach außen zu öffnen dieses Jahr. Das heißt, ich kann dann zum Beispiel Power Automate, ein Flow in Power Automate,
00:47:49
Speaker
direkt benutzen, um Nachrichten auf den Screen eines Werkers zu schicken oder Informationen von dort zu empfangen. Während Power Automate in der Cloud läuft, der Werker aber in einem relativ isolierten Produktionsnetzwerk unterwegs ist, mit der entsprechenden Brücke zu dem SaaS Hub. Das ist etwas, das viele Kunden nachfragen und womit man natürlich total geile Architekturen bauen kann, weil ich diese ganzen Geschichten, die mit Predictive Maintenance und sonstigem
00:48:18
Speaker
sonstigen Cloud-Dingen eben in der Cloud passiert, eben direkt zu den Werken und zu den Logistikleuten bringen kann. Und dann kommt natürlich dieses Riesenthema AI, hatten wir schon angesprochen. AI im Designprozess der Applikation, aber natürlich auch AI für die Leute vor Ort in allen möglichen Kontexten. Fehlererkennung, Kamerabilder, die irgendetwas sehen, was andere Leute nicht sehen oder nicht so schnell sehen oder nicht so zuverlässig.
00:48:48
Speaker
Das Ansteuern irgendwelcher Instrumente für die Qualitätssicherung, das ist völlig endlos diese Liste für eine Prozessverbesserung aufgrund von AI. Das sind Dinge, denen wir uns die nächsten Monate annehmen.
00:49:05
Speaker
Sehr cool, sehr schön auf jeden Fall auch ein Tool wie Peekbot kennenlernen zu dürfen und eben auch zu sehen, dass Low-Code sich eben auch in Branchen oder Bereichen wie der Produktion durchsetzt, weil egal ob man das jetzt als Tool nimmt, um in einem kleinen Unternehmen Prozessor zu automatisieren oder privat sich eine App zu bauen oder aber eben in der Produktion irgendwie sich das Leben leichter zu machen. Am Ende ist es ja dieselbe Philosophie hinter Low-Code. Nehmen wir einfach den Zugang zu der Technologie
00:49:34
Speaker
und um sich sozusagen die eigenen Probleme vielleicht lösen zu können, ohne unbedingt Entwickler oder Entwicklerin zu sein. Das ist auf jeden Fall sehr, sehr, sehr spannend. Ich bin gespannt, wo es da noch hingeht.
Ratschläge für angehende Unternehmer
00:49:45
Speaker
Ja, vielleicht noch abschließend jetzt als du als Gründer
00:49:50
Speaker
der auch ein Low-Code-Tool selber baut, aber generell als Gründer, weil du ja auch am Anfang meintest, du hast es lange so nebenbei aufgezogen. Was würdest du Leuten mitgeben, die gerade so vielleicht am Anfang dieses Weges stehen oder überlegen, ob sie nebenbei vielleicht irgendwie was bauen sollten, so als Side-Hustle? Ja, also generell immer ja. Ja, immer Side-Hustle, immer Dinge ausprobieren, immer Dinge hinterfragen. Das ist ein Mindset. Das gilt aber nicht nur
00:50:18
Speaker
für die Gründung, dass ich bin der Meinung, dass das eine grundsätzliche Lebenseinstellung sein sollte, die viel zu wenig haben und die ich wirklich allen wirklich allen ans Herz legen würde. Völlig unabhängig davon, wenn das Thema Gründen, Firma selber bauen, Tools selber bauen. Ja, Sidehustle starten. Aber eines der ganz großen Punkte ist Fokus. Ja, ich meine, wenn die Sache zündet oder zünden soll, dann vollen Fokus.
00:50:47
Speaker
Ich glaube, das ist brutal wichtig. So richtig drauf konzentrieren, Resilienz entwickeln und idealerweise nur eine Sache und die richtig geil und richtig machen und sich nicht bei zehn verheizen, sondern eine Sache richtig geil machen. Das wäre so meine
00:51:06
Speaker
meine Altersweisheit zum, meinen Kalenderspruch zum heutigen Tag. Sehr schön. Das ist doch ein schöner Abschluss. Ja, Patrick, vielen, vielen Dank, dass du, dass du dabei warst. Hast du irgendwas, was den Leuten noch mitgeben möchtest? Seid ihr gerade am Einstellen? Ich meine natürlich, wenn unsere Zuhörenden Leute aus der Produktion sind, die finden den Link zu Peekbot in der Episodenbeschreibung. Auch dein Link im Profil, da können die dir wahrscheinlich auch jederzeit auf dich zukommen. Genau, aber hast du sonst noch was?
00:51:35
Speaker
Ja, gerne. Also ich habe immer ein total großes Interesse mit allen Leuten aus der Branche in Dialog zu treten. Kontaktiert mich auf LinkedIn. Teilt eure Gedanken. Wir können gerne ein Bier trinken gehen, auch völlig anlasslos jederzeit. Ich interessiere mich generell für alles, was andere Leute machen, mit dem sie Geld verdienen. Neue Ideen. Kommt auf mich zu. Ich bin total offen. Perfekt. Wo sitzt du?
00:52:05
Speaker
Also grundsätzlich ist die Firma ansässig in Stuttgart. Ich bin aber zurzeit in Taiwan, in Taipei und pendel zwischen Taiwan und Deutschland hin und her, weil trotz Work from Anywhere immer noch körperliche Anwesenheit erfordert bei Kunden und im Büro, aber so gestalte ich mein Leben.
00:52:29
Speaker
Ja, sehr spannend. Na gut, also wenn jemand gerade in Taipei ist, dann kann er... Jederzeit vorbeischauen. Ja, auf ein Bier und ansonsten... Kein guter Mars hier, wir gehen einen trinken. Sehr gut, alles klar. Dann ja, vielen, vielen Dank, dass du dabei warst, Patrick. Ich bin gespannt, was Peekbot in der Zukunft noch bringen wird und ja, auf bald dann hoffentlich. Ja, vielen Dank für die Einladung und an alle, die bis hierhin zugehört haben, vielen Dank fürs Zuhören. Ich weiß, das zu schätzen. Macht's gut. Tschüss.