Integrieren statt konsolidieren: KI macht Best of Breed wirtschaftlich

Wie KI Schnittstellen schnell, günstig und prüfbar macht – und damit den Vendor-Lock-in in den Life Sciences lockert.

Auf einen Blick

• KI senkt die Kosten, Schnittstellen zu spezialisierten Werkzeugen zu bauen, so stark, dass zugekaufte Zusatzmodule und Konnektoren ihren Preis rechtfertigen müssen. Der ERP-Kern bleibt Standardsoftware.
• Austauschbar wird ein Baustein nur, wenn seine Funktionen adressierbar sind, also über APIs statt über Masken erreichbar. Wie weit die eigene Landschaft davon entfernt ist, bestimmt den Spielraum.
• Im GxP-Umfeld bleibt der Nachweis der Engpass. KI automatisiert die Daueraufwände der Validierung, die bisher gegen Individualsoftware sprachen. Die Freigabe bleibt beim Menschen.
• Empfehlung: Prozesse und Anforderungen aufnehmen und an einer überschaubaren Schnittstelle einen validierten Pilot umsetzen.

Was passiert momentan

Das Open-Source-Projekt ArtCraft hat Ende September 2026 begonnen, sieben Adobe-Anwendungen nachzubauen. Gut eine Woche später liefen Pendants zu Photoshop, Illustrator und Premiere. Bemerkenswert ist neben dem Tempo die Bauweise: Die Programme sind nicht nur für Menschen gebaut, sondern auch für KI-Agenten. Jede Funktion ist ein benannter Befehl, den Oberfläche, API und Agent gleichermaßen aufrufen.

Für ERP-Landschaften folgt daraus eine unbequeme Frage: Wenn sich fehlende Funktionen so schnell bauen und so sauber anbinden lassen, warum dann noch das Zusatzmodul kaufen? Die Antwort hängt davon ab, wie adressierbar die eigene Landschaft ist. SAP geht mit Clean Core in diese Richtung, doch dem Zielbild stehen vielerorts Jahrzehnte an Eigenentwicklungen und Modifikationen gegenüber.

Lock-in war immer der Preis

Dass sich geschlossene Systeme am Markt halten, liegt weniger an unzugänglichem Code als an den Kosten: Die fehlenden zehn Prozent selbst zu entwickeln, war bisher teurer, als das nächste Modul zu lizenzieren. Unternehmen beschaffen ein ERP-System selten wegen des vollen Funktionsumfangs. Ausschlaggebend ist meist, dass sich die Lücke zwischen vorhandener und benötigter Funktionalität anders nicht wirtschaftlich schließen lässt. Bezahlt wird also im Kern für das Schließen dieser Lücke.

Verschoben hat sich die Grenze, an der ein Verantwortlicher sagt: Das bauen wir nicht selbst. In der Praxis lag sie bei etwa einem Personenmonat, darunter baute man, darüber kaufte man. Nach unserer Projekterfahrung liegt sie inzwischen deutlich höher und wandert weiter.

Den ERP-Kern betrifft diese Entwicklung nicht. Ein SAP S/4HANA®-System nachzubauen ist wirtschaftlich nicht darstellbar; die Kostenbetrachtung weiter unten zeigt, warum. Betroffen ist die Ebene darüber: Schnittstellen und Konnektoren, Zusatzmodule, Portale, Reporting-Lösungen und Workflow-Erweiterungen. Das ist das Kerngeschäft der Add-on- und Partnerlösungsanbieter.

Composable ERP hört auf, ein Folienbegriff zu sein

Composable ERP scheiterte bisher nicht an der Idee, sondern an den Schnittstellen. Ein zerlegtes System braucht mehr Schnittstellen, mehr Mapping, mehr Zustandsabgleich, und jede Schnittstelle kostete Entwicklungsbudget und einen Wartungsvertrag. Ein einziges monolithisches System war günstiger als viele kleine Einzelsysteme.

Die Schnittstelle ist nun nicht mehr die Aufwandsposition. Ein Mapping zwischen zwei Datenmodellen, ein Adapter auf eine undokumentierte Schnittstelle, ein Konverter für ein Altformat: klar abgegrenzte Aufgaben mit prüfbarem Ergebnis, und damit die Klasse, in der KI-gestützte Entwicklung heute schon funktioniert. Wie eine solche Integrationsschicht für GxP-Prozesse aussieht, beschreibt unser Beitrag GxP-Compliance am Limit.

Abbildung 1 stellt beide Ansätze gegenüber: Wer Integrationsaufwand fürchtet, bezieht alles aus einer Quelle und nimmt schwach ausgeprägte Funktionen in Kauf. Wird die Integration mit KI-Unterstützung günstig und prüfbar, lassen sich spezialisierte Werkzeuge an den ERP-Kern anbinden, die ihre Aufgabe jeweils gut erfüllen. Die Darstellung ist schematisch.

Die Konsequenz ist nicht „jeder baut sein ERP“, sondern es wird unbequemer für Softwarelieferanten: Der Preis für eine Schnittstelle lässt sich nicht mehr aus ihrer Komplexität begründen. Wer heute pro Konnektor lizenziert, verkauft etwas, das der Kunde inzwischen selbst bauen und dessen Aufwand er nachrechnen kann.

Die Grenze liegt beim fachlichen Know-how. Chargenrückverfolgung, Serialisierung nach EU-FMD, Freigabelogiken, zwanzig Jahre akkumulierte Sonderfälle in einem Materialstamm: Das ist kein Code-Problem, sondern ein Domänenproblem. KI senkt die Kosten des Schreibens, nicht die Kosten des Wissens, was zu schreiben ist.

Die Architektur, die das möglich macht

PhotoCraft, das Photoshop-Pendant aus ArtCraft, ist nicht deshalb agentenfähig, weil es KI enthält, sondern weil jede Fachfunktion als ansprechbare Schnittstelle zur Verfügung steht. Oberfläche, Kommandozeile, Steuerkanal und MCP-Server rufen dieselbe Implementierung auf (Abbildung 2). Das ist keine Modeerscheinung, sondern die älteste saubere Trennung der Informatik, und sie entscheidet darüber, ob Systeme austauschbar sind.

In der Praxis heißt das: Der Prozess wird dort modelliert, wo er fachlich verankert ist, in BPMN, lesbar und prüfbar. Die technische Ausführung liegt in der Automatisierungsschicht. Der Datenbestand bleibt in den führenden Systemen.

Dieses Konzept hat das Lock-in bereits an der entscheidenden Stelle aufgelöst, lange bevor irgendetwas selbst entworfen wird. Denn der Austausch eines Bausteins wird dann zu einer Frage von Adaptern, nicht von Migrationsprojekten.

Für SAP-Landschaften heißt das konkret Clean Core: Erweiterungen greifen über freigegebene Schnittstellen wie OData, Events oder BAPIs auf den Kern zu, statt ihn zu modifizieren. Sie laufen auf der SAP® Business Technology Platform (BTP) oder in der Automatisierungsschicht. Nur so bleibt eine Ergänzung austauschbar und übersteht Releases des Kerns ohne Neuentwicklung.

In einem System, dessen Funktionen nur über Masken erreichbar sind, nützt die beste KI wenig. Sie kann dann klicken. Ein Klickpfad ist weder spezifizierbar noch reproduzierbar und damit in regulierten Umgebungen die schlechteste aller Optionen.

Was in regulierten Umgebungen zählt

Eine wesentliche Einschränkung benennt das Projekt selbst: Jeder Menüpunkt ist zwar angebunden, die Paritätstabelle prüft aber nur, ob eine Funktion aufrufbar ist, nicht, ob sie fachlich korrekt arbeitet.

In GxP-Umgebungen sind die Kosten für Entwurf und Implementierung nicht das Problem. Validierung, Lifecycle und der Betrieb sind es. KI senkt auch diese Kosten, aber ungleichmäßig. Validierung steigert nicht die Qualität, sie erbringt den Nachweis: Ein fehlerfreies System braucht denselben dokumentierten Nachweis wie ein System mit Fehlern.

Gerade die Daueraufwände im Lifecycle sprachen bisher gegen Individualsoftware: Testfälle aus Spezifikationen ableiten, Traceability pflegen, Abweichungen vorsortieren, Trendanalysen und Periodic Review vorbereiten. Diese Aufgaben lassen sich jetzt weitgehend automatisieren und laufend statt einmal jährlich durchführen. Hier liegt der unterschätzte Vorteil von KI in regulierten Umgebungen.

Die Entscheidung selbst lässt sich nicht automatisieren. Verantwortlich bleibt, wer die Korrektheit bestätigt und freigibt. Besondere Sorgfalt ist geboten, wenn Spezifikation, Code und Testfälle aus demselben Modell stammen. Ein bestandener Test belegt dann lediglich, dass die Artefakte untereinander konsistent sind; ob das System die Anforderungen erfüllt, ist damit nicht nachgewiesen. Die Unabhängigkeit der Prüfung ist deshalb eine inhaltliche Voraussetzung für eine belastbare Validierung. Testfälle sind aus der Anforderungsspezifikation abzuleiten, nicht aus der Implementierung. Die erwarteten Ergebnisse legt ein fachlich Verantwortlicher fest oder ein davon getrennter Prozess.

Die Wirtschaftlichkeit kippt trotzdem zugunsten des Eigenbaus, aber aus einem anderen Grund, als der Hype nahelegt (Tabelle 1):

Tabelle 1: Zugekauftes Modul und KI-gestützte Anbindung im Vergleich

Der Hebel ist also nicht die gesparte Entwicklungszeit, sondern der kalkulierbare, kleine und selbst bestimmte Validierungsgegenstand. Mit KI-gestützter Erstellung von Testfällen und Nachweisen ist eine Schnittstelle mit 200 Zeilen und zwölf Testfällen nach unserer Erfahrung in rund zwei Tagen validierbar. Manuell dauert das Wochen. Ein zugekauftes Modul bringt einen Funktionsumfang mit, den niemand bestellt hat und für den trotzdem ein Risikobewertungs- und Re-Validierungszyklus läuft.

Zwei Risiken, die man dafür einhandelt, in der Reihenfolge ihrer Relevanz:

1. Wartungsschuld. Code entsteht in Stunden, lebt aber zehn Jahre. Ohne verbindlichen Eigentümer je Komponente entsteht ein Bestand, den niemand mehr versteht. Es braucht die Disziplin, Lösungen zu inventarisieren, zu dokumentieren und Verantwortlichkeiten auf Rollen- statt auf Personenebene festzulegen.
2. Prüferwahrnehmung. Selbstentwickelte GxP-Software ist zulässig, zieht aber Aufmerksamkeit auf sich. Eine saubere Spezifikation, Risikobewertung und Testnachweise in derselben Form wie bei Standardsoftware entschärfen diesen Punkt.

Der regulatorische Rahmen zieht in dieselbe Richtung, ist aber noch nicht gesetzt: Der neue EU-GMP-Annex 22 zu künstlicher Intelligenz liegt seit der Konsultation vom 7. Juli 2025 im Entwurf vor und ist bislang nicht in Kraft; die Überarbeitung läuft, ob der ursprüngliche Ausschluss generativer Modelle nach dem EMA-Workshop von Ende Juni 2026 fallen wird, ist offen, wird aber diskutiert. Er ersetzt weder Annex 11 noch Kapitel 4, sondern ergänzt sie. Wer heute Systeme und Applikationen entwirft, sollte nicht auf ein Datum warten, sondern auf die Prinzipien bauen, die in allen Entwurfsfassungen stabil sind: definierter Verwendungszweck, risikobasierte Prüfung, menschliche Entscheidung bei kritischen Schritten.

Was daraus folgt

Das ERP-System bleibt Standardsoftware. Für Ergänzungen, deren Entwicklungsaufwand sich heute selbst kalkulieren lässt, sollten Lizenzkosten jedoch kritisch geprüft werden.

Drei Schritte:

1. Den eigenen Bestand nach Lücken sortieren. Welche Module, Konnektoren und Zusatzlizenzen decken eine Funktion ab, die kleiner ist als ihr Preis? Eine Kosten-Nutzen-Betrachtung, kein Projekt.
2. Die Adressierbarkeit prüfen, bevor etwas entworfen wird. Ein System, dessen Fachfunktionen nur über Masken erreichbar sind, bleibt geschlossen, egal wie gut die Werkzeuge werden. Das ist das härtere Auswahlkriterium für Neubeschaffungen als jede Funktionsliste.
3. Den Validierungspfad vor dem ersten Prompt festlegen. Anforderung, Risikobewertung, Testfälle gegen die Anforderung, benannter Eigentümer, Eintrag im Systeminventar. Wer das nachgelagert erledigt, arbeitet im Anschluss in einem nicht validierten System.

Empfehlung: Nehmen Sie Prozesse und Anforderungen auf und setzen Sie an einer fachlich kleinen Schnittstelle einen validierten Pilot um, etwa an einem Konnektor, einem Reporting-Export oder einem Formatwandler. Nicht als Pilot für die Technik, die funktioniert. Als Pilot für den Validierungsweg, denn der ist der eigentliche Engpass.

Standardsoftware behält ihre Berechtigung, vor allem im ERP-Kern. An den Rändern verschieben sich die Entscheidungskriterien aber zugunsten der Individualsoftware: KI senkt den Aufwand für Entwicklung, Validierung und Wartung so weit, dass sich eine passgenaue Lösung häufiger rechnet als ein zugekauftes Modul. Umsetzen kann sie zunehmend der Business Analyst, der Prozesswissen und IT-Verständnis verbindet und nicht mehr nur spezifiziert. Der Aufpreis für Geschlossenheit lässt sich damit nicht mehr durchsetzen.

Warum Significon

Die oben dargestellte Kostenbetrachtung setzt voraus, dass drei Kompetenzen in einer Hand liegen: fachliches Prozesswissen, die Verantwortung für die Validierung und der Lösungsentwurf. Werden diese Rollen auf drei Dienstleister verteilt, zehrt der Abstimmungsaufwand den Kostenvorteil wieder auf. Häufiges Ergebnis ist eine Schnittstelle, die technisch funktioniert, aber von der Qualitätssicherung nicht freigegeben wird.

Wir decken diese Rollen in einem Haus ab. Die Significon AG arbeitet in SAP-Landschaften bei Pharma-, Medizintechnik- und Chemieunternehmen und bewegt sich in GxP-Umgebungen als Normalfall. Unsere Berater entwerfen mit Ihnen Ihren Prozess, setzen ihn anschließend um und führen die Validierung gemäß Ihren lokalen QA-Vorgaben durch.

Unser Angebot umfasst drei Bausteine:

• Prozess- und Anforderungsaufnahme. Gemeinsam mit Ihren Fachbereichen erfassen wir Prozess, Anforderungen und GxP-Relevanz der Schnittstellen und Ergänzungen rund um Ihr ERP. Ergebnis ist eine priorisierte Kandidatenliste mit Aufwandsschätzung.
• Pilot an einer überschaubaren Schnittstelle. Von der Anforderungsspezifikation über Risikobewertung und Testnachweis bis zur Übergabe in Ihren Betrieb. Der Pilot zeigt, ob der Validierungsweg trägt, und liefert die Ist-Zahlen für den Vergleich mit einem zugekauften Modul.
• Zielarchitektur. Prozessmodellierung in BPMN, Ausführung in der Automatisierungsschicht, Datenhaltung im führenden System, ohne redundante Statusführung.

Zeigt der Pilot, dass ein zugekauftes Modul wirtschaftlicher ist, sagen wir Ihnen das. Ein Projekt, das sich nicht rechnet, empfehlen wir nicht.

Sprechen Sie uns an: Wir nehmen gemeinsam mit Ihnen Prozesse und Anforderungen auf und setzen darauf aufbauend einen validierten Pilot um. Danach haben Sie eine belastbare Grundlage für die Entscheidung zwischen Eigenentwicklung und Modul. Bei Significon kommen SAP-Prozesswissen, GxP-Validierungserfahrung und Lösungsarchitektur in einem Team zusammen.

SAP, SAP S/4HANA und SAP Business Technology Platform sind Marken oder eingetragene Marken der SAP SE oder ihrer verbundenen Unternehmen in Deutschland und anderen Ländern. Adobe, Photoshop, Illustrator und Premiere sind Marken oder eingetragene Marken der Adobe Inc. in den USA und/oder anderen Ländern. Alle weiteren genannten Produkt- und Firmennamen sind Marken ihrer jeweiligen Inhaber.