Brauchen wir noch ERP, wenn KI die Arbeit übernimmt?
Eine KI kann Bestellungen verstehen, Rückfragen klären und Vorgänge anstoßen. Ein Unternehmen muss zugleich wissen, was es zugesagt, geliefert und berechnet hat. Wie Unternehmen diese Aufgaben künftig verbinden, entscheidet über den Wert der Software.
Zehn Stück sind verfügbar. Ein Kunde bestellt sieben, ein anderer sechs. Beide Bestellungen treffen fast gleichzeitig ein. Ein KI-Agent liest die erste Nachricht, prüft den Bestand und findet genug Ware. Ein zweiter Agent kommt bei der anderen Bestellung zum gleichen Ergebnis. Jede Anfrage für sich lässt sich erfüllen. Zusammen fehlen drei Stück.
Das Problem entsteht auch dann, wenn beide Agenten jede Nachricht richtig verstanden und fehlerfrei gerechnet haben. Zwischen dem Lesen eines Bestands und dem Reservieren der Ware kann ein anderer Vorgang denselben Bestand verändern. Das Unternehmen braucht einen Mechanismus, der konkurrierende Zugriffe koordiniert und seine Lieferregeln durchsetzt.
An diesem alltäglichen Lagerfall lässt sich die Frage nach der Zukunft von ERP genauer stellen. Unternehmen werden weiterhin verlässliche Geschäftsfunktionen brauchen. Offen ist, wie viel davon künftig in einem großen Softwarepaket steckt und wie Menschen und KI darauf zugreifen.
Ein Auftrag verbindet mehrere Abteilungen
ERP steht für Enterprise Resource Planning. Der betriebliche Gedanke dahinter ist die Verbindung zusammengehöriger Prozesse: Einkauf, Bestand, Verkauf, Produktion und Finanzen arbeiten mit aufeinander abgestimmten Daten. Aus einer Bestellung entsteht ein Vorgang, dessen Folgen durch das Unternehmen reichen. Diese Verbindung erklärt unsere grundlegende ERP-Definition.
Ein Auftrag braucht einen eindeutig bestimmten Kunden, die richtigen Artikel, Mengen und Preise. Für die Lieferung muss Ware verfügbar sein. Eine Reservierung verändert, was anderen Kunden zugesagt werden kann. Später müssen Lieferung, Rechnung und Zahlung zueinander passen. Eine Retoure kann erneut Bestand schaffen, zunächst eine Prüfung erfordern oder zu einer Gutschrift führen.
Die Zahl im Lager ist deshalb nur ein Ausschnitt. Ware kann bereits reserviert sein, einem anderen Eigentümer gehören oder wegen ihres Zustands gesperrt sein. Lagerort, Charge und Seriennummer können darüber entscheiden, welche Stücke tatsächlich verwendet werden dürfen. Die Bestandsverwaltung muss solche Zuordnungen und die Verbindung zu Aufträgen und Finanzbuchungen abbilden.
Eine Datenbank kann diese Informationen speichern. Was sie bedeuten und welche Änderung zulässig ist, muss fachlich festgelegt und in Software umgesetzt werden. Auch die beste Datenhaltung korrigiert keine Entnahme, die niemand erfasst hat. Im System steht der gebuchte betriebliche Zustand. Wie gut dieser zur Wirklichkeit passt, hängt ebenso von Erfassung, Prüfungen und Arbeitsabläufen ab.
Was bei den zehn Stück passieren muss
Im Lagerbeispiel soll gelten: Es wird ausschließlich vorhandene Ware reserviert, Überverkäufe sind ausgeschlossen. Dann müssen Prüfung und Reservierung so zusammenwirken, dass die beiden Aufträge nicht gemeinsam dreizehn Stück belegen können. Geht die Reservierung über sieben Stück zuerst durch, bleiben für den anderen Auftrag drei. Ob der Kunde eine Teillieferung erhält, auf Nachschub wartet oder eine Absage bekommt, entscheidet die Geschäftsregel.
Für die technische Umsetzung gibt es unterschiedliche Verfahren. Datenbanken können beispielsweise konkurrierende Zugriffe sperren oder Konflikte erkennen und eine Transaktion abbrechen. Welches Verfahren passt, hängt von Anwendung und Datenmodell ab. Die Dokumentation zur Transaktionsisolation erklärt diese Unterschiede. Ein bloßes Abfragen vor dem Schreiben genügt als Schutz nicht.
Zusammengehörige Änderungen müssen außerdem innerhalb einer entsprechend angelegten Datenbanktransaktion vollständig gelingen oder zurückgenommen werden können. Sonst könnte eine Umlagerung am ersten Lagerort als Abgang erscheinen, ohne am zweiten als Zugang anzukommen. Bestätigte Transaktionen müssen dauerhaft gespeichert bleiben. Das sind Eigenschaften transaktionaler Datenhaltung, die eine Anwendung gezielt nutzen muss.
Auch eine technisch sauber ausgeführte Transaktion kann fachlich falsch sein. Wenn die Software eine gesperrte Charge freigibt oder Stück mit Kartons verwechselt, speichert die Datenbank möglicherweise genau diesen Fehler zuverlässig. Die Software muss fachliche Regeln korrekt umsetzen und die geeigneten Datenbankmechanismen nutzen. Ein vorhandenes ERP verdient deshalb dieselbe kritische Prüfung wie eine neu entwickelte Lösung.
KI umfasst unterschiedliche Aufgaben
Die Frage „KI oder ERP?“ vergleicht eine Gruppe technischer Verfahren mit einer Kategorie von Unternehmenssoftware. Ein Sprachmodell ist dabei eine mögliche Komponente. KI kann auch für Prognosen, Bilderkennung oder die Erkennung ungewöhnlicher Vorgänge eingesetzt werden.
Das macht im Lager einen erheblichen Unterschied. Eine Absatzprognose schätzt einen unsicheren zukünftigen Bedarf. Eine Reservierung legt fest, welche heute verfügbare Menge einem Auftrag zugeordnet wird. Die Prognose darf mit Wahrscheinlichkeiten und Fehlermaßen arbeiten. Die Reservierung muss die festgelegte Bestandsregel einhalten. Bedarfsprognosen können etwa historische Transaktionen und Zeitreihenverfahren nutzen. Dafür muss kein Sprachmodell die Bestände berechnen.
Ein LLM kann wiederum dort helfen, wo ein Kunde keine sauber ausgefüllte Bestellmaske liefert. In seiner E-Mail steht vielleicht: „Noch einmal wie im Frühjahr, aber die kleinere Ausführung und diesmal an die Baustelle.“ Daraus müssen Artikel, Menge und Lieferadresse werden. Vielleicht lässt sich die frühere Bestellung eindeutig finden. Vielleicht bleiben zwei Ausführungen möglich. Dann braucht der Vorgang eine Rückfrage.
Der mögliche Nutzen liegt in der Bearbeitung dieser Unklarheit und in der Verbindung zur anschließenden Arbeit. Wie gut das gelingt, muss sich am tatsächlichen Bestelleingang zeigen. Eine überzeugende Vorführung mit ausgewählten Nachrichten sagt noch wenig über mehrdeutige Artikelbezeichnungen oder unvollständige Lieferadressen aus.
Ein Agent kann den ganzen Vorgang führen
Mit Zugriff auf passende Funktionen kann ein KI-Agent die frühere Bestellung suchen, eine Variante vorschlagen, eine Rückfrage vorbereiten und nach Klärung den Auftrag anlegen. Dafür muss nicht nach jedem Schritt ein Mensch auf eine Schaltfläche drücken. Welche Vorgänge automatisch laufen dürfen, hängt von den eingeräumten Rechten und den festgelegten Freigaben ab.
Der Ablauf lässt sich in vier Aufgaben zerlegen: die Kundenabsicht verstehen, daraus einen konkreten Auftrag vorbereiten, dessen Zulässigkeit prüfen und ihn verbindlich ausführen. Der Agent kann durch diese Aufgaben führen und auf Ergebnisse reagieren. Die Funktionen für Reservierung und Buchung müssen bei jedem Aufruf ihre Bedingungen durchsetzen. Diese Aufteilung ist eine Architekturentscheidung. Die Unterscheidung zwischen festen Workflows und Agenten mit selbst gesteuerter Werkzeugnutzung hilft, den möglichen Automatisierungsgrad genauer zu beschreiben.
Dabei reichen sprachliche Anweisungen als Kontrolle nicht aus. Eine Aufforderung wie „Gib keine Zahlungen frei“ im Prompt entzieht dem Agenten keine Zahlungsberechtigung. Wenn er diese Funktion für seine Aufgabe nicht braucht, sollte die technische Zugriffskontrolle sie ihm verweigern. Die Trennung von Lieferantenpflege, Warenannahme und Zahlung ist ein Beispiel für getrennte Rollen und Aufgaben.
Hinzu kommt ein Risiko des neuen Eingangswegs: Eine E-Mail oder ein Anhang kann manipulierte Anweisungen enthalten, die den Agenten zu unerwünschten Aktionen bewegen sollen. OWASP beschreibt dieses Problem als Prompt Injection. Begrenzte Rechte und die technische Prüfung zulässiger Aktionen begrenzen mögliche Folgen. Das Unternehmen muss festlegen, welche Vorgänge eine menschliche Freigabe benötigen.
Verlässliche Anbindungen brauchen zudem eine Antwort auf einen unscheinbaren Betriebsfall: Der Agent sendet eine Buchung, die Verbindung bricht ab, die Bestätigung fehlt. Er weiß nun nicht, ob der Auftrag angelegt wurde. Ein erneuter Aufruf darf keinen zweiten Auftrag erzeugen. Wiederholungen müssen deshalb über eine eindeutige Vorgangskennung oder ein gleichwertiges Verfahren erkannt und passend behandelt werden. Dieses Prinzip heißt Idempotenz; die verlinkte Schnittstellendokumentation zeigt eine konkrete Umsetzung. Für die jeweilige Unternehmenssoftware muss sie eigens gewährleistet sein.
Das Softwarepaket steht zur Disposition
Aus dem Bedarf an solchen Funktionen folgt keine Bestandsgarantie für ein heutiges ERP-Produkt. Buchhaltung, Auftragsverwaltung, Lager und Planung können in einer Suite zusammenarbeiten oder auf mehrere spezialisierte Anwendungen verteilt sein. Auch innerhalb eines ERP-Pakets gibt es unterschiedliche Module und ergänzende Dienste. Die Grenze zwischen einem großen System und einer verbundenen Anwendungslandschaft ist in der Praxis beweglich.
Ein Dienstleistungsbetrieb braucht möglicherweise Projektabrechnung und Buchhaltung, aber keine Materialplanung. Ein Hersteller muss Stücklisten, Fertigungsaufträge und Bestände aufeinander abstimmen. Welcher Zuschnitt wirtschaftlich passt, ergibt sich aus diesen Aufgaben. Die bloße Verfügbarkeit eines Sprachmodells beantwortet die Frage nicht.
Verteilte Anwendungen schaffen eigene Arbeit. Gelingt die Reservierung im Lagersystem, während die Auftragsanlage in einer anderen Anwendung scheitert, muss der Vorgang weitergeführt oder die Reservierung gezielt aufgehoben werden. Dafür braucht es erkennbare Zustände, Fehlerbehandlung und Zuständigkeiten. Verfahren wie Sagas für verteilte Transaktionen koordinieren lokale Änderungen und gegebenenfalls ausgleichende Schritte. Eine gemeinsame Datenbanktransaktion über alle beteiligten Systeme kann man nicht einfach voraussetzen.
Ein Agent kann solche Funktionen aufrufen. Der Betrieb muss trotzdem wissen, was nach einem Fehler bereits geschehen ist. Mit jeder ausgelagerten Funktion entsteht deshalb auch die Frage, wer die Übergaben und Fehlerbehandlung verantwortet. Ein niedrigerer Preis für einzelne Anwendungen kann durch zusätzlichen Integrations- und Betriebsaufwand aufgezehrt werden. Umgekehrt können spezialisierte Anwendungen einen Arbeitsablauf besser abdecken. Beides muss im konkreten Fall gerechnet werden.
Weniger Masken, andere Abhängigkeiten
Wenn Agenten mehr Bedienarbeit übernehmen, könnte die vertraute ERP-Oberfläche für manche Aufgaben an Bedeutung verlieren. Der Sachbearbeiter müsste dann seltener zwischen Masken wechseln oder Angaben von einer Nachricht in mehrere Felder übertragen. Wie weit dieser Wandel reicht, ist offen. Er setzt voraus, dass Agenten die Arbeit zuverlässig ausführen und Menschen die relevanten Entscheidungen und Ausnahmen weiterhin überblicken können.
Für die Softwareauswahl gewinnt damit eine praktische Frage an Gewicht: Welche Geschäftsvorgänge lassen sich von außen kontrolliert ausführen? Eine Schnittstelle, die nur Daten liest, kann einen Bestand anzeigen. Um Ware zu reservieren, braucht sie eine fachliche Funktion, die Verfügbarkeit prüft, Rechte beachtet und ein eindeutiges Ergebnis liefert. Ein allgemeiner Schreibzugriff auf Tabellen verlagert diese Arbeit zum aufrufenden System.
Auch die Herkunft der KI ist eine eigene Entscheidung. Ein gemeinsamer Anbieter kann die Einbindung erleichtern. Mehrere Anbieter können Möglichkeiten zur Auswahl und zum Wechsel eröffnen. Daraus folgt jeweils zusätzlicher Prüfbedarf: Funktionieren Berechtigungen und Fehlerbehandlung über die gesamte Verbindung? Lassen sich Modell oder Agent austauschen? Welche Kosten entstehen im laufenden Betrieb?
Eine KI-Roadmap beantwortet diese Fragen erst, wenn daraus nutzbare Funktionen mit überprüfbarem Verhalten werden. Für Unternehmen zählt etwa, wie viele eingehende Bestellungen ohne Nacharbeit korrekt erfasst werden, wie lange die verbleibenden Fälle dauern und wie Fehler entdeckt und behoben werden. Modellaufrufe und Lizenzkosten gehören ebenso in die Rechnung wie Kontrolle, Integration und Wartung. Eine pauschale Einsparquote lässt sich daraus nicht ableiten.
Wer die Software baut, übernimmt ihre Pflege
KI kann schließlich bei der Entwicklung einer eigenen Lösung helfen. Damit wird eine weitere Alternative zum gekauften Paket denkbar: Das Unternehmen lässt genau die Funktionen bauen, die es benötigt, und verbindet sie mit vorhandenen Diensten.
Dann übernimmt die entwickelte Software die bisherigen Aufgaben. Sie braucht belastbare Regeln für Reservierungen und Buchungen, eine geeignete Datenhaltung, Tests und einen verantwortlichen Betrieb. Jemand muss Änderungen an Abläufen und Schnittstellen nachziehen und Fehler beheben können. Selbst wenn sich die erste Fassung schneller erstellen lässt, bleiben diese Aufgaben über ihre gesamte Nutzungsdauer bestehen.
Die Frage nach ERP führt damit zu einer wirtschaftlichen Entscheidung über Kauf, Eigenentwicklung und Integration. Unternehmen müssen bestimmen, welche Funktionen sie benötigen, wer die Abläufe über alle Anwendungen hinweg gewährleistet und welchen Aufwand sie dafür dauerhaft tragen können. KI verändert die Möglichkeiten, diese Arbeit zu organisieren.
Bei den zehn Stück im Lager bleibt die Anforderung unverändert: Nach zwei gleichzeitigen Bestellungen muss feststehen, welche Mengen welchem Auftrag zugesagt sind. Dafür braucht das Unternehmen eine verlässliche Lösung. Ob auf deren Rechnung künftig noch „ERP“ steht, ist offen.