Composable ERP im Unternehmen: Modular modernisieren, ohne den ERP-Kern zu entwerten

Viele Unternehmen stehen heute nicht vor der simplen Frage, ob sie ein neues ERP brauchen. Die schwierigere Frage lautet: Wie lässt sich eine gewachsene ERP-Landschaft modernisieren, ohne den laufenden Betrieb zu destabilisieren? Genau an dieser Stelle taucht der Begriff composable ERP auf.

Der Begriff klingt schnell nach Technologietrend. In der Praxis beschreibt er jedoch vor allem eine Architekturentscheidung. Soll das ERP möglichst jede neue Anforderung selbst aufnehmen, oder ist es sinnvoller, einen stabilen Kern mit gezielt angebundenen Spezialfähigkeiten zu kombinieren? Für das Unternehmen ist das keine akademische Diskussion, sondern eine Frage von Änderungsfähigkeit, Betriebsstabilität und wirtschaftlicher Umsetzbarkeit.

Composable ERP ist deshalb weder ein neues Schlagwort für beliebige Tool-Sammlungen noch ein Gegenmodell zum ERP selbst. Gemeint ist eine Modernisierungslogik, bei der der ERP-Kern für transaktionskritische Prozesse, verbindliche Geschäftsobjekte und kaufmännische Steuerung bewusst stabil gehalten wird, während einzelne Fähigkeiten modular angebunden oder ersetzt werden können.

Was mit composable ERP gemeint ist

Composable ERP bezeichnet keinen einzelnen Produkttyp. Gemeint ist ein Aufbau, bei dem Unternehmen ihre ERP-Landschaft nicht ausschließlich als einen geschlossenen Systemblock weiterentwickeln, sondern gezielt zwischen Kern und Erweiterung unterscheiden.

Zum stabilen Kern gehören typischerweise Prozesse und Logiken, bei denen Konsistenz und Verbindlichkeit entscheidend sind. Dazu zählen etwa Buchungslogik, Finanzprozesse, Belegketten, verbindliche Auftrags- und Bestandszustände oder zentrale kaufmännische Datenmodelle. Genau diese Bereiche werden in vielen Unternehmen nicht deshalb im ERP geführt, weil das System traditionell dort steht, sondern weil hier keine mehrdeutige Wahrheit entstehen darf.

Modular angebunden werden dagegen häufig Fähigkeiten, die schnellerem Wandel unterliegen oder fachlich spezialisierter sind, zum Beispiel:

• E-Commerce- und Portal-Funktionen
• Service- und Ticketing-Prozesse
• Workflow- und Freigabelogik
• Reporting-, BI- und Analysebausteine
• Planungs- und Forecasting-Funktionen
• Partner- und Integrationslogik zwischen mehreren Systemen

Der Kernpunkt ist nicht die Zahl der Module. Der Kernpunkt ist die Rollenklarheit. Ein composable ERP-Ansatz ist nur dann tragfähig, wenn eindeutig feststeht, welches System für welche Daten und Prozesszustände führend ist, wie Informationen synchronisiert werden und wie Änderungen kontrolliert in Betrieb gehen.

Worin sich composable ERP von einem klassischen Monolithen unterscheidet

Ein klassisches ERP verfolgt die Logik, möglichst viele Anforderungen innerhalb einer eng integrierten Suite abzubilden. Das kann im Mittelstand sehr sinnvoll sein. Ein konsistenter Daten- und Betriebsrahmen reduziert Abstimmungsaufwand, vereinfacht Verantwortlichkeiten und macht den Gesamtbetrieb oft robuster.

Problematisch wird der Monolith dort, wo jede neue Anforderung nur noch über weiteres Customizing, Zusatzlogik oder Sonderanbindungen in denselben Kern gepresst werden kann. Dann bleibt das System zwar formal integriert, wird aber mit jeder Anpassung schwerer zu ändern. Upgrades werden heikel, Abhängigkeiten wachsen, und fachliche Sonderwege bleiben immer tiefer im Kern verankert.

Composable ERP setzt genau an diesem Punkt an. Der Ansatz fragt nicht zuerst, welche Suite am meisten kann. Er fragt, welche Fähigkeiten aus fachlichen und betrieblichen Gründen zentral bleiben müssen und welche gezielt außerhalb des Kerns besser aufgehoben sind.

Der Unterschied liegt damit weniger in der Formel Suite gegen Best of Breed, sondern in der Modernisierungslogik:

• Monolithische Logik: Neue Anforderungen werden möglichst innerhalb des ERP-Kerns abgebildet.
• Composable Logik: Der ERP-Kern bleibt bewusst schlanker, während ausgewählte Fähigkeiten modular angebunden werden.

Wichtig ist dabei: Composable ERP ist kein Automatismus für bessere Architektur. Wenn ein vorhandenes ERP die relevanten Prozesse wartbar, wirtschaftlich und upgradefähig abbildet, schafft zusätzliche Modularität keinen Mehrwert. Interessant wird der Ansatz erst dort, wo Veränderungsdruck, Integrationsbedarf oder historisch gewachsene Anpassungen mit der bestehenden ERP-Logik kollidieren.

Warum das Thema für KMU relevant wird

In vielen kleinen und mittleren Unternehmen ist nicht das ERP als solches das Problem, sondern die Art, wie sich über Jahre neue Anforderungen daran angelagert haben. Ein Webshop wurde angebunden, ein Partnerprozess per Sonderlogik ergänzt, Auswertungen außerhalb aufgebaut, ein Serviceprozess notdürftig im ERP mitgeführt. Das Ergebnis ist oft keine saubere Suite mehr, sondern ein schwer durchschaubares Geflecht aus Kernlogik, Erweiterungen und Abhängigkeiten.

Typische Auslöser für eine composable Diskussion sind:

• ein neuer Vertriebskanal soll enger mit Auftrags- und Bestandslogik gekoppelt werden
• Service- oder Freigabeprozesse passen nicht mehr sinnvoll in die vorhandenen ERP-Masken
• Reporting und Planung brauchen mehr Tempo oder fachliche Tiefe als das bestehende ERP hergibt
• EDI-, Logistik- oder Partneranbindungen werden geschäftskritisch
• einzelne Altmodule sind fachlich oder technisch überholt, während der ERP-Kern kurzfristig nicht komplett ersetzt werden kann

Gerade für KMU ist das relevant, weil Budgets, interne Kapazitäten und Projekttoleranzen meist begrenzt sind. Ein phasenweises Modernisierungsvorgehen ist oft realistischer als ein Komplettaustausch. Composable ERP kann hier eine sinnvolle Denkweise sein, wenn es nicht als Abkürzung missverstanden wird. Der Ansatz reduziert nicht automatisch Komplexität. Er verlagert sie von einem überladenen Kern hin zu mehr Integrations-, Steuerungs- und Governance-Arbeit.

Welche Vorteile composable ERP realistisch bringen kann

Der Nutzen eines composable ERP-Ansatzes liegt nicht in mehr Technologie, sondern in einer besseren Verteilung von Veränderung und Stabilität.

Schrittweise Modernisierung statt Komplettumbau

Unternehmen können einzelne Fähigkeiten gezielt erneuern, ohne sofort den gesamten ERP-Kern ablösen zu müssen. Das senkt Projektrisiken und macht Investitionen besser etappierbar.

Bessere Passung für spezialisierte Anforderungen

Nicht jede Anforderung ist im ERP-Kern fachlich gut aufgehoben. Portale, Serviceprozesse, Analytik oder flexible Freigabeabläufe lassen sich in spezialisierten Bausteinen oft sauberer entwickeln und betreiben als in tief angepassten ERP-Oberflächen.

Entlastung des ERP-Kerns

Wer nicht jede Erweiterung im Kern unterbringt, verhindert, dass das ERP mit historischer Sonderlogik überfrachtet wird. Das verbessert mittelfristig auch die Perspektive für Wartung, Upgradefähigkeit und Releasewechsel.

Höhere Anpassungsfähigkeit an neue Anforderungen

Wenn Markt, Partnerprozesse oder interne Abläufe sich ändern, müssen nicht jedes Mal zentrale ERP-Strukturen umgebaut werden. Unternehmen können gezielter entscheiden, wo eine Änderung fachlich und betrieblich am besten verankert wird.

Diese Vorteile entstehen allerdings nur dann, wenn Architekturentscheidungen zentral gesteuert werden. Mehr Module ohne klares Zielbild erzeugen keine Agilität, sondern nur neue Abhängigkeiten.

Wo die Risiken liegen

Composable ERP ist kein Schonraum vor Komplexität. Der Ansatz kann historisch gewachsene Probleme entschärfen, führt aber zu neuen Anforderungen, die oft unterschätzt werden.

Integration wird zum kritischen Erfolgsfaktor

Wo mehr Systeme gemeinsam Prozesse tragen, steigen die Anforderungen an APIs, Events, Mapping, Monitoring und Fehlerbehandlung. Ohne belastbare Integrationslogik wird aus modularem Aufbau schnell ein neuer Flickenteppich.

Datenhoheit muss explizit geregelt werden

Sobald mehrere Systeme denselben fachlichen Ablauf berühren, entstehen Konflikte um den verbindlichen Datenstand. Wenn nicht eindeutig klar ist, wo Kunden-, Auftrags-, Preis-, Bestands- oder Rechnungsdaten führend sind, sinkt das Vertrauen in Prozesse und Auswertungen.

Governance wird vom Randthema zur Betriebsnotwendigkeit

Ein composable Ansatz braucht Regeln für Änderungen, Schnittstellenverantwortung, Freigaben, Dokumentation, Testtiefe und Eskalation bei Störungen. Ohne diese Leitplanken entsteht die gleiche Intransparenz wie in gewachsenen Monolithen, nur anders verteilt.

Der Betriebsaufwand wird anspruchsvoller

Eine verteilte ERP-Landschaft braucht klare Verantwortung für Überwachung, Incident-Bearbeitung, Releaseabstimmung und technische Weiterentwicklung. Wer diesen Aufwand nicht einplant, baut keine flexible Architektur auf, sondern eine störungsanfällige.

Unscharfe Prozesse werden sichtbarer, aber nicht gelöst

Wenn Rollen, Stammdatenqualität oder Prozessverantwortung bereits heute unklar sind, heilt composable ERP diese Probleme nicht. Der Ansatz macht sie meist schneller sichtbar und damit betriebsrelevanter.

Welche Fragen vor einer Entscheidung geklärt sein müssen

Ob composable ERP sinnvoll ist, entscheidet sich nicht an einer Produktdemo. Entscheidend sind einige Architektur- und Betriebsfragen, die vor einer Umsetzung geklärt sein müssen.

Welche Fähigkeiten müssen bewusst im ERP-Kern bleiben?

Nicht alles, was technisch auslagerbar ist, sollte fachlich außerhalb des ERP liegen. Unternehmen müssen definieren, welche Prozesse wegen Transaktionssicherheit, Nachvollziehbarkeit und kaufmännischer Führung bewusst zentral bleiben.

Für welche Daten und Zustände gibt es eine verbindliche Quelle?

Bei Kunden, Artikeln, Preisen, Aufträgen, Bestandszuständen oder Rechnungen braucht es klare Führungssysteme. Ohne diese Festlegung wird jede Erweiterung zum Abstimmungsproblem.

Welche Prozessschritte brauchen Echtzeit und welche nicht?

Nicht jede Integration braucht unmittelbare Synchronisation. Manche Prozesse funktionieren mit Batch-Logik, andere brauchen sofortige Rückmeldungen. Die Zeitlogik muss fachlich zum Prozess passen, nicht zum bevorzugten Integrationswerkzeug.

Wie werden Fehler sichtbar und bearbeitbar?

Ein fehlgeschlagener Datentransfer ist kein technisches Randereignis. Je nach Prozess kann er Lieferfähigkeit, Servicequalität oder Rechnungsstellung beeinträchtigen. Deshalb brauchen modulare ERP-Landschaften Monitoring, Protokollierung und klare Eskalationswege.

Wer entscheidet über Änderungen?

Composable ERP funktioniert nicht ohne Rollen für Architektur, Fachverantwortung und Betrieb. Gerade im Mittelstand ist das wichtig, weil operative Abhängigkeit oft an wenigen Personen hängt.

Wie ein sinnvoller Einstieg aussehen kann

Ein tragfähiger composable ERP-Ansatz beginnt nicht mit der Toolliste, sondern mit einem Zielbild für Prozesse, Systemrollen und Modernisierungsetappen.

Ein sinnvolles Vorgehen läuft meist über fünf Schritte:

1. Ausgangslage und Reibungspunkte sichtbar machen

Zuerst muss klar sein, wo die heutige ERP-Landschaft Änderung blockiert: im Kern, an den Schnittstellen oder in den Prozessen selbst.

2. Stabilen Kern definieren

Danach wird festgelegt, welche Fähigkeiten aus fachlichen und betrieblichen Gründen bewusst im ERP bleiben. Das verhindert, dass Modularisierung zur Beliebigkeit wird.

3. Priorisierte Modernisierungsbausteine auswählen

Nicht jeder Engpass muss zuerst gelöst werden. Sinnvoll sind Bausteine mit hohem Nutzen, überschaubarem Risiko und klarer Prozessverantwortung, etwa Reporting, Portale, Serviceprozesse oder Partneranbindungen.

4. Integrations- und Governance-Modell vorab festlegen

Bevor neue Bausteine produktiv gehen, müssen Datenhoheit, Schnittstellenmuster, Monitoring, Testlogik und Betriebsverantwortung definiert sein.

5. In beherrschbaren Etappen umsetzen

Der Vorteil modularer Modernisierung liegt darin, aus frühen Etappen lernen zu können. Das funktioniert aber nur, wenn die einzelnen Schritte auf ein gemeinsames Architekturziel einzahlen.

Wann composable ERP eher nicht der richtige Weg ist

Nicht jedes Unternehmen braucht eine modulare ERP-Strategie. Wenn Prozesse weitgehend standardisiert sind, das vorhandene ERP wirtschaftlich tragfähig arbeitet und der Integrationsbedarf begrenzt bleibt, kann ein gut geführter Suite-Ansatz die bessere Wahl sein.

Auch Unternehmen mit schwacher Datenqualität, unklaren Verantwortlichkeiten oder fehlender Betriebsdisziplin sollten vorsichtig sein. In solchen Situationen erhöht composable ERP zunächst die Steuerungsanforderungen, bevor es Nutzen schafft.

Die entscheidende Frage lautet deshalb nicht: Ist composable ERP moderner? Die bessere Frage lautet: Welche Architektur gibt unserem Unternehmen in den nächsten Jahren die bessere Balance aus Stabilität, Veränderungsfähigkeit und beherrschbarem Betriebsaufwand?

Fazit

Composable ERP ist für Unternehmen weder Wundermittel noch Zukunftsfloskel. Der Ansatz kann sinnvoll sein, wenn ein Unternehmen seine ERP-Landschaft schrittweise modernisieren will, ohne den gesamten Kern in einem Projekt neu zu bauen. Sein Wert liegt in einer klaren Trennung zwischen stabil zu führenden Kernfähigkeiten und gezielt angebundenen Spezialisierungen.

Genau darin liegt aber auch die Bedingung für den Erfolg. Mehr Modularität schafft nur dann echten Nutzen, wenn Integration, Datenkonsistenz, Governance und Betriebsverantwortung bewusst organisiert werden. Ohne diese Disziplin entsteht kein modernes Zielbild, sondern nur eine andere Form historisch gewachsener Komplexität.

Für KMU lohnt sich deshalb keine reflexhafte Antwort pro oder contra. Sinnvoll ist eine nüchterne Architekturentscheidung: Welche Kernprozesse müssen stabil geführt werden, wo blockiert die heutige Landschaft Veränderung, und welche Modernisierungsschritte sind fachlich, technisch und betrieblich verantwortbar?

WWInterface unterstützt Unternehmen dabei, genau diese Fragen strukturiert zu klären: vom Zielbild für die ERP-Landschaft über Integrations- und Governance-Fragen bis zu einer schrittweisen Modernisierungslogik, die im Mittelstand auch im Alltag tragfähig bleibt.