Die Idee entstand auf einer Konferenz: Während ein Sprecher über Automatisierungen sprach, die in einem Monat entwickelt wurden, witzelten die Führungskräfte von InPost und Office Samurai, sie könnten es in einer Woche schaffen. „Warum nicht in 24 Stunden?“ – meinte jemand. Monatelang blieb es ein Insider-Witz, bis beide Unternehmen beschlossen, ihn Wirklichkeit werden zu lassen und sich für ein mutiges 24-Stunden-Automatisierungsexperiment zusammenschlossen.
Ergebnisse? Lesen Sie weiter.
Die Herausforderung
Die erste Regel des SpeedRun lautete: Der zu automatisierende Prozess musste real sein. Eine künstliche Herausforderung aufzustellen, hätte sich wie Schummeln angefühlt – Automatisierung ist nur dann von Bedeutung, wenn sie tatsächliche Unternehmensbedürfnisse erfüllt. Business-Analysten erstellten „Must-have“- und „Nice-to-have“-Testfälle, um die Erfolgskriterien messbar zu machen.
Der ausgewählte Prozess war keine Routineaufgabe – er bestand darin, Daten aus gescannten Dokumenten zu lesen und zu extrahieren. Das bedeutete, unstrukturierte Eingaben zu verarbeiten, gelegentlich sogar Handschrift, und Szenarien zu bewältigen, in denen Genauigkeit nicht verhandelbar war.
Was als scherzhafte Bemerkung auf einer Konferenz begann, wurde schnell zu einem ernsthaften Projekt. Je tiefer wir in die Planung einstiegen, desto deutlicher wurde uns, wie komplex der gewählte Prozess war – und die Vorstellung, innerhalb von 24 Stunden eine vollständige Automatisierung zu liefern, begann undenkbar zu erscheinen.
Zurückzugehen war jedoch keine Option. Beide Unternehmen stellten ihre besten Fachleute zusammen und stürzten sich in die Vorbereitungen. Zwei Business-Analysten erhielten die Möglichkeit, den Prozess im Vorfeld zu prüfen, um die Machbarkeit des Projekts einzuschätzen, gaben jedoch vor dem Event keine Informationen an das SpeedRun-Team weiter. Wie in einem Standardprojekt – die Erstanalyse ist der Moment, in dem die Spezialisten den Prozess zum ersten Mal sehen.
Drei Entwickler von InPost, drei Entwickler von Office Samurai und zwei Fachexperten (SMEs) von InPost betraten die SpeedRun-Arena, ohne vorher zu wissen, was sie automatisieren würden. Erst als die 24-Stunden-Uhr zu ticken begann, offenbarte sich der volle Umfang der Herausforderung.
Auf die Plätze, fertig, los!
Der Timer startete um 14 Uhr – und es ging los. Das Team verbrachte die ersten zwei Stunden damit, die SMEs zu befragen und den Prozess sorgfältig zu analysieren. Ein großes Whiteboard an der Wand wurde zur Leinwand für Lösungsdesigns und wichtige Notizen. Die Energie und Entschlossenheit waren groß, doch die ersten Hürden tauchten auf – etwa die Entdeckung, dass eine der relevanten E-Mail-Adressen kein gemeinsames Postfach, sondern eine Gruppe war, was eine erhebliche technische Herausforderung darstellte. Der Umfang der Aufgabe begann überwältigend zu wirken.
Die Analyse zog sich in die Länge und zehrte erheblich am kostbaren Zeitbudget. An diesem Punkt durften die Business-Analysten (BAs) eingreifen, einige Hinweise geben und überwachen, ob der Hauptprozessfluss nicht durch weniger wichtige Details aus der Bahn geriet. Die Räder griffen wieder. Das Team erkannte, dass sich der End-to-End-Prozess in zwei Hauptteile gliedern ließ, und teilte ihn daher in zwei selbstorganisierte Squads auf, in denen jede Person eine spezifische Rolle übernahm.
Jedes Squad bestimmte eine Person für die Dokumentation (hauptsächlich zur Erstellung einer Prozesslandkarte), eine weitere für die Programmierung eines Dispatcher-Roboters (zuständig für die Vorbereitung einer Aufgabenwarteschlange) und eine dritte für die Entwicklung eines Performer-Roboters (der den eigentlichen Prozess in Systemen und Anwendungen ausführt). Zusätzlich konzentrierte sich ein Squad-Mitglied auf den Aufbau der wesentlichen KI-Komponenten – das „Gehirn“ der gesamten Lösung: UiPath Document Understanding™ zum Auslesen gescannter Dokumente und generative KI (OpenAI’s ChatGPT) zur semantischen Umwandlung der benötigten Werte.
Insgesamt musste das Team fünf Roboter entwickeln, die jeweils so konzipiert waren, dass sie sowohl eigenständig als auch gemeinsam reale Testfälle ausführen konnten.
Marathon der Mitte
Als die Nacht hereinbrach, brachte die Programmierphase ein Gefühl von Stabilität. Mit klaren individuellen Zielen und reibungsloser Zusammenarbeit innerhalb der Squads fand das Team seinen Rhythmus. Jedes Squad bestand aus drei Personen und wurde somit ganz natürlich zu einem „Trio“. Beide Trios saßen in kurzer Entfernung voneinander – nah genug für sofortige Zusammenarbeit, aber weit genug entfernt, um die Konzentration zu wahren.
Wenn ich das wichtigste Highlight der Veranstaltung benennen müsste, dann wäre es dies: reibungslose Zusammenarbeit.
Stellen Sie sich ein Projekt vor, in dem jedes Hindernis, jede Frage oder Entscheidung sofort von Angesicht zu Angesicht gelöst wird. Kein Warten auf Antworten, keine Ablenkungen – nur volle Konzentration, bei der jeder den Auftrag, den Prozess und die Technologie versteht. Auch wenn dies außergewöhnliche Umstände waren, war es die effizienteste Projektdurchführung, die ich je erlebt habe.
Aber natürlich traten unterwegs auch einige Probleme auf.
Die Komplexität des Prozesses wurde stark unterschätzt. Was während der Vorabanalyse beherrschbar schien, erwies sich als von Ausnahmen und Feinheiten durchzogen. Der Ehrgeiz des Teams, jeden Fall korrekt abzudecken, musste gebremst werden. Da die Zeit davonlief, mussten sie sich darauf konzentrieren, sicherzustellen, dass der Hauptprozessfluss von Anfang bis Ende funktionierte.
Und dann war da noch die Müdigkeit. Es lag nicht an den Rahmenbedingungen – die Einrichtung bot alles: köstliches Catering, Ruheräume mit Schlafmatten, so viel Kaffee, wie man trinken konnte, und medizinische Unterstützung für Notfälle (zum Glück ungenutzt) – es ist einfach unnatürlich, so lange wach zu bleiben. Die größte Krise traf gegen 3 Uhr morgens. Die Entwicklung stieß auf einen schwierigen Punkt und das Team zerstreute sich – einige suchten nach einem kurzen Nickerchen, andere hielten durch.
Die Nacht ist am dunkelsten kurz vor der Morgendämmerung.
Phönix aus der Asche
Der Wendepunkt kam mit der aufgehenden Sonne, gegen fünf Uhr morgens. Es mag allzu poetisch klingen – nennen Sie es, wie Sie wollen – aber es fühlte sich wirklich so an, als hätte das Team nach einer langen, meeresgleichen Stille seinen zweiten Atem gefunden.
Zu diesem Zeitpunkt waren die ersten Versionen der Roboter bereits funktionsfähig genug, um mit Unit-Tests zu beginnen. Entwurfsfassungen der Dokumentation lagen vor, und die Squads intensivierten ihre Zusammenarbeit erneut, um die einzelnen Komponenten langsam zu einer kohärenten Lösung zu integrieren. Trotz begrenzter Trainingsbeispiele extrahierte das Document-Understanding-Modell erfolgreich Daten – und das Morgenlicht schien wirklich einen Unterschied zu machen. Die Suche nach realen Testfällen begann. Ich wünschte, wir hätten dabei Pyjamas und Hasen-Hausschuhe getragen, um die Stimmung perfekt zu treffen.
Abgesehen von der Geschichte dürfen wir die Komplexität des Problems und der Lösung nicht vergessen.
Der erste Hauptteil musste mit E-Mails und gescannten Dokumenten umgehen. Text war handhabbar, doch bei Scans musste UiPath Document Understanding die Hauptarbeit leisten. Die extrahierten Werte konnten nicht unverarbeitet genutzt werden, daher kam ChatGPT ins Spiel, um unscharfe Logik für Details wie Adressen oder Daten zu übernehmen – nicht gerade einfach angesichts der Komplexität der polnischen Deklination.
Der zweite Teil war noch kniffliger. Die Daten aus der ersten Phase mussten auf das Eintreffen von Folgedokumenten mit zusätzlichen Eingaben warten. Scans wurden (wie Sie sich denken können) an Document Understanding übergeben, Threads mussten zugeordnet, Elemente aktualisiert werden – und erst dann führte der finale Performer-Bot die erforderlichen Aktionen aus.
Dies wäre selbst mit mehreren Wochen zur Umsetzung ein herausforderndes Projekt gewesen. Aber niemand gab auf. Das Team hielt bis zur allerletzten Minute durch – entschlossen, Ergebnisse zu liefern. Hier ein Bild als Beweis – das alles begann am Freitag um 14 Uhr.
Die Zeit ist um!
Der Countdown blieb stehen. Wir hatten zehn Minuten Verschnaufpause, bevor wir uns in einem Konferenzraum zu Testrunden und einer abschließenden Zusammenfassung trafen. Trotz Erschöpfung wirkten alle wirklich glücklich und erstaunlich gelassen in Bezug auf das Ergebnis. Am Ende ging es nicht nur um die Resultate – am wichtigsten war das gemeinsame Erleben dieser einzigartigen Erfahrung. Aber um es auf den Punkt zu bringen…
Es hat funktioniert.
Zehn echte, nicht fingierte Test-E-Mails durchliefen den gesamten Ablauf und lieferten das erwartete Ergebnis, das in einer SharePoint-Tabelle protokolliert wurde. Angesichts der bekannten Schwachstellen an bestimmten Stellen waren wir angenehm überrascht, dass die Fälle völlig fehlerfrei liefen. Das Komitee, bestehend aus Vertretern von InPost, Office Samurai und UiPath, erklärte das Projekt für erfolgreich – und es fühlte sich ehrlich gesagt wie ein greifbares Resultat an, nicht wie ein leerer Slogan.
Um die Süße etwas auszugleichen: Es wurden nur die „Must-do“-Funktionalitäten entwickelt, und der Code erforderte nach dem Event noch einige Optimierungen. So wurden beispielsweise die Bot-Paare „Dispatcher“ und „Performer“ zu einzelnen Einheiten zusammengeführt. Dies mindert jedoch keineswegs die Tatsache, dass InPost in Rekordzeit eine funktionierende, produktionsreife Automatisierung erhielt. Das Team bewältigte eine äußerst schwierige und anstrengende Herausforderung und lieferte dabei ein unvergleichliches Beispiel für Zusammenarbeit. Die Initiative und das Format des Events selbst waren ein bahnbrechendes Unterfangen in der Automatisierungsbranche, das möglicherweise wiederholt wird (Spoiler!) oder andere zur Nachahmung inspiriert. Wir ermutigen Sie nachdrücklich, zu experimentieren, Ihr tägliches Geschäft herauszufordern und dabei auch Spaß zu haben.
Die während des SpeedRun entwickelte Lösung arbeitet bis heute effizient. Bisher wurden 13.875 Fälle verarbeitet, bei lediglich 534 aufgetretenen Business-Exceptions (Daten vom 05.04.2024 – 30.07.2025). Mit einer durchschnittlichen Bearbeitungszeit von 6,19 Minuten hat sie bereits rund 1,3 FTE pro Monat eingespart. Abgesehen von der Zusammenführung der Roboter erfuhr die Lösung nur kleinere Anpassungen: kleine Änderungen bei Antwortvorlagen, Umwandlungen von Daten und Namen oder das Speichern von Anhängen in SharePoint. Die während des Events entwickelte Kernarchitektur besteht unverändert fort.
Darüber hinaus inspirierte der Erfolg des SpeedRun das InPost-Team, das Momentum beizubehalten – und ein halbes Jahr später wurde dieselbe Architektur erneut aufgebaut, um einen sehr ähnlichen Prozess zu automatisieren, der dem Unternehmen ebenfalls weiterhin Vorteile bringt (über 9.000 erfolgreiche Durchläufe).
Würden Sie es wieder tun?
Wenn Sie eine einfache Antwort wollen: Ja, ich würde es tun (ich persönlich). Aber was ich mir wirklich wünsche, ist die Chance, solche fantastischen Arbeitsbedingungen öfter zu erleben. Ich spreche nicht davon, 24 Stunden am Stück zu arbeiten – das war eine einmalige Aktion, bedingt durch das Event-Format. Was ich jedoch jederzeit gerne wiederholen würde, sind der Teamgeist, die intensive Konzentration und der Spaß. Es waren einzigartige Umstände, schwer dauerhaft aufrechtzuerhalten oder oft zu wiederholen, aber sie haben uns gezeigt, wie unglaublich Menschen sein können.
