Aus Dokumenten werden geprüfte, nutzbare Daten.
Der Workflow erkennt Dokumenttyp und relevante Inhalte, strukturiert Felder und Tabellen, prüft Vollständigkeit und übergibt das Ergebnis an ERP, CRM, DMS, Excel oder eine menschliche Freigabe.
Briefing für Design und Fotografie:
- Dokument-zu-Daten-Motiv: links ein reales, anonymisiertes PDF oder Formular, in der Mitte markierte erkannte Bereiche, rechts strukturierte Datenfelder mit Status „geprüft", „unklar" und „fehlt".
- Tabellen zeigen: mindestens ein Beispiel mit Positionszeilen, nicht nur sechs einfache Kopffelder.
- Realitätsnähe: unterschiedliche Layouts und ein schief gescannter Beleg dürfen sichtbar sein.
Ein PDF ist digital. Seine Informationen sind es oft noch nicht.
Dokumente kommen als Anhang, Scan, Download oder Dateiablage. Menschen erkennen den Typ, suchen relevante Felder, übertragen Positionen, prüfen Pflichtangaben und legen das Ergebnis im nächsten System ab. Bei wechselnden Layouts oder langen Tabellen wird aus einer scheinbar einfachen Aufgabe schnell ein dauerhafter Engpass.
Der Dokumentenprozess in fünf Schritten
- Dokument erkennen: Typ, Sprache, Version und mögliche Mehrfachdokumente bestimmen.
- Inhalte extrahieren: Felder, Tabellen, Positionen und relevante Textabschnitte erfassen.
- Daten normalisieren: Datums-, Mengen-, Einheiten-, Artikel- und Adressformate vereinheitlichen.
- Plausibilität prüfen: Pflichtangaben, Summen, Stammdaten und fachliche Regeln kontrollieren.
- Ergebnis übergeben: Daten in Zielsystem, Prüfansicht oder Folgeprozess bereitstellen.
Welche Dokumente verarbeitet werden können
| Dokumenttyp | Typische Informationen | Möglicher Zielprozess |
|---|---|---|
| Bestellung | Kunde, Bestellnummer, Positionen, Mengen, Termine | Auftrag im ERP vorbereiten |
| Angebot / Auftragsbestätigung | Preise, Positionen, Lieferbedingungen, Abweichungen | Vergleich und Freigabe |
| Formular | Stamm-, Auswahl- und Freitextfelder | Fachanwendung oder Datenbank |
| Lieferschein | Lieferant, Positionen, Mengen, Referenzen | Wareneingang oder Prüfung |
| Rechnung | Kopf- und Positionsdaten, Steuer, Summen | Buchhaltung / Rechnungsworkflow |
| Technisches Dokument | Bauteile, Merkmale, Hinweise, Revision | Technische Prüfung oder Suche |
| Excel-Datei | Tabellenstruktur, Spalten, Zeilen, Einheiten | Import, Abgleich oder Bereinigung |
Flexible Erkennung braucht ein klares Datenmodell
Die KI kann unterschiedliche Begriffe und Layouts erkennen. Für die spätere Verarbeitung muss jedoch eindeutig definiert sein, welche Felder benötigt werden, welches Format sie haben und welche Werte zulässig sind. Deshalb entsteht vor der Umsetzung ein Zielschema mit Pflichtfeldern, Datentypen, Tabellenstruktur und Prüfregeln.
| Felddefinition | Beispiel |
|---|---|
| Fachlicher Name | Gewünschter Liefertermin |
| Mögliche Bezeichnungen | Lieferdatum, requested date, Terminwunsch |
| Datentyp | Datum |
| Pflicht / optional | Pflicht bei Expressauftrag |
| Prüfung | Nicht in der Vergangenheit, gegen Werkskalender prüfen |
| Bei Unsicherheit | Im Prüfdialog markieren |
| Ziel | ERP-Auftragskopf |
Human-in-the-Loop ist Teil des Produkts
Bei Dokumenten ist nicht nur wichtig, was erkannt wurde, sondern wie sicher die Erkennung ist und welche Folgen ein Fehler hätte. Eine gute Prüfansicht zeigt Originalausschnitt, erkannten Wert, Regelverletzung und vorgeschlagene Korrektur direkt nebeneinander.
- Kritische Felder erhalten strengere Schwellenwerte.
- Unklare Werte werden im Originaldokument hervorgehoben.
- Korrekturen können protokolliert und für die Verbesserung ausgewertet werden.
- Freigabe erfolgt rollenbasiert und nicht pauschal durch jeden Nutzer.
- Das Originaldokument bleibt mit dem strukturierten Ergebnis verknüpft.
Was für einen Pilot benötigt wird
- 30 bis 100 repräsentative Dokumente je relevanter Variante als erste Arbeitsbasis; Umfang wird pro Prozess festgelegt.
- Beschreibung des gewünschten Zieldatensatzes.
- Pflichtfelder, fachliche Regeln und bekannte Sonderfälle.
- Zugang zu Test- oder Stammdaten für Abgleiche.
- Entscheidung, wo Prüfung und Freigabe stattfinden sollen.
- Testkriterien für Feldgenauigkeit, Vollständigkeit und Prozessnutzen.
Die notwendige Zahl der Beispieldokumente hängt von Varianz, Qualität, Tabellenkomplexität und Fehlerfolgen ab. Deshalb wird keine pauschale Mindestmenge als Leistungsversprechen veröffentlicht.
Woran der Nutzen gemessen werden kann
| Kennzahl | Messidee |
|---|---|
| Erfassungszeit | Aktive Minuten je Dokument |
| Feldgenauigkeit | Korrekte Werte je definiertem Feld und Dokumenttyp |
| Nachbearbeitung | Anteil der Dokumente mit menschlicher Korrektur |
| Durchlaufzeit | Eingang bis verfügbare strukturierte Daten |
| Vollständigkeit | Anteil der Dokumente mit allen notwendigen Pflichtfeldern |
| Übertragungsfehler | Fehler, die erst im Zielsystem auffallen |
Der Ablauf im Überblick
Häufige Fragen
Ja, wenn die enthaltenen Informationen fachlich vergleichbar sind und die Varianten im Pilot ausreichend berücksichtigt werden. Sehr unterschiedliche Dokumentarten werden häufig zunächst getrennt klassifiziert und anschließend mit passenden Schemas verarbeitet.
Ja. Tabellen sind jedoch anspruchsvoller als einzelne Kopffelder. Verschachtelte Zeilen, Seitenumbrüche, Mengeneinheiten und uneinheitliche Spalten benötigen eigene Tests und Prüfregeln.
Das kann möglich sein, muss aber mit realen Beispielen geprüft werden. Bildqualität, Schrift, Hintergrund und Fehlerfolge bestimmen, ob automatische Verarbeitung, Vorverarbeitung oder menschliche Prüfung sinnvoll ist.
Speicherort und Laufzeit werden im Architekturkonzept festgelegt. Möglich sind direkte Übergaben, kontrollierte Zwischenablagen oder kundenseitige Umgebungen – abhängig von Systemen, Datenschutz und Betriebskonzept.
Welches Dokument wird heute noch Zeile für Zeile übertragen?
Laden Sie im Prozess-Check optional ein anonymisiertes Beispiel hoch oder beschreiben Sie Dokument, Prüfregeln und Zielsystem.
Fachliche Prüfung durch einen Menschen, keine automatische Standardauswertung.