Welche Prozessdaten vor einer Automation fehlen

Bevor du einen Arbeitsablauf automatisierst, muss feststehen, welche Daten seinen nächsten Schritt auslösen und welche Angaben eine richtige Entscheidung ermöglichen. Eine grosse Sammlung von Dokumenten genügt dafür nicht. Wenn Vorgangskennung, Status oder Herkunft fehlen, kann eine Automation zwar Inhalte verarbeiten, aber den falschen Fall verändern oder eine offene Entscheidung als abgeschlossen behandeln.

Dieser Artikel entwickelt einen eigenen Datencheck für einen Dokumentenprozess. Das Beispiel ist fiktiv: Ein Team will eingehende Serviceberichte automatisch einem Vorgang zuordnen und zur fachlichen Prüfung weiterleiten. Es geht um die Datenreife nach der Auswahl eines sinnvollen Prozesses. Die Entscheidung, welcher Engpass zuerst bearbeitet wird, liegt davor.

Beschreibe den nächsten Schritt als Entscheidung

Beginne mit dem Satz: "Damit dieser Schritt ausgeführt werden darf, müssen folgende Tatsachen feststehen." Für die Zuordnung eines Serviceberichts sind das beispielsweise die eindeutige Vorgangskennung, der erlaubte Dokumenttyp und der aktuelle Bearbeitungsstatus. Für eine spätere Freigabe kommen andere Angaben hinzu. Vermische diese Entscheidungen nicht zu einer einzigen Liste beliebiger Pflichtfelder.

Unterscheide Informationen, die für die Entscheidung erforderlich sind, von solchen, die lediglich hilfreich sind. Eine Telefonnummer kann die spätere Rückfrage erleichtern. Sie ist nicht zwingend nötig, um einen Bericht dem richtigen Vorgang zuzuordnen. Eine fehlende Vorgangskennung kann dagegen genau diesen Schritt blockieren. Die Pflicht ergibt sich aus der Handlung, nicht aus der Bequemlichkeit eines Formulars.

Die fachlich verantwortliche Person muss diese Grenze bestätigen. Ein Entwickler kann die Prüfung implementieren, aber nicht eigenständig entscheiden, welche Unsicherheit im Prozess akzeptabel ist. Der Beitrag Prozessdokumentation mit KI hilft, die beteiligten Schritte und Entscheidungen vor der technischen Umsetzung sichtbar zu machen.

Was Ereignisdaten zur Analyse beitragen

Das Process Mining Manifesto der IEEE Task Force, 2011 beschreibt Ereignisprotokolle als Grundlage für die Analyse von Prozessen. Ereignisse beziehen sich auf Aktivitäten und Fälle; zusätzliche Angaben können unter anderem Zeitstempel und Ressourcen sein. Daraus folgt keine universelle Pflichtfeldliste für jeden Automationsprozess.

Für den hier vorgeschlagenen Check ist die Übertragung konkret: Eine stabile Fallzuordnung und nachvollziehbare Ereignisse helfen, tatsächliche Abläufe zu untersuchen. Wenn du Durchlaufzeiten berechnen willst, brauchst du zusätzlich geeignete und vergleichbare Zeitangaben. Ohne diese Daten bleibt die Zeitrechnung offen. Ein Modell kann fehlende historische Ereignisse nicht nachträglich als gemessene Tatsachen rekonstruieren.

Ein fiktiver Bericht mit scheinbar vollständigen Angaben

Ein Servicebericht enthält Kundenname, Gerätetyp, Datum und eine ausführliche Beschreibung. Die Vorgangsnummer fehlt. Im System existieren zwei offene Fälle für denselben Kunden und dasselbe Gerät. Eine Zuordnung anhand des Namens allein ist deshalb nicht eindeutig. Der umfangreiche Text verdeckt die fehlende Information, die für den nächsten Schritt tatsächlich erforderlich ist.

Eine zweite Datei enthält die richtige Vorgangsnummer, aber einen veralteten Status. Eine dritte ist eine korrigierte Fassung eines bereits eingegangenen Berichts. Diese Fälle benötigen unterschiedliche Behandlung. Der erste verlangt Klärung der Zuordnung. Der zweite verlangt einen aktuellen Status aus dem führenden System. Der dritte braucht eine nachvollziehbare Beziehung zur früheren Fassung.

Ein einziger Wert "Dokument vollständig" bildet diese Unterschiede nicht ab. Der Datencheck muss die konkreten Voraussetzungen separat prüfen. So kann ein Bericht inhaltlich vollständig und trotzdem nicht automatisch verarbeitbar sein. Umgekehrt kann ein kurzer Bericht alle Angaben für eine sichere Weiterleitung enthalten, obwohl die fachliche Prüfung später weitere Informationen verlangt.

Erstelle einen kleinen Datenvertrag

Ein Datenvertrag beschreibt hier die vereinbarte Bedeutung, Herkunft und Prüfung der Eingaben. Der Begriff bezeichnet in diesem Artikel eine interne Arbeitsvereinbarung, keinen juristischen Vertrag. Die folgende Tabelle ist ein eigenes Muster für den fiktiven Serviceprozess.

Jede Zeile braucht zusätzlich ein Verhalten bei fehlender oder widersprüchlicher Angabe. Dieses Verhalten gehört zur Umsetzung, nicht in eine spätere Fehlerliste. Für die Vorgangskennung lautet es im Beispiel: keine automatische Zuordnung, Übergabe zur Klärung. Für einen ungültigen Dokumenttyp: keine Verarbeitung in diesem Ablauf, dokumentierte Weiterleitung nach der vereinbarten Regel.

Unterscheide fehlend, ungültig und unbekannt

Ein leeres Feld ist nicht dasselbe wie ein ungültiger Wert. Eine nicht erreichbare Quelle ist ebenfalls ein anderer Zustand. Wenn das Fachsystem gerade nicht antwortet, ist der Vorgangsstatus unbekannt. Er darf nicht als offen, geschlossen oder nicht vorhanden gespeichert werden, nur damit die Verarbeitung weiterläuft.

Definiere deshalb Zustände, die den tatsächlichen Befund erhalten. "Nicht angegeben" beschreibt die Eingabe. "Format ungültig" beschreibt eine Prüfung. "Quelle nicht erreichbar" beschreibt einen technischen Zugriff. Diese Angaben führen zu verschiedenen nächsten Schritten. Ein Sammelstatus "Fehler" reicht für eine handlungsfähige Ausnahmebearbeitung meist nicht.

Auch ein Wert null oder nullähnlicher Text muss fachlich erklärt sein. Bedeutet er keine Menge, nicht gemessen oder nicht anwendbar? Ohne diese Bedeutung kann eine Berechnung falsche Ergebnisse liefern. Der Artikel CSV-Importe mit KI vorbereiten ergänzt die praktische Behandlung solcher Werte beim Datenübergang.

Prüfe Herkunft und Aktualität gemeinsam

Ein Wert kann formal gültig und trotzdem veraltet sein. Für eine Aktion im Fachsystem muss deshalb feststehen, welche Quelle den aktuellen Zustand liefert. Ein Status aus einem gestern exportierten Bericht ist nicht automatisch geeignet, heute eine Freigabe auszulösen. Die erlaubte Aktualität hängt von der konkreten Entscheidung ab.

Notiere pro Feld das führende System und den Zeitpunkt der Abfrage. Wenn mehrere Quellen unterschiedliche Werte liefern, braucht der Prozess eine fachlich festgelegte Vorrangregel oder eine Klärung. Das Modell darf nicht die plausibelste Angabe auswählen und die Abweichung verschweigen. Ein Quellenkonflikt ist Teil des Ergebnisses.

Für Angaben aus Freitext muss zudem erkennbar bleiben, ob sie direkt übernommen oder abgeleitet wurden. Ein ausdrücklich genanntes Datum ist etwas anderes als die Interpretation "nächste Woche". Wenn eine relative Zeitangabe in ein Datum umgerechnet wird, müssen Bezugszeitpunkt und Regel feststehen. Fehlen sie, bleibt die Angabe offen.

Eine kleine Stichprobe zeigt konkrete Lücken

Im fiktiven Beispiel prüft das Team dreissig kürzlich bearbeitete Berichte. Vier enthalten keine eindeutige Vorgangskennung. Zwei weitere haben eine Kennung, die nicht zum vorgesehenen Bereich passt. Alle sechs Fälle brauchen vor der automatischen Zuordnung eine Klärung. Die übrigen vierundzwanzig bestehen nur diese Zuordnungsprüfung; ihre fachliche Richtigkeit ist damit noch nicht bestätigt.

Sechs von dreissig entsprechen zwanzig Prozent in dieser Stichprobe. Diese Zahl ist kein allgemeiner Fehleranteil des Unternehmens. Die Auswahl kann bestimmte Eingangskanäle oder Zeiträume überbetonen. Dokumentiere deshalb, welche Fälle untersucht wurden und welche fehlen. Eine kleine Stichprobe ist ein Diagnosewerkzeug, kein Ersatz für eine belastbare Verteilung über den späteren Einsatzbereich.

Untersuche die sechs Fälle einzeln. Fehlt die Kennung bereits beim Absender? Geht sie beim Export verloren? Verwendet ein Team ein anderes Format? Die passende Verbesserung hängt von dieser Ursache ab. Ein zusätzlicher KI-Schritt ist nicht automatisch die richtige Antwort auf ein unvollständiges Eingabeformular.

Repariere Daten möglichst an ihrer Entstehung

Wenn eine Information regelmässig fehlt, prüfe den Ursprung. Ein klares Formularfeld, eine automatische Übernahme aus dem Vorgang oder eine bessere Übergabe kann die Lücke direkt vermeiden. Eine spätere Vermutung aus Freitext bleibt dagegen mit Unsicherheit verbunden. Diese Unsicherheit muss dann dauerhaft geprüft werden.

Nicht jede Lücke lässt sich sofort am Ursprung schliessen. Für externe Dokumente kann eine manuelle Zuordnung nötig bleiben. Plane diesen Weg als reguläre Ausnahme ein und messe seinen Aufwand. Ein Prozess mit kontrollierten Ausnahmen kann sinnvoll sein. Ein Prozess, der Ausnahmen still als erfolgreiche Zuordnungen zählt, liefert dagegen ein falsches Bild seiner Leistung.

Die Behandlung solcher Fälle ergänzt Prüfwarteschlangen für Ausnahmen. Massgeblich für die Gestaltung ist, dass die zuständige Person die fehlende Information tatsächlich beschaffen kann. Eine Warteschlange ohne Zugriff auf die nötige Quelle verlagert den Stillstand nur an einen anderen Ort.

Teste den Datenvertrag vor der Automatisierung

Baue Testfälle für vollständige Eingaben, fehlende Pflichtangaben und widersprüchliche Werte. Ergänze doppelte Dokumente, korrigierte Fassungen und einen Ausfall des führenden Systems. Für jeden Fall muss vorab feststehen, ob die Verarbeitung weiterläuft, wartet oder zur Klärung geht. Ein Test besteht nur, wenn auch der richtige Zustand dokumentiert wird.

Prüfe die tatsächliche Wirkung im Zielsystem mit einem freigegebenen Testaufbau. Eine akzeptierte Eingabe beweist nicht, dass sie dem richtigen Vorgang zugeordnet wurde. Kontrolliere den erzeugten Datensatz und seine Herkunft. Bei Entwürfen bleibt die Schreibaktion gesperrt, bis die vorgesehene Freigabe erfolgt. Freigabegrenzen vor ERP-Einträgen beschreibt diese Trennung ausführlicher.

Halte ausserdem fest, welche Fälle nicht geprüft wurden. Wenn nur ein Eingangskanal getestet ist, gilt die Abnahme zunächst für diesen Kanal. Andere Dokumenttypen oder Sprachen benötigen passende Fälle. Diese Begrenzung ist Teil einer ehrlichen Freigabe und verhindert, dass ein kleiner Versuch als vollständige Datenreife ausgegeben wird.

Prüfe Zeitangaben auf ihren tatsächlichen Zweck

Ein Erstellungsdatum, ein Eingangszeitpunkt und ein Freigabezeitpunkt beschreiben unterschiedliche Ereignisse. Für eine Durchlaufzeit muss feststehen, welche beiden Ereignisse verglichen werden. Wenn ein Dokument nachträglich hochgeladen wird, ist sein Dateidatum kein verlässlicher Ersatz für den ursprünglichen Eingang. Die Berechnung muss diese Lücke sichtbar lassen.

Prüfe ausserdem Zeitzonen und die Reihenfolge von Ereignissen. Ein scheinbar negativer Zeitraum kann aus uneinheitlichen Zeitangaben entstehen. Er darf nicht still auf null gesetzt werden. Kläre die Ursache und dokumentiere die Korrekturregel. Ohne belastbare Zeitbasis ist die betreffende Kennzahl nicht prüfbar.

Für eine reine Zuordnung kann dieser Mangel unerheblich sein, während er eine Friststeuerung blockiert. Genau deshalb wird Datenreife pro Entscheidung bewertet. Ein Prozess ist nicht pauschal datenreif oder unreif. Die konkrete Aktion bestimmt, welche Information vorhanden, aktuell und überprüfbar sein muss.

Wann der Prozess bereit für den nächsten Schritt ist

Der Datencheck ist abgeschlossen, wenn die für die konkrete Aktion nötigen Angaben definiert, ihre Quellen erreichbar und die Fehlerwege geprüft sind. Fehlende Daten erhalten einen ausführbaren Klärungsweg. Die verantwortliche Person bestätigt die fachlichen Regeln. Der technische Nachweis zeigt, dass Eingaben tatsächlich zum richtigen Zustand im Zielsystem führen.

Wenn diese Voraussetzungen fehlen, lautet das Ergebnis nicht pauschal "Automation unmöglich". Benenne die konkrete Lücke: etwa uneindeutige Vorgangszuordnung oder fehlende aktuelle Statusabfrage. Daraus entsteht ein begrenzter Verbesserungsauftrag. Erst nach dessen Prüfung wird entschieden, welchen Teil des Ablaufs die Automation zuverlässig übernehmen kann.