Composable ERP
Woher der Begriff kommt, wie er sich von Best of Breed und Clean Core unterscheidet und was er für Integration, Betrieb und die ERP-Auswahl bedeutet
Kernaussagen
- Composable ERP ist eine Architekturstrategie: Ein ERP-Kern führt Stammdaten und Buchungen, eigenständige Bausteine übernehmen die Prozesse, in denen sich ein Unternehmen unterscheidet oder die sich häufig ändern. Verbunden sind beide über Schnittstellen und meist über eine Integrationsplattform.
- Was eine integrierte Suite intern zusammenhält, wird damit zur Aufgabe des Unternehmens: Datenabgleich, Tests bei jedem Update und die Verantwortung für jede einzelne Schnittstelle. Wer das nicht betreiben kann, tauscht Funktionslücken gegen Schnittstellenfehler.
- Die Bausteine sollten entlang von Prozessen geschnitten werden, nicht entlang von Modulen oder Anbietern. Diese Sicht vertritt auch die Forschung zu prozesszentrierten Geschäftsprozessplattformen [3].
- In der Auswahl verschiebt sich die Prüfung von der Funktionsbreite zu der Frage, welche Geschäftsobjekte über stabile Schnittstellen erreichbar sind und wer die Verbindungen betreibt.
Der Begriff stammt von Gartner und beschreibt eine Architekturstrategie
Composable ERP ist ein Begriff des Analystenhauses Gartner [1]. Er knüpft an eine ältere Gartner-Vorhersage an: Unter dem Namen Postmodern ERP erwartete Gartner, dass das monolithische ERP in lose gekoppelte, überwiegend cloudbasierte Anwendungen zerfällt [1][2]. Den Zwischenschritt beschreibt ein früherer Gartner-Analyst, der heute für SAP schreibt. 2019 schlug Gartner vor, das ERP auf seinen standardisierten Kern zurückzuführen und mit wechselnden fachlichen Fähigkeiten zu umgeben; die Architektur sollte sich an Geschäftsfähigkeiten ausrichten statt an Modulen [2]. Composable ERP ist der heutige Name für diese Idee [2]. 2020 sprach Gartner vom Leitbild der „Composable Enterprise“, auf das sich auch die Forschung bezieht [3].
Gartner beschreibt damit einen Weg, Unternehmenssoftware so zusammenzusetzen, dass sich einzelne Teile ändern lassen, ohne das Ganze zu ersetzen. Wenn Hersteller ihre Produkte inzwischen selbst „composable“ nennen, beschreiben sie, wie gut sich ihr System in eine solche Landschaft einfügt. Zusammengesetzt wird die Landschaft beim Kunden.
Die Definitionen setzen unterschiedliche Schwerpunkte
| Quelle | Definition (sinngemäß übersetzt) | Schwerpunkt |
|---|---|---|
| Gartner, wiedergegeben bei TechTarget [1] | Eine anpassungsfähige Technologiestrategie, die eine Grundlage aus administrativen und operativen Fähigkeiten schafft, mit der Unternehmen schneller auf Veränderungen ihres Geschäftsumfelds reagieren. Häufig werden dafür On-Premise- und Cloud-Anwendungen kombiniert | Strategie und Reaktionsfähigkeit |
| SAP, Beitrag eines früheren Gartner-Analysten [2] | Flexible, modulare, über APIs verbundene ERP-Fähigkeiten aus der Cloud, aus denen Unternehmen Lösungen zusammensetzen und bei Bedarf neu zusammensetzen | Bausteine und ihre Verbindung |
| Böhme, Wuttke, Bender u. a., AMCIS 2023 [3] | Keine Definition des Begriffs, sondern ein Gegenentwurf zum ERP aus Modulen: eine Plattform, in der Geschäftsprozesse eigenständige, anpassbare Einheiten sind, als Schritt zu Gartners „Composable Enterprise“ | Prozesse statt Module |
Gartner betont die Reaktionsfähigkeit des Unternehmens, SAP die technischen Bausteine, die Forschung den Geschäftsprozess als Einheit, aus der sich die Landschaft zusammensetzt. Einig sind sich die Quellen darin, dass ein einzelnes System nicht mehr alles abdecken muss.
Unser Verständnis
Wir verstehen Composable ERP als Architekturentscheidung mit zwei Teilen. Ein ERP-Kern führt die verbindlichen Stammdaten und Buchungen, also das, worauf sich Finanzen, Lager und Auftragsabwicklung verlassen müssen. Prozesse, in denen sich ein Unternehmen vom Wettbewerb unterscheidet oder die sich häufig ändern, laufen in eigenständigen Bausteinen, die über definierte Schnittstellen an den Kern angebunden sind. Der Ausgangspunkt ist der Prozess mit seinen Besonderheiten, nicht das System. „Composable“ ist damit eine Eigenschaft der Landschaft. Erreicht wird sie über drei Festlegungen: welches System welche Daten führt, über welche Schnittstellen die Bausteine verbunden sind und wer diese Verbindungen betreibt. Die Kurzdefinition steht im Glossar unter Composable ERP.
Im Beispiel trägt ein ERP-Kern vier Bausteine
Ein mittelständischer Pumpenhersteller verkauft Ersatzteile über einen eigenen Webshop und betreibt einen Außendienst, der Anlagen beim Kunden wartet. Er hat sich für einen ERP-Kern und vier Bausteine entschieden:
| System | Aufgabe | führt die Daten zu | bezieht aus dem Kern |
|---|---|---|---|
| ERP-Kern | Finanzen, Einkauf, Lager, Produktion, Auftragsabwicklung | Kunden, Lieferanten, Artikel, Preise, Bestände, Buchungen | – |
| Webshop für Ersatzteile | Bestellungen von Kunden | Produkttexte und Bilder | Preise, Verfügbarkeit, Kundenkonditionen |
| Service-App für den Außendienst | Einsatzplanung, Serviceberichte | Anlagen beim Kunden, Einsätze, Serviceberichte | Kunden, Artikel, Ersatzteilbestand |
| Feinplanung in der Fertigung | Reihenfolge an den Maschinen | Maschinenbelegung | Fertigungsaufträge, Termine |
| Analyse | Auswertungen über alle Systeme | Kennzahlen | liest aus allen Systemen |
Lehrbeispiel, kein Kundenprojekt.
Fünf Systeme, die alle miteinander Daten austauschen, ergeben bis zu zehn Punkt-zu-Punkt-Verbindungen. Über eine Integrationsplattform (siehe Glossar, Middleware / iPaaS) braucht jedes System nur eine Anbindung. Dafür kommt die Plattform als sechstes System hinzu, das betrieben werden muss. Wie viel Integrationsarbeit in der Landschaft steckt, zeigt ein einziger Serviceeinsatz:
- Ein Kunde meldet eine Störung an einer Pumpe. Der Einsatz entsteht in der Service-App, die Kundendaten kommen aus dem ERP-Kern.
- Der Techniker braucht ein Ersatzteil. Die App fragt den Bestand im Kern ab, die Entnahme wird dort gebucht.
- Nach dem Einsatz meldet der Techniker Arbeitszeit und Material zurück. Der Kern erstellt daraus die Rechnung und bucht sie.
- Die Analyse wertet Einsätze und Kosten je Anlage aus.
Jeder dieser Schritte überquert eine Schnittstelle. Bleibt die Rückmeldung aus Schritt 3 hängen, entsteht keine Rechnung, und weder die App noch der Kern zeigen das von selbst an. In einer integrierten Suite wäre derselbe Ablauf ein Vorgang in einem System.
Die Forschung setzt bei Prozessen statt bei Modulen an
Böhme, Wuttke, Bender und weitere Autoren haben auf der Americas Conference on Information Systems (AMCIS) 2023 untersucht, woran heutige ERP-Systeme in wachsenden Unternehmen stoßen [3]. Grundlage waren 15 Interviews mit Gründern und Verantwortlichen für ERP- und Unternehmenssoftware im deutschsprachigen Raum, vom Start-up bis zum internationalen Konzern. Die Ergebnisse wurden mit sechs Fachleuten eines ERP-Herstellers abgeglichen.
Drei Probleme traten hervor. Prozesse sind im System implizit: Sie stecken in der Folge von Belegen wie Auftrag, Lieferschein und Rechnung und sind kaum dokumentiert. Die Einstiegshürde ist hoch, weil Module voneinander abhängen, mehr Funktionen mitbringen als gebraucht werden und Standardprozesse vorgeben. Und die Systeme lassen sich schlecht mit anderen Anwendungen verbinden; auch größere Unternehmen mit Best-of-Breed-Strategie kämpfen mit heterogenen Landschaften und doppelter Datenhaltung [3].
Die Antwort der Autoren ist eine Geschäftsprozessplattform (Business Process Platform). In ihr sind Geschäftsprozesse eigenständige, ausführbare und grafisch dargestellte Einheiten statt Module für einzelne Abteilungen. Ein Unternehmen nimmt Prozesse auf oder lässt sie weg, ohne ein Modul mit überschüssigen Funktionen einzuführen, und stellt einzelne Prozesse auf eine Vorlage für größere Unternehmen um, wenn es wächst. Fremde Software wird über abstrakte Schnittstellen als Schritt in einen Prozess eingebunden. Semantisch beschriebene Daten sollen den Austausch zwischen Systemen erleichtern, eine cloudnative Basis soll Skalierung und Verfügbarkeit liefern [3].
Für die Praxis zählt vor allem der Perspektivwechsel: Der Zuschnitt der Bausteine geht vom Prozess aus. Im Beispiel ist der Serviceeinsatz die Einheit, nicht das Modul „Service“. Dazu passt eine frühere Arbeit aus Potsdam zur Datenhaltung. Bender, Bertheau, Körppen, Lauppe und Gronau zeigen, dass kein einzelnes Datenbankkonzept alle heutigen Anforderungen an ERP-Systeme erfüllt, und plädieren für föderierte Datenbanken, die untereinander Daten austauschen können [4]. Verteilte Daten gehören in einer zusammengesetzten Landschaft also zum Bauprinzip. Umso mehr hängt davon ab, wer welche Daten führt.
Die Autoren schränken selbst ein: Ihr Ansatz passt besonders zu Start-ups und wachsenden Unternehmen, die sich schnell anpassen müssen. Größere Unternehmen mit eingespielten Abläufen profitieren nach ihrer Einschätzung weniger, weil sie ihre Systeme seltener umbauen [3].
Best of Breed und Clean Core beantworten andere Fragen
Zwei Begriffe fallen in Architekturgesprächen fast immer zusammen mit Composable ERP. Beide meinen etwas anderes.
| Merkmal | Best of Breed | Composable ERP | Clean Core |
|---|---|---|---|
| Leitfrage | Welches Produkt ist je Aufgabenbereich das stärkste? | Welche Prozesse laufen im Kern, welche in eigenen Bausteinen? | Wie bleibt der ERP-Kern updatefähig? |
| Ausgangspunkt | Fachbereich und Produktauswahl | Prozess und Datenhoheit | Erweiterungen am ERP |
| Rolle des ERP | ein Spezialsystem unter mehreren | Kern für Stammdaten und Buchungen | Standard, der unverändert bleibt |
| Typische Gefahr | widersprüchliche Datenstände | Integrations- und Betriebsaufwand unterschätzt | Anforderungen wandern in Nebenanwendungen, deren Betrieb niemand geklärt hat |
Einordnung von Find-Your-ERP auf Grundlage von [5], [6] und dem ERP-Glossar.
Best of Breed wählt für jeden Aufgabenbereich die stärkste Speziallösung und verbindet sie mit den übrigen Systemen (siehe Glossar, Best of Breed). Der Ansatz denkt vom Produkt her und braucht kein ERP als Zentrum. Composable ERP setzt einen stabilen Kern voraus und fragt erst danach, welche Prozesse daneben laufen; ein Baustein kann dabei auch ein Modul des ERP-Herstellers sein. Wie sich Spezialisten und Suite grundsätzlich gegeneinander abwägen lassen, beschreibt find-your-software.de unter Best-of-Breed vs. All-in-One.
Clean Core ist vor allem ein Begriff von SAP. Erweiterungen werden strikt von der Standardanwendung getrennt und greifen auf Geschäftsobjekte nur über definierte, upgradestabile Schnittstellen zu [6]. Andere Hersteller verfolgen dasselbe Prinzip unter eigenen Namen (siehe Glossar, Clean Core). Eine Literaturstudie von Abendroth, Bender und Gronau beschreibt die Richtung dahinter: Angepasst wird in Cloud-ERP-Systemen immer weniger durch Änderungen am Programmcode und immer mehr über Schnittstellen und Integration [5]. Clean Core ist damit die Voraussetzung dafür, dass der Kern in einer zusammengesetzten Landschaft stabil bleibt. Umgekehrt gilt das nicht: Ein sauberer Kern ohne Bausteine ist eine standardnah genutzte Suite. Wie sich Anpassungen im Kern, an vorgesehenen Erweiterungspunkten und neben dem ERP unterscheiden, zeigt das Stufenmodell im Beitrag zum ERP-Customizing.
Eine API macht noch kein Composable ERP
In Auswahlprojekten begegnen uns drei Irrtümer immer wieder.
Der erste lautet, ein System mit Programmierschnittstelle sei schon composable. Entscheidend ist, welcher Ausschnitt des Systems über die Schnittstelle erreichbar ist (siehe Glossar, Schnittstelle / API). Ein Kern muss seine wichtigen Geschäftsobjekte lesend und schreibend über freigegebene Schnittstellen anbieten, die Updates überstehen, und Änderungen als Ereignisse melden, damit andere Systeme nicht ständig nachfragen müssen.
Der zweite: Composable ERP mache die Landschaft schlanker und günstiger. Kleinere Lizenzpakete sind möglich, dafür kommen Kosten für die Integration und den Betrieb der Plattform hinzu. Der frühere Gartner-Analyst Mike Guay rät, genau abzuwägen, bevor ein Prozess mit hohem Transaktionsvolumen und vielen Daten, die konsistent bleiben müssen, aus einer Herstellerlösung herausgelöst wird. Gartner-Kunden, die nur die Finanzbuchhaltung ersetzen wollten, kamen von Einkauf und Kreditorenbuchhaltung schwer los, weil dort die Lieferantendaten lagen [1].
Der dritte: Je mehr Bausteine, desto flexibler. Jeder Baustein bringt eine weitere Schnittstelle, einen eigenen Release-Zyklus und einen weiteren Vertragspartner. Composable ERP ist deshalb keine Einladung, immer mehr Software einzuführen. Flexibel wird eine Landschaft durch wenige, gut geschnittene Bausteine mit klarer Datenhoheit.
Integration und Betrieb gehen vom Hersteller auf das Unternehmen über
In einer integrierten Suite hält der Hersteller die Teile zusammen. Er pflegt ein gemeinsames Datenmodell, testet seine Module miteinander und liefert Updates für das Ganze. In einer zusammengesetzten Landschaft übernimmt das Unternehmen diese Arbeit, selbst oder mit einem Partner.
| Aufgabe | Integrierte Suite | Composable ERP |
|---|---|---|
| Datenabgleich zwischen Bereichen | im gemeinsamen Datenmodell | über Schnittstellen, je Objekt mit festgelegtem führendem System |
| Updates | ein Release-Zyklus, vom Hersteller getestet | ein Zyklus je Baustein; Verbindungen nach jedem Update testen |
| Störung in einer Prozesskette | ein Ansprechpartner für das Gesamtsystem | Ursache kann im Kern, im Baustein oder auf der Plattform liegen; Zuständigkeit vorher regeln |
| Berechtigungen und Nachvollziehbarkeit | ein Rollenmodell | Rollen und Protokolle über Systemgrenzen hinweg abstimmen |
| Wissen im eigenen Haus | Anwendungsbetreuung | zusätzlich Integrationsarchitektur und Betrieb der Plattform |
Am häufigsten unterschätzt wird die Verantwortung für die einzelne Schnittstelle. Jeder Hersteller pflegt seine eigene Programmierschnittstelle, die Verbindung zwischen zwei Systemen pflegt keiner von beiden. Für jede Verbindung braucht es deshalb jemanden, der fachlich verantwortet, welche Daten in welche Richtung fließen, und jemanden, der die Verbindung technisch betreibt und Störungen behebt. Beides gehört in die Verträge mit Herstellern und Implementierungspartnern, bevor die erste Verbindung gebaut wird. Welche Schnittstellenarten es gibt und wann sich eine Middleware lohnt, beschreibt find-your-software.de unter ERP-Schnittstellen.
Mit jedem Update eines Bausteins ist zu prüfen, ob die Verbindungen noch tragen. Bei Cloud-Software bestimmt der Anbieter den Takt, und mehrere Bausteine bedeuten mehrere Takte, die sich nicht aufeinander abstimmen lassen. Automatisierte Tests der wichtigsten Prozessketten, im Beispiel der Serviceeinsatz bis zur Rechnung, gehören deshalb zum Betrieb.
In der Auswahl zählt, was über die Schnittstellen erreichbar ist
Vor der Systemauswahl steht das Zielbild: welche Prozesse im Kern bleiben, welche als Baustein laufen und welches System welche Daten führt. Erst danach lässt sich prüfen, ob ein ERP als Kern taugt. Ein solches Zielbild erarbeiten wir mit Unternehmen in der Leistung ERP-Strategie und Roadmap.
In der Demo zeigt sich der Unterschied, wenn der Anbieter einen Prozess über Systemgrenzen hinweg durchspielen muss. Geben Sie dafür ein Szenario wie den Serviceeinsatz aus dem Beispiel vor, so wie es das Drehbuch für Anbieterpräsentationen beschreibt. Diese Prüffragen trennen einen tragfähigen Kern von einem System, das nur eine Liste von Schnittstellen vorzeigt:
| Prüffrage | Woran Sie es in der Demo erkennen |
|---|---|
| Welche Geschäftsobjekte sind über freigegebene Schnittstellen erreichbar? | Die Dokumentation deckt Kunde, Artikel, Auftrag und Buchung ab; in der Demo legt der Anbieter einen Auftrag über die Schnittstelle an |
| Bleiben die Schnittstellen bei Updates stabil? | Versionierung und Fristen für abgekündigte Schnittstellen sind dokumentiert; der Anbieter benennt, welche Schnittstellen als upgradestabil freigegeben sind |
| Meldet das System Änderungen als Ereignisse? | Eine Statusänderung am Auftrag löst eine Nachricht aus, die ein anderes System empfängt |
| Wie werden Erweiterungen umgesetzt? | Anpassungen laufen über vorgesehene Erweiterungspunkte oder daneben, ohne Änderung am Kern |
| Welche Integrationswerkzeuge gehören dazu, und was kosten sie? | Konnektoren, Plattform und die Abrechnung von Schnittstellenaufrufen stehen im Angebot |
| Wer betreibt und überwacht die Verbindungen? | Anbieter oder Partner nennen Zuständigkeit, Überwachung und Fehlerbehandlung; das Angebot enthält neben dem Aufbau auch den Betrieb |
| Lässt sich ein Vorgang über Systemgrenzen nachverfolgen? | Der Serviceeinsatz ist vom Auftrag bis zur Rechnung über alle beteiligten Systeme nachvollziehbar |
Häufige Fragen
Ist Composable ERP dasselbe wie eine Microservice-Architektur?
Nein. Microservices beschreiben, wie ein Hersteller seine Software technisch in kleine, einzeln betreibbare Dienste zerlegt. Composable ERP beschreibt, wie ein Unternehmen seine Anwendungslandschaft fachlich zuschneidet. Ein ERP aus Microservices kann als geschlossene Suite im Einsatz sein, und eine zusammengesetzte Landschaft kann aus klassisch gebauten Systemen bestehen.
Lässt sich ein bestehendes ERP schrittweise zu einem Kern mit Bausteinen umbauen?
Ja, und meist ist das der realistische Weg. Begonnen wird an einem Rand mit klarer Grenze und eigenem Nutzen, etwa beim Webshop oder im Außendienst, und nicht in der Finanzbuchhaltung, die eng mit Einkauf und Kreditoren verflochten ist [1]. Voraussetzung ist, dass das bestehende ERP seine Daten über Schnittstellen anbietet. Die Frage, ob es als Kern taugt oder abgelöst werden sollte, behandelt der Beitrag ERP-Upgrade oder Ablösung.
Ist Composable ERP auch für kleinere Mittelständler sinnvoll?
Die Forschung sieht den größten Nutzen bei wachsenden Unternehmen, die ihre Prozesse häufig anpassen [3]. Dem steht der Betriebsaufwand gegenüber: Wer keine eigenen Leute für Integration hat, braucht einen Partner, der Plattform und Verbindungen dauerhaft betreut. Für viele kleinere Unternehmen ist ein standardnah genutztes ERP mit wenigen angebundenen Fachanwendungen der tragfähigere Weg.
Kann man einen Baustein später ohne Weiteres gegen ein anderes Produkt tauschen?
Nur, wenn das beim Zuschnitt vorbereitet wurde. Austauschbar ist ein Baustein, wenn der Kern die gemeinsamen Daten führt und der Baustein über dokumentierte Schnittstellen angebunden ist, die nicht auf seine Eigenheiten zugeschnitten sind. Dazu gehört ein vertraglich zugesicherter Export der Daten, die der Baustein selbst führt, im Beispiel der Anlagendaten und Serviceberichte.
Weiterlesen
Kurzdefinitionen zu Composable ERP, Best of Breed, Clean Core, Schnittstelle und Middleware.
Das Stufenmodell von der Konfiguration bis zur Kernmodifikation und warum Erweiterungen neben dem ERP updatefest bleiben.
Wann das bestehende ERP als Kern weiterträgt und wann ein Neustart das Zielbild schneller erreicht.
Zielarchitektur, ERP-zentriert oder modular, mit priorisiertem Umsetzungspfad: unser Beratungsangebot.
Die Grundsatzentscheidung zwischen Spezialisten und Suite, mit dem hybriden Weg Best-of-Fit.
Schnittstellenarten, Middleware und iPaaS im Vergleich, mit Aufwand und typischen Fallstricken.
Quellen
[1] Essex, D. (2022): Evolution of postmodern ERP to composable ERP explained. TechTarget, 30. März 2022, Gespräch mit dem früheren Gartner-Analysten Mike Guay. Abgerufen am 9. November 2026.
[2] Saunders, P. (2025): ERP vs. enterprise management: Why words (still) get in the way. SAP, 25. August 2025. Abgerufen am 9. November 2026.
[3] Böhme, L.; Wuttke, T.; Bender, B.; Teusner, R.; Baltes, S.; Matthies, C.; Perscheid, M. (2023): From Full-fledged ERP Systems Towards Process-centric Business Process Platforms. AMCIS 2023 Proceedings, Panama City.
[4] Bender, B.; Bertheau, C.; Körppen, T.; Lauppe, H.; Gronau, N. (2022): A proposal for future data organization in enterprise systems: an analysis of established database approaches. Information Systems and e-Business Management 20, S. 441–494.
[5] Abendroth, A.; Bender, B.; Gronau, N. (2024): The Evolution of Original ERP Customization: A Systematic Literature Review of Technical Possibilities. Proceedings of the 26th International Conference on Enterprise Information Systems (ICEIS 2024), S. 17–27.
[6] SAP Learning: Introducing the Clean Core Approach. Kurs „Practicing Clean Core Extensibility for SAP S/4HANA Cloud“. Abgerufen am 9. November 2026.
Herstellerquellen belegen allgemeine Prinzipien und sind keine Produktempfehlung.
Dr. Benedict Bender
Co-Founder der Sectorlens GmbH
Besprechen Sie Ihre Zielarchitektur mit einem ERP-Berater
Im Gespräch klären Sie mit einem Berater, welche Prozesse in Ihren ERP-Kern gehören und welche Bausteine sich für Sie rechnen. 30 Minuten, kostenlos und unverbindlich. Anbieterneutral: Kein Anbieter kann seine Platzierung kaufen oder beeinflussen.
Sie haben eine Frage? Dann schicken Sie uns gern eine Nachricht.