Fuenfzig Bestellungen am Tag. Jede als PDF per E-Mail. Jede einzelne manuell abtippen. Das war der Alltag bei einem unserer Kunden — einem mittelstaendischen Grosshaendler, der mit genau diesem Problem zu uns kam. Nicht weil er von K.I. gelesen hatte und mal ausprobieren wollte. Sondern weil seine Sachbearbeiterin gedroht hat zu kuendigen.
Das klingt ueberspitzt, ist aber ziemlich nah an der Realitaet. Der Prozess war so stumpf, so repetitiv und so fehleranfaellig, dass niemand ihn laenger als ein paar Monate durchhielt, ohne entweder innerlich abzuschalten oder sich einen anderen Job zu suchen. Drei bis vier Stunden taeglich nur Bestelldaten eintippen. Artikelnummern, Mengen, Lieferadressen — von einem PDF-Dokument in ein Warehouse-Management-System. Copy-Paste im besten Fall, Abtippen im schlechtesten.
Was in den naechsten Wochen passierte, ist diese Case Study. Sie zeigt, wie wir den Prozess analysiert, automatisiert und stabilisiert haben — und was wir dabei gelernt haben, das wir beim naechsten Mal anders machen wuerden.
Als wir den Prozess zum ersten Mal analysierten, fiel uns etwas auf, das wir inzwischen bei fast jedem Kunden sehen: Niemand wusste genau, wie viel Zeit der Prozess tatsaechlich kostet. Die Schaetzung des Geschaeftsfuehrers war anderthalb Stunden. Die Sachbearbeiterin sagte drei Stunden. Die Wahrheit lag bei dreieinhalb — an Tagen mit vielen Sonderbestellungen auch mal vier.
Wir haben eine Woche lang mitgestoppt. Nicht weil wir dem Kunden nicht glaubten, sondern weil belastbare Zahlen die Grundlage fuer jede Automatisierungsentscheidung sind. Ohne Zahlen automatisiert man nach Bauchgefuehl, und Bauchgefuehl liegt bei Zeitschaetzungen systematisch daneben.
Der Ablauf sah so aus:
Was auf den ersten Blick wie sechs einfache Schritte aussieht, war in der Praxis ein Minenfeld. Die PDFs kamen in acht verschiedenen Formaten — weil acht verschiedene Kunden ihre Bestellungen in acht verschiedenen Systemen erstellten. Manche hatten Artikelnummern oben links, andere unten rechts, wieder andere mitten im Fliesstext. Manche lieferten strukturierte Tabellen, andere Freitext-E-Mails mit angehaengtem PDF, das eigentlich nur ein Scan eines handschriftlichen Bestellzettels war.
Die Fehlerquote lag bei geschaetzt 5-8%. Klingt wenig, bedeutet aber bei fuenfzig Bestellungen am Tag: zwei bis vier Fehlbestellungen taeglich. Falsche Menge, falscher Artikel, falsche Adresse. Jede Fehlbestellung kostete im Schnitt zwanzig Minuten Nacharbeit — Storno, Rueckruf, Neubestellung. Plus den Imageschaden beim Kunden, den niemand beziffern konnte, der aber definitiv da war.
Der Geschaeftsfuehrer hatte vorher zwei Optionen geprueft. Erstens: Eine Vollzeit-Kraft einstellen, die sich nur um Bestellungen kuemmert. Kosten: rund 45.000 Euro im Jahr mit Nebenkosten. Zweitens: Ein grosses ERP-Upgrade mit integriertem EDI-Modul. Kosten: sechsstellig, Implementierungszeit sechs bis zwoelf Monate, und seine Kunden haetten ihre Systeme ebenfalls umstellen muessen — was keiner von ihnen vorhatte.
Wir haben einen dritten Weg vorgeschlagen, der deutlich pragmatischer war: Die PDFs bleiben wie sie sind. Die Kunden aendern nichts. Aber zwischen E-Mail-Eingang und WMS-Eintrag setzen wir eine Automatisierung, die das manuelle Abtippen ueberfluessig macht.
Kein riesiges IT-Projekt. Kein Change-Management bei den Lieferanten. Kein sechsstelliges Budget. Stattdessen ein Python-Script, das PDFs lesen kann, ein n8n-Workflow fuer die Orchestrierung, und ein dedizierter Windows Server, auf dem das Ganze taeglich automatisch laeuft.
Wir haben das dem Kunden genau so erklaert — ohne Buzzwords, ohne K.I.-Versprechen, ohne Folie mit einem Roboterarm. Die ehrliche Ansage war: Wir bauen ein Script, das PDFs liest und die Daten ins WMS uebertraegt. Das ist keine Raketenwissenschaft. Aber es muss zuverlaessig funktionieren, jeden Tag, ohne menschliches Eingreifen. Und genau das ist der schwierige Teil.
Die Architektur ist bewusst einfach gehalten. Nicht weil wir keine komplexeren Systeme bauen koennten, sondern weil Einfachheit der beste Freund von Zuverlaessigkeit ist. Jede zusaetzliche Komponente ist ein zusaetzlicher Punkt, an dem etwas kaputtgehen kann.
Schritt 1: E-Mail-Eingang ueberwachen. Ein n8n-Workflow prueft das Bestellpostfach in regelmaessigen Intervallen. Wenn eine neue E-Mail mit PDF-Anhang eintrifft, wird der Anhang extrahiert und auf dem Server gespeichert. Das klingt trivial, war es aber nicht — weil manche Kunden ihre Bestellungen nicht als Anhang schicken, sondern als eingebettetes Bild im E-Mail-Body. Fuer diese Faelle mussten wir einen separaten Extraktionspfad bauen.
Schritt 2: PDF parsen. Hier passiert die eigentliche Arbeit. Ein Python-Script (Python 3.12) liest jedes PDF und extrahiert die relevanten Daten: Artikelnummern, Mengen, Lieferadressen. Wir nutzen dafuer eine Kombination aus regelbasiertem Parsing und Mustererkennung. Fuer die acht Hauptkunden haben wir jeweils ein eigenes Template erstellt, das weiss, wo im PDF welche Information steht.
Das war der aufwendigste Teil des Projekts. Nicht das Programmieren selbst, sondern das Verstehen der PDF-Strukturen. Ein Kunde hatte zum Beispiel Bestellungen, bei denen die Artikelnummer manchmal sechsstellig und manchmal achtstellig war — weil er zwei verschiedene Kataloge verwendete, einen aktuellen und einen von 2019. Ein anderer Kunde schickte gelegentlich Sammelbestellungen, bei denen mehrere Lieferadressen in einem einzigen PDF standen, getrennt durch eine horizontale Linie, die aber nicht immer an der gleichen Stelle war.
Fuer jedes dieser Probleme brauchten wir eine Loesung. Manche waren elegant (Regex-Pattern, die beide Artikelnummernformate erkennen), manche waren pragmatisch (wenn die horizontale Linie fehlt, nach dem Wort „Lieferanschrift“ suchen). Keines dieser Probleme war unloesbar, aber jedes hat Zeit gekostet — und das ist etwas, das man bei Automatisierungsprojekten ehrlich kommunizieren muss.
Schritt 3: Daten ins WMS einspeisen. Die extrahierten Daten werden validiert (Artikelnummer existiert? Menge plausibel? Adresse bekannt?) und dann per Schnittstelle ins Warehouse-Management-System uebertragen. Bei Validierungsfehlern wird kein Eintrag erstellt, sondern eine Benachrichtigung an die Sachbearbeiterin geschickt, die den Fall manuell bearbeitet.
Schritt 4: Statusmeldung. Nach jeder Verarbeitung erhaelt die Sachbearbeiterin eine Zusammenfassung: Wie viele Bestellungen wurden automatisch verarbeitet, wie viele erfordern manuelle Nachbearbeitung, und warum. Das klingt nach einem Detail, war aber fuer die Akzeptanz entscheidend — die Mitarbeiterin wollte nicht das Gefuehl haben, die Kontrolle zu verlieren.
Der gesamte Stack: Python 3.12 fuer das Parsing, n8n fuer die Workflow-Orchestrierung, ein dedizierter Windows Server (wir nennen ihn intern die UXUIX-VM) mit einem Scheduled Task, der den Prozess taeglich automatisch anstosst.
Hier eine ehrliche Einsicht, die wir aus diesem Projekt mitgenommen haben: Der Bau der Automatisierung war ein Drittel der Arbeit. Die Stabilisierung war ein Drittel. Und das Monitoring war das letzte Drittel — und vermutlich das wichtigste.
Denn eine Automatisierung, die ausfaellt und es niemand merkt, ist schlimmer als gar keine Automatisierung. Wenn die Sachbearbeiterin den Prozess manuell macht, merkt sie sofort, wenn etwas nicht stimmt. Wenn ein Script den Prozess macht und still versagt, stapeln sich die unverarbeiteten Bestellungen, waehrend alle denken, es laeuft.
Deshalb haben wir ein Monitoring aufgesetzt, das auf einer Supabase Edge Function basiert. Es funktioniert nach dem Heartbeat-Prinzip: Die Automatisierung meldet sich nach jedem erfolgreichen Durchlauf bei der Edge Function. Wenn die Meldung ausbleibt, wird ein Alarm ausgeloest. Zusaetzlich gibt es ein Dashboard, auf dem der Kunde jederzeit sehen kann, wie viele Bestellungen verarbeitet wurden, wie viele Fehler aufgetreten sind und ob das System gesund ist.
Das Monitoring hat sich bereits bezahlt gemacht. In der dritten Betriebswoche gab es einen Fall, bei dem ein Kunde sein PDF-Format geaendert hatte — ohne Vorankuendigung, wie das eben so laeuft. Der Parser erkannte die Artikelnummern nicht mehr, die Bestellungen liefen in die manuelle Queue, und das Monitoring hat sofort eine Warnung geschickt. Wir konnten das Template innerhalb von zwei Stunden anpassen. Ohne Monitoring haette es vermutlich zwei Tage gedauert, bis jemand es bemerkt haette.
Nach zwei Wochen Setup und einer Woche Feintuning war das System produktiv. Hier die Zahlen nach mehreren Wochen stabilem Betrieb:
Zeitaufwand vorher: 3-4 Stunden taeglich fuer die manuelle Bearbeitung aller Bestellungen.
Zeitaufwand nachher: Etwa 45 Minuten taeglich. Das sind die Sonderfaelle, die der Parser nicht automatisch verarbeiten kann — handschriftliche Bestellzettel, unbekannte Artikelnummern, Bestellungen von Neukunden ohne hinterlegtes Template.
Zeitersparnis: 70%.
In absoluten Zahlen: Rund 2,5 Stunden pro Tag, die die Sachbearbeiterin fuer andere Aufgaben nutzen kann. Auf den Monat gerechnet sind das ueber 50 Stunden. Auf das Jahr hochgerechnet ueber 600 Stunden.
Fehlerquote vorher: 5-8% (zwei bis vier Fehlbestellungen pro Tag).
Fehlerquote nachher: Unter 1%. Die verbleibenden Fehler sind fast ausschliesslich Quellfehler — also Faelle, in denen bereits das Bestell-PDF falsche Angaben enthielt. Die kann auch kein Mensch verhindern.
Kosten: Eine einmalige Setup-Gebuehr plus eine laufende Monatslizenz, die zusammen einen Bruchteil dessen kosten, was eine zusaetzliche Teilzeitkraft oder ein ERP-Upgrade gekostet haette. Die Amortisation war nach weniger als drei Monaten erreicht.
Unsichtbare Gewinne: Was die Zahlen nicht zeigen, ist die Entlastung fuer das Team. Die Sachbearbeiterin bearbeitet jetzt nur noch die interessanten Faelle — die Sonderbestellungen, die Rueckfragen, die Neukundenaufnahmen. Der monotone Teil ist weg. Das hat einen direkten Einfluss auf Mitarbeiterzufriedenheit und Fluktuation, auch wenn sich das schwer in Euro beziffern laesst.
Was gut lief:
Die Entscheidung, die Kundenformate nicht zu aendern, war goldrichtig. Jeder Versuch, die Kunden dazu zu bringen, ein einheitliches Bestellformat zu nutzen, waere gescheitert oder haette Monate gedauert. Stattdessen haben wir uns an die Realitaet angepasst — und die Realitaet ist: PDFs kommen in allen Formen und Farben.
Die enge Zusammenarbeit mit der Sachbearbeiterin war entscheidend. Sie kannte jeden Spezialfall, jede Ausnahmeregel, jeden Kunden mit seinen Eigenheiten. Ohne ihr Wissen haetten wir mindestens die Haelfte der Edge Cases uebersehen. Automatisierungsprojekte scheitern oft daran, dass Entwickler mit Managern sprechen statt mit den Leuten, die den Prozess tatsaechlich ausfuehren.
Das Monitoring von Tag eins an aufzusetzen — und nicht erst nachtraeglich, wenn der erste Ausfall passiert ist — hat uns vor mehreren Problemen bewahrt, die sonst tagelang unbemerkt geblieben waeren.
Was schwierig war:
Die Vielfalt der PDF-Formate war aufwendiger als erwartet. Wir hatten mit vier bis fuenf verschiedenen Strukturen gerechnet und am Ende acht Templates gebraucht, plus drei Sonderbehandlungen fuer Kunden, die ihre Formate waehrend des Projekts aenderten.
Die Erwartungshaltung beim Kunden war anfangs „100% automatisch, null manuell“. Wir mussten erklaeren, dass es immer Faelle geben wird, die manuell bearbeitet werden muessen — und dass das voellig in Ordnung ist. Das Ziel war nie 100% Automatisierung, sondern 100% Zuverlaessigkeit bei den 85-90% der Faelle, die automatisierbar sind. Die restlichen 10-15% bleiben beim Menschen, und das ist gut so.
Ein Scheduled Task auf einem Windows Server klingt altmodisch — und das ist er auch. Aber er funktioniert. Zuverlaessig, jeden Tag, ohne Container-Orchestrierung oder Cloud-Architektur. Manchmal ist die langweiligste Technologie die beste.
Diese Case Study ist kein Sonderfall. Praktisch jedes Unternehmen, das regelmaessig Daten von einem Format in ein anderes uebertragen muss — ob Bestellungen, Rechnungen, Lieferscheine oder Kundendaten — hat einen Prozess, der genauso aussieht: repetitiv, fehleranfaellig und fuer die beteiligten Mitarbeiter frustrierend.
Die Frage ist nicht, ob sich eine Automatisierung lohnt. Die Frage ist, ob der Prozess stabil genug ist, um automatisiert zu werden, und ob die Quelldaten strukturiert genug sind, um maschinell verarbeitet zu werden. In unserem Fall war die Antwort: Ja, mit Einschraenkungen. Und die Einschraenkungen haben wir nicht ignoriert, sondern bewusst adressiert — durch Templates pro Kunde, durch Validierungsregeln und durch einen klaren Fallback auf manuelle Bearbeitung bei Unklarheiten.
Wenn Sie einen aehnlichen Prozess in Ihrem Unternehmen haben und wissen wollen, ob sich eine Automatisierung lohnt, empfehle ich Ihnen als Einstieg unseren Artikel ueber Geschaeftsprozessautomatisierung. Dort beschreiben wir unsere Scoring-Matrix, mit der Sie selbst bewerten koennen, welcher Prozess den hoechsten Hebel hat.
Wenn Sie sich fuer die technischen Details interessieren — wie wir Python-Scripts fuer PDF-Parsing aufsetzen, wie n8n-Workflows funktionieren oder wie unser Monitoring fuer Lager- und Logistikprozesse aufgebaut ist — sprechen Sie uns direkt an.
Mehr darueber, wie wir als K.I.-Automatisierungsagentur arbeiten und welche Projekte wir umsetzen, finden Sie auf unserer Website.
Und wenn Sie nicht lesen, sondern reden wollen: Hier gehts zum Kontaktformular. Kein Sales-Pitch. Wir hoeren zu, schauen uns Ihren Prozess an und sagen Ihnen ehrlich, ob eine Automatisierung Sinn ergibt — oder ob Ihre Zeit und Ihr Geld woanders besser investiert waeren. Denn manchmal ist die beste Automatisierung die, die man nicht baut.
