KI an ERP und CRM anbinden: warum die Schnittstelle über den Erfolg entscheidet

In den meisten mittelständischen Unternehmen liegt zwischen dem ersten funktionierenden KI-Prototyp und der ersten produktiven Nutzung ein Zeitraum, der sich nicht mit Entwicklungsaufwand erklären lässt. Der Prototyp entsteht in zwei Wochen, weil er mit einem Exportauszug arbeitet, den jemand aus dem ERP gezogen hat. Danach passiert monatelang nichts. Nicht, weil das Modell zu schwach wäre, sondern weil sich niemand findet, der die Freigabe für den dauerhaften Zugriff auf dieselben Daten unterschreibt.

Diese Verzögerung wird in der Regel als technisches Problem beschrieben — „die Schnittstelle fehlt noch“. Ein Blick in die Herstellerdokumentation der gängigen Mittelstandssysteme zeigt ein anderes Bild: Die Schnittstellen existieren, sind dokumentiert und in ihren Grenzen gut beschrieben. Was fehlt, ist die Entscheidung darüber, welche Felder ein zusätzlicher Dienst lesen darf und wer für diese Entscheidung geradesteht.

Wo KI-Vorhaben im Mittelstand tatsächlich hängen bleiben

Der Bitkom hat im Sommer 2025 604 Unternehmen ab 20 Beschäftigten telefonisch befragen lassen; die Erhebung lief von Kalenderwoche 27 bis 32 und ist als repräsentativ ausgewiesen. Als größte Hemmnisse beim KI-Einsatz nannten die Befragten die Verunsicherung durch rechtliche Hürden und fehlendes technisches Know-how (je 53 Prozent) sowie fehlende personelle Ressourcen (51 Prozent). Fehlende Daten belegten mit 24 Prozent einen der hinteren Plätze.

Diese Rangfolge ist aufschlussreicher, als sie zunächst wirkt. Sie besagt, dass die Datenbestände in den Unternehmen vorhanden sind — sie werden nur nicht herausgegeben. Rechtsunsicherheit, Datenschutzanforderungen und die Sorge vor unkontrolliertem Abfluss sind keine Aussagen über den Datenbestand, sondern über die Bereitschaft, den Zugriff darauf zu verantworten. Wer ein KI-Vorhaben plant und die Verzögerung im Entwicklungsteam sucht, sucht an der falschen Stelle.

Die kursierenden Scheiterquoten und was sie wirklich messen

Im Umlauf sind mehrere Zahlen, die Auskunft darüber geben sollen, wie oft KI-Vorhaben scheitern. Die bekannteste stammt aus dem Bericht State of AI in Business 2025 der MIT-Initiative NANDA und lautet, 95 Prozent der Pilotprojekte für generative KI blieben ohne messbaren Ergebnisbeitrag. Wer sie zitiert, sollte die Methodik mitliefern: Grundlage sind 52 strukturierte Interviews, eine Befragung von 153 Führungskräften und die Auswertung von rund 300 öffentlich dokumentierten Initiativen. Der Bericht ist kein begutachtetes Forschungspapier, und die Stichprobe trägt keine Aussage über den deutschen Mittelstand.

Belastbarer sind zwei andere Angaben. S&P Global Market Intelligence berichtete 2025, der Anteil der Unternehmen, die die Mehrzahl ihrer KI-Initiativen wieder einstellen, sei binnen eines Jahres von 17 auf 42 Prozent gestiegen. Gartner sagte im Februar 2025 voraus, bis Ende 2026 würden 60 Prozent der KI-Projekte ohne ausreichend aufbereitete Daten aufgegeben — eine Prognose, keine Messung. Beide Angaben verweisen auf dieselbe Ursache wie die Bitkom-Zahlen: nicht auf das Modell, sondern auf den Zustand und die Verfügbarkeit der Daten.

Vier Wege, wie ein Modell an die Daten eines Bestandssystems kommt

Technisch gibt es überschaubar viele Möglichkeiten, und ihre Reihenfolge ist keine Geschmacksfrage. Der erste Weg führt über die Programmierschnittstelle des Systems: dokumentiert, versioniert, mit definierten Fehlermeldungen. Der zweite ist der lesende Zugriff auf die Datenbank — schneller gebaut, aber ohne Zusage des Herstellers, dass die Tabellenstruktur nach dem nächsten Update noch dieselbe ist.

Der dritte Weg ist eine Importstrecke aus Dateien, wie sie Altsysteme oft als einzigen Ausgang anbieten: CSV, XML oder ein festes Satzformat, abgelegt in einem Verzeichnis. Der vierte besteht darin, eine schlanke eigene Anwendung vor das Bestandssystem zu setzen, die den Zugriff bündelt und protokolliert. In allen vier Fällen bleibt das Ursprungssystem führend; keiner dieser Wege ersetzt das ERP, und keiner setzt voraus, dass es ausgetauscht wird.

Was die Schnittstellen gängiger Mittelstandssysteme tatsächlich hergeben

Ein Abgleich mit den Herstellerunterlagen — nicht mit Vergleichsportalen — ergibt ein nüchternes Bild. Alle vier hier betrachteten Systeme bieten einen dokumentierten Zugang. Die Unterschiede liegen im Umfang und in den Bedingungen, unter denen er nutzbar ist.

Zwei Punkte daraus verdienen Aufmerksamkeit. Erstens ist der Zugang bei Odoo an den Tarif gebunden — ein Umstand, der ein Vorhaben nicht technisch, sondern kaufmännisch blockiert und deshalb vor der ersten Zeile Code geklärt gehört. Zweitens deckt die dokumentierte Sage-100-Schnittstelle vier Bereiche ab; alles außerhalb davon braucht einen der anderen drei Anbindungswege.

Grenzwerte bestimmen die Architektur, nicht die Modellwahl

Wer eine Anbindung entwirft, arbeitet nicht gegen ein Protokoll, sondern gegen dessen Kontingente. Microsoft veröffentlicht die Betriebsgrenzen für Business Central online im Detail: höchstens fünf gleichzeitig verarbeitete OData-Anfragen je Benutzer, maximal 100 gleichzeitige Verbindungen einschließlich der wartenden, höchstens 20.000 Datensätze je Antwort und maximal 100 Vorgänge in einer Sammelanfrage. Anfragen, die in der Warteschlange landen, laufen nach acht Minuten in einen Fehler.

Diese Zahlen entscheiden über den Zuschnitt einer Integration. Ein Dienst, der einmal täglich einen Bestand abgleicht, ist unkritisch; einer, der bei jeder Nutzeranfrage live in das ERP greift, erreicht die Grenze schnell. Microsoft empfiehlt ausdrücklich, die Last über mehrere Benutzerkonten oder Dienstprinzipale zu verteilen. Für die Planung heißt das: Die Frage nach dem Modell ist nachrangig gegenüber der Frage, wie oft und in welcher Menge gelesen wird.

Die eigentliche Hürde liegt bei der Freigabe

Der Bitkom hat 2024 in einer zweiten repräsentativen Befragung von 603 Unternehmen ab 20 Beschäftigten erhoben, warum Daten nicht bereitgestellt werden. Am häufigsten genannt wurde der Datenschutz, der einen Austausch nicht erlaube (58 Prozent), gefolgt von der Unsicherheit, ob eine Weitergabe rechtlich überhaupt möglich sei (44 Prozent), und der Sorge, Daten könnten gegen den eigenen Willen genutzt werden (41 Prozent). Ein Drittel führte fehlende Kompatibilität an, ein Fünftel die Gefahr, versehentlich Geschäftsgeheimnisse preiszugeben.

Dieselbe Erhebung ergab, dass lediglich 6 Prozent der Unternehmen das Potenzial ihrer verfügbaren Daten nach eigener Einschätzung vollständig ausschöpfen, während 42 Prozent es eher wenig und 18 Prozent es überhaupt nicht tun. Die Befunde beschreiben zwar den Austausch zwischen Unternehmen, doch dieselbe Mechanik wirkt innerhalb eines Betriebs: Wer die Verantwortung für eine Freigabe trägt, ohne den Nutzen zu verantworten, entscheidet im Zweifel gegen die Freigabe.

Rechte, Protokoll und die Frage nach dem Rückschreiben

Eine Freigabeentscheidung fällt leichter, wenn sie begrenzbar ist. Technisch heißt das: Jede Anbindung erhält eigene Zugangsdaten mit eigenen Rechten statt des Administratorzugangs, und sie protokolliert, was sie gelesen und was sie geschrieben hat. Damit wird aus der unbestimmten Frage „darf die KI ins ERP“ die beantwortbare Frage, ob ein benannter Dienst vier Tabellen lesend sehen darf.

Die zweite Trennlinie verläuft zwischen Lesen und Schreiben. Ein Dienst, der ausschließlich liest, kann keinen Datenbestand beschädigen; die Rücknahme besteht darin, den Zugang zu entziehen. Sobald zurückgeschrieben wird, ändern sich Prüfaufwand und Haftungslage grundlegend, und die Freigabe braucht eine andere Ebene. Vorhaben, die beides in einem Schritt beantragen, verlängern ihre Genehmigungsdauer erheblich, ohne dass der erste Nutzen davon abhinge.

Zuständigkeit lässt sich nicht beschaffen, nur benennen

In vielen mittelständischen Betrieben ist unklar, wer über die Herausgabe von ERP-Daten an einen zusätzlichen Dienst entscheidet. Die IT verwaltet das System, verantwortet aber nicht dessen Inhalt. Die Fachabteilung kennt die Daten, hat aber keinen Zugriff auf die Rechtevergabe. Der Datenschutzbeauftragte prüft die Zulässigkeit, entscheidet aber nicht über den Geschäftsnutzen. Solange diese drei Rollen nicht zusammengeführt werden, gibt es keine Instanz, die eine Freigabe erteilen könnte.

1. Datenbedarf benennen Welche Felder aus welchem System werden gebraucht — nicht „Kundendaten“, sondern die konkrete Liste.
2. Rechtsgrundlage klären Zweck, Aufbewahrung und Auftragsverarbeitung prüfen, bevor ein technischer Zugang eingerichtet wird.
3. Entscheider festlegen Eine benannte Person, die Nutzen und Risiko gemeinsam verantwortet, nicht ein Gremium.
4. Zugang eng schneiden Eigene Zugangsdaten, nur die benötigten Felder, zunächst ausschließlich lesend.
5. Protokoll auswerten Nach vier Wochen prüfen, was tatsächlich gelesen wurde, und die Rechte nachziehen.

Was eine Anbindung nicht leistet

Eine Schnittstelle verbessert keine Stammdaten. Wenn dieselbe Firma im CRM dreimal mit unterschiedlicher Schreibweise steht, liefert die Anbindung diese drei Datensätze zuverlässig aus, und jede darauf aufsetzende Auswertung erbt den Fehler. Ebenso wenig ersetzt eine Anbindung eine Prozessbeschreibung: Ein Ablauf, den niemand vollständig erklären kann, wird durch Automatisierung nicht klarer, sondern unübersichtlicher.

Auch die Prüfbarkeit kommt nicht von selbst. Ein Modell, das eine Zahl nennt, ohne die Quelle mitzuliefern, aus der sie stammt, erzeugt Aufwand statt ihn zu sparen — jemand muss nachrechnen. Rechenoperationen und Schwellenprüfungen gehören deshalb in regelbasierten Code, nicht in das Sprachmodell; dieses ordnet ein, erkennt Felder und meldet Unsicherheit.

Die Reihenfolge, die sich bewährt

Aus alledem folgt eine Reihenfolge, die der üblichen Praxis widerspricht. Am Anfang steht nicht die Auswahl eines Modells und auch nicht die Schnittstelle, sondern die Freigabeentscheidung für einen eng umrissenen Datenausschnitt. Erst danach wird geklärt, welcher der vier Anbindungswege für das vorhandene System gangbar ist und welche Kontingente er setzt. Die Modellwahl steht zuletzt und bleibt austauschbar, weil sie an der Architektur wenig ändert.

Ob ein Unternehmen die Integration von KI in ERP und CRM selbst baut oder KI an bestehende Systeme anbinden lassen will, ändert an dieser Reihenfolge nichts. Kaido Studios etwa, ein Hamburger Entwicklungspartner für KI-Anwendungen und Individualsoftware im Mittelstand, arbeitet nach genau diesem Muster: eigene Zugangsdaten je Anbindung statt des Administratorzugangs, Protokollierung des Gelesenen und Geschriebenen, und das ERP bleibt führend. Abgerechnet wird dort über eine monatliche Pauschale mit festem Entwicklungskontingent statt über einen Projektvertrag mit festem Endzustand.

Häufige Fragen

Welche Daten braucht eine KI-Anwendung aus dem ERP?

So wenige wie möglich, aber konkret benannt. Statt eines pauschalen Zugriffs auf „Kundendaten“ wird eine Liste von Feldern aus einzelnen Tabellen definiert — etwa Belegkopf, Positionen und Artikelstamm für eine Angebotsauswertung. Diese Eingrenzung ist keine Formalie: Sie ist die Voraussetzung dafür, dass jemand die Freigabe überhaupt erteilen kann, weil erst dadurch das Risiko abschätzbar wird.

Muss das ERP für den Einsatz von KI ersetzt werden?

Nein. Alle vier gängigen Anbindungswege — Programmierschnittstelle, lesender Datenbankzugriff, Dateiimport und eine vorgelagerte eigene Anwendung — setzen voraus, dass das Bestandssystem führend bleibt. Ein Systemwechsel verlagert das Problem nur: Auch das neue System stellt dieselbe Frage danach, wer welchen Datenausschnitt freigeben darf.

Reicht ein lesender Datenbankzugriff statt einer dokumentierten Schnittstelle?

Er ist schneller gebaut und für Auswertungen oft ausreichend. Der Preis ist fehlende Zusicherung: Hersteller garantieren die Stabilität ihrer Tabellenstruktur nicht, während dokumentierte Schnittstellen versioniert sind. SAP etwa hat mit Feature Package 2405 OData Version 3 im Service Layer abgekündigt und Version 4 zum primären Protokoll erklärt — solche Übergänge sind angekündigt und planbar, Schemaänderungen in der Datenbank sind es nicht.

Was treibt den Aufwand einer Anbindung?

Nicht die Zahl der Nutzer, sondern vier andere Faktoren: wie viele Systeme beteiligt sind, in welchem Zustand die Stammdaten sind, wie viele Sonderfälle tatsächlich vorkommen und ob Daten in das Ursprungssystem zurückgeschrieben werden. Der letzte Punkt verändert die Größenordnung am stärksten, weil er Prüfschritte, Protokollierung und eine andere Freigabeebene nach sich zieht.

Wer im Unternehmen muss einer Datenfreigabe zustimmen?

In der Praxis sind drei Rollen beteiligt: die IT als Verwalterin des Systems, die Fachabteilung als Kennerin der Inhalte und die Datenschutzfunktion als Prüferin der Zulässigkeit. Keine dieser Rollen kann allein entscheiden. Vorhaben kommen dann voran, wenn eine benannte Person Nutzen und Risiko gemeinsam verantwortet — ein Gremium ohne festgelegte Entscheidungsbefugnis erzeugt in der Regel weitere Sitzungen statt einer Freigabe.