Fallstudie: Vom n8n-Prototyp zum Python-Produktivsystem
Nicht jede Automatisierung, die in n8n gut startet, sollte auch in n8n bleiben. Diese Fallstudie zeigt ein konkretes Beispiel, an dem ich selbst beteiligt war – inklusive dem Punkt, an dem der Wechsel auf eigenen Code die richtige Entscheidung war.
Die Ausgangslage
Die Aufgabe: Ein E-Mail-Postfach wird laufend mit eingehenden Dokumenten befüllt – Rechnungen, Lieferscheine, Verträge, unterschiedlichste Absender und Formate. Diese Dokumente sollten automatisch ausgelesen, klassifiziert und mit den passenden Metadaten in ein d.velop-DMS-System importiert werden, statt dass jemand jedes einzelne Dokument manuell öffnet, einordnet und die Felder von Hand pflegt.
Klassische Kandidatenaufgabe für Automatisierung. Und ein klassischer Fall dafür, mit n8n zu starten.
Warum n8n für den Prototyp die richtige Wahl war
n8n hat den Prototyp in wenigen Tagen lauffähig gemacht: E-Mail-Trigger, Anhang extrahieren, an ein KI-Modell zur Dokumentenauslese schicken, Ergebnis validieren, ins DMS schreiben. Für den ersten Praxistest – funktioniert das Konzept überhaupt zuverlässig genug, um es weiterzuverfolgen – war das genau richtig. Man sieht sofort, ob die Idee trägt, ohne wochenlang Infrastruktur zu bauen.
Das ist die eigentliche Stärke von n8n: schnell von der Idee zum funktionierenden Testlauf.
Wo es für den Produktiveinsatz eng wurde
Sobald der Prototyp mehr Dokumente verarbeiten sollte und die Vielfalt der eingehenden Formate zunahm, zeigten sich drei konkrete Grenzen:
Fehlerbehandlung bei uneindeutigen Dokumenten. Nicht jedes Dokument liefert ein eindeutiges Klassifizierungsergebnis. Manche sind mehrdeutig, manche technisch beschädigt, manche in einem Format, das die Erkennung nicht sauber verarbeitet. Diese Fälle brauchten eigene, differenzierte Behandlungspfade – nicht nur „Fehler, Workflow stoppt“, sondern unterschiedliche Reaktionen je nach Fehlerart. Das in einer visuellen Workflow-Oberfläche sauber und wartbar abzubilden, wurde mit jeder zusätzlichen Fallunterscheidung unübersichtlicher.
Testbarkeit. Bei einer Logik, die zunehmend verzweigt, will man automatisierte Tests schreiben können – neue Dokumenttypen hinzufügen, ohne bei jeder Änderung alle bisherigen Fälle manuell durchzuklicken. In eigenem Code ist das Standard. In einem visuellen Workflow-Tool ist es aufwendiger nachzubilden.
Versionskontrolle und Nachvollziehbarkeit. Bei komplexer werdender Verarbeitungslogik wird die Frage „was genau hat sich zwischen Version A und B geändert“ wichtig – für Debugging genauso wie für Dokumentationspflichten. Ein Python-Repository mit Git-Historie beantwortet das direkt. Bei einem visuellen Workflow ist der Unterschied zwischen zwei Ständen deutlich schwerer zu erkennen.
Die Portierung
Der produktive Teil wurde als eigenständige Python-Anwendung neu gebaut: gleiche Grundlogik wie im n8n-Prototyp (E-Mail-Eingang überwachen, Dokumente an ein Modell zur Auslese schicken, Ergebnis ins DMS schreiben), aber mit eigener Fehlerbehandlung pro Dokumenttyp, automatisierten Tests für die Klassifizierungslogik und versionierter Codebasis.
Der n8n-Prototyp war damit nicht verschwendete Arbeit – er hat innerhalb weniger Tage gezeigt, dass die Idee funktioniert, und als funktionierende Referenz für die Python-Implementierung gedient. Ohne den Prototyp hätte die Python-Entwicklung von null angefangen, mit deutlich mehr Vorlaufzeit, bevor überhaupt klar gewesen wäre, ob sich der Aufwand lohnt.
Wo das System heute läuft
Diese Lösung läuft heute im Rahmen der Zusammenarbeit zwischen BrainRock und Transferdata produktiv im Einsatz – als Teil der Schnittstellen-Automatisierung, die dort für Kunden im Dokumentenmanagement-Umfeld bereitgestellt wird.
Die eigentliche Lehre daraus
Die Entscheidung „n8n oder eigener Code“ ist keine grundsätzliche, sondern eine, die sich mit der Aufgabe ändert. Für den ersten Test einer Idee ist n8n oft die schnellere und damit richtige Wahl. Sobald Fehlerbehandlung komplex wird, Testbarkeit wichtig wird oder die Nachvollziehbarkeit über Versionen eine Rolle spielt, verschiebt sich die Balance.
Der Fehler, den ich in Audits häufiger sehe als eine falsche Erstentscheidung, ist das Ausbleiben dieser zweiten Entscheidung: Ein Prototyp bleibt im Produktiveinsatz, obwohl er die Anforderungen längst überschritten hat, einfach weil er „irgendwie läuft.“
Weitere Ressourcen
Zu den technischen Mustern, die genau an dieser Stelle entstehen:
→ Die Fehler, die ich in jedem n8n-/Make-Audit wiederfinde
Wenn du wissen willst, ob eine deiner Automatisierungen an diesem Punkt steht:
→ Kostenloser KI-Compliance Schnellcheck
Für eine vollständige technische Analyse:
