Klare Regeln für ERP-Änderungen: Stammdaten und Zuständigkeiten bei Auftragsänderungen

Wenn KI-Agenten eigenständig Aufträge in ERP-Systemen ändern, stellt sich die Frage nach Kontrolle und Verantwortung. Klare Zuständigkeiten und verlässliche Prüfmechanismen sind dabei entscheidend. Karl Wibbecke von der Deutschen Automatisierungsgesellschaft zeigt, wie Datenherkunft, Versionsprüfung und Freigaben solche Änderungen absichern.

Ein KI-Agent kann eine Kundenmail verstehen und trotzdem den falschen ERP-Auftrag ändern. Entscheidend ist nicht nur, ob Daten plausibel sind. Vor einer Änderung müssen Quelle, Bedeutung, Version und Verantwortung jedes relevanten Feldes feststehen. Ein Demonstrationsprozess zeigt die nötigen Übergaben.

Eine Mail ist noch kein Änderungsauftrag

Im folgenden, abstrahierten Beispiel bittet ein Kunde darum, eine offene Auftragsposition an eine andere Lieferadresse zu senden. Der Agent soll die Nachricht zuordnen und eine Änderung vorbereiten. Es handelt sich um einen Demonstrationsprozess, nicht um ein eingeführtes Produkt oder eine Kundenreferenz. Es werden weder Ergebnisse noch Einsparungen behauptet.

Bereits die Zuordnung braucht feste Regeln: Welche Kundennummer gehört zum Absender? Welche Auftragsnummer ist gemeint? Betrifft der Wunsch alle Positionen oder nur eine? Der Agent darf Lücken nicht mit einer wahrscheinlichen Antwort füllen. Fehlt eine eindeutige Zuordnung, legt er einen Klärungsfall mit den vorhandenen Belegen an. Der ERP-Auftrag bleibt unverändert.

Verantwortung je Feld statt einer gemeinsamen Wahrheit

Für das Beispiel wird eine Zuständigkeitsliste festgelegt. Das ERP führt Auftragsnummer, Positionsstatus und bestätigte Lieferadresse. Ein freigegebener Kundenstamm führt zulässige Anschriften. Die Mail ist der Beleg für den Änderungswunsch, aber keine neue Stammdatenquelle. Ein Ansprechpartner prüft bislang unbekannte Anschriften. Diese Zuordnung ist eine Gestaltungsentscheidung des Beispiels, keine Vorgabe für jedes Unternehmen.

Wichtig ist die Trennung zwischen Stammdaten und Belegdaten. Eine abweichende Anschrift in genau einem Auftrag rechtfertigt nicht automatisch, den Kundenstamm dauerhaft umzuschreiben. Der Agent erzeugt deshalb einen Vorschlag für die konkrete Position. Änderungen an Stammdaten folgen einem eigenen, ausdrücklich freigegebenen Ablauf. Gleiche Feldnamen dürfen diese Grenze nicht verdecken.

Den Ausgangsstand bis zur Übernahme mitführen

Mit dem Vorschlag werden die gelesene Auftragsversion, die betroffene Position, die bisherige und die gewünschte Anschrift sowie die Herkunft der Angaben gespeichert. Am ERP-Schreibpunkt müssen Versionsprüfung und Übernahme gegen konkurrierende Änderungen abgesichert zusammen erfolgen. Die Position muss noch offen sein und zur freigegebenen Ausgangsversion passen. Unterstützt die Schnittstelle keinen solchen bedingten Übergang, bleibt die Übernahme manuell. Ein inzwischen gestarteter Versand beendet den automatischen Weg.

Eine Freigabe gilt nur für diesen Änderungsumfang und diesen Ausgangsstand. Ändert ein Mitarbeiter zwischenzeitlich die Position, wird die alte Freigabe nicht auf den neuen Stand übertragen. Der Vorschlag geht zurück in die Prüfung. Ein technischer Zugriff auf das ERP ersetzt weder diese fachliche Berechtigung noch die Prüfung des Prozesszustands.

Vorschlag und Ausführung getrennt freigeben

Der Agent liefert einen strukturierten Entwurf: Objekt, Felder, alter Stand, gewünschter Stand, Beleg und offene Konflikte. Die Freigabeansicht zeigt diese Differenz, nicht nur eine sprachliche Zusammenfassung. Die zuständige Person kann genau die Anschriftenänderung genehmigen oder ablehnen. Andere Felder, insbesondere Preis und Menge, bleiben außerhalb des Auftrags.

Die Ausführung übernimmt eine eng begrenzte Schnittstellenfunktion. Sie akzeptiert nur die festgelegten Felder und verlangt eine einmalige Änderungskennung. Nach einem Verbindungsabbruch wird zuerst geprüft, ob diese Kennung bereits verarbeitet wurde. Ein fehlendes Antwortsignal darf nicht ungeprüft eine zweite Änderung auslösen. Bleibt das Ergebnis unklar, übernimmt ein Mensch die Statusklärung.

Ein Prüfraster für den nächsten Übergang

Vor der Inbetriebnahme lässt sich die Kette mit gezielten Gegenbeispielen prüfen: eine doppelte Auftragsnummer im Mailtext, eine unbekannte Anschrift, eine bereits versandte Position und eine Änderung nach der Freigabe. Jeder Fall braucht ein erwartetes Ergebnis: stoppen, zur Klärung vorlegen oder die geprüfte Änderung einmalig übernehmen. Eine überzeugend formulierte Agentenantwort ist kein Abnahmekriterium.

Das Protokoll verknüpft Beleg, Datenherkunft, gelesene Version, Vorschlag, Freigabe und tatsächliches Ergebnis. Zuständigkeit und nächster Schritt bleiben auch im Ausnahmefall sichtbar. Der praktische Einstieg ist deshalb eine einzelne, klar abgegrenzte Auftragsänderung. Erst wenn ihre Quellen und Übergaben eindeutig sind, lässt sich verantwortlich entscheiden, welche weiteren Felder überhaupt automatisiert werden sollen.

---