KI-ERP versus klassisches ERP: Was unterscheidet die beiden wirklich, und spielt das eine Rolle?

Jeder ERP-Anbieter verkauft derzeit KI: etablierte Suiten, Mittelstandsanbieter, branchenspezifische Nischenlösungen. Alle haben dazu Banner auf der Startseite, Demo-Skripte und Keynotes auf Konferenzen. Fast nichts davon sagt Ihnen, ob die Software tatsächlich etwas anders macht.

Worauf es ankommt: Was passiert an einem Freitagnachmittag, wenn eine vor drei Monaten gebuchte Lieferantenlieferung einen Monat zu spät eintrifft und die Produktion blockiert, sofern niemand eingreift? Die meisten „KI-ERP"-Demos verändern bei genauem Hinsehen genau diesen Moment nicht.

Wenn ein Hersteller also fragt, was ein KI-natives ERP wirklich von einem klassischen unterscheidet, muss die Antwort die Marketingebene überspringen und an die Architektur heranführen. Zwei Systeme können beide KI-Fähigkeiten beanspruchen und strukturell trotzdem fast nichts gemeinsam haben.

Diese Lücke entscheidet darüber, ob die Implementierung Wochen oder Jahre dauert, ob Ihr Team die tägliche Arbeit erledigt oder beaufsichtigt und ob Ihre Betriebskosten mit dem Wachstum steigen oder sinken. Wer in diesem Jahr ein System auswählt, sollte diese Lücke genau verstehen.

Was „KI-ERP" 2026 in der Regel bedeutet

Bei den meisten etablierten ERP-Anbietern besteht das KI-Narrativ heute aus einer Kombination von drei Elementen, die oft übereinandergestapelt werden:

1. Ein Chatbot, mit dem Sie fragen können „Wie viele Artikel haben wir letzten Monat versandt?", anstatt sich durch drei Menüs zu klicken.
2. Claude Code in ein Modul eines etablierten Open-Source-ERPs einbinden und dann erklären, man sei „ein KI-natives ERP".
3. Einen MCP-Server auf eine (kaputte) API aufsetzen.

All diese Funktionen haben einen gewissen praktischen Nutzen. Sie sind aber auch oberflächliche Veränderungen, die das darunterliegende System nicht berühren.

Das ERP bleibt das starre, schemagetriebene System, das es immer war: Jede Geschäftsregel, jeder Workflow, jede kundenspezifische Ausnahme ist in Feldern modelliert, die vor Jahren definiert wurden und sich nur mühsam ändern lassen. Die KI-Schicht ist wie eine cleverere Empfangskraft, aber die Prozesse und Dateisysteme haben sich nicht verändert.

Keine noch so ausgefeilte KI-Schicht kann ein Datenmodell ausgleichen, das vor der Existenz großer Sprachmodelle (LLMs) entworfen wurde und auf der Annahme beruht, dass jede kundenspezifische Regel als individuelles Entwicklungsprojekt von Hand modelliert werden muss.

Wenn der Arbeitstag Ihres Teams nach dem Muster „Bildschirm prüfen, Anweisung befolgen, klicken, wiederholen" abläuft, ändert ein Chatbot vor allem die Eingabemethode. Die eigentliche operative Arbeit, also Entscheiden, Priorisieren, Abgleichen und Nachfassen, ruht weiterhin auf denselben Schultern wie zuvor.

Was ein KI-natives ERP tatsächlich ist

KI-native ERPs unterscheiden sich im Fundament, nicht im Funktionsvergleich. Der eigentliche Unterschied liegt in der Architektur, und diese bestimmt, was das System jemals für Sie werden kann. Die relevanten Fragen zur Architektur lassen sich auf drei Punkte zurückführen.

Das System schlägt den nächsten Zustand vor und handelt

Ein klassisches ERP erfasst alles, was bereits geschehen ist: die erteilten Aufträge, die eingegangenen Teile, die versandten Produkte. Den nächsten Zustand, also den nächsten zu versendenden Kundenauftrag, die nächste auszustellende Bestellung, den nächsten zu startenden Produktionslauf, muss der Mensch ermitteln und einpflegen.

Ein KI-natives ERP führt dieselbe Historie, bereitet aber zugleich den nächsten Zustand vor und führt ihn aus, nachdem der Mensch ihn dort prüft, wo es darauf ankommt:

• Fertigungsaufträge werden automatisch auf Basis der Vertriebspipeline, der Haltbarkeit und der Kühllagerkapazität erstellt.
• Dieselbe Logik erstellt Beschaffungspläne aus eingehenden Aufträgen und Lieferanten-Lead-Times und baut Produktionspläne fortlaufend rund um Restriktionen neu auf, die das System mit der Zeit gelernt hat.
• Für Kundenaufträge, die unbeantwortet liegen geblieben sind, werden Nachfass-E-Mails verfasst und zur Freigabe in die Warteschlange gestellt.

Die Aufgabe des Teams verschiebt sich vom Erzeugen des nächsten Zustands hin zum Prüfen dessen, was das System vorschlägt, und zum Eingreifen bei Ausnahmen.

Sie können das in der Praxis bei L'Atelier du Ferment sehen, wo Bonx Fertigungsaufträge auf Basis von Absatzprognosen, Haltbarkeit und Kühllagerkapazität erstellt. Da L'Atelier du Ferment Lebensmittel mit engen Haltbarkeits- und Kühllagerrestriktionen produziert, kann die Planungsmathematik unbarmherzig sein. Mit Bonx kann das Team das freigeben, was herauskommt, und eingreifen, wenn etwas nicht stimmt.

Die Rolle des Teams verlagert sich vom Bedienen zum Überwachen

Klassische ERPs verlangen Ihrem Team mit der Zeit immer mehr Arbeit ab. Stammdaten driften und müssen bereinigt werden, Prozesse entwickeln sich weiter und müssen neu dokumentiert werden, neue SKUs benötigen frisch konfigurierte Arbeitspläne, die per Hand angelegt werden. Das System wird mit jedem Jahr Nutzung schwerer, und die Wartungskosten steigen stillschweigend.

KI-native ERPs gehen den umgekehrten Weg. Sie lernen die Muster Ihres Unternehmens, übernehmen mehr von der täglichen Routine und überlassen dem Team die Ermessensentscheidungen:

• Vertriebsleiter geben keine Aufträge mehr ein, sondern geben Stapel frei, die das System vorbereitet hat.
• Einkaufsleiter erteilen keine Bestellungen mehr, sondern bearbeiten die Eskalationen, die die Agenten nicht selbst lösen konnten.
• Produktionsplaner pflegen keine Tabelle mehr, sondern legen die Parameter fest, anhand derer ein Agent kontinuierlich plant.

Der Abstand wächst mit der Zeit. Im dritten Jahr ist es der Unterschied zwischen 25 Personen im Operations-Team und 12 Personen für dasselbe Volumen.

Was ein KI-ERP braucht, um wirklich zu funktionieren

Das Datenmodell ist hybrid, nicht zu 100 % ein starres Schema

Klassische ERPs speichern alles in vordefinierten Datenschemata. Das funktioniert bei Themen wie Bestandsbewegungen, Stücklisten und Rückverfolgbarkeit gut, wo das Schema weitgehend universell ist und sich in rechnerischer Präzision auszahlt.

Bei den 10 bis 30 % der operativen Daten, die kundenspezifisch oder schnelllebig sind, scheitert das Modell jedoch: Preisregeln mit regionalen Ausnahmen, Arbeitsplanlogik, die davon abhängt, welche Fertigungszelle online ist, Beschaffungsregeln, die je nach Lieferant und Materialqualität variieren. Diese Daten passen entweder nicht in das Schema (und wandern in Tabellen ab) oder werden ins Schema hineingezwängt und legen das System auf eine Form fest, die später nur mühsam zu ändern ist.

Bonx löst dieses Problem gezielt mit einer hybriden Architektur:

• Strukturierte Schemata für die Teile des Betriebs, in denen Präzision zählt und Näherungswerte nicht akzeptabel sind: Bestand, MRP, Rückverfolgbarkeit.
• Textbasierte, von LLMs interpretierbare Regeln für die Teile, in denen Starrheit historisch mehr geschadet als genutzt hat: Preisgestaltung, Planungsrestriktionen, kundenspezifische Workflows. Diese Regeln existieren als Text, den das System lesen und auf den es handeln kann, statt als Felder, die ein Berater im Vorfeld modellieren muss.

Diese Hybrid-Architektur ist der architektonische Grund, warum sich in Jahren bemessene Einführungen auf Wochen verkürzen lassen.

Die schnell wachsende Lebensmittelmarke Feroce ist beispielsweise mit Bonx in nur 42 Tagen ohne Betriebsunterbrechung live gegangen, ein Zeitrahmen, der für ein zu 100 % schemagetriebenes System strukturell unmöglich ist.

Es ist auch der Grund, weshalb sich das System nach dem Go-Live ohne Beraterprojekte weiter anpassen lässt: Das meiste, was ein Hersteller im Laufe der Zeit ändern möchte, liegt in der textbasierten Schicht, in der das interne Team eine Regel genauso bearbeiten kann wie ein Dokument.

Macht der Unterschied tatsächlich einen Unterschied?

Die Lücke zwischen KI-nativen und klassischen Architekturen wird vor allem für COOs relevant, die den Betrieb in wachsenden Fertigungsunternehmen ausbauen. Die Mechanik zeigt sich in vier operativen Dimensionen:

Zeit bis zum Nutzen. Das klassische ERP-Vorgehen sieht 12 bis 24 Monate bis zum Go-Live vor, teils länger, wobei ein nennenswerter Anteil der Projekte komplett scheitert. KI-native Einführungen dauern 4 bis 12 Wochen. Wenn Ihr Unternehmen jährlich um 30 % wächst, bedeutet eine 18-monatige Implementierung, dass Sie aus den ursprünglichen Anforderungen herausgewachsen sind, bevor das System überhaupt läuft.

Operative Abdeckung. Die meisten klassischen ERPs decken rund 60 % dessen ab, was ein Hersteller tatsächlich tut. Die übrigen 40 % leben in Tabellen, Nebentools und den Köpfen langjähriger Mitarbeiter. KI-native Systeme nehmen mehr von diesem Long Tail auf, weil das hybride Schema die kundenspezifische Logik aufnehmen kann, die klassische ERPs in Excel gedrängt haben. Die Abdeckung steigt in der Regel auf über 90 %, was weniger Excel-Dateien bedeutet, die den Betrieb zusammenhalten, und weniger Stellen, an denen etwas durchrutschen kann.

Teamkapazität. Wenn die Software die Routine übernimmt, bewältigt dasselbe Team mehr Geschäft. Das Zwei- bis Vierfache des Volumens bei gleicher Mitarbeiterzahl ist die strukturelle Folge davon, operative Entscheidungen aus menschlicher Hand in die Software zu verlagern. Mitarbeiter wechseln in eine Überwachungsrolle: Stapel prüfen, Ausnahmen freigeben, Regeln nachjustieren. Ein klassisches ERP kann diesen Effekt nicht reproduzieren, weil es darauf ausgelegt war, dass der Mensch der Motor ist und nicht die Aufsicht.

Langfristige Wirkung. Ein klassisches ERP entwickelt im Laufe der Zeit eine Drift gegenüber der Realität des Unternehmens. Ein KI-natives ERP, das sich aus vergangenen Ausführungen selbst korrigiert und selbst verbessert, kann mit der Realität des Geschäfts im Gleichtakt bleiben.

Wenn keiner dieser Punkte für Ihr Unternehmen eine Rolle spielt, ist die Frage nach KI-ERP versus klassischem ERP eine Marketingunterscheidung. Für alle anderen, besonders wenn Sie den Betrieb ausbauen wollen, ohne die Mitarbeiterzahl mitwachsen zu lassen, in einem Markt, der ständig mehr Individualisierung und schnellere Lieferung erwartet, ist die Unterscheidung operativ und substanziell.

Woran Sie beides bei der Evaluierung erkennen

Ein paar Fragen schneiden in jeder Demo durch das Marketing hindurch.

Wer konfiguriert das System während und nach dem Go-Live? Wenn die Antwort lautet „Wir schicken unser Team für ein Konfigurationsprojekt", haben Sie ein klassisches ERP vor sich. KI-native Systeme legen das Steuer in die Hand Ihres internen Teams.

Was tut das System tatsächlich aus eigenem Antrieb? Antworten wie „Es benachrichtigt Sie" und „Es schlägt vor" stammen aus Systems of Record. Systems of Action verwenden Verben wie „Es erstellt", „Es plant ein", „Es verfasst". Die Arbeit ist erledigt, bevor der Mensch sie freigibt.

Wie lange dauert die Implementierung? Ein Angebot mit 12 bis 18 Monaten verkauft ein ERP aus dem Jahr 2010 mit einer Marketingschicht von 2026. KI-native Systeme werden in Wochen ausgerollt, weil die Architektur das zulässt. Aufwand und Seniorität im Implementierungsteam sind eine Folge davon.

Wo leben Ihre kundenspezifischen Regeln? „In Konfigurationsfeldern, die die Berater einrichten" ist die Antwort des starren Schemas. „Als Text, den das System liest und auf den es handelt und den das Team selbst bearbeiten kann" ist die Antwort des hybriden Schemas. Die erste Variante macht klassische ERPs schwer veränderbar. Die zweite lässt KI-native Systeme mit Ihnen weiterwachsen.

Wie hoch ist die tatsächliche operative Abdeckung? Fragen Sie den Anbieter, welcher Prozentsatz Ihres Tagesgeschäfts wirklich in seinem System leben wird, im Vergleich zu Tabellen und Nebentools. Anbieter, die diese Frage ehrlich beantworten, sind diejenigen, die eine weitere Prüfung verdienen.

Das größere Bild

In fünf Jahren wird „KI-ERP versus klassisches ERP" so klingen, wie heute „Cloud-ERP versus On-Prem-ERP" klingt. Die Kategorie wird sich entlang dieser Linie nicht mehr lange aufteilen.

Die entscheidende Trennlinie verläuft zwischen Herstellern, die auf Systemen arbeiten, in denen die Software die operative Arbeit erledigt, und Herstellern, deren ERP stillschweigend zum Gerüst geworden ist, während der eigentliche Betrieb in Tabellen und ein paar gut organisierten Slack-Kanälen abläuft. Die erste Gruppe baut ihren Vorsprung Quartal für Quartal aus. Die zweite Gruppe verbringt einen wachsenden Anteil ihrer Zeit damit, Daten zwischen Systemen abzugleichen, die eigentlich miteinander kommunizieren sollten.

Für die meisten COOs wird der Schritt zu KI-nativem Betrieb früher oder später kommen. Die Variable ist der Zeitpunkt. Ein geplanter Schritt jetzt, auf einem Zeitplan Ihrer Wahl, mit einem System, das für diese Architektur gebaut ist, läuft in der Regel besser als ein erzwungener Schritt in drei Jahren, nachdem ein paar wichtige Kunden über Lead Times abgesprungen sind, die der Legacy-Stack nicht stützen konnte.

Wenn Sie am Anfang einer ERP-Evaluierung stehen und einen klareren Blick darauf gewinnen möchten, wie das neue Modell in der Praxis aussieht, zeigen wir es Ihnen gerne.