ERP im Mittelstand: Wie Individualsoftware dein ERP erweitert

Die IT-Agenda 2026 liest sich wie eine Aufgabe, die man nicht lösen kann.

Auf der einen Seite die Pflichtenliste. Die E-Rechnung wird im B2B-Geschäft ab dem 1. Januar 2027 zur Ausgangspflicht, für kleinere Unternehmen ein Jahr später. Das NIS2-Umsetzungsgesetz ist seit Dezember 2025 in Kraft und hat den Kreis der beaufsichtigten Unternehmen von rund 4.500 auf etwa 29.500 erweitert, industrielle Produktion ausdrücklich eingeschlossen, ohne Übergangsfrist. Die KI-Verordnung der EU ist seit dem 2. August 2026 anwendbar. Wer SAP ECC betreibt, hat die Mainstream-Wartung bis Ende 2027 und danach eine bezahlte Verlängerung bis 2030.

Auf der anderen Seite das Budget. Nach der Lünendonk-Studie zur CIO-Agenda rechnen für 2026 nur noch 55 Prozent der IT-Entscheider mit einem steigenden IT-Budget. Ein Jahr zuvor hatten das noch 79 Prozent erwartet. Gleichzeitig wollen 91 Prozent mehr in Sicherheit investieren und 80 Prozent in IT-Modernisierung, um Altlasten abzubauen.

Und dazwischen, meist ungenannt, der eigentliche Punkt: Der Prozess, der dein Unternehmen von der Konkurrenz unterscheidet, läuft immer noch in einer Excel-Datei auf einem Netzlaufwerk. Nicht weil niemand es gemerkt hätte, sondern weil er im ERP nicht abbildbar war und für ein eigenes Projekt nie Luft war.

Die Antwort darauf ist selten ein größeres ERP und so gut wie nie eine weitere Insellösung. Sie ist ein schlanker ERP-Kern plus wenige, gezielte eigene Anwendungen an sauberen Schnittstellen. Das ist kein Angriff auf deinen ERP-Anbieter. Es ist genau die Architektur, die die Anbieter selbst empfehlen.

Was ist ERP-Software, und was ist sie nicht

Kurz, weil der Begriff so oft benutzt wird, dass er unscharf geworden ist.

Ein ERP-System (Enterprise Resource Planning) ist die zentrale Verwaltung der betriebswirtschaftlichen Ressourcen deines Unternehmens auf einem gemeinsamen Datenmodell. Kunden, Artikel, Aufträge, Bestände, Belege, Kosten und Konten liegen einmal an einer Stelle, und die Module für Einkauf, Vertrieb, Lager, Produktion, Finanzen und Personal arbeiten alle auf diesen Daten. Das ist die eigentliche Bedeutung von ERP-Software, und sie steckt nicht in der Funktionsliste, sondern in diesem einen Satz: eine Wahrheit, viele Sichten.

Damit ist auch gesagt, was ein ERP nicht ist. Es ist kein Werkzeugkasten, in dem jeder Prozess deines Hauses Platz findet. Es ist ein Führungssystem für Standardvorgänge: Vorgänge, die überall ungefähr gleich ablaufen, die reguliert sind, die dokumentiert und revisionssicher sein müssen, und mit denen du dich von niemandem unterscheidest.

Diese Unterscheidung ist die Achse, um die sich der ganze Rest dieses Beitrags dreht:

• Führungssysteme halten die verbindlichen Daten. Buchhaltung, Bestände, Belege, Stammdaten. Hier gewinnt der Standard, immer.
• Differenzierungssysteme bilden ab, wie dein Betrieb arbeitet. Die Reihenfolge, in der du Aufträge einsteuerst. Die Art, wie du prüfst. Die Regel, nach der euer Einkauf disponiert. Hier verliert der Standard, weil es diesen Standard nicht gibt.

Ein ERP-System, das versucht, beides zu sein, wird an beiden Enden schlecht.

Das schlanke ERP als Fundament, nicht als Kompromiss

Es gibt eine Lesart von „Individualsoftware", die ich für falsch halte: die, in der das ERP das Problem ist. Ist es nicht. Für alles, was standardisiert und reguliert ist, ist ein gut eingeführtes ERP-System die günstigste und langlebigste Lösung, die du kaufen kannst. Finanzbuchhaltung, Steuern, Lohn, Bestandsführung, Belegfluss, und ab 2027 die E-Rechnung: Das willst du weder selbst bauen noch selbst pflegen.

Entscheidend ist das Wort schlank. Ein schlankes ERP ist eines, das so weit wie möglich im Standard läuft. Genau da liegt in der Praxis das Geld.

Denn jede Modifikation im Kern ist ein Kredit, den du beim nächsten Upgrade zurückzahlst. Und das nächste Upgrade steht bei vielen an. Bei SAP-Kunden endet die Mainstream-Wartung für ECC 6.0 zum 31. Dezember 2027, verlängerbar bis 2030 gegen einen Aufschlag von zwei Prozentpunkten auf die Wartungsgebühr. Ein ehrlicher Umstieg auf S/4HANA dauert im Mittelstand achtzehn bis dreißig Monate, und Erhebungen zufolge verfehlen rund 60 Prozent dieser Migrationen ihr Budget-, Termin- oder Qualitätsziel. Ich nenne SAP hier nur als Beispiel, weil die Frist so gut datiert ist. Die Mechanik ist bei jedem ERP dieselbe: Was du in den Kern hineingebaut hast, migrierst du mit, testest du erneut und bezahlst du zweimal.

Die Anbieter sagen das inzwischen selbst. SAP nennt es Clean Core, Gartner nennt es Composable ERP, als Nachfolger des 2013 formulierten „Postmodern ERP". Die Kernaussage ist in allen Varianten identisch: Halte den Kern standardnah und erweitere ihn daneben, über Schnittstellen, statt darin.

Und die Anwender folgen dem. Im DSAG-Investitionsreport 2026 ist die SAP Business Technology Platform mit 39 Prozent hoher und mittlerer Investitionsbereitschaft die am stärksten nachgefragte SaaS-Lösung, nach 33 Prozent im Jahr 2024. Wofür sie eingesetzt wird, ist bemerkenswert eindeutig: 45 Prozent nennen komplexe Integrationsaufgaben, 38 Prozent datengetriebene Analyse. Das Fazit des Reports lautet, dass nicht Visionen die Investitionsentscheidungen leiten, sondern Machbarkeit, Wirtschaftlichkeit und Integrationsfähigkeit.

Anders gesagt: Der Markt gibt gerade sehr viel Geld dafür aus, Erweiterungen aus dem ERP-Kern heraus und an dessen Schnittstellen zu verlagern.

Wo das ERP im Mittelstand an die Grenze kommt

Ein Standardprodukt setzt einen sauber definierten, idealtypischen Prozess voraus. Der Mittelstand lebt von Prozessen, die über Jahre gewachsen sind, die in Köpfen stecken statt in Handbüchern, und die genau das tun, was dieses eine Unternehmen erfolgreich macht. Über 70 Prozent der mittelständischen Unternehmen haben ihre End-to-End-Prozesse nicht vollständig dokumentiert. Das ist nicht Schlamperei, das ist die Natur der Sache.

Diesen Widerspruch haben wir an anderer Stelle ausführlich behandelt, deshalb hier nur der Verweis: Kann eine KMU überhaupt Individualsoftware für den Mittelstand bauen?

Interessanter ist, wo die Grenze im Mittelstand verlässlich verläuft. Nach unserer Erfahrung fast immer an denselben vier Stellen:

Fertigungs- und Werkstattspezifika. Die Feinplanung an der Maschine, Rüstreihenfolgen, Sonderfälle, die jeder Meister kennt und kein Modul vorsieht.

Koordination über Gesellschaften und Standorte hinweg. Sobald mehrere Einheiten füreinander gleichzeitig Lieferant und Kunde sind, endet die Vorstellung des ERP von „einem" Auftrag.

Prüf- und QS-Workflows. Wer prüft was, in welcher Reihenfolge, mit welcher Freigabe, mit welchem Nachweis. Kaum ein Betrieb macht das wie der Nachbarbetrieb, und kaum ein Prüfergebnis passt in ein Standardfeld.

Kalkulation, Konfiguration und Disposition. Überall dort, wo eine Regel entscheidet und nicht ein Formular. Wie viel bestellen wir, wie preisen wir eine Sonderanfertigung, welche Variante ist überhaupt baubar.

Woran du merkst, dass du an dieser Grenze stehst, und zwar ohne Analyseprojekt:

• Neben dem System wird eine Liste geführt, und die Liste hat recht.
• Dieselbe Information wird zweimal erfasst, an zwei Stellen, von zwei Leuten.
• Es gibt einen Auswertungsstand, dem alle glauben, und der entsteht in einer Tabelle.
• Ein Vorgang wartet regelmäßig auf eine Person, nicht auf eine Freigabe.
• Auf die Frage, warum ein Ergebnis so aussieht, antwortet jemand mit einer Erfahrungsregel, nicht mit einer Systemlogik.
• Beim letzten ERP-Update ist etwas kaputtgegangen, das ihr selbst hineingebaut hattet.

Wie so ein Punkt in der Realität aussieht, haben wir an einem konkreten Projekt aufgeschrieben, in dem der Einkauf der eigenen Bestellplanung nicht mehr geglaubt hat: Anatomie einer Prozessoptimierung.

Zwei Wege aus der Lücke, und nur einer skaliert

Wenn die Lücke erkannt ist, gibt es zwei Reaktionen. Beide fühlen sich pragmatisch an, und sie unterscheiden sich um eine Größenordnung in den Folgekosten.

Weg eins: die Insellösung. Man kauft ein spezialisiertes Werkzeug für genau diesen Fall. Es kann den Fall wirklich gut. Es bringt aber auch mit: seine eigene Kundenliste, seinen eigenen Artikelstamm, seine eigene Benutzerverwaltung, seinen eigenen Berechtigungsbegriff, seinen eigenen Wartungsvertrag, sein eigenes Update-Risiko und, seit NIS2, seinen eigenen Anteil an deinem Sicherheitskonzept.

Das Teure daran ist nicht das erste Werkzeug. Es ist das dritte. Denn die Kosten wachsen nicht mit der Anzahl der Systeme, sondern mit der Anzahl der Verbindungen zwischen ihnen, und die wächst deutlich schneller. Dazu kommt der Teil, der in keiner Rechnung steht: Ab zwei Kopien einer Stammdatenwahrheit ist nicht mehr geklärt, welche gilt. Ab da diskutiert deine Organisation nicht über Entscheidungen, sondern über Zahlen.

Genau dieses Muster beschreibt die DIHK-Digitalisierungsumfrage 2026, an der sich 4.686 Unternehmen beteiligt haben, aus der Innensicht: Als größte Hürden der Digitalisierung nennen die Betriebe Zeit (58 Prozent) und Komplexität (56 Prozent), deutlich vor fehlenden IT-Fachkräften (29 Prozent). Nicht das Nichtkönnen bremst, sondern das Verwalten des Gewachsenen.

Weg zwei: die Erweiterung. Man baut die fehlende Fachlichkeit als eigene Anwendung, aber ohne eigenen Datenhaushalt für Dinge, die das ERP schon führt. Sie liest Kunden, Artikel und Aufträge aus dem ERP, statt sie nachzuhalten. Sie nutzt die Anmeldung und die Rollen, die es im Haus schon gibt. Sie schreibt ihr Ergebnis dorthin zurück, wo es hingehört.

Der Unterschied zwischen den beiden Wegen ist also nicht „kaufen oder selbst bauen". Du kannst ein Werkzeug kaufen, das sauber an deinem ERP hängt, und du kannst dir eine eigene Anwendung bauen, die trotzdem ihren eigenen Kundenstamm mitschleppt.

Der Unterschied ist, ob danach noch eine einzige Stelle im Haus verbindlich sagt, wer dieser Kunde ist und was dieser Artikel kostet. Oder zwei.

Datenintegration: duplizieren oder konsolidieren?

Damit sind wir bei der Frage, an der solche Vorhaben technisch entschieden werden. Und weil hier viel Vokabular durcheinandergeht, zuerst zwei Begriffe, die es zu trennen lohnt:

• Das Führungssystem ist der Ort, an dem ein Datenobjekt entsteht und verbindlich gilt. Es gibt pro Objekt genau eines.
• Der Konsolidierungspunkt ist der Ort, an dem Daten aus mehreren Systemen für Auswertung zusammenlaufen. Er ist verbindlich für Analysen und nie für Vorgänge.

Wer die beiden verwechselt, baut ein Datenlager, in das irgendwann zurückgeschrieben wird. Das ist der Anfang vom Ende der Nachvollziehbarkeit.

Darauf aufbauend gibt es vier Muster, und die Wahl ist eine fachliche Entscheidung, keine Geschmacksfrage:

Kopieren hat also einen legitimen Platz, aber einen engen: Offline-Fähigkeit, Leselast, Entkopplung von Wartungsfenstern, Historie und Nachweis, sowie Migrationsphasen. Was Kopieren nie legitimiert, ist Bequemlichkeit an der Schnittstelle.

Und damit die Entscheidung nicht im Projekt versickert, gehört sie in ein Dokument, das ein CIO einfordern kann, bevor eine Zeile Code entsteht. Wir nennen es die Datenhoheitsmatrix. Sie ist eine Tabelle, sie passt auf eine Seite, und sie beantwortet pro Datenobjekt fünf Fragen:

Der wichtigste Effekt dieser Tabelle ist der, den man beim ersten Ausfüllen nicht erwartet: Ein Teil der Zeilen wird von der Erweiterung geführt, nicht vom ERP. Prüfergebnisse, Maschinenrückmeldungen und Prognosen sind Daten, für die dein ERP kein zuständiges Feld hat und auch keines haben sollte. Sobald das schriftlich steht, ist die Erweiterung kein Anhängsel mehr, sondern ein regulärer Teil deiner Landschaft mit klar umrissener Verantwortung.

Die Architektur, wie ein CIO sie sehen sollte

Fangen wir mit dem Fall an, in dem du noch keine Architektur brauchst.

Die erste eigene Anwendung darf sich direkt an das ERP hängen. Sie nutzt dessen Schnittstellen, holt sich Kunden und Artikel, schreibt ihr Ergebnis zurück, fertig. Das ist keine Notlösung und kein Schulden-Machen, das ist die richtige Entscheidung: Eine Integrationsschicht für eine einzige Verbindung zu bauen, wäre Aufwand ohne Gegenwert.

Der Punkt, an dem es kippt, ist die zweite Erweiterung. Und zwar aus einem Grund, der auf einer Folie harmlos aussieht und im Betrieb nicht harmlos ist: Nicht die Anzahl der Anwendungen wächst, sondern die Anzahl der Verbindungen zwischen ihnen. Drei Erweiterungen, die sich gegenseitig kennen müssen, sind nicht drei Strecken, sondern sechs. Dazu kommt, dass jede dieser Strecken dieselbe Arbeit ein weiteres Mal enthält: Anmeldung am ERP, Feldzuordnung, Fehlerbehandlung, Wiederanlauf nach einer Störung. Beim nächsten ERP-Update wird jede davon einzeln nachgezogen und einzeln getestet.

Ab hier zahlt sich die Schicht dazwischen aus. Nicht weil Architektur schön wäre, sondern weil sie diese Arbeit einmal statt sechsmal erledigt. Auf Vorstandsebene braucht es dafür kein Komponentendiagramm. Es braucht drei Bänder und fünf Regeln.

Oben deine Erweiterungen, jede für genau einen Prozess, der dich unterscheidet. In der Mitte eine Integrationsschicht, die aus Verträgen besteht statt aus Kabeln. Unten der ERP-Kern, standardnah und unangetastet. Daneben, bewusst abgesetzt, eine ausschließlich lesende Datenplattform für Auswertung und KI.

Die fünf Regeln, die diese Architektur zusammenhalten:

1. Ein Führungssystem pro Datenobjekt. Nicht pro System, pro Objekt. Steht in der Datenhoheitsmatrix, sonst gilt es nicht.
2. Kein Schreibzugriff in ERP-Tabellen. Nur über freigegebene Schnittstellen. Wer direkt in die Datenbank schreibt, hat den Wartungsvertrag seines ERP-Anbieters gerade wertlos gemacht.
3. Fachlogik gehört in die Erweiterung. Nicht in Modifikationen des Kerns. Das ist derselbe Gedanke, den dein ERP-Anbieter Clean Core nennt.
4. Jede Schnittstelle hat einen Vertrag. Was kommt, in welcher Version, was passiert bei einem Fehler, wie läuft es nach einer Störung wieder an. Eine Schnittstelle ohne Wiederanlauf ist ein Ausfall mit Terminverschiebung.
5. Austauschbarkeit ist Teil des Entwurfs. Eine Erweiterung, die ausschließlich über Verträge redet, überlebt den Wechsel des ERP darunter.

Regel fünf ist die, die auf CIO-Ebene die meiste Diskussion beendet. Wenn ohnehin eine Migration ansteht, ist das kein Argument gegen eine eigene Anwendung. Es ist das Argument dafür, sie jetzt aus dem Kern heraus und hinter einen Vertrag zu legen. Was neben dem ERP liegt und nur über Schnittstellen spricht, wandert bei der Migration mit. Was im Kern liegt, wird Teil des Migrationsrisikos.

Zwei Dinge liegen quer über allen drei Bändern und werden regelmäßig vergessen: eine Identität statt einer Benutzerverwaltung pro Anwendung, mit Berechtigungen, die aus dem bestehenden Verzeichnis und aus dem ERP abgeleitet werden. Und ein Betriebskonzept mit Protokollierung, Überwachung, Wiederanlauf und benannter Verantwortung. Letzteres ist seit dem NIS2-Umsetzungsgesetz nicht mehr nur guter Stil. Bei Verstößen gegen die neuen Pflichten stehen Bußgelder bis zu 10 Millionen Euro oder zwei Prozent des Jahresumsatzes im Raum, und die Meldefristen liegen bei 24 Stunden für die Frühwarnung und 72 Stunden für die Meldung.

Warum das ein Differenzierungsthema ist und kein IT-Thema

Mit dem Hauptbuch unterscheidet sich niemand. Das ist keine Provokation, das ist der ganze Grund, warum es Standardsoftware gibt und warum sie gut ist.

Du unterscheidest dich mit dem, was dein Kunde merkt: dass du eine Sonderanfertigung in vier Tagen kalkulierst und nicht in zwei Wochen. Dass dein Prüfnachweis vollständig mit der Lieferung ankommt. Dass du eine Bestellung sinnvoll disponierst, obwohl vier Gesellschaften daran hängen. Das sind Prozesse, nicht Funktionen, und für Prozesse gibt es keinen Standard, weil sie sonst kein Vorteil wären.

Dazu kommt ein Punkt, der aus der Personalabteilung in die IT-Strategie gewandert ist. Nach dem DIHK-Fachkräftereport 2025/26 können 36 Prozent der Unternehmen offene Stellen nicht besetzen, und am härtesten trifft es genau die Größenklassen, um die es hier geht: 44 Prozent der Betriebe mit 20 bis 199 Beschäftigten und 47 Prozent derer mit 200 bis 999.

Wenn zusätzliche Leute keine verfügbare Option mehr sind, bleibt als Hebel nur, dass die Arbeit pro Person besser passt. Genau das ist der wirtschaftliche Kern einer Erweiterung: nicht mehr Funktionen, sondern weniger Reibung an der Stelle, wo dein Volumen entsteht.

Und die Grenze dabei bleibt dieselbe, die wir immer ziehen: individuell genau dort, wo dein Prozess dich vom Wettbewerb unterscheidet. Alles andere kauft man zu. Wer seine Lohnabrechnung selbst baut, verbrennt Geld, und wir würden davon abraten.

In welchen Phasen so etwas entsteht

Das häufigste Scheitern in diesen Vorhaben ist nicht technisch. Es ist, dass die schwierigste Frage zu spät gestellt wird. Deshalb dieses Phasenmodell, in dem die Schnittstellenfrage nach vorne wandert.

Phase 0: Prozess- und Systemaufnahme

• Ziel: verstehen, was tatsächlich passiert, nicht was im Handbuch steht.
• Ergebnis: der Ist-Prozess, ein Verzeichnis der beteiligten Systeme und Tabellen, und die erste Fassung der Datenhoheitsmatrix. Bewusst kein Lastenheft.
• Wer dabei sein muss: die Menschen, die den Prozess täglich fahren, nicht nur ihre Leitung.
• Abbruchkriterium: Wenn sich hier zeigt, dass der Prozess sich standardisieren lässt, hör auf und nimm das ERP-Modul.

Phase 1: Integrations-Machbarkeit

• Ziel: beweisen, dass dein ERP die benötigten Daten überhaupt liefern und annehmen kann, in ausreichender Geschwindigkeit und ohne Lizenzüberraschung.
• Ergebnis: eine lauffähige kleine Strecke gegen das echte System, plus eine Aussage zu Mengen und Antwortzeiten.
• Wer dabei sein muss: dein ERP-Partner, und zwar hier und nicht später.
• Abbruchkriterium: Wenn die benötigten Daten nur über direkten Tabellenzugriff erreichbar sind, ist der Entwurf falsch und nicht das ERP.

Diese Phase kostet wenige Tage und rettet Projekte. Der klassische Fehler ist, ein halbes Jahr Fachlichkeit zu bauen und dann festzustellen, dass die Schnittstelle nicht hergibt, was gedacht war.

Phase 2: ein vollständiger Prozess in Produktion

• Ziel: ein einziger Vorgang, aber von Anfang bis Ende, mit echten Daten und einem kleinen Nutzerkreis. Nicht ein Prototyp, nicht drei halbe Fälle.
• Ergebnis: der erste Prozess, der wirklich im neuen Werkzeug läuft.
• Wer dabei sein muss: die künftigen Nutzer, und zwar als Anwender im Echtbetrieb, nicht als Testgruppe.
• Abbruchkriterium: Wenn die Nutzer nach zwei Wochen weiter ihre Liste führen, stimmt der Zuschnitt nicht, und mehr Funktionen helfen nicht.

Wie man diesen ersten vertikalen Durchstich auf den Kern-Use-Case zuschneidet, haben wir hier aufgeschrieben: Requirements Engineering im iterativen Zyklus.

Phase 3: ausrollen und abschalten

• Ziel: die alte Lösung wegnehmen. Das ist der eigentliche Inhalt dieser Phase, und der Teil, der am häufigsten unterbleibt.
• Ergebnis: Die Excel-Datei ist archiviert und nicht mehr im Umlauf, das ersetzte Werkzeug ist gekündigt.
• Wer dabei sein muss: wer die alte Lösung heute besitzt und pflegt, sonst lebt sie weiter.
• Abbruchkriterium: Wenn hier nichts verschwindet, hat das Projekt die Landschaft komplizierter gemacht.
• Merksatz: Eine Insel, die man nicht abschaltet, ist keine Ablösung, sondern eine zusätzliche Insel.

Phase 4: Betrieb und Weiterentwicklung

• Ziel: dass die Erweiterung ein normales System deines Hauses wird.
• Ergebnis: Überwachung der Schnittstellen mit Alarm, ein geprobter Wiederanlauf, eine benannte fachliche und technische Verantwortung.
• Wer dabei sein muss: die benannten Verantwortlichen, ab jetzt dauerhaft und nicht projektweise.
• Dauerregel: ein Regressionstest, der vor jedem ERP-Update gegen die Schnittstellenverträge läuft.

Diese letzte Regel entscheidet, ob die Lösung in drei Jahren noch geliebt wird oder nur noch geduldet.

Quer über alles liegt Compliance, und zwar von Anfang an: Berechtigungen aus dem ERP übernehmen statt neu erfinden, protokollieren, wer was geändert hat, und die Erweiterung im Sicherheitskonzept des Hauses führen.

KI als Werkzeug im Projekt, nicht als Produktversprechen

Hier geht es ausdrücklich nicht um KI-Funktionen in der fertigen Software, sondern um KI als Werkzeug während der Integration. Das ist der Teil, über den in Vorstandspräsentationen selten geredet wird und der die Projektdauer am deutlichsten verändert.

Wo sie bei uns real hilft:

Prozessaufnahme. Interviews und Werkstattgespräche als Transkript, daraus eine erste strukturierte Prozessbeschreibung mit den offenen Fragen. Das ersetzt kein Gespräch, aber es ersetzt das Protokollieren und macht sichtbar, wo zwei Beteiligte denselben Schritt unterschiedlich beschreiben.

Excel-Archäologie. Der Prozess steckt in einer Tabelle, die seit elf Jahren gewachsen ist. Formeln, Makros, Sonderfälle in ausgeblendeten Spalten. Ein Modell kann diese Regeln extrahieren und in eine lesbare Liste überführen, die man mit dem Fachbereich durchgehen kann. Das ist die Arbeit, die vorher niemand machen wollte, und sie ist der eigentliche Anforderungsschatz.

Schnittstellen-Abbildung. Aus Feldkatalogen und Schnittstellenbeschreibungen des ERP Vorschläge für die Zuordnung erzeugen, statt sie abzutippen.

Testfälle und Abgleich. Testdaten für Schnittstellen erzeugen, und beim Umstieg die Ergebnisse von alt und neu gegenüberstellen, um Abweichungen zu finden, statt sie zu hoffen.

Dokumentation und Übergabe. Der Teil, der ohne Werkzeug immer zuletzt und zu knapp gemacht wird.

Dazu drei Leitplanken, die wir nicht verhandeln. KI schlägt vor, Menschen entscheiden. Keine extrahierte Regel geht ohne fachliche Prüfung in Produktion, denn eine plausibel formulierte falsche Regel ist teurer als eine fehlende. Und: Die Ersparnis ist real, aber sie ist nicht kostenlos. Im Bitkom-Studienbericht 2026 sagen 33 Prozent der Unternehmen, KI sei teurer geworden als gedacht, und als größte Hürden nennen sie fehlende KI-Kompetenz im Team (53 Prozent), Unsicherheit beim Datenschutz (41 Prozent) und unklare Kosten (37 Prozent). Wer KI im Projekt einsetzt, muss sie können, nicht nur lizenzieren.

Wie KI sicher in die Landschaft passt

Bis hierhin war KI ein Werkzeug. Sie hat im Projekt geholfen und danach den Raum wieder verlassen. Ab jetzt reden wir über etwas anderes, und dieser Wechsel ist größer, als er klingt.

Eine KI-Funktion in deiner fertigen Erweiterung ist keine Hilfe auf Zeit, sondern eine Systemkomponente. Sie läuft im Betrieb, sie verarbeitet dauerhaft echte Daten, und sie braucht eine benannte Verantwortung, eine Protokollierung und einen geprobten Wiederanlauf wie jedes andere System aus Phase 4. Damit steht sie in deinem Sicherheitskonzept.

Dieser Unterschied verschiebt die Frage. Beim Werkzeug fragst du: Darf ich diese Daten einmal durch dieses Modell schicken? Bei der Systemkomponente fragst du: Darf dieses Modell diese Daten dauerhaft und unbeaufsichtigt verarbeiten, und wer verantwortet das Ergebnis? Die Einordnung, die jetzt kommt, brauchst du für beides, denn auch das Werkzeug im Projekt sieht echte Daten. Für die Systemkomponente ist sie nur nicht verhandelbar.

Wo diese Komponente hingehört, hat die Architektur weiter oben schon entschieden. Weil der ERP-Kern standardnah bleibt, ist die Erweiterung der natürliche Ort für KI-Funktionen. Dort darfst du experimentieren, dort kannst du zurückrollen, und dort gefährdet ein Fehlversuch nicht deine Buchhaltung. Gartner erwartet, dass bis Ende 2026 rund 40 Prozent der Unternehmensanwendungen aufgabenspezifische KI-Agenten mitbringen, nach weniger als 5 Prozent im Jahr 2025. Die Frage ist also weniger, ob KI in deine Landschaft kommt, sondern an welcher Stelle.

Bleibt die Frage, wo das Modell selbst läuft. Darauf wird meistens zu technisch geantwortet. Die Reihenfolge ist eine andere: Zuerst die Einordnung des Anwendungsfalls, dann die Wahl des Betriebsmodells.

Denn die Risikoklasse der KI-Verordnung hängt am Einsatzzweck, nicht am Rechenzentrum. Ein Modell in der eigenen Halle macht aus einem hochriskanten Anwendungsfall keinen harmlosen. Seit dem 2. August 2026 ist die Verordnung allgemein anwendbar, mit Transparenzpflichten und nationaler Aufsicht, und mit Bußgeldrahmen bis zu 15 Millionen Euro oder drei Prozent des weltweiten Jahresumsatzes. Die Pflichten für Hochrisiko-Systeme sind allerdings verschoben worden, und zwar durch den sogenannten Digital Omnibus. So nennt die EU ein Sammelgesetz, das mehrere bestehende Verordnungen auf einmal ändert, statt jede einzeln anzufassen. Für die KI-Verordnung gibt es davon eine eigene Ausgabe, in Kraft seit dem 27. Juli 2026: Sie verlegt die Hochrisiko-Pflichten auf den 2. Dezember 2027 für eigenständige Systeme nach Anhang III und auf den 2. August 2028 für Systeme, die in regulierte Produkte eingebettet sind. Der Grund ist nüchtern: Die harmonisierten technischen Normen und die prüfenden Stellen waren nicht rechtzeitig fertig. Die Anforderungen sind also nicht weicher geworden, sie kommen nur später. Das ist Zeit zum Vorbereiten und kein Grund, das Thema zu vertagen. Und wichtig für dich als Anwender: Auch wenn der Anbieter die technischen Nachweise liefert, bleibst du dafür verantwortlich, wie das System in deinen Prozessen eingesetzt und überwacht wird.

Daraus ergeben sich drei Betriebsmodelle, und alle drei sind legitim, für unterschiedliche Fälle:

On-Premise oder am Rand der Fertigung. Das Modell läuft auf eigener Hardware, es verlässt kein Datum das Haus. Passend, wenn du Konstruktions-, Fertigungs- oder Kalkulationsdaten verarbeitest, deren Abfluss dein Geschäft berührt, wenn du gleichmäßig hohe Mengen fährst, oder wenn ein Anwendungsfall in die Hochrisiko-Klasse fällt und du Protokollierung und Nachvollziehbarkeit vollständig in eigener Hand haben willst. Der Preis ist Modellauswahl und Betriebsaufwand. Ob sich das rechnet, ist eine Frage von Mengen und nicht von Haltung, und wir haben sie hier durchgerechnet: Lohnt sich ein lokales KI-Setup für ein Unternehmen wirklich?

Souveränes Hosting in der EU. Betrieb in einer europäischen Region mit Auftragsverarbeitungsvertrag, ohne Nutzung deiner Daten für Training, mit belastbaren Aussagen zur Datenhaltung. Passend für den größten Teil der personenbezogenen und geschäftskritischen Fälle, auch für hochriskante, wenn die Dokumentations- und Protokollpflichten vertraglich und technisch abgedeckt sind. Der Anbieterkreis in Deutschland ist inzwischen konkret, und digitale Souveränität ist in der Lünendonk-Erhebung nicht zufällig eine der Top-Investitionsprioritäten für 2026 und 2027.

Beliebige Cloud. Für unkritische Daten und Aufgaben ohne Personenbezug und ohne Geschäftsgeheimnis. Übersetzungen öffentlicher Texte, Formulierungshilfen, Recherche in offenen Quellen. Hier auf souveränes Hosting zu bestehen, kostet Geld ohne Gegenwert.

Zwei Architekturentscheidungen halten dir diese Wahl offen, statt sie einmalig zu betonieren:

Das Modell hängt hinter deinem eigenen Zugangspunkt. Deine Anwendungen sprechen mit einer Stelle in deiner Landschaft, nicht direkt mit einem Anbieter. Dann ist das Betriebsmodell pro Anwendungsfall wählbar und später wechselbar, und du protokollierst an einer Stelle, was gefragt und was geantwortet wurde. Das brauchst du sowohl für die Transparenzpflichten als auch für die Nachvollziehbarkeit gegenüber deinen eigenen Leuten. Zur Auswahl solcher Zugangspunkte und zur Datenresidenz haben wir hier geschrieben: OpenRouter erklärt, und was das für EU-Teams bedeutet.

Die KI redet nie direkt mit dem ERP. Sie greift auf dieselben Schnittstellen zu wie die Erweiterung selbst, mit denselben Berechtigungen. Damit bleiben deine ERP-Rollen wirksam, und niemand kann über einen Assistenten Daten sehen, die er im Fachsystem nicht sehen dürfte. Das ist die Regel, die in Pilotprojekten am häufigsten übersprungen wird, und die einzige, die verhindert, dass dein Berechtigungskonzept nebenbei ausgehebelt wird.

Dass diese Vorsicht nicht Bremse, sondern Voraussetzung ist, zeigt die Adoptionslücke: Nach der DIHK-Umfrage 2026 setzen 41 Prozent der Unternehmen KI aktiv ein, im Mittelstand aber nur 20 Prozent, und als Hemmnisse bei Daten und KI werden rechtliche Unsicherheit (59 Prozent) und technische Hürden (50 Prozent) genannt. Wer die Einordnung und das Betriebsmodell vorher klärt, gehört zu den 20 Prozent, statt auf Klarheit zu warten. Wie man das Vertrauen dabei schrittweise aufbaut, statt alles auf einmal zu riskieren, steht hier: Erklärbare KI im Mittelstand.

Fünf Fragen für dein nächstes IT-Meeting

Wenn du aus diesem Beitrag nur eines mitnehmen willst, dann diese Fragen:

1. Welcher unserer Prozesse unterscheidet uns wirklich vom Wettbewerb? Wenn die Antwort länger als drei Prozesse ist, ist sie noch nicht fertig.
2. Welche Modifikation in unserem ERP bezahlen wir beim nächsten Upgrade ein zweites Mal? Und was davon könnte stattdessen daneben liegen?
3. Wer ist Führungssystem für unsere zehn wichtigsten Datenobjekte? Wenn es dazu kein Dokument gibt, ist das die erste Aufgabe und sie kostet einen Nachmittag.
4. Welche unserer Insellösungen könnten wir abschalten? Und warum ist das beim letzten Projekt nicht passiert?
5. Welchen KI-Anwendungsfall dürften wir mit unserem heutigen Betriebsmodell sofort produktiv fahren? Wenn die Antwort „keinen" ist, ist nicht die KI das Problem, sondern die fehlende Einordnung.

Die Entscheidung, um die es hier geht, ist nicht ERP oder Individualsoftware. Diese Gegenüberstellung hat noch niemandem geholfen, weil beide Seiten Recht haben, nur an verschiedenen Stellen.

Die Entscheidung ist, ob dein ERP schlank bleiben darf, damit dein Unterschied woanders wachsen kann.