Podcast

33 Min. Lesezeit

Folge 11 | EXTRA: Samurai & Friends 2025: Konferenzzusammenfassung (Interview)

Einleitung: Der Adrenalin- und Koffein-Nachglühen

Andrzej Kinastowski (AK): Konnichiwa! Willkommen, alle zusammen, im AI Automation Dojo, wo wir uns den Zustand von Geschäftskonferenzen ansehen und uns fragen: Hätte das nicht alles eine E-Mail sein können? Nun, wir haben beschlossen, eine zu machen, die das nicht hätte sein können. Heute genießen wir noch das Nachglühen unserer dritten Ausgabe der Samurai and Friends Konferenz. Ihr werdet von den beiden Gründern von Office Samurai hören, die derzeit auf einer gefährlichen Kombination aus Adrenalin und Koffein laufen. Wir sind hier, um zu analysieren, was passiert, wenn man eine intelligente Automatisierungskonferenz schafft, die die Intelligenz aller respektiert. Ich bin euer Gastgeber, Andrzej Kinastowski, einer der Gründer von Office Samurai, dem Unternehmen, das beschlossen hat, eine Konferenz zu veranstalten – und sie tatsächlich nützlich zu machen. Stellt euch das vor. Also, egal ob ihr dabei wart und den Glanz noch einmal erleben wollt oder ob ihr es verpasst habt und jetzt in FOMO ertrinkt – ihr seid hier genau richtig. Schnappt euch jetzt euer Lieblings-Katana oder den Kugelschreiber, den ihr ganz sicher vom Registrierungstisch mitgenommen habt, und los geht’s. Letzte Woche hatten wir die dritte Ausgabe unserer jährlichen Samurai and Friends Konferenz. Dominik, wie fühlst du dich – wie müde bist du? Hast du dich schon erholt?

Dominik Jaskulski (DJ): Andrzej, zuerst sollte ich dich fragen: Welche Konferenz? Offiziell gab es keine Konferenz. Es gibt quasi keine Webseite, auf der man Tickets kaufen könnte. Dies ist eine rein private Veranstaltung, zu der wir unsere Freunde einladen, überwiegend in Management-, Direktoren- oder C-Level-Positionen, um über KI-Automatisierung und Prozessverbesserung zu sprechen. Und ich fühle mich ein wenig erschöpft, aber zufrieden.

(AK): Am Ende hatten wir etwa 160 Personen. Wir hatten eine wirklich schöne Afterparty, die meiner Meinung nach natürlich ziemlich wichtig ist. Und die Frage direkt nach der Konferenz, die ich mir oft stelle, lautet: Warum machen wir das eigentlich?

(DJ): Wir veranstalten das Event, weil es auf dem Markt viel Aufsehen darum gibt, was mit KI potenziell möglich ist. Man sieht diese Beiträge auf LinkedIn mit 500 KI-Anwendungsfällen, die im Grunde genommen nichts bedeuten, oder? Wenn man genauer hinsieht, wurden sie wahrscheinlich von KI selbst generiert, und das sind keine echten Anwendungsfälle. Wir wollten also sehen, was auf dem Markt passiert, was möglich ist, welche Art von Projekten verschiedene Unternehmen durchführen und auch, welche Art von Fehlern sie während der Projekte machen. Ich denke, das war auch ein interessanter Teil zu beobachten, und das ist auf Konferenzen sehr selten, oder? Dass die Speaker auch zeigen, was nicht gut gelaufen ist oder wie sie denken, dass sie ihr Projekt pivotieren müssen. Ich glaube, das ist der größte Wert: Diese Konferenz drehte sich um echte Sachen, echte Projekte.

(AK): Ich denke, das ist etwas, das – und das sehen wir auch in den Umfragen, die die Teilnehmer ausfüllen – vor allem die No-Bullshit-Regel beachtet wurde. Und die Leute, die sprechen, sind die, die tatsächlich etwas tun und bereit sind, ihre Geschichten zu teilen.

(DJ): Ich wollte nur hinzufügen, dass es keine Reden über Pläne für KI-Programme, über KI-Roadmaps oder anderes Beratungs-BS gab, oder? Es ging ausschließlich um echte Projekte, die wirklich stattgefunden haben, und welche Erkenntnisse die Leute daraus gewonnen haben.

Technologien und Partner

(AK): Auf der Konferenz hatten wir eine ganze Reihe verschiedener Technologien, obwohl wir bereits sehen, dass zum Beispiel im RPA-Bereich einige Anbieter beim Thema KI ein wenig hinterherhinken. Aber wir hatten großes Glück, Unternehmen als Partner und Sponsoren zu haben. Wir hatten UiPath und KYP.ai. Aspire hat uns bei der Konferenz unterstützt und dabei geholfen, die Botschaft zu verbreiten. Und natürlich hatten wir Shock, die jedes Jahr eine großartige Szenografie vorbereiten, inklusive aller technischen Details. Was sie dieses Jahr gemacht haben – die Farben des gesamten Raums mit der Hauptfarbe der Präsentation zu synchronisieren – war, glaube ich, eines dieser kleinen Dinge, die man sonst nirgendwo sieht.

(DJ): Und ich denke, wir müssen auch erwähnen, dass die Konferenz so heiß war, dass wir sogar ein Feuer hatten, oder?

(AK): Oh ja. Wir hatten tatsächlich ein Feuer. Es war nicht absichtlich, aber es ging sehr, sehr schnell, und wir konnten es eindämmen, aber ja, wir hatten das.

Höhepunkte des ersten Tages

(AK): Also, du hast am ersten Tag moderiert und alles unter Kontrolle und im Zeitplan gehalten. Wir haben mit meiner Keynote über die Gaming-Industrie begonnen. Irgendwelche Gedanken dazu?

(DJ): Ja, ich war wirklich überrascht und neugierig zu sehen, was du aus der Gaming-Industrie in den Bereich der KI-Automatisierung übertragen wolltest. Ich bin sicher, dass wir dazu eine Podcast-Folge machen werden. Also hat es wahrscheinlich keinen Sinn, hier tiefer einzutauchen.

Präsentation 1: Agentische Automatisierung (Krzysztof Karaszewski von AgenciAI.biz)

(AK): Danach hatten wir Krzysztof Karaszewski von AgenciAI.biz. Sein Thema war „Die neue Grenze: Was mit agentischer Automatisierung möglich ist“ und wir kennen Krzysztof schon lange. Was hast du davon gehalten?

(DJ): Well it was I would say very different from other presentations which were focused on projects. So Krzysztof was showing what’s currently possible with AI and also how fast the models develop. I have two learnings from his presentation:

  1. Nun, ich würde sagen, es war sehr anders als die anderen Präsentationen, die sich auf Projekte konzentrierten. Krzysztof zeigte, was derzeit mit KI möglich ist und wie schnell sich die Modelle entwickeln. Ich habe zwei Erkenntnisse aus seiner Präsentation gewonnen:
  2. Die zweite Erkenntnis betrifft das Prompting, oder? Wie man die KI richtig fragt, damit sie uns hilft, einer anderen KI die Frage korrekt zu stellen.

(AK): Das ist etwas, worüber viele Leute sehr neugierig waren, denn wenn man das schon macht, weiß man es irgendwie und es erscheint ziemlich offensichtlich. Aber wenn man es vorher noch nicht gemacht hat, ist es ein richtiges Aha-Erlebnis: Man kann ein LLM bitten, einen Prompt für ein anderes LLM zu schreiben – und es macht das wirklich, wirklich gut. Man muss trotzdem wissen, was man damit erreichen möchte.

(DJ): Ich meine, es hängt auch davon ab, was man vom LLM möchte, oder? Wenn man das LLM fragt, welcher der höchste Berg der Welt ist, braucht man wahrscheinlich keine speziellen Prompt-Engineering-Techniken dafür. Aber wenn man möchte, dass das LLM komplexere, echte Aufgaben übernimmt, dann sollte man sich mehr auf die Qualität der Frage konzentrieren. Ich glaube, er nannte es Meta-Prompting.

(AK): Meta-Prompting. Ja, genau. Eine weitere Sache, die mich ziemlich neugierig gemacht hat, waren seine Experimente zur Nutzung von LLMs für die Prozessanalyse. Darüber haben wir im Unternehmen schon viel diskutiert. Es würde uns sehr helfen. Momentan ist es eher ein Treffer- oder Fehlschuss. Manche Dinge funktionieren, andere nicht so gut, wie wir es uns wünschen würden.

(DJ): Definitiv, was ich derzeit sehe, ist, dass unsere Analysten KI sehr aktiv nutzen, um Notizen aus den Meetings zu erstellen, Zusammenfassungen zu schreiben und nächste Schritte festzuhalten. Es hilft also auf jeden Fall. Aber wenn die KI auch die gesamte Prozesskarte nahezu fehlerfrei erstellen könnte oder zumindest 80 % der Arbeit erledigen würde, wäre das perfekt, oder? Ich denke, die Herausforderung ist, dass solche Lösungen gut funktionieren, wenn man einen „Happy Path“ hat. Sobald jedoch viele Ausnahmen auftreten und man zu einem früheren Teil des Prozesses zurückkehrt oder etwas hinzufügt, wird es für die KI viel komplizierter, Schritt zu halten.

(AK): Ja, ich meine, es ist schon für Menschen schwierig, also ist es für KI noch schwieriger. Und die meisten Prozesse, auf die wir stoßen, sind längst nicht mehr einfach oder nur Happy-Path-Prozesse. Außerdem hat Krzysztof viele interessante Beiträge auf LinkedIn. Wir empfehlen jedem, sich anzusehen, was er schreibt. Er versucht immer, die Grenzen dessen, was KI leisten kann, zu verschieben.

(DJ): Es gibt noch etwas, an das ich mich aus Krzysztofs Präsentation erinnere. Er verglich UI-Agenten, oder? Also Agenten, bei denen man anstelle klassischer RPA-Roboter mit Selektoren arbeitet. Man sagt dem Roboter Schritt für Schritt, was er in der Anwendung tun soll. Und jetzt mit LLMs ist das Konzept, dass man das LLM prompten könnte: „Hey, buche mir nächste Woche einen Flug nach Dubai“ oder „Hey, ich will ein neues Skateboard, wähle das beste Skateboard für meine mittleren Fähigkeiten aus und kaufe es für mich“. Es gibt auch Beispiele auf dem Markt, wo LLM zum Beispiel Pizza für einen bestellen kann.
Aber wenn wir über echte Geschäftsprozesse sprechen und man dem LLM sagt: „Hey, ich möchte Andrzej in meiner Firma einstellen, kontaktiere ihn und stell ihn ein“, könnte das LLM Schwierigkeiten haben herauszufinden, was es tatsächlich tun muss, um dich einzustellen. Krzysztof zeigte auch einen Vergleich, wie, glaube ich, Claude und ihr agentisches UI auf verschiedenen Anwendungen operieren. Für mich war besonders interessant, dass das LLM Anwendungen positionsbasiert lernt. Es identifiziert Buttons und weiß dann: Ich muss 200 Pixel nach unten, 100 Pixel nach links und auf einen anderen Button klicken. Aber was, wenn sich die Auflösung ändert? Was, wenn sich die Oberfläche ändert?
Er verglich es auch mit, glaube ich, UiPath UI Vision oder UI Agent oder so etwas, bei dem der Agent immer noch den grundlegenden Prompt erhält, was er tun muss, aber tatsächlich mit Selektoren arbeitet, nicht mit den Button-Positionen. Das ist interessant und, soweit ich mich erinnere, ein deutlich schnellerer Ansatz.

(AK): Ja, aber es wird noch eine sehr, sehr lange Zeit dauern, bis wir Agenten tatsächlich eigenständig in unseren Systemen klicken lassen, oder? Diese Technologie hat noch einen weiten Weg vor sich, und um sicherzugehen: Wenn man zehntausende Fälle bearbeitet, wäre es nicht effizient, den Agenten jedes Mal entscheiden zu lassen. Außerdem wäre es zu diesem Zeitpunkt auch ziemlich riskant.

(DJ): Und ich denke, für kleine Unternehmen oder Privatpersonen, die dieses Risiko eingehen können, wäre das kein Problem, oder? Aber für große Konzerne, bei denen die KI sich an die eigenen Prozesse halten soll, könnte das eine Herausforderung sein. Und dieses Thema tauchte tatsächlich in verschiedenen Vorträgen immer wieder auf: Wie stellen wir sicher, dass KI, und speziell GenAI, keine dummen Dinge macht?

Präsentation 2: E-Mail-Automatisierung mit KI (Kingfisher)

(AK): Danach hatten wir Dariusz Procyk und Miroslaw Rodzen von Kingfisher. Für diejenigen unter euch, die es nicht wissen: Kingfisher betreibt in Polen Castorama-Filialen, im Vereinigten Königreich VNQI. Es ist ein wirklich großes internationales Unternehmen, und so viele Filialen zu haben, ist schon für sich eine Herausforderung. Der Titel ihres Vortrags lautete „Dear Email, we need to talk: E-Mail-Automatisierung mit KI“. Es ist ein Projekt, das wir tatsächlich gemeinsam mit ihnen durchführen, daher haben wir Einblicke, was dort vor sich geht. Sie erhalten etwa 30.000 E-Mails pro Monat in ihre gemeinsamen Finanz-Mailboxen. Und jemand muss diese E-Mails verarbeiten, oder?

(DJ): Und es geht nicht nur um eine Mailbox, oder? Wenn ich mich richtig erinnere, sind es über 40 Mailboxen. Also verschiedene Teams, verschiedene Sprachen. Man kann also nicht einfach ein Formular erstellen und allen sagen: „Oh, jetzt müsst ihr das Formular ausfüllen, und wir bearbeiten es dann als Serviceanfrage“, zum Beispiel.

(AK): Und die Geschichte handelte davon, wie wir gemeinsam ein Framework aufgebaut haben, das auf vielen verschiedenen Komponenten basiert, wobei die KI-Komponente das Communication Mining war. Die Aufgabe des Communication Mining bestand darin, die E-Mails zu nehmen und die Daten zu strukturieren, die für die Roboter nötig sind, um die Prozesse auszuführen. Es gab einige interessante Beispiele, bei denen diese E-Mails sogar für Menschen schwer zu bearbeiten sind. Sie enthalten nicht immer alle notwendigen Informationen, manchmal sind sie sehr merkwürdig formuliert, und manchmal beziehen sie sich auf eine E-Mail in der Mail-Kette, die fünf E-Mails zurückliegt, auf das, was angefragt wird. Ich erinnere mich tatsächlich an zwei Beispiele:

  • Ein Beispiel war eine E-Mail mit dem Inhalt: „Hey, bitte erledige für mich dieselbe Aufgabe wie letzte Woche.“ Und man muss diese Person wirklich kennen und ihre vorherige Anfrage finden, um herauszufinden, was sie wollen.
  • Ein weiteres Beispiel war eine E-Mail mit einem Bild, oder? Jemand hatte einfach ein Foto geschickt, auf dem Informationen über den Stromverbrauch in einem Geschäft zu sehen waren. Nur ein Foto, und das war der gesamte Inhalt der E-Mail. Die Aufgabe bestand darin, im Finanzsystem zu buchen, wie viel Strom in einem bestimmten Monat verbraucht wurde.

(AK): Das sind wirklich gute Beispiele dafür, wie Theorie auf Praxis trifft, und wir sehen, dass diese Technologien große Fortschritte gemacht haben. Communication Mining ist ein großartiges Werkzeug, und wir hatten großen Erfolg damit. Aber bei bestimmten Projekten reicht die Technologie im Moment einfach nicht aus. Die eigentliche Geschichte ist also, dass wir nun untersuchen, wie wir LLMs einsetzen können, um diese E-Mails zu verarbeiten, da die Komplexität der E-Mails das Communication-Mining-Tool nicht mehr bewältigen kann. Aber natürlich bringt der Einsatz von LLMs eigene Herausforderungen mit sich. Man erhält keinen Confidence-Score, der in solchen Prozessen entscheidend ist.

(DJ): Für diejenigen unter euch, die Communication Mining nicht kennen – vielleicht hören einige unserer Zuhörer diesen Begriff zum ersten Mal – das ist ein Ansatz, bei dem man ein Machine-Learning-Modell anhand einer ziemlich großen Menge an E-Mails darin trainiert, was damit zu tun ist. Wie man die E-Mails in verschiedene Kategorien einordnet, wie man unterschiedliche Informationen daraus extrahiert. Und das ist ein völlig anderer Ansatz als bei LLMs, bei denen man einfach den Prompt gibt: „Finde heraus, worum es in dieser E-Mail geht“ – und hofft auf das Beste.

(AK): Ja, wirklich eine interessante Technologie. Ich bin sicher, dass wir dazu eine Episode machen werden. Perfekte Lösungen gibt es im Moment noch nicht, wenn es um die Verarbeitung von E-Mails oder Tickets geht. Wir werden sehen, wohin uns die Technologie führt. Aber ich denke, dieser Vortrag war sehr wertvoll aus der Perspektive dessen, was du vorher erwähnt hast. Es ist großartig, über Dinge zu sprechen, die funktioniert haben, aber vielleicht noch wichtiger, über Dinge zu sprechen, die nicht funktioniert haben, damit andere nicht dieselben Fehler machen müssen wie wir.

Präsentation 3: Analyse digitaler Interaktionen (SPS Ungarn)

(AK): Danach hatten wir Gábor Körmendi von SPS Ungarn. Er sprach über das Thema der Präsentation: „Analyse digitaler Interaktionen: Der Fall SPS Ungarn“. Sie berichteten darüber, wie sie KYP.ai in ihrer Organisation einsetzen, richtig? Dominik, du arbeitest ja ziemlich viel mit KYP.ai.

(DJ): SPS, für diejenigen, die die Organisation nicht kennen: Sie sind ein BPO, also ein Anbieter von ausgelagerten Dienstleistungen. Früher waren es Dienstleistungen der Schweizer Post, früher Teil des XC. Jetzt sind sie eine eigenständige Organisation und haben natürlich viele repetitive Aufgaben. Sie führen Prozesse für viele Kunden durch, hauptsächlich aus Deutschland. Und sie müssen die Zeit erfassen, richtig? Also nehmen wir an, du, Andrzej, verbringst 2 Stunden mit einem bestimmten Prozess für BMW. Dann müssen sie eine Rechnung für deine zwei Stunden Arbeit an dieses Unternehmen schicken. Früher wählten die Mitarbeiter im Grunde manuell aus: „Jetzt arbeite ich für Unternehmen A und mache diesen Prozess, jetzt arbeite ich für Unternehmen B und mache diesen Prozess.“
Mit KYP.ai haben wir herausgefunden, dass die Mitarbeiter etwa 4 % ihrer Zeit nur damit verbringen, auszuwählen, welche Prozesse sie bearbeiten. Das summierte sich auf viele tausend Stunden pro Jahr allein für diese Tätigkeit. Mit KYP.ai konnten sie das reduzieren, weil KYP.ai im Hintergrund arbeitet, selbst herausfindet, was die Mitarbeiter tun, und die Messungen bis auf die Sekunde genau durchführen kann.


(AK): Also spart man nicht nur die Zeit der Mitarbeiter, sondern erhält auch Ergebnisse, die der Wahrheit viel näher kommen als manuelle Messungen.

(DJ): Außerdem hatten sie Informationen über die Aktivitäten ihrer Mitarbeiter. So konnten sie sehen, wie viel ihre Mitarbeiter arbeiten, ob einige unter- oder überlastet sind und wie man die Arbeit innerhalb eines Teams besser ausbalancieren kann. Allerdings war ich ein wenig überrascht, dass sie keine Process-Discovery-Funktionen von KYP.ai nutzen. Also Funktionen, die aufzeigen, was in den Prozessen automatisiert oder verbessert werden kann und aus den Aktivitäten der Mitarbeiter Prozesskarten erstellen. Soweit ich es verstanden habe, ist dies jedoch der nächste Schritt, den sie in ihrer Entwicklung gehen möchten.

(AK): Und etwas, das mich an KYP.ai immer wieder erstaunt, ist, dass als ich das Tool zum ersten Mal gesehen habe – ich komme aus dem Bereich Continuous Improvement – mein erster Gedanke war: „Oh mein Gott, wenn ich Lean-Management-Projekte machen würde, hätte ich so großartige Daten.“ Aber dann stellen wir fest, dass verschiedene Unternehmen es für völlig unterschiedliche Zwecke nutzen – und es macht immer noch Sinn. Am Ende ist es also ein Tool, das von verschiedenen Unternehmen aus völlig unterschiedlichen Gründen implementiert wird.

(DJ): Im Fall von SPS ging es um operative Steuerung. Sie wollten ihre Abläufe besser managen. Aber wir haben auch Unternehmen, die KYP.ai nur nutzen, um Fälle für Automatisierung oder Verbesserung zu identifizieren oder um zu erfahren, welche Arten von Prozessen sie haben.

Präsentation 4: Mit Lean starten und niemals aufhören (Euroclear)

(AK): Der nächste Vortrag kam von Michał Baraniak von Euroclear. Sein Thema war Mit Lean starten… und niemals aufhören. Die Geschichte der kontinuierlichen Transformation der Euroclear Bank . Das war genau mein Ding, oder? Ich komme aus dem Lean Management und habe meine Karriere im Bereich Continuous Improvement gemacht. Tatsächlich war Michał damals Teil meines Teams bei Lufthansa. Euroclear ist eine Bank für Banken. Sie wickeln Transaktionen zwischen Banken ab und erledigen viele wirklich wichtige Aufgaben – im Grunde könnte die Welt stillstehen, wenn bei Euroclear etwas nicht funktioniert, oder? Irgendwelche Gedanken dazu, was sie bei Euroclear machen?

(DJ): Ich meine, es war sehr anders als eine typische Lean-Transformation. Was wir sehr oft sehen, sind Lean-Transformation-Blackbelts, die in ein Unternehmen kommen, Kaizen einführen – also kleine Verbesserungen, die jeder einreichen kann – eventuell Boards für die Teams oder Stand-up-Meetings implementieren. Ich würde sagen, eher grundlegende Dinge, die die Basis der Lean-Kultur schaffen. Euroclear ist da ganz anders, weil sie das schon viele Jahre gemacht haben und festgestellt haben, dass sie sich auf Teamebene nicht wirklich konzentrieren können, wenn sie eine Lean-Transformation durchführen.
Also begannen sie, End-to-End-Projekte zu machen, bei denen sie analysierten, was verschiedene Teams tun, aber innerhalb eines End-to-End-Prozesses. Für mich war es sehr überraschend, das Beispiel zu sehen, das Michał zeigte: Sie hatten einen Prozess mit, ich glaube, 95 Schritten oder so. Außerdem waren mehrere Teams beteiligt, und die Teams verschoben die Aufgaben während des Prozesses etwa 50 Mal untereinander.
Als sie das analysierten, die Ergebnisse den Teams zeigten und versuchten, den Prozess neu zu gestalten, reduzierten sie die Anzahl der Schritte auf 40. Die Stellen, an denen Aufgaben zwischen Teams verschoben wurden, waren nur noch etwa 15. Sie haben den Prozess also erheblich vereinfacht. Außerdem haben sie die Durchlaufzeit mehrfach reduziert – von mehreren Tagen auf einen Tag, glaube ich. Und wenn man an Automatisierung denkt: Hätte jetzt ein RPA- oder sogar AI-Team diese erste Version des Prozesses genommen und gefragt, wie wir ihn mit LLMs oder KI automatisieren könnten, hätten sie vielleicht ein paar schnelle Verbesserungen erzielen können, aber tatsächlich wäre das eine enorme Zeitverschwendung gewesen.

(AK): Das stimmt, und das ist etwas wie der heilige Gral des Continuous Improvement: End-to-End-Prozesse zu verbessern. Jeder spricht darüber und jeder möchte es tun, aber nur sehr wenige Unternehmen setzen es tatsächlich um. Und hier machen sie es – aber, wie du gesagt hast, es ist eine logische Abfolge von Schritten. Sie haben mit den Grundlagen begonnen: Dashboards, Meetings – all diese Dinge haben sie gemacht. Aber dann haben sie nicht aufgehört. Sie gingen zu immer komplexeren Aufgaben über. Und es funktioniert wirklich. Es ist jahrelange Arbeit. Und was wirklich wichtig ist: Man darf nicht aufhören. Man kann den Kurs nicht nach ein paar Jahren ändern, denn genau das passiert oft: Ein neuer Geschäftsführer kommt, setzt ein Continuous-Improvement-Programm auf, führt es drei oder vier Jahre lang durch – tolle Ergebnisse – und dann wechselt der Geschäftsführer. Ein neuer kommt und sagt: „Nein, nein, nein, wir machen jetzt etwas anderes.“

(DJ): Das stimmt. Eine weitere Sache, die ich für ziemlich besonders halte, ist, dass sie den Kunden an erste Stelle setzen. Die gesamte Transformation war kundenorientiert, und sie haben tatsächlich Kunden eingeladen, an diesen Projekten teilzunehmen, ihnen Feedback zu geben und der sogenannten „Voice of the Customer“ zuzuhören.

(AK): Das ist absolut zutreffend. Jeder sagt, er tut es. Jeder weiß, dass es getan werden sollte, aber fast niemand setzt es wirklich um.

Präsentation 5: RABuy-Automatisierungsinitiative (Rockwell Automation)

(AK): Der nächste Vortrag kam von Sawa Konfisz und Jakub Markowski von Rockwell Automation. Rockwell Automation ist, wie der Name schon sagt, ein Unternehmen, das Automatisierungen durchführt. Aber sie machen die Art von Automatisierungen, an die jeder denkt, wenn man von Robotern spricht – also tatsächliche physische Industrieautomation. Der Titel ihres Vortrags lautete „RABuy: Automatisierungsinitiative zur Entfernung von SAP aus dem Einkaufsworkflow“. Mir gefällt die Idee wirklich gut, weil sie etwas bedacht haben, woran ich selbst wahrscheinlich nicht gedacht hätte. Grundsätzlich, wenn sie Bestellanforderungen in ihr System eingeben müssen – und sie kaufen viel ein – nehmen sie das Angebot, das sie vom Lieferanten erhalten haben, laden es in ein System hoch, und die KI liest das Angebot und wandelt es in eine Bestellung um. Sobald man es gesehen hat, ist es die logischste Vorgehensweise. Es wirkt offensichtlich.

(DJ): Und wenn man darüber nachdenkt, klingt das nicht spektakulär. Aber als sie über Zahlen sprachen, habe ich tatsächlich mein Handy genommen, den Taschenrechner geöffnet und schnell ausgerechnet, dass sie die Produktivität für das gesamte Unternehmen um etwa 50 FTE gesteigert haben, wenn ich mich richtig erinnere. Ich bin mir nicht sicher, ob sie das in die Gewinn- und Verlustrechnung übertragen konnten, aber selbst wenn man nur Einsparungen in Höhe von 50 FTE über die gesamte Organisation von mehreren tausend Mitarbeitern hat, bedeutet das, dass die Mitarbeitenden sich auf wichtigere Aufgaben konzentrieren können, anstatt Bestellungen ins System einzutragen.

(AK): Das ist nichts, was die Leute gerne tun. Manuelle Dateneingabe gehört nicht zu den Lieblingsaufgaben der Menschen. Und sie haben dieses praktische Tool mit einer leicht zu bedienenden Oberfläche entwickelt, das die Arbeit für einen erledigt. Aber natürlich, mit dem Wissen, dass LLMs immer noch Halluzinationen haben und Fehler machen, besteht der letzte Schritt im Wesentlichen darin, dass ein Mensch überprüft, was die KI aus dem Angebot verstanden hat, bei Bedarf Änderungen vornimmt und es dann einfach erstellen lässt.

(DJ): Es gibt auch eine andere Perspektive darauf: Sie haben tatsächlich Low-Code-Anwendungsentwicklung genutzt. Sie haben ihre eigene Low-Code-Anwendung erstellt, die viel besser aussah als ihr altes SAP-Altssystem. Außerdem konnten sie auf SAP-Lizenzen verzichten, was vielleicht keine gute Nachricht für SAP ist, aber für Rockwell bedeutete das auf jeden Fall Einsparungen.

Tiefergehende Einblicke am zweiten Tag

(AK): Damit war Tag eins abgeschlossen. Auf die Details der Afterparty wollen wir nicht eingehen – sie war phänomenal. Am zweiten Tag – denn am ersten Tag dauern die Vorträge 30 Minuten, es gibt ein bisschen Zeit für Fragen, aber der Fokus liegt eher darauf, Ideen zu vermitteln, die Leute zu inspirieren und Use Cases zu zeigen – nutzen wir für Deep Dives. Wir haben weniger Vorträge, aber diese dauern jeweils eine Stunde, und wir gehen mehr ins Detail über die Implementierung und oft auch über technische Details. Dagmara Sysula, unsere Delivery Managerin, moderierte diesen Teil.

Präsentation 1: P2P-Service-Desk-KI-Agent (McCormick)

(AK): Der erste Vortrag am zweiten Tag kam von Radoslaw Ociepa von McCormick. Er sprach über den P2P-Service-Desk-KI-Agenten. Das ist etwas, das uns besonders am Herzen liegt, weil wir in den letzten Monaten auch daran gearbeitet haben. Wie hast du den Vortrag gefunden?

(DJ): Ich denke, dass diese Service-Desk-Agenten – egal, ob wir über Finanzen, HR, Einkauf oder IT-Helpdesk sprechen – der Bereich ist, in dem tatsächlich eine große Zahl an Automatisierungen mit KI stattfinden wird. Das ist auch meine Vermutung, wenn wir zum Beispiel über die Entlassungen bei Salesforce sprechen. Sie haben angekündigt, dass von 9.000 Mitarbeitern im Customer Operations-Bereich die Zahl um 4.000 reduziert wird. Und meine Vermutung ist, dass es sich dabei hauptsächlich um Level-1-Service-Desk-Agenten handelt.

(AK): Und ich denke, wenn wir von diesen massiven Entlassungen hören, die die Unternehmen durchführen, sind die meisten davon meiner Meinung nach Bullshit aus der Perspektive, dass sie sagen, es liege an KI – die KI-Adoption ist nicht so hoch. Es ist nur ein Vorwand, etwas zu tun, das man ohnehin getan hätte. Aber in dem Beispiel, das du ansprichst, könnte es tatsächlich passen. GenAI ist in diesen Prozessen wirklich, wirklich effektiv – Level-1-Service-Desk absolut. Ein Lernpunkt für dich: Wenn du nach einem guten Bereich suchst, um mit KI zu starten, könnte Service-Desk-Arbeit ein guter Einstieg sein. Sie haben es mit UiPath-Agenten umgesetzt, was ziemlich neu ist – ich meine, nur ein paar Monate alt, was den allgemeinen Zugang betrifft. Aber sie zeigten, dass sie dank dieser Technologie Dinge implementieren können, und das ziemlich schnell. Denn wenn sie es von Grund auf neu bauen müssten, würde es enormen Aufwand erfordern und viel Können, das möglicherweise in der Organisation nicht vorhanden ist, oder sie müssten wahrscheinlich einige Machine-Learning-DevOps-Ingenieure und ähnliche Fachkräfte hinzuziehen.

(DJ): Das ermöglicht ihnen, da sie bereits die UiPath-Plattform nutzen und Roboter im Einsatz haben, die Implementierung wesentlich einfacher zu gestalten. Ich freue mich wirklich darauf. Sie haben gesagt, dass sie mit dem P2P-Service-Desk begonnen haben, weil man dort viele wiederkehrende Fragen erhält, wie zum Beispiel: „Hey, wie ist der Status meiner Rechnung?“

(AK): Und es macht Sinn, dort zu beginnen, aber sie haben bereits Pläne, dieselbe Technologie auch bei anderen Service-Desks einzusetzen. Dank der einstündigen Sitzung konnten wir ziemlich tief eintauchen und genau sehen, wie sie die Agenten aufgebaut haben.

(DJ): Ich denke, das war ein ziemlich übliches Setup. Sie hatten, glaube ich, drei oder vier Anwendungen, in denen Informationen überprüft werden mussten – SAP, Ariba und noch zwei weitere. Je nach Use Case musste man eine davon nutzen. Es war also nicht so, dass der Agent nur innerhalb einer Anwendung arbeitet, sondern man musste wirklich orchestrieren, was die Agenten tun. Außerdem haben die Agenten nicht die gesamte Arbeit übernommen. Es gab auch Integrationen, es gab RPA-Roboter – also klassische Dinge. Die Agenten wurden verwendet, um zu verstehen, worum es bei der Frage geht. Aber sobald das klar ist, braucht man den Agenten nicht mehr für die Ausführung; dafür kann man eine klassische Automatisierung einsetzen.

(AK): Absolut. Und ich denke, sie haben einen weiteren Agenten verwendet, um aus den Daten, die der Roboter dem Agenten liefert, eine passende Antwort zu formulieren. Aber es macht Sinn und zeigt deutlich, dass man KI nicht für alles einsetzen möchte. Es gibt Bereiche, in denen KI sinnvoll ist, und andere, in denen andere Technologien besser geeignet sind. Weißt du, was mich in dieser Präsentation überrascht hat?

(DJ): Sie erwähnten, dass kein Mensch in den Prozess eingebunden ist. Und ihr Business Director hat sie gebeten, die versendeten E-Mails nicht zu überprüfen. Für mich war das wirklich überraschend, dass sie das tatsächlich so umgesetzt haben. Normalerweise empfehlen wir, dass es eine Art finale Überprüfung durch einen Menschen gibt oder zumindest eine frühe Überprüfung, um sicherzustellen, dass der Agent in die richtige Richtung arbeitet.

(AK): Und die Leute haben danach gefragt, und es wurde diskutiert. Grundsätzlich sind die Prozesse, die derzeit vom Agenten ausgeführt werden, sehr risikoarm. Ich stimme zu, dass ich wahrscheinlich zumindest in den ersten Wochen empfehlen würde, einen Menschen in den Prozess einzubinden. Aber wir mögen mutige Menschen, die mutige Dinge tun.

Präsentation 2: UiPath Akt Zwei: Agentische Automatisierung (UiPath)

(AK): Danach hatten wir Piotr Zajac von UiPath. UiPath Akt 2: Agentische Automatisierung. Das waren viele Informationen.

(DJ): Das war, glaube ich, die am dichtesten gepackte Präsentation. Piotr spricht sehr schnell und zeigte sehr zügig, wie UiPath ihre Organisation und Produkte von traditionellem RPA zu AI-First-Automatisierung transformiert. Ich denke, das war vor allem für UiPath-Kunden interessant, vielleicht weniger für Nutzer von Blue Prism oder Automation Anywhere. Aber wenn wir andere Anbieter zur Konferenz eingeladen hätten, um über ihre KI-Fähigkeiten zu sprechen, wären wir uns nicht sicher, ob sie wirklich eine stimmige Geschichte hätten. Die Antwort könnte sein: „Welche KI-Fähigkeiten?“

(AK): UiPath arbeitet stark am KI-Bereich ihres Geschäfts, so stark, dass sie es als Akt Zwei sehen – als eine Transformation ihrer Plattform zu etwas völlig anderem. Das bedeutet nicht, dass sie aufhören, Roboter und Ähnliches bereitzustellen, denn das hat weiterhin seinen Platz in der gesamten Landschaft. Aber sie sagen zu Recht, dass das nicht mehr ausreicht, und all diese KI-Fähigkeiten müssen vorhanden sein, weil genau das die Kunden erwarten.

(DJ): Und um es kurz zu machen: Ich habe das Gefühl, dass UiPath versucht, KI in jede Art von Produkt einzubauen. Sie integrieren sie in Roboter, zum Beispiel Self-Healing-Selektoren, in Testautomatisierung wie KI-Anwendungsfälle für Tests, in Process Mining, also im Grunde Dokumentenextraktion. Kurz gesagt, überall dort, wo man sich vorstellen könnte, dass KI eingesetzt werden könnte. Aber sie haben bereits das gesamte Framework – sie bauen es also nicht von Grund auf neu auf.

(AK): Und es ist auch wichtig, dass diese KI-Funktionen gewissermaßen optional sind. Wenn man die Idee der Self-Healing-Selektoren nicht mag – wozu ich persönlich einige Zweifel habe, und ich bin sicher, dass meine Entwickler auch welche haben – dann nutzt man sie einfach nicht. Aber man hat die Möglichkeit, sie zu verwenden, wenn es passt und sinnvoll ist.

Präsentation 3: KYP.ai und die unerwarteten Erkenntnisse (Office Samurai)

(AK): Danach hatten wir Zuzanna Pamula und Michał Kozubski, beide von Office Samurai, die über KYP.ai und die unerwarteten Erkenntnisse sprachen. Das war etwas, auf das ich mich wirklich gefreut habe, obwohl ich täglich mit ihnen arbeite, da sie versucht haben, so viele überraschende Dinge wie möglich zusammenzutragen, die sie oder unsere Kunden während der Projekte mit KYP.ai entdeckt haben. Wie wir zuvor besprochen haben, kann KYP.ai für viele verschiedene Dinge eingesetzt werden.

(DJ): Aber für mich war die wichtigste Erkenntnis daraus, dass wir vielleicht darüber nachdenken sollten, mehr benutzerdefinierte Dashboards in KYP.ai zu erstellen, mit denen man herausfinden kann, wie viel ein Meeting in der eigenen Organisation kostet. Es gab auch wirklich schöne Beispiele, bei denen die Arbeit eines Managers analysiert wurde. Man weiß ja, Manager nutzen heutzutage typischerweise Outlook, vielleicht Teams, vielleicht ein bisschen Excel. Anstatt selbst zu arbeiten, verbringen sie die meiste Zeit in Meetings und im Gespräch mit Menschen – manchmal gerechtfertigt, manchmal könnte es wahrscheinlich reduziert werden. Aber man weiß nicht wirklich, in welchem Umfang das geschieht. Mit KYP.ai kann man tatsächlich berechnen, wie viel die täglichen Meetings kosten.

(AK): Und das ist etwas, das für Manager den Großteil ihrer Arbeit ausmacht. Aber selbst operative Mitarbeiter verbringen viel Zeit in Meetings. Ein gewisses Maß an Meetings ist notwendig, damit die Dinge funktionieren, aber in vielen Organisationen gibt es zu viele Meetings, die den Mitarbeitern nur im Weg stehen, ihre eigentliche Arbeit zu erledigen.

(DJ): Wenn ich darüber nachdenke, habe ich in keiner Organisation je gehört, dass wir zu wenige Meetings haben. Normalerweise höre ich: Wir haben genug – das wäre die perfekte Situation – oder wir haben zu viele, was in etwa 80 % der Fälle zutrifft.

(AK): Ich versuche, Zuzanna oder Michał davon zu überzeugen, tatsächlich eine Solo-Podcast-Folge darüber zu machen. Also bleibt dran – wir kommen mit weiteren Beispielen zurück.

Präsentation 4: KI-Automatisierungs-Playbook (Dominik Jaskulski)

(AK): Und dann das Sahnehäubchen: Dominik Jaskulski mit dem Vortrag „KI-Automatisierungs-Playbook“. Für mich war das etwas, bei dem ich während des gesamten Vortrags dachte: Wir hätten so etwas früher erstellen sollen. Er hat Gedanken, Frameworks und Ideen zusammengetragen, wie KI in Organisationen eingeführt werden sollte.

(DJ): Ehrlich gesagt habe ich diese Präsentation eher zufällig erstellt, weil ich ursprünglich einen Vortrag über KI-Anwendungsfälle geplant hatte – also darüber, wo man nach Use Cases suchen sollte, welche sinnvoll sind und welche nicht, um den Leuten am Ende der Konferenz konkrete Ideen mitzugeben, wo sie anfangen können.
Als ich jedoch alle Folien zusammenstellte, merkte ich, dass etwas in der Story fehlte. So kam ich auf die Idee, dass man im Grunde genommen einige Hauptphasen hat, wie man KI richtig in einer Organisation implementiert. Das wurde auch auf Basis von Feedback und Lessons Learned aus zwei Reports erstellt: einem von McKinsey und einem vom MIT. Beide Reports sprachen über eine Art Lücke, bei der viele Organisationen horizontale Implementierungen durchführen. Mit „horizontal“ meinen sie zum Beispiel, dass alle Mitarbeiter Zugang zu ChatGPT oder Microsoft Copilot erhalten – einige nutzen es, andere nicht. Es ist schwer, daraus Vorteile messbar zu machen. KYP.ai kann helfen, die Vorteile in solchen Szenarien zu messen, aber es bleibt schwierig, diese in die Gewinn- und Verlustrechnung zu übersetzen. McKinsey fand heraus, dass nur 1 % der Organisationen ihre KI-Strategie als umfassend ansehen.
Zusätzlich zu diesen horizontalen Projekten gibt es vertikale Projekte, wie etwa den P2P-Service-Desk-Agenten von McCormick oder Rockwell Automation. Hierbei handelt es sich um Projekte in einem bestimmten Bereich mit End-to-End-Prozess, die ein konkretes Problem der Organisation lösen. Tatsächlich gelingt nur etwa 5 % dieser Projekte; viele bleiben in der POC- oder Pilotphase stecken. Die Schlussfolgerung: Nur diese Art von Projekten liefert echte Vorteile, die sich auf P&L übertragen lassen.
Es ist jedoch nicht einfach, mit diesen Projekten zu starten. Meine Empfehlung war daher, KI phasenweise einzuführen: Zuerst horizontal mit Chatbots oder Copilots, dann vielleicht KI-Assistenten – also KI, die an euer Wissen und eure Datenbanken angeschlossen ist, Fragen beantworten kann und Informationen zusammenfasst. Die nächste Stufe wären einfache KI-Agenten – Agenten, die etwas für euch erledigen, aber innerhalb eines einzelnen Systems. Die Fälle von McCormick und Rockwell sind gute Beispiele für solche Einzelagenten: Der Agent hat nur eine Aufgabe, und man muss kein komplexes, agentisches System synchronisieren.
Und das ist die letzte Stufe: Hier müsst ihr die Agenten orchestrieren; manchmal orchestriert ein Agent andere Agenten. Bevor man dieses Level erreicht, sollte man meiner Meinung nach Hausaufgaben machen und grundlegende Dinge implementiert haben.

(AK): Diese letzte Stufe erreichen nur sehr wenige Unternehmen, und es ist klar, dass niemand sie im großen Maßstab umsetzt. Es stimmt: Was auch immer man tut, wenn man es verantwortungsvoll und nicht nur in PowerPoint tun möchte, muss man vorher bestimmte Schritte unternehmen. Und dieser MIT-Report ist brutal. Ich habe ihn gelesen und hatte das Gefühl: Nur 5 % dieser Projekte schaffen es tatsächlich und bringen Vorteile. Ich hätte gedacht, dass es mehr als 5 % sind. Die Tatsache, dass 40 % der Organisationen Copilots oder KI-Chatbots für ihre Mitarbeiter eingeführt haben – und in 90 % der Unternehmen die Mitarbeiter sie bereits nutzen – bedeutet, dass eure Daten ohne Zustimmung und ohne Aufsicht in die Cloud eines Dritten gesendet werden. Ich halte das für eine großartige Erkenntnis, denn wenn man in der IT-Sicherheit tätig ist, muss man erkennen: Wenn man keinen sicheren Weg bietet, wie Mitarbeiter KI nutzen können, werden sie sie einfach unsicher verwenden – und man wird sie nicht daran hindern können.

(DJ): Und noch etwas: Schulungen. Wir haben gesehen, dass viele Organisationen zum Beispiel generische Trainings einkaufen oder ihre Mitarbeiter einfach YouTube-Videos ansehen lassen oder eine Schulung darüber machen, was ein LLM ist – aber sie können das nicht wirklich auf ihre Arbeit übertragen. Ich zeigte ein Beispiel von einem Unternehmen, das ich nicht nennen kann, wo das Team sehr komplexe, transaktionale SQL-Abfragen mit tausenden Zeilen analysierte. Ich habe diese gesamten Abfragen in, ich glaube, Copilot eingefügt, einfach einen simplen Prompt erstellt, und innerhalb von sieben Minuten hatten sie ein Ergebnis, wofür vorher ein Team von drei Personen den ganzen Tag gebraucht hätte. Laut der MIT-Studie hat man, wenn man KI im eigenen Unternehmen alleine implementiert, nur 50 % der Erfolgschancen im Vergleich zur Implementierung mit einem externen, erfahrenen Partner.

(AK): Deinen Vortrag werde ich dich auch noch verfolgen, um ihn in eine Podcast-Episode zu verwandeln. Zusammengefasst: Diese zwei Tage waren für uns auf jeden Fall anstrengend, aber es war unglaublich bereichernd, all die Geschichten der Unternehmen zu hören und all die Menschen zu treffen, die sich für diese Themen interessieren.

(DJ): Und weißt du, tatsächlich fühle ich mich sehr inspiriert und voller Energie. Und das ist normalerweise der Hauptgrund, warum ich an Konferenzen teilnehme, oder? Einerseits, um etwas Neues zu lernen. Aber dieser inspirierende Teil, dieses aufregende Gefühl: „Hey, wir haben eigentlich dasselbe Problem, und sie haben uns schon gezeigt, wie man es löst. Also lasst es uns auch in unserem Unternehmen umsetzen.“

Schlussfolgerung

(AK): Und damit ist unser Samurai and Friends-Debrief abgeschlossen. Die Bühne ist leer, die Banner abgebaut, und die letzten Gratis-Kekse wurden erbittert erkämpft und verzehrt. Dōmo arigatō, dass ihr bei unserem Victory Lab eingeschaltet habt. Ein riesiges, herzliches Dankeschön geht an die wahren Helden der Veranstaltung – die Speaker und die Unternehmen, die ihre Geschichten geteilt haben. Diese Episode und die Konferenz selbst wären ohne unsere Produzentin Anna Cubal, die Master-Strategin hinter den Kulissen, nicht möglich gewesen. Wir nehmen im legendären Wodzu Beats Studio auf, wo wir bereits Ideen für die nächste Veranstaltung auf Whiteboards skizzieren. Wenn euch dieses Recap Lust auf die nächste Runde gemacht hat, folgt uns auf Social Media für Ankündigungen. Bis zum nächsten Mal – haltet eure Prozesse automatisiert und eure Konferenzen bullshit-frei. Mata ne.

Erleben Sie Automation in Aktion

Melden Sie sich für unseren regelmäßigen Newsletter an, um die neuesten Updates von der RPA-, KI- und Prozessverbesserungsfront zu erhalten. Erhalten Sie Tipps zur Automatisierung, lernen Sie aus Fallstudien und holen Sie sich Ideen für Ihr nächstes tolles Projekt.

Das Abenteuer der Automatisierung geht weiter...

Automatisierung ist keine einmalige Sache – sie ist ein fortlaufender Prozess. Genau wie gute Geschichten entwickeln sie sich mit jeder neuen Herausforderung und Verbesserung weiter. Lesen Sie weitere Artikel, um zu erfahren, wie andere die Grenzen der Technik immer weiter verschieben und Automatisierung zu einer Denkweise machen, die keine schnelle Lösung darstellt.

Lassen Sie sich bei Ihrem nächsten Projekt nicht von Fragen aufhalten

Stellen Sie eine Frage oder sagen Sie einfach „Hallo“ – wir melden uns innerhalb eines Tages bei Ihnen. Das geht schnell, ist kostenlos und könnte Ihnen eine Menge Ärger ersparen. In einem kurzen Telefonat (online/telefonisch) besprechen wir, wie wir Ihnen bei der Lösung Ihrer Probleme helfen können. Wir werden Sie nach bestem Wissen und Gewissen beraten, auch wenn das bedeutet, dass wir Ihnen unsere Dienste nicht anbieten können.