Kontext und Geschichte der Dokumentenverarbeitung
Andrzej Kinastowski (AK): Konnichiwa, willkommen beim Office Samurai podcast, wwo wir Ineffizienzen mit der Präzision eines Bogenschützen aus der Edo-Periode bekämpfen. Dieses Mal sprechen wir über Intelligent Document Processing (IDP), also die digitalisierte Verarbeitung von Rechnungen, Bestellungen, Kontoauszügen, Ausweisdokumenten, Zollpapieren – all dem Papier und papierlosen Papier, das Sie vielleicht haben. Ich bin Ihr Gastgeber, Andrzej Kinastowski, einer der Gründer von
Vor fast 20 Jahren, als ich meine Konzernkarriere begann, wurde ich in einem BPO eingestellt, und meine Aufgabe war es zunächst, Rechnungen zu buchen – ein ganz typischer Einstiegsjob zu dieser Zeit. Jeden Tag bekam ich ein Paket mit echten Papierrechnungen, die ich dann in den Computer eintippen musste. Ich erinnere mich, dass ich damals dachte, es sei ziemlich verrückt, dass wir im 21. Jahrhundert leben und trotzdem große internationale Unternehmen einander Papierstücke schicken – Papierstücke, die dann von Menschen in den Computer übertragen werden müssen. Das war schon seltsam. Einige andere Kunden dieses BPO nutzten OCRs (Optical Character Recognition), und ich war ziemlich neidisch auf sie.
Ein paar Jahre später, als ich in den Bereich der kontinuierlichen Verbesserung wechselte und Lean-Management-Projekte durchführte, sah ich, dass einige dieser Teams tatsächlich mehr Arbeit damit hatten, die Fehler der OCR zu korrigieren, als wenn sie die Rechnungen einfach manuell gebucht hätten. Das waren noch die altmodischen OCR-Systeme, bei denen man für jede neue Rechnung eine sogenannte Maske erstellen musste. Wenn sich das Rechnungslayout änderte, musste man auch die Maske anpassen. Die Maske teilte dem Tool mit, dass man bei diesem Rechnungstyp das Bankkonto an dieser Stelle der Seite und den Bruttobetrag an jener Stelle erwarten kann. Das bedeutete also viel Wartungsaufwand – und wirklich gut war das nicht. Heute sind wir hier, um darüber zu sprechen, wie diese Dinge inzwischen gemacht werden.
Heute ist Tomasz Wierzbicki bei mir. Er ist einer der Berater bei Office Samurai. Er ist Experte in vielen Bereichen – unter anderem in Intelligent Document Processing, Communication Mining und GenAI Agents. Tomasz, willkommen im Podcast.
Tomasz Wierzbicki (TW): Hi, ich freue mich sehr, hier zu sein.
AK: Sag mir, warum bist du hier (also warum bist gerade du derjenige, mit dem ich über Intelligent Document Processing spreche)?
TW: Ich beschäftige mich mit Intelligent Document Processing und in letzter Zeit zunehmend mit klassischem Machine Learning und Communication Mining (was größtenteils NLP, also Natural Language Processing, ist). Die Geschichte begann vor etwa zwei Jahren. Ich erinnere mich, dass unser Tech Lead Konrad damals einige Experimente mit Document Understanding gemacht hat, und ich habe es ausprobiert und war sofort begeistert. Es ist sehr spannend, die Dinge, die wir regelmäßig tun (RPA oder Automatisierung), mit einem Stück künstlicher Intelligenz zu kombinieren. Heute, mit dem rasanten technologischen Fortschritt, ist es eine sehr interessante Zeit und ein spannendes Feld, in dem man tätig ist. Ich habe das Gefühl, dass ich jeden Tag etwas Neues lerne – und dass Dinge derzeit unglaublich schnell veralten.
Entwicklung: vom klassischen OCR zur layoutunabhängigen IDP
AK: Wenn es um die altmodischen OCR-Systeme geht, die wir vor 20 Jahren in einem BPO verwendet haben – wie unterscheiden sich die heutigen Tools davon? Denn das, was ich damals gesehen habe, war nicht besonders beeindruckend.
TW: Nur ein kurzer Hinweis: Für mich ist das eher so 10 bis 15 Jahre her (vor 20 Jahren war ich eher noch Schüler). Ich hatte damals mit diesen klassischen Systemen zu tun. Soweit ich mich erinnere, war es damals immer eine Frage, ob sich der Einsatz wirklich lohnt, denn die Nutzung solcher OCRs war unglaublich teuer – und die Technologie war bei Weitem nicht so ausgereift wie heute. Unser Tech Lead Konrad meinte neulich, dass OCRs mittlerweile so ziemlich die obere Grenze ihrer Effizienz erreicht haben. Die Technologie ist also wirklich ausgereift und wird derzeit durch Deep Learning und wahrscheinlich auch durch Large Language Models weiter verbessert.
Es gab immer noch viele Fehler, daher mussten die Volumina, die man mit OCR verarbeiten wollte, wirklich groß genug sein, damit sich die Lösung langfristig lohnte. Man musste trotzdem viele Tippfehler korrigieren – typisch war zum Beispiel, dass eine „1“ wie ein „L“ aussah oder Nullen wie „O“s, und so weiter. Es wurde also sehr viel Nachbearbeitung an dem von der OCR erkannten Text durchgeführt.
Der klassische Ansatz war, dass die OCR zwar vorhanden war, aber nicht viel mehr konnte, als Text zu lesen und zu erkennen. Heute hingegen führen wir mit IDP (Intelligent Document Processing) auch Mustererkennungen durch, sodass das Tool layoutunabhängig ist.
Kategorisierung der Dokumentenstruktur
TW: Wenn man ein Dokument hat, weist es in der Regel eine gewisse Struktur auf. Man könnte diese Dokumente in verschiedene Kategorien einteilen:
- Keine Struktur: Wenn man sich etwa einen Vertrag oder ein Zertifikat anschaut, kann dieser völlig anders aufgebaut sein als ein anderer.
- Halbstrukturierte Dokumente: Gängige Typen wie Rechnungen oder Bestellungen, bei denen man erwarten kann, dass bestimmte Informationen enthalten sind. In der polnischen Gesetzgebung ist man beispielsweise verpflichtet, bestimmte Angaben auf einer Rechnung zu machen. Man kann also nicht nur mit dem Vorhandensein bestimmter Daten rechnen, sondern auch mit einer gewissen Struktur (zum Beispiel einem Kopfbereich, der sich über mehrere Seiten wiederholt).
- Voll strukturierte Dokumente: Unser berühmtes Steuerformular PIT oder die altmodischen Überweisungsformulare bei der Post.
Heutzutage konzentrieren wir uns nicht nur darauf, den Text zu erfassen, sondern auch auf Positionen, möglicherweise den Winkel, in dem das Dokument schief liegt, und viele andere Parameter. Kurz gesagt, es geht nicht mehr nur um die Texterkennung, sondern auch um die Strukturerkennung – also eher um etwas in Richtung Bilderkennung, nicht nur um den reinen Textteil.
AK: Das ist etwas, das für Menschen sehr einfach ist. Ich erinnere mich, als man mir beigebracht hat, solche Rechnungen zu lesen – man zeigte mir ein paar Beispiele und erklärte, welche Informationen ich suchen soll – und für einen Menschen ist es ganz leicht, diese Muster zu erkennen. Für einen Computer war das jedoch immer sehr schwierig.
IDP-Workflow: Klassifizierung, Merkmalsextraktion und Datenausgabe
AK: Wie funktioniert das eigentlich – wir geben eine digitalisierte Rechnung ein, und als Ergebnis erhalten wir alle Informationen schön sortiert in einer Excel-Tabelle?
TW: Basierend auf den Projekten, die ich durchgeführt habe, besteht der übliche Ablauf aus ein paar entscheidenden Schritten, die man immer durchführt.
Schritt 1: Digitalisierung und Merkmalsextraktion
TW: Nicht jedes Dokument liegt in nativer Form vor (also etwa als PDF, bei dem man den Text tatsächlich markieren kann). Manchmal ist es ein flaches oder sogar gescanntes Dokument – dann müssen die Tools den Text entweder per OCR erfassen oder extrahieren. Der erste Schritt besteht also in der Digitalisierung, und in diesem Bereich der OCR gibt es noch viel Forschungs- und Entwicklungspotenzial.
Im Grunde müssen wir den Text erfassen, aber neben dem reinen Text extrahieren wir auch verschiedene Merkmale. Das nimmt die Form eines großen Objekts an (im Programmierkontext), in dem alle möglichen Parameter enthalten sind. Das können Wörter sein, ihre Position, vielleicht die nächstgelegenen Umgebungen, Informationen wie die Schieflage des Dokuments sowie verschiedene Gewichte und Wahrscheinlichkeiten, die man erwarten kann. Dieses Dokumentobjektmodell wird anschließend in einen Machine-Learning-Algorithmus eingespeist.
In einem eher klassischen Ansatz wäre das wahrscheinlich eine Kombination aus Deep Neural Networks für den Bild- bzw. Strukturteil und Convolutional Neural Networks. Für den Textteil kämen wahrscheinlich Embeddings zum Einsatz. Diese Modelle sind entweder vortrainiert (der Anbieter kann Ihnen Modelle speziell für Rechnungen oder andere Dokumenttypen bereitstellen) oder man muss das Training selbst durchführen.
Schritt 2: Dokumentklassifizierung
TW: Der erste Schritt ist die Klassifizierung. Wenn man nicht sicherstellen kann, dass man nur einen bestimmten Dokumententyp erhält, möchte man zunächst klassifizieren. Der Algorithmus erkennt dann, um welchen Dokumententyp es sich handelt (z. B. Rechnung oder Gutschrift) – ganz ohne menschliches Eingreifen. Dabei handelt es sich nicht um einen einfachen, schlüsselwortbasierten Klassifikator, sondern erneut um einen Machine-Learning-Ansatz.
AK: Also, wenn der Algorithmus sich nicht sicher ist, ob es sich um einen bestimmten Dokumententyp handelt, würde er menschliche Hilfe anfordern – und diese Daten könnten wir dann nutzen, um das Modell nachzutrainieren, damit es stärker wird und künftig sicherere Entscheidungen treffen kann?
TW: Ja, genau. Man kann eine Feedbackschleife aufbauen – wenn ohnehin ein Mensch zur Validierung eingreifen muss, kann man diese Information gleich nutzen und dem Modell zusätzliche Trainingsbeispiele liefern. Sobald man weiß, um welchen Dokumententyp es sich handelt, kann man das Dokument dann an spezialisierte Modelle weiterleiten (zum Beispiel ein Modell nur für Rechnungen, ein anderes für Bestellungen) und es gezielt dem richtigen Modell zuführen.
Schritt 3: Datenerfassung
TW: Der zweite Teil, der häufiger erwartet wird, ist die Extraktion – also das Herausziehen der wichtigen Informationen aus dem Dokument. Bei Rechnungen wären das zum Beispiel die Rechnungsnummer, ein Datum sowie die Produkte oder Dienstleistungen, für die man bezahlt. Das Ziel ist, dass der Algorithmus genau diese spezifischen Werte erfasst, sodass man ein strukturiertes Datenformat erhält, mit dem man weiterarbeiten kann. Auf diese Weise muss kein Mensch die Daten manuell abtippen oder gar kopieren und einfügen – was ebenfalls eine monotone und mühsame Aufgabe ist.
Implementierung und die Notwendigkeit des „Human in the Loop“ (HITL)
AK: Also, das Tool erkennt, um welchen Dokumententyp es sich handelt, weiß, welche Daten es daraus extrahieren muss, und holt sie sich dann aus dem Dokument. Was passiert danach? Wie wird das Ganze mit unseren Geschäftsprozessen verknüpft?
TW: Da man nun strukturierte Daten hat, kann man im Grunde alles damit tun, was programmatisch oder mit RPA technisch möglich ist. Wie die Anbindung erfolgt, hängt vom jeweiligen Anbieter der IDP-Lösung ab.
🔸 Das kann alles sein – angefangen bei einer einfachen API (funktioniert mit jeder Programmiersprache).
🔸 Bei fortgeschritteneren Plattformen (wie UiPath) gibt es oft bereits fertige Schnittstellen oder Bibliotheken für RPA, in denen vordefinierte Aktivitäten vorhanden sind – man wählt einfach das Modell und den Dokumentenpfad aus.
Wenn man keine Ressourcen für Hardcoding hat (also nicht im RPA-Stil und nicht Low-Code, sondern klassische Programmierung), muss man sich mit den Integrationen befassen, da dies die Einstiegshürde deutlich erhöhen kann. Lösungen wie
Die Rolle von HITL und dem Confidence Score
AK: Früher war es bei den altmodischen OCR-Systemen so, dass, wenn das Modell ein bestimmtes Dokument nicht verarbeiten konnte, es an die manuelle Bearbeitung übergeben wurde, damit ein Mensch es buchen konnte. Wenn man nicht genug Aufwand in die Wartung steckte, verstand das Modell mit der Zeit immer weniger von den Rechnungen. Wie funktioniert das beim Intelligent Document Processing?
TW: Man sollte nach einer Lösung suchen, die das Konzept „Human in the Loop“ (HITL) integriert. Dabei wird der Prozess nicht unterbrochen, sondern ein Mensch wird zwischengeschaltet (kein Roboter oder KI), um zu überprüfen, ob die Daten korrekt sind. Außerdem kann man bestimmte Elemente parallel ausführen, sodass nicht der gesamte Prozess gestoppt wird, nur weil ein einzelnes Dokument validiert werden muss.
Die Validierungsstation ist eine grafische Benutzeroberfläche, auf der das Dokument angezeigt wird – zusammen mit den erkannten Werten für den jeweiligen Dokumententyp und allen Feldern. Dort kann man prüfen, ob das Modell korrekt gearbeitet hat oder nicht. Hier kommt der wichtige Aspekt des Confidence Score ins Spiel. Man muss akzeptieren, dass es sich hierbei nicht um klassisches RPA handelt. Das neuronale Netz liefert Werte (meist zwischen 0 und 100 %), die angeben, wie sicher das Modell ist, dass ein bestimmter Wert tatsächlich der relevante ist. Dann kann man entscheiden, ob man beispielsweise mit einer Sicherheit von 85 % zufrieden ist, um die nächste Automatisierungsschritt auszuführen. Unser üblicher Ansatz ist, sich nicht vor Heuristiken zu scheuen. KI ist großartig, aber man sollte keine Angst haben, Daten nachzuschlagen oder Mapping-Tabellen zu erstellen – etwa, indem man zuerst die Rechnungsnummer irgendwo im System sucht – und erst dann entscheidet, ob man dem menschlichen Benutzer die Validierungsstation anzeigt.
Das Paradoxon der Genauigkeit von Mensch vs. Maschine
TW: Das Tool wird wahrscheinlich etwa 80 % der Arbeit übernehmen, aber wir sind noch nicht an dem Punkt (vielleicht bei sehr einfachen Fällen), an dem ein vollständig automatischer Durchlauf ohne menschliches Eingreifen zu 100 % funktioniert. Dennoch wird kaum jemand bei wichtigen Prozessen alles allein der KI überlassen.
AK: Wir müssen auch bedenken, dass KI nicht perfekt sein soll – aber Menschen sind es ebenso wenig. Unsere Genauigkeits-KPIs beim Buchen von Rechnungen lagen normalerweise bei etwa 96 %. Das bedeutet, dass bei 4 % der Rechnungen Fehler vorkamen, wenn sie von Menschen bearbeitet wurden. Die Arbeit wird sehr monoton, man lässt sich leicht ablenken oder vergisst etwas. Ich verstehe also, warum Unternehmen zögern, nicht-deterministische Modelle einzusetzen – aber es ist nicht so, dass Menschen dabei wesentlich besser wären.
TW: Menschen validieren nicht so gründlich. Zeig mir jemanden, der geduldig genug ist, ein 30-seitiges PDF Zeile für Zeile mit einem MRP-System abzugleichen. Wenn man ein großes Unternehmen ist, bekommt man täglich Tausende, ja Zehntausende von Rechnungen. Es ist schlicht unmenschlich, jemandem zu sagen: „Du hast hier 10.000 Seiten, und du musst sie mit irgendeiner Datenbank vergleichen.“ Man muss verstehen, dass sowohl Menschen als auch Maschinen Fehler machen – und die Prozesse müssen so aufgebaut sein, dass sie damit umgehen können.
Anwendungsfälle: über Rechnungen und Dokumente mit hohem Volumen hinaus
AK: Also, wir haben mit Rechnungen begonnen – das ist ja etwas, womit die meisten Unternehmen beim Intelligent Document Processing starten, weil jeder Rechnungen erhält, und je größer man ist, desto mehr davon bekommt man. Aber welche anderen Dokumenttypen könnte man noch mit IDP verarbeiten, bei denen der Einsatz der Technologie tatsächlich sinnvoll ist?
TW: Ich würde vorschlagen, sich auf die beiden grundlegenden Funktionen zu konzentrieren – Klassifizierung und Extraktion (also zu verstehen, um welchen Dokumententyp es sich handelt und dann die relevanten Daten daraus zu holen) – und dann zu überlegen, welche Prozesse man mit diesen beiden Fähigkeiten unterstützen könnte. Andere, interessantere Beispiele, die wir umgesetzt haben (denn nur klassifizieren, extrahieren und irgendwo eintippen ist der häufigste Anwendungsfall), waren etwa die Erkennung, ob auf einem Dokument eine Unterschrift vorhanden ist.
Anwendungsfall 1: Erkennung der Anwesenheit einer Unterschrift
TW: Ein Kunde interessierte sich überhaupt nicht für Text- oder Datenerkennung – auf bestimmten Lieferdokumenten gab es drei Felder, und alles, was ihn interessierte, war festzustellen, ob es dort drei „Ja“-Angaben gab. Es handelte sich um Stempel und handschriftliche Unterschriften. Bei solchen Fällen sollte man eher auf bildbasierte Erkennungssysteme setzen, da diese darauf spezialisiert sind. Glücklicherweise unterstützt die von uns verwendete Lösung ein spezielles Feld für Unterschriften, die einfach als boolesche Werte (also Ja/Nein) erfasst werden können. Wir haben das genutzt – und in etwa 80–90 % der Fälle wurde alles korrekt erkannt.
Anwendungsfall 2: Datenverschleierung (Anonymisierung)
TW: Ein weiteres Beispiel war für ein litauisches Unternehmen, bei dem einige staatliche Behörden bestimmte Dokumente vom Unternehmen angefordert hatten, und sie dazu berechtigt waren. Aber andererseits musste die DSGVO eingehalten werden, also konnten sie diese Dokumente nicht einfach herausgeben. Sie mussten personenbezogene Daten der Mitarbeiter verschleiern (anonymisieren), weil es sich wahrscheinlich um Personalunterlagen oder Verträge handelte. Die Lösung war, diese Extraktion zu nutzen, aber nicht zum Extrahieren, sondern um genau festzulegen, wo diese persönlichen Werte lagen, und dann einige Drittanbieter-Bibliotheken (wir verwendeten Python) einzusetzen, die einfach schwarze Rechtecke darüber zeichnen, und anschließend das Ganze in eine Datei zu überführen, die man nicht mehr rückgängig machen kann.
Anwendungsfall 3: Verwaltung und Aufteilung von HR-Dokumenten
TW: Und noch ein interessanter Fall – wieder mit hohem Volumen und einigen Herausforderungen: HR-Dokumente. Das Unternehmen hatte eine große Menge an personalbezogenen Dokumenten (Verträge, Fitnessstudio-Mitgliedschaften, Gesundheitsvereinbarungen). Sie wollten diese digitalisieren, hatten aber ganze Papierstapel einfach direkt in den Scanner gelegt, wodurch 100 bis 150 Seiten lange zusammengeführte PDFs entstanden. Wenn diese Dateien zusammengeführt sind, ist es schwierig zu erkennen, wo Dokument A endet und Dokument B beginnt. Diese Tools können auch dabei helfen, indem sie analysieren, dass ein bestimmtes Dokument von hier bis hier reicht, und es automatisch in Abschnitte aufteilen. Das übergeordnete Ziel war später zu prüfen, ob ein Mitarbeiter (z. B. John Smith) bestimmte Dokumente unterschrieben hat – also etwa diesen Vertrag und jenen, aber vielleicht keine Krankenversicherungsunterlagen.
AK: Also, wenn ich dich richtig verstehe, beginnen wir oft mit einfachen, stärker strukturierten Dokumenten mit hohem Volumen – also Rechnungen, Bestellungen, Kontoauszüge. In der Personalverwaltung hingegen gibt es sehr viele Papierdokumente, und viele Unternehmen sind noch dabei, ihre Archive zu digitalisieren. Dann gibt es diese Kategorie mit etwas ungewöhnlicheren Anwendungsfällen – wie du gesagt hast: das Erkennen von Unterschriften oder das Anonymisieren von Daten. Das ist also eine eher kreative Art, das Tool zu nutzen, um mit allen möglichen Dokumenten umzugehen, die man im Unternehmen hat.
Technische Herausforderungen und das „Digital Paper“-Paradoxon
AK: Was mich immer wieder erstaunt, ist, dass wir zwar PDFs verwenden, dieses Format aber eigentlich gar nicht gut für die Datenverarbeitung geeignet ist. Ein PDF ist immer noch unstrukturierte Daten (es sei denn, es gibt versteckte Strukturebenen darin). In den letzten 20 Jahren – seit ich mit der manuellen Rechnungsverarbeitung begonnen habe – sind wir zwar vom Papier zum sogenannten digitalen Papier übergegangen, aber im Grunde ist es immer noch Papier, weil es keine strukturierten Daten sind. Wir sind also nicht zu CSV-Dateien oder SQL-Tabellen übergegangen, sondern haben uns nur von einer Art Papier zu einer anderen bewegt.
TW: Viele vergessen, dass das PDF ursprünglich für den Druck gedacht war – also für Marketingmaterialien, Broschüren oder digitale Flugblätter. Es wurde aber sehr schnell zum beliebtesten Format für so ziemlich alles. Es war ein Eigentor, dass wir damals nicht den nächsten Schritt gegangen sind und ein besser standardisiertes Format entwickelt haben. Im Grunde helfen uns diese Tools heute, einen Fehler aus der Vergangenheit zu korrigieren. Wenn alles über APIs oder ein EDI-System laufen würde, bräuchte man keine KI-Tools, die Daten für einen erkennen.
Zentralisierte E-Rechnungsstellung und die Zukunft von IDP
AK: Das wäre auch gleich meine nächste Frage, denn es gibt bereits einige Länder in Europa, die eine zentralisierte Rechnungsstellung eingeführt haben. In Polen tun wir uns damit noch schwer – die Einführung wurde schon mehrfach verschoben, aber vielleicht kommt es ja irgendwann. Wie denkst du, wird sich das auf den Bedarf an IDP-Technologien auswirken?
TW: Im Moment, auf der Basis dessen, was wir haben, ist es schwer zu sagen. Da Rechnungen der häufigste Dokumenttyp sind, würde ich zumindest empfehlen, sich damit zu befassen und etwas Recherche zu betreiben – insbesondere zu Initiativen der Europäischen Union oder der eigenen Regierung. Ich sehe, dass die Verwaltungen zunehmend digital werden. Daher würde ich auf jeden Fall im Voraus prüfen, damit es nicht passiert, dass man eine Lösung in einem halben Jahr entwickelt – und ein weiteres halbes Jahr später alle auf digitale Rechnungsstellung umsteigen müssen, weil es gesetzlich vorgeschrieben ist.
AK: Aber die Recherche muss gründlich sein, denn soweit ich weiß, enthalten viele dieser Rechnungssysteme nur die Basisdaten der Rechnung und nicht die Tabellen mit den Details. Man muss also weiterhin einen Weg finden, diese auszulesen – außerdem geht es dabei nur um Rechnungen, und wir verarbeiten immer noch viele andere Dokumenttypen.
TW: Das Tempo der technologischen Entwicklung und das Tempo der Anpassung sind zwei völlig unterschiedliche Dinge. Wir sehen, dass IDP-Lösungen zwar vor drei oder vier Jahren neu waren, aber die Leute kommen immer noch mit denselben alten Problemen, denselben Themen, denselben PDFs zu uns. Ich denke, diese Technologie wird uns noch eine Weile begleiten. Etwas, das bereits funktioniert und echten Mehrwert bringt, ist immer noch besser, als einem Traum hinterherzujagen und am Ende nichts umgesetzt zu bekommen.
Anbieterauswahl: Warum UiPath Document Understanding
AK: Es gibt einige große Anbieter auf dem Markt, und bei Office Samurai nutzen wir hauptsächlich Document Understanding von UiPath. Kannst du mir erklären, warum wir das tun und warum wir nicht die meisten anderen Anbieter verwenden?
TW: Ich denke, unsere Gewohnheiten spielen hier eine große Rolle – wir kennen die Technologie bereits gut. Der Anbieter ist zudem dafür bekannt, dass seine Lösungen sich hervorragend in das übrige Produktportfolio integrieren lassen. Ein weiterer Vorteil ist die einfache Implementierung für Business-User. Ich nenne das Training oft ein „Malbuch“ – der Fachanwender markiert einfach Text- und Datenelemente. Außerdem bietet UiPath vortrainierte Modelle mit einer gewissen Grundeffizienz. Für die gängigsten vordefinierten Felder auf Rechnungen kann man mit einem durchschnittlichen Confidence Score von etwa 60–70 % rechnen. Wenn man die Software ohnehin schon für RPA nutzt, ist die Einführung eines weiteren Tools innerhalb derselben Plattform sehr einfach. Zudem wird UiPath allgemein als führender Anbieter in diesem Technologiebereich angesehen.
Der hybride Ansatz: IDP und Large Language Models (LLMs)
AK: Wir bekommen oft Fragen zu Large Language Models (LLMs). Viele Unternehmen haben die Idee: „Warum sollten wir statt Intelligent Document Processing nicht einfach alles in ChatGPT eingeben?“ – Wie siehst du das?
TW: Das Erste, was ich immer erwähne, ist die Wiederholbarkeit. Wenn man große Volumina verarbeiten will, braucht man einen klar definierten Workflow. Zweitens sind transaktionsorientierte Dokumente – wie Rechnungen – inhaltlich gar nicht so textreich. LLMs sind darauf ausgelegt, Sprache zu verstehen, nicht Strukturen. Und genau da sind spezialisierte IDP-Lösungen nach wie vor deutlich besser geeignet.
Ein sehr interessantes Feld ist der Aufbau hybrider Ansätze. Man kann das Ergebnis einer IDP-Lösung nehmen und anschließend ein LLM einsetzen, um es beispielsweise zu validieren. Man könnte auch einen Agenten entwickeln, der Zugriff auf das ERP-System hat, um Daten nachzuschlagen und zu überprüfen. Ein großes Thema ist das Fuzzy Matching: Man kann den Agenten prüfen lassen, ob unterschiedlich formulierte Produktbezeichnungen „eigentlich dasselbe“ meinen, nur anders ausgedrückt. Ein weiteres Einsatzgebiet für LLMs ist die Handschriftenerkennung. Unser Tech Lead Konrad hat einmal den von der OCR erkannten Text zusammen mit dem Bild, das viele handschriftliche Elemente enthielt, an ein LLM gegeben und es gebeten, Fehler in der Handschrift zu korrigieren – und so haben wir das Beste aus beiden Welten kombiniert.
Der dritte Faktor ist das Confidence Level. LLMs liefern keine Wahrscheinlichkeitsangaben. Wenn man LLMs verwendet, kennt jeder das Phänomen der sogenannten „Halluzinationen“. Wenn das Modell etwas Falsches ausgibt, tut es das mit 100%iger Überzeugung. Kaum ein Manager würde derzeit alles vollständig der KI überlassen, ohne menschliche Kontrolle. Daher setzen wir im Moment auf einen hybriden Ansatz.
Wenn Automatisierung an ihre Grenzen stößt: die problematischen Dokumente
AK: Bist du auf Projekte oder Dokumenttypen gestoßen, bei denen diese Technologie versagt hat oder nicht so funktioniert hat, wie wir es uns vorgestellt hatten?
TW: Handschrift ist nach wie vor ein Thema – also: lieber keine Handschrift. Man kann nur erwarten, dass es funktioniert, wenn die Schrift wirklich gut lesbar ist. Schlechte Scans kommen heutzutage zwar seltener vor, aber da würde ich mich fragen, ob es nicht günstiger wäre, einfach die Geräte auszutauschen. Auch Unterschriften sind problematisch, insbesondere wenn sie unleserlich sind. In unserem Fall mussten wir lediglich prüfen, ob überhaupt eine Unterschrift vorhanden war – mehr nicht.
Aber das eigentlich größte Problem waren verschachtelte Tabellen. Das Tool kann zwar zweidimensionale X- und Y-Strukturen definieren, aber viele Dokumente neigen dazu, eine große Tabelle zu enthalten, in der sich innerhalb einer Spalte wiederum eine weitere Tabelle befindet. Das ist für das Modell sehr schwierig zu erlernen. Man musste Workarounds einsetzen und die Daten anschließend nachbearbeiten.
AK: Das ist also unsere Botschaft an alle, die Rechnungen und andere Dokumenttypen entwerfen: Wenn wir wirklich Menschen ersetzen wollen, die diese Daten nur abtippen oder per Copy-Paste übertragen, müssen wir anfangen, Dokumente so zu gestalten, dass Maschinen sie leichter verstehen können.
TW: Lasst uns aufhören mit diesen ausgefallenen Layouts. Wirklich – für die Automatisierung ist eine einfache Textdatei, in der einfach alles aufgelistet ist, deutlich besser.
AK: Keine verschachtelten Tabellen, bitte.
Abschließende Gedanken: IDP oder die Apokalypse
AK: Nun, vielleicht werden wir eines Tages in einer Welt leben, in der Intelligent Document Processing nicht mehr nötig ist, weil wir Daten auf eine Weise austauschen, die dem 21. Jahrhundert entspricht – und nicht dem 20. Jahrhundert. Aber bis dahin wird es wohl noch lange dauern.
TW: Wenn man als neues Unternehmen oder Startup ganz von vorn beginnt, sollte man von Anfang an darüber nachdenken, wie gut man dieses Thema angeht. Wenn man gleich digitale Prozesse integriert, bei denen Computer über APIs oder standardisierte Formate wie XML oder JSON miteinander kommunizieren, ist das immer noch besser, als Papier einfach nur durch seine digitale Version im PDF-Format zu ersetzen.
AK: Ich denke, wir sehen ganz klar, dass es unzählige Möglichkeiten gibt, Intelligent Document Processing einzusetzen – und dass es dabei nicht nur um Kosteneinsparungen geht.
TW: Es geht auch darum, dass es immer schwieriger wird, Menschen zu finden, die solche Arbeiten überhaupt noch machen wollen. Jemanden zu finden, der lange genug bleibt, damit es sich lohnt, ihn einzuarbeiten, wird zunehmend kompliziert. Die Volumina werden nicht kleiner – jedes Unternehmen muss wachsen. Daher sehen wir zwei Möglichkeiten: Entweder wir implementieren Intelligent Document Processing, oder wir warten einfach auf die Apokalypse.
AK: Mit diesen optimistischen Worten, Thomas, vielen Dank, dass du deine Erfahrungen mit uns geteilt hast.
TW: Schauen wir zunächst einmal, was unsere Botschaft „Keine ausgefallenen PDFs“ bewirkt. An alle, die Dokumente gestalten: Denkt daran – in fünf Jahren schauen wir nach, ob ihr euch daran gehalten habt. Einfachheit ist schön. Vielen Dank an alle!
AK: Alles klar, Leute, das war’s – eine weitere Folge des Office Samurai Podcast, fein säuberlich geschnitten, zerlegt und serviert wie euer Lieblings-Sashimi-Teller.
Diese Episode entstand in Zusammenarbeit mit UiPath, unserer ersten Wahl unter den Plattformen für Prozessautomatisierung.
Ein riesiges Dankeschön an euch, unsere Zuhörerinnen und Zuhörer – ob ihr uns auf dem Weg zur Arbeit hört, in einem Meeting sitzt und so tut, als würdet ihr mitschreiben, oder euch einfach vor eurem Posteingang versteckt. Wir schätzen euch – und versprechen, euch (noch) nicht zu automatisieren.
Ein großes Dankeschön auch an unseren Gast Tomasz Wierzbicki, der uns den Weg zum Sieg über den Papierkram gezeigt hat.
Und wie immer Applaus für Anna Cubal, unsere Produzentin, die diese Episoden mit mehr Präzision zusammenhält als ein IDP-Modell, das eine perfekt formatierte Rechnung liest.
Aufgenommen wurde das Ganze im legendären Wodzu Beats Studio, wo der Kaffee stark ist – aber unser Hass auf manuelle Dateneingabe noch stärker.
Wenn euch gefallen hat, was ihr gehört habt, erzählt es euren Freunden – und wenn nicht, dann erzählt es auf jeden Fall euren Feinden.
Abonniert uns dort, wo ihr gerade am liebsten prokrastiniert – bei Spotify, Apple oder in dieser seltsamen Podcast-App, die euer Cousin empfohlen hat.
Und hey – wenn ihr die Folge geliebt, gehasst oder Ideen für zukünftige Themen habt, oder einfach über Akronyme diskutieren wollt – meldet euch bei uns!
Schickt uns euer Feedback, eure Fragen oder sogar Haikus über Automatisierung – wir Samurais sind offen für alles.
Bis zum nächsten Mal: Haltet eure Klingen scharf und eure Prozesse noch schärfer.
