KI im ERP einführen – vom Zielbild zum produktiven Betrieb

Diese Seite setzt dort an, wo die Grundsatzentscheidung bereits gefallen ist. Ob sich künstliche Intelligenz im ERP überhaupt lohnt, welche Funktionen die Systeme heute beherrschen, wie sie lizenziert werden und welche Pflichten aus der EU-KI-Verordnung folgen, behandelt der Überblick zu künstlicher Intelligenz im ERP. Hier geht es ausschließlich um die Umsetzung: Wie kommt eine beschlossene KI-Initiative von der Zusage im Lenkungskreis zu einem Prozess, der produktiv läuft, geprüft wird und dessen Wirkung sich belegen lässt – oder der begründet wieder abgeschaltet wird.

Der Bedarf an diesem zweiten Schritt ist gut dokumentiert. Der DSAG-Investitionsreport 2026 (Befragung vom 8. Dezember 2025 bis 21. Januar 2026, n = 198, DACH) weist aus, dass 43 Prozent der befragten Anwenderunternehmen KI-Use-Cases umgesetzt haben und 51 Prozent noch keine. Von denen, die umgesetzt haben, betreiben 77 Prozent ihre Anwendungsfälle mit Lösungen außerhalb der ERP-Suite und nur 3 Prozent mit Lösungen des ERP-Herstellers selbst. Die Kennzahlen dieser Seite sind mit Quelle und Erhebungszeitraum im Abschnitt KI im ERP der ERP-Statistiken dokumentiert. Für ein Einführungsprojekt heißt das vor allem eines: Die Lizenz auf dem Angebotsblatt und der produktive Prozess sind zwei getrennte Dinge, und zwischen beiden liegt die Arbeit, um die es im Folgenden geht.

Zielbild statt Funktionsshopping

Das häufigste Muster nach der Grundsatzentscheidung ist der Griff zur Funktionsliste: Der Anbieter zeigt, was der Assistent alles kann, das Projektteam sucht sich daraus die eindrucksvollsten Punkte aus, und die Einführung wird danach geplant, welche Funktion zuerst verfügbar ist. Dieses Vorgehen erzeugt Aktivität, aber kein Ergebnis, weil die Reihenfolge dabei von der Roadmap des Herstellers bestimmt wird und nicht vom eigenen Engpass.

Ein Zielbild dreht die Reihenfolge um. Es beschreibt einen betrieblichen Zustand in 18 bis 24 Monaten und besteht aus vier Bestandteilen: dem Prozessausschnitt, der anders laufen soll; der Veränderung in den Rollen, also wer künftig was nicht mehr und was stattdessen tut; einer Kennzahl, die diesen Zustand abbildet und heute schon erhoben wird; und dem Kontrollmodell, also der Antwort darauf, wie im Zielzustand geprüft wird. Ein Satz wie „Im Rechnungseingang werden Belege wiederkehrender Lieferanten ohne manuelle Kontierung verbucht, die Sachbearbeitung prüft Ausnahmen und Stichproben, die Durchlaufzeit vom Eingang bis zur Buchung sinkt messbar“ erfüllt alle vier Punkte. Ein Satz wie „Wir setzen KI in der Buchhaltung ein“ erfüllt keinen davon.

Genauso wichtig ist die Negativabgrenzung. Ein belastbares Zielbild benennt ausdrücklich, was nicht Gegenstand ist: keine Automatisierung von Einzelfällen ohne Wiederholrate, keine Verarbeitung von Personaldaten in der ersten Ausbaustufe, keine Ausweitung auf weitere Belegarten vor einer Auswertung. Diese Ausschlüsse sind später der Schutz gegen den schleichenden Zuwachs an Anforderungen, der ERP-Projekte auch ohne KI regelmäßig überdehnt – siehe dazu die Checkliste für die ersten 90 Tage.

Process Mining als Vorstufe: erst den Prozess kennen

Automatisierung verstärkt den bestehenden Ablauf, sie verbessert ihn nicht. Wer einen Freigabeprozess automatisiert, in dem 30 Prozent der Vorgänge eine Schleife über eine zweite Abteilung nehmen, automatisiert diese Schleife mit. Deshalb gehört eine Prozessaufnahme vor die Auswahl der Werkzeuge – und zwar auf Basis der tatsächlichen Ereignisdaten, nicht auf Basis von Workshop-Protokollen.

Process Mining rekonstruiert aus den Zeitstempeln der Belege und Vorgänge im ERP den real gelaufenen Prozess: welche Varianten es gibt, wie häufig jede vorkommt, wo Wartezeiten entstehen und an welchen Stellen Vorgänge zurückspringen. Aus dieser Auswertung fallen drei Dinge ab, die im weiteren Verlauf gebraucht werden. Erstens die Varianten­verteilung: Nur wenn ein großer Teil der Vorgänge demselben Pfad folgt, gibt es überhaupt ein Muster, das ein Modell lernen kann. Zweitens die Rework-Quote, also der Anteil der Vorgänge mit Korrektur- oder Rücksprungschritten – oft der eigentliche Kostentreiber und ein Hinweis darauf, dass eine Prozess- oder Stammdatenkorrektur mehr bringt als jede Automatisierung. Drittens die Ausgangsmessung für den späteren Piloten: Durchlaufzeit, Bearbeitungsschritte je Vorgang und Fehlerquote im Ist-Zustand, gemessen und nicht geschätzt.

Wo kein Process-Mining-Werkzeug vorhanden ist, lässt sich ein großer Teil davon aus Standardauswertungen und Belegtabellen ableiten. Entscheidend ist nicht das Tool, sondern dass die Zahlen aus dem System stammen. Eine geschätzte Baseline macht jede spätere Wirkungsmessung angreifbar, weil sich Erfolg dann immer irgendwie herbeirechnen lässt.

Use-Cases bewerten: Wirkung mal Machbarkeit mal Datenverfügbarkeit

Aus der Prozessaufnahme entsteht in der Regel eine Liste von acht bis zwanzig Kandidaten. Sie wird nicht nach Begeisterung sortiert, sondern nach drei Dimensionen, die getrennt bewertet werden. Jede Dimension bekommt einen Wert von 1 bis 5, und die Bewertung stützt sich auf erhobene Werte, nicht auf Einschätzungen aus der Runde.

Dimension	Was konkret bewertet wird	1 Punkt	5 Punkte
Wirkung	Vorgangsmenge pro Jahr mal durchschnittliche Bearbeitungszeit oder Fehlerkosten je Vorgang	Einzelfälle, kein Mengengerüst	hohe Wiederholrate, Aufwand je Vorgang messbar
Machbarkeit	Funktion im lizenzierten Standard verfügbar, keine neue Schnittstelle, Prozess stabil, Verantwortung geklärt	Roadmap-Ankündigung, neue Integration nötig	im Standard enthalten, Prozess und Rollen unverändert
Datenverfügbarkeit	benötigte Felder gepflegt, Historie in passender Form vorhanden, Zugriff rechtlich und technisch geklärt	Daten liegen in Vorsystemen oder unstrukturiert vor	alle Pflichtfelder im ERP, Historie vollständig

Die drei Werte werden multipliziert, nicht addiert. Das ist der wesentliche Punkt: Eine Summe verdeckt Ausfälle, ein Produkt nicht. Ein Anwendungsfall mit hoher Wirkung (5) und guter Machbarkeit (4), dessen Daten aber in einer Nebenanwendung liegen (1), kommt auf 20 – und liegt damit hinter einem unspektakulären Fall mit durchgängig mittlerer Bewertung (3 mal 3 mal 3 = 27). Genau diese Reihenfolge ist richtig, weil der erste Fall zuerst ein Datenprojekt ist und erst danach ein KI-Projekt. Ein Wert von 1 in der Datenverfügbarkeit ist deshalb sinnvollerweise ein Ausschluss für die erste Welle, kein Abzug.

Zwei Zusatzregeln haben sich bewährt. Erstens: Ein Kandidat ohne heute erhobene Kennzahl wird zurückgestellt, bis diese Kennzahl existiert – ohne Ausgangswert ist die spätere Erfolgsmessung wertlos. Zweitens: Bei gleichem Produkt gewinnt der Fall mit der geringeren Fehlerfolge. Ein falscher Prognosewert wird im nächsten Planungslauf korrigiert, eine falsche Kontierung landet im Abschluss.

Datenqualität messbar machen

Der Satz „belastbare Daten sind Voraussetzung“ steht in nahezu jeder Veröffentlichung zum Thema. Eine Kennzahl, an der sich das prüfen ließe, steht dort fast nie. Dabei lassen sich die relevanten Werte aus fast jedem Bestandssystem per Abfrage ziehen, und ohne sie ist die Frage, ob ein Use Case datenseitig tragfähig ist, reine Meinung. Die folgenden fünf Kennzahlen bilden das Minimum. Ein kompakter Selbsttest über alle Projektdimensionen hinweg findet sich im ERP-Readiness-Check; hier geht es um die operative Erhebung.

Kennzahl	Operationale Definition	So wird sie erhoben	Was ein schlechter Wert bedeutet
Dublettenquote je Objektart	Anteil der Kunden-, Lieferanten- und Artikelsätze mit identischer Schlüsselkombination (Name plus Ort, Hersteller plus Herstellernummer, Steuernummer)	Gruppierung über die Schlüsselkombination, Zählung der Gruppen mit mehr als einem Satz, getrennt je Objektart	Zuordnungen werden mehrdeutig; Vorschläge treffen den falschen Satz, ohne dass es auffällt
Vollständigkeitsgrad der Pflichtfelder	Anteil aktiver Sätze, in denen alle Felder gefüllt sind, die der geplante Use Case tatsächlich braucht	Feldliste aus dem Use Case ableiten, dann Nullwert- und Leerstring-Prüfung je Feld	Das Modell arbeitet mit Lücken und ergänzt sie plausibel, aber nicht belegt
Anteil Artikel ohne Klassifizierung	Anteil aktiver Artikel ohne Warengruppe, ohne eCl@ss oder ETIM, ohne Zolltarif- oder Steuerkennzeichen	Zählung je Klassifizierungsmerkmal, getrennt nach Artikeln mit und ohne Bewegung in den letzten zwölf Monaten	Gruppenbezogene Vorschläge und Auswertungen greifen ins Leere
Alter der letzten Stammdatenpflege	Anteil aktiver Stammsätze ohne inhaltliche Änderung in den vergangenen 24 Monaten	Auswertung des Änderungsdatums, bereinigt um rein technische Massenupdates	Das Modell lernt Zustände, die es im Betrieb nicht mehr gibt
Verfügbare Historienlänge je Use Case	Zeitraum und Umfang auswertbarer Bewegungs- beziehungsweise Belegdaten, getrennt erhoben	je Use Case einzeln bestimmen, nicht pauschal für das System	Die Funktion wird lizenziert und geht mangels passender Daten nie produktiv

Die fünfte Kennzahl wird am häufigsten übersprungen, weil „Historie“ je nach Anwendungsfall etwas völlig anderes bedeutet. Eine Absatz- oder Bedarfsprognose braucht mehrere abgeschlossene Saisonzyklen an Bewegungsdaten samt dokumentierten Sondereffekten – ohne die Information, dass ein Absatzeinbruch auf einem Werksstillstand beruhte, lernt das Modell den Einbruch als Saisonmuster. Eine Belegerkennung braucht dagegen keine Zeitreihe, sondern ein Archiv möglichst vieler Belegvarianten der wichtigsten Lieferanten, idealerweise mit den zugehörigen freigegebenen Buchungen als Referenz. Eine Anomalie-Erkennung wiederum braucht vor allem einen ausreichend langen Zeitraum unauffälliger Normalfälle, um überhaupt eine Abweichung definieren zu können.

Für die Erhebung gelten drei Regeln. Erstens werden die Werte je Objektart und je Mandant getrennt ausgewiesen, weil Mittelwerte über den Gesamtbestand die relevanten Ausreißer glätten. Zweitens wird die Messung als wiederholbare Abfrage abgelegt und monatlich erneut ausgeführt, damit aus dem Momentaufnahme-Wert eine Zeitreihe wird. Drittens werden Schwellenwerte vor der Messung festgelegt, nicht danach – wer erst misst und dann entscheidet, was ein akzeptabler Wert ist, bekommt immer einen akzeptablen Wert. Branchenweit verbindliche Normen für diese Schwellen gibt es nicht; sie sind eine Projektfestlegung und gehören ins Protokoll des Lenkungskreises. Grundlagen zur dauerhaften Absicherung liefern Stammdatenpflege und Master Data Management.

Der Pilot-Steckbrief

Ein Pilot ohne schriftlich fixierte Rahmenbedingungen endet regelmäßig als unentscheidbarer Fall: Er lief irgendwie, alle haben eine Meinung, niemand kann belegen, ob das Ziel erreicht wurde. Der folgende Steckbrief passt auf eine Seite und wird vor dem Start abgestimmt und abgezeichnet. Die Beispielspalte zeigt eine Belegerkennung im Rechnungseingang; die Struktur ist auf jeden anderen Anwendungsfall übertragbar.

Feld	Was hineingehört	Beispiel Rechnungseingang
Prozessausschnitt	exakt abgegrenzter Vorgangstyp, benannte Ausschlüsse	Eingangsrechnungen der 20 umsatzstärksten Lieferanten, ohne Gutschriften und Anzahlungen
Dauer	fester Zeitraum mit Start- und Enddatum	zwölf Wochen, davon zwei Wochen Einrichtung
Teamgröße und Rollen	benannte Personen mit Zeitanteil, nicht Abteilungen	eine fachliche Verantwortliche (40 Prozent), zwei Sachbearbeitende (je 20 Prozent), eine IT-Ansprechperson (10 Prozent)
Datenmenge	Zahl der im Pilot verarbeiteten Vorgänge, plus Umfang der Referenzdaten	rund 600 Belege im Zeitraum, Referenzarchiv der letzten 24 Monate
Ausgangsmessung	Ist-Werte der Zielmetrik vor Start, aus dem System erhoben	Durchlaufzeit und manuelle Korrekturquote der vergangenen sechs Monate
Zielmetrik	genau eine führende Kennzahl, dazu höchstens zwei Nebenbedingungen	führend: Anteil ohne manuellen Eingriff verarbeiteter Belege; Nebenbedingung: Fehlerquote steigt nicht
Erfolgsschwelle	Zahlenwert, ab dem skaliert wird, mit Stichtag	vorab festgelegter Zielwert der führenden Kennzahl, gemessen in Woche 12
Abbruchkriterium	Zahlenwert oder Ereignis, bei dem sofort gestoppt wird	Überschreiten der vereinbarten Fehlerquote in zwei aufeinanderfolgenden Wochen oder ein nicht rekonstruierbarer Buchungsvorschlag
Kontrollmodus	wie geprüft wird, solange der Pilot läuft	vollständige Nachprüfung in Woche 1 bis 4, danach feste Stichprobenquote
Entscheidung	Termin, Gremium und die vier zulässigen Ergebnisse	Lenkungskreis in Woche 13: skalieren, nachschärfen, einfrieren oder abbrechen

Das Abbruchkriterium ist das Feld, das in der Praxis am häufigsten fehlt – und das einzige, das den Piloten überhaupt zu einem Test macht. Es muss vor dem Start festgelegt werden, weil danach niemand mehr unbefangen darüber entscheidet: Sobald Budget, Arbeitszeit und Erwartungen im Spiel sind, wird jedes Ergebnis nachträglich als Teilerfolg lesbar. Sinnvoll ist außerdem, das Kriterium an eine Fehlerart zu knüpfen und nicht nur an eine Quote. Ein einzelner Vorschlag, dessen Zustandekommen sich nicht nachvollziehen lässt, ist ein härteres Signal als eine leicht verfehlte Trefferquote.

Vertrag und Auftragsverarbeitung vor dem Pilot klären

Ein Pilot mit Echtdaten ist datenschutzrechtlich kein Testbetrieb, sondern eine Verarbeitung. Vier Punkte sollten deshalb geklärt und schriftlich vorliegen, bevor der erste Beleg das System verlässt: ob Eingaben für das Training oder Fine-Tuning von Modellen genutzt werden, die auch anderen Kunden zugutekommen; welche Subprozessoren und Modellanbieter beteiligt sind und ob sie im Auftragsverarbeitungsvertrag vollständig benannt sind; in welcher Region die Verarbeitung stattfindet und ob sich eine EU-Region vertraglich zusichern lässt; und was beim Ausstieg mit den im Betrieb entstandenen Regelwerken, Rückmeldungen und Freigabehistorien geschieht.

Belastbar ist bei der Trainingsfrage nur eine vertragliche Zusage mit Nachweispflicht, kein Schalter im Administrationsmenü, den ein Release-Wechsel zurücksetzen kann. Der letzte Punkt wird regelmäßig unterschätzt: Die Bindungswirkung entsteht weniger durch die Funktion als durch die Daten, die im Betrieb um sie herum entstehen. Die vollständigen Formulierungen dazu stehen in der Checkliste für den ERP-Vertrag, die einen eigenen Abschnitt zu KI-Klauseln enthält.

Governance im Betrieb: wer prüft, und woran

Mit dem Rollout verschiebt sich die Aufgabe von der Einführung zur Aufsicht. Vier Festlegungen tragen diesen Betrieb.

Benannte fachliche Verantwortung. Für jede produktive KI-Funktion gibt es genau eine Person im Fachbereich, die für die Qualität der Vorschläge verantwortlich ist – nicht die IT, die den Betrieb sicherstellt, und nicht der Anbieter, der das Modell liefert. Diese Person entscheidet über Schwellenwerte, wertet die Stichproben aus und hat die Befugnis, die Funktion abzuschalten. Ohne diese Einzelzuständigkeit fällt die Aufsicht zwischen die Zuständigkeiten.

Prüfbarkeit statt Protokollpflicht. Jede automatisch erzeugte Buchung braucht eine Spur, die im Nachhinein zeigt, welche Belege, Stammdaten oder Regeln zum Ergebnis geführt haben, wer freigegeben hat und wann. Ein Audit-Trail, der nur festhält, dass ein Systemnutzer gebucht hat, genügt den Anforderungen der GoBD an Nachvollziehbarkeit im Prüfungsfall nicht. Ebenso gehört das Berechtigungsmodell auf den Prüfstand: Ein Assistent, der über Rollen hinweg aggregiert, hebelt ein sorgfältig aufgebautes Rollenkonzept aus.

Automation Bias aktiv gegensteuern. Wer 200 Vorschläge am Tag freigibt und dabei fast durchgehend korrekte Ergebnisse sieht, prüft die Ausnahmen erfahrungsgemäß weniger sorgfältig – die formale menschliche Aufsicht bleibt bestehen, ihre Wirkung nicht. Wirksam sind feste Stichprobenquoten unabhängig vom Auffälligkeitsgrad, bewusst nicht vorbelegte Prüffelder oberhalb definierter Beträge und rotierende Freigabezuständigkeiten statt dauerhaft derselben Person.

Fehlbuchungen als Regelfall behandeln. Für den Korrekturweg braucht es eine feste Strecke: Wie wird storniert, wer wird informiert, wo wird der Fall erfasst, und wie fließt er in die Verbesserung zurück? Entscheidend ist die Unterscheidung zwischen Einzelfall und Muster. Manuelle Fehler streuen zufällig, Modellfehler sind systematisch – taucht dieselbe Fehlerart zweimal auf, ist die Frage nicht, wer sie übersehen hat, sondern welche Regel oder welcher Datenstand sie erzeugt. Nach jedem angekündigten Modell- oder Release-Wechsel gehört eine gezielte Nachprüfung dazu, weil sich die Trefferquote ohne Meldung verschieben kann.

Erfolgsmessung und die ehrliche Abbruchentscheidung

Gemessen wird gegen die Ausgangsmessung des Steckbriefs, mit derselben Abfrage und demselben Zuschnitt. Zulässig sind vier Ergebnisse, und drei davon sind keine Skalierung: skalieren, wenn die Erfolgsschwelle erreicht ist und die Nebenbedingungen halten; nachschärfen mit einem neuen, ebenfalls befristeten Durchlauf, wenn die Abweichung erklärbar und behebbar ist; einfrieren, wenn die Funktion technisch trägt, aber der Nutzen den laufenden Kontrollaufwand nicht deckt; abbrechen, wenn das Abbruchkriterium gegriffen hat oder die Ursache in den Daten liegt und nicht im Modell.

Der wirtschaftliche Grund für diese Disziplin ist gut belegt: Laut einer McKinsey-Analyse aus dem Jahr 2025 schöpfen knapp 70 Prozent der ERP-Transformationsprogramme ihr Potenzial nicht voll aus, überwiegend wegen des organisatorischen Vorgehens – Programme an System- statt Geschäftszielen ausgerichtet, unklare Ownership, zu wenig Fokus auf die Realisierung des Nutzens – und nicht wegen der Technologie. Die Zahl steht mit Quelle unter messbarer Nutzen in den ERP-Statistiken. Ein abgebrochener Pilot ist gemessen daran kein Scheitern, sondern das günstigste verfügbare Ergebnis einer Prüfung.

Bei der Skalierung wächst nicht nur das Volumen mit, sondern auch die Kontrolle. Wenn ein Pilot mit 600 Belegen im Quartal trägt, heißt das nicht, dass dieselbe Fehlerquote bei 20.000 Belegen tragbar ist – die absolute Zahl der Fehler steigt proportional. Zum Rollout gehören deshalb festgelegte Stichprobenquoten, Schwellenwerte für die zwingend manuelle Prüfung, definierte Eskalationswege und rollengerechte Schulungen, die zugleich die Kompetenzpflicht aus Artikel 4 der EU-KI-Verordnung erfüllen. Die Kostenseite gehört als eigene Position in die TCO-Betrachtung, weil Datenaufbereitung, Kontrollaufwand und Schulung dauerhaft anfallen und nicht mit dem Projekt enden; ein Gerüst dafür bietet der TCO-Rechner. Für die Akzeptanz in der Belegschaft gelten dieselben Regeln wie in jedem anderen ERP-Vorhaben, nachzulesen im Leitfaden zum Change-Management für ERP-Projekte.

Einordnung

Die Einführung von KI im ERP unterscheidet sich methodisch weniger von anderen ERP-Vorhaben, als die Diskussion nahelegt. Der Unterschied liegt in zwei Punkten: Die Datenbasis ist nicht Voraussetzung, sondern Bestandteil der Funktion, und ein Fehler bleibt nicht bei einem Vorgang, sondern wirkt auf alle gleichartigen. Beides lässt sich beherrschen – aber nur mit Zahlen. Wer die fünf Datenkennzahlen erhoben hat, den Steckbrief samt Abbruchkriterium abgezeichnet vorliegen hat und benennen kann, wer im Betrieb prüft, hat die Voraussetzungen geschaffen. Wer das nicht kann, sollte den Start vertagen, bis er es kann. Eine kompakte Begriffsdefinition liefert das Glossar zu KI im ERP, den funktionalen und rechtlichen Rahmen der Überblick zu künstlicher Intelligenz im ERP.

← Zurück zur Startseite