Das klassische Versprechen klingt verführerisch: Eine Plattform für alles. Sourcing, Auktionen, Verträge, Spend-Analyse, Lieferantenmanagement. Ein System, eine Schnittstelle, eine Wahrheit.
Die Realität ist brutaler.
Die meisten Unternehmen, die eine große S2P-Suite implementiert haben, beschreiben denselben Entwicklungsverlauf: 12–18 Monate Implementierung. 500.000 bis 2 Millionen Euro — oft mehr. Ein halbes Dutzend Berater vor Ort. Jede kleine Anpassung kostet extra. Und am Ende nutzen sie 30 % der Funktionen.
Das ist nicht mehr das Szenario, das 2026 gewinnt.
Das Suite-Versprechen funktioniert nicht mehr
S2P-Suiten wurden für eine andere Zeit gebaut. Eine Zeit, in der Digitalisierung bedeutete: Prozesse in Software abbilden, große Investitionen rechtfertigen sich über lange Amortisationszeiträume, Anbieter konnten Kunden binden, weil es sonst keine Alternativen gab.
Das hat sich geändert. Drei Dinge haben den Markt verschoben:
Erstens: KI-Integration. Die wichtigsten neuen Features im Einkauf — automatisierte Angebotsauswertung, intelligente Lieferanten-Vorqualifizierung, Report-Generierung — laufen über APIs. Proprietäre Suiten, die nicht offen sind, sind blockiert. Sie können diese Features nicht ohne Jahre neuer Entwicklung integrieren.
Zweitens: Lieferketten-Volatilität. Das klassische Suite-Implementierungsprojekt nimmt an, dass Prozesse stabil sind. Du spezifizierst sie, implementierst sie, packst sie in Software. Dann läuft es drei Jahre. 2026 funktioniert das nicht. Zoll-Schocks, Lieferantenausfälle, disruptive Regulierung — alles passiert schneller. Unternehmen brauchen Software, die in Wochen neue Anforderungen aufnehmen kann, nicht in Monaten.
Drittes: Kosten-Bewusstsein. Mittelständler fangen an zu rechnen. Nicht nur Lizenzkosten, sondern alles: Implementierung, erste zwei Jahre Betrieb, interne Kapazität, Berater. Das Gesamtbudget für eine Suite ist oft 3–4x die jährliche Lizenzgebühr. Das Rechnen wird unangenehm, wenn man es konsequent durchzieht.
Was Composable Procurement bedeutet
Composable Procurement ist nicht neu als Konzept — aber es wird erst jetzt realistisch als Alternative.
Das Modell funktioniert so: statt einen großen Monolithen zu bauen, baust du aus modularen Komponenten zusammen. Jede Komponente macht genau eine Sache gut. Eine für Bedarfsmanagement. Eine für Ausschreibungen. Eine für Auktionen. Eine für Lieferantenmanagement.
Diese Module sind verbunden über standardisierte APIs. Daten fließen durch, automatisiert. Wenn später ein neues Anforderung kommt — say, KI-gestützte Angebotsauswertung — addierst du ein neues Modul. Du machst nicht das ganze System neu.
Das Wichtige: Einzelne Module sind austauschbar. Wenn das Bedarfsmanagement-Modul nicht mehr passt, ersetzt du es. Das System bleibt stabil. Das ist möglich, weil die Schnittstellen standardisiert sind.
Ein Vergleich zur älteren Welt: Statt auf einen Server-Raum mit zentralem ERP zu setzen und alles darin zu integrieren — baust du ein Netzwerk von einzelnen, sehr guten Werkzeugen, die miteinander sprechen.
Warum der Mittelstand das perfekt findet
Der Mittelstand hat eine ganz andere Priorität als Konzerne.
Konzerne haben ein IT-Team, 100+ Millionen Einkaufsvolumen, fünf Jahre Implementierungsbudget. Die Suite rechnet sich dort.
Der Mittelstand sagt: Ich will das in zwei Monaten nutzen, nicht in zwei Jahren. Ich will nicht ein System für alles, sondern ein sehr gutes System für das, das ich wirklich brauche. Ich will nicht an einen Anbieter gebunden sein für die nächsten fünf Jahre.
Composable Procurement spricht diese Priorität direkt an.
Schnelle Einführung ist möglich, weil jedes Modul klein ist. Ein Sourcing-Modul kann in Tagen live gehen. Die Nutzer sehen sofort Wert — das motiviert das Team, nicht demotiviert.
Der Nutzen pro Modul ist klar. Du implementierst nicht "ein Einkaufs-System". Du implementierst "automatisierte Angebotsvergleiche". Die Nutzung ist dann nicht optional — sie ist offensichtlich.
Es gibt keinen langfristigen Lock-in. Die meisten Module sind monatlich kündbar. Das bedeutet nicht, dass Kunden kündigen — es bedeutet, dass das Vertrauen größer ist, weil die Abhängigkeit kleiner ist.
Die Preislogik passt zur Größe. Große Suiten haben eine Basis-Lizenzgebühr von 50–100.000 Euro pro Jahr, egal wie groß dein Einkauf ist. Bei modularen Systemen zahlst du für das, das du nutzt. Ein Team mit 50 Millionen Einkaufsvolumen zahlt weniger als eines mit 500 Millionen.
Warum jetzt? Ein Convergence-Punkt
Composable Procurement ist nicht 2026 erfunden worden. Die Architektur existiert seit 2015. Aber der Markt hat bis jetzt auf den Monolithen gesetzt.
2026 verschiebt sich der Punkt. Mehrere Trends konvergieren:
APIs sind Normalfall geworden, nicht Ausnahme. Cloud-Services sprechen selbstverständlich miteinander. Die technische Infrastruktur für Composable Procurement ist reif.
AI-Integration wird erzwungen. Die neuen Funktionen, die den ROI ausmachen, sind KI-native. Offene APIs sind nicht mehr optional. Proprietäre Suiten, die das nicht haben, sind am Rande des Marktes.
TCO-Vergleiche werden sichtbar. Trend-Reports (McKinsey, Deloitte, Inverto) publizieren die Kostenvergleiche — und die zeigen: Composable ist 30–50 % billiger über fünf Jahre, wenn man alles rechnet.
Zoll-Schocks und Lieferkettenverwerfungen schaffen Handlungsdruck. Das erzwingt schnelle Lösungen. 12-Monats-Projekte sind nicht realistisch. Modulare Systeme, die in Wochen skalieren, passen zum Moment.
Was das konkret bedeutet
Wenn du jetzt eine Einkaufssoftware evaluierst, ist die zentrale Frage: Monolith oder Composable?
Die Monolith-Frage ist: Decke ich alle meine Prozesse ab? Die Suite verspricht das. Du kriegst ein System, das eigentlich alles kann — aber viel zu kompliziert für deine konkrete Nutzung ist.
Die Composable-Frage ist: Welche Probleme habe ich heute? Welche Probleme habe ich morgen? Welche davon kann ich mit modularen Best-of-Breed-Lösungen angehen?
Das zweite ist ehrlicher.
Ein Beispiel: Du hast Bedarfsmanagement im ERP. Das funktioniert okay. Aber Ausschreibungen sind noch ein Excel-Marathon, Angebotsvergleich dauert Tage, Lieferantenmanagement ist über drei Systeme verteilt.
Mit Composable: du addierst ein Ausschreibungsmodul (geht schnell live). Dann ein Angebotsvergleich-Modul. Dann ein Lieferantenmanagement-Modul. Jedes ist Independent deployable. Jedes spart Zeit. Jedes ist testbar, bevor es Geld kostet.
Mit Suite: du brauchst all das — aber packst es in einen großen Implementierungsprojekt, weil es eine Suite ist. Kosten steigen. Risiken steigen. Timelines verschieben sich. Nach 18 Monaten läuft das System, hat dein Team sich Workarounds gebaut, die älter sind als das neue System.
cusoso Target als Beispiel für Composable
cusoso Target ist von Anfang an composable gebaut. 13 Module, api-first, jede kann standalone deployt werden.
Das bedeutet konkret: Ein Mittelständler mit 60 Millionen Einkaufsvolumen und 4 Einkäufern kann mit dem Ausschreibungs-Modul starten. Das löst sein Kernproblem. Nach 3 Monaten läuft das stabil. Dann kommt das Lieferantenmanagement-Modul. Dann Spend-Analyse.
Nicht als 12-Monats-Big-Bang-Projekt. Sondern als iterative, risikoarme Erweiterung.
Die Schnittstellen sind offen. Wenn 2027 eine neue KI-Komponente für Angebotsauswertung kommt, lässt sie sich einfach einstöpseln. Das System wird nicht neu geplant, sondern erweitert.
Keine Vendor Lock-in über Jahrzehnte. Monatliche Kündigung ist möglich (und sollte nicht die Norm sein, aber die Option existiert). Das schafft Vertrauen anders als ein Vertrag, der dich für fünf Jahre bindet.
Die häufigsten Fragen
Ist das nicht komplexer, wenn alles modulär ist statt integriert?
Nein, das Gegenteil. Komplexität entsteht, wenn ein System zu viel macht, das du nicht brauchst. Eine Monolith hat Komplexität mit dir. Ein Composable-System hat nur die Komplexität, die du brauchst. Die anderen Module sind einfach nicht da.
Brauche ich dann 5 verschiedene Logins und Interfaces?
Nein. Die Module haben eine einheitliche UX. Die Integration passiert auf API-Ebene, nicht auf UI-Ebene. Der Nutzer sieht ein System.
Was wenn später zwei Module nicht miteinander sprechen?
Das ist ein Design-Fehler. Composable Procurement funktioniert nur mit standardisierten APIs. Wenn zwei Module nicht sprechen, ist die Architektur falsch gewählt.
Ist Composable nicht nur was für große Unternehmen mit IT-Teams?
Im Gegenteil. Es ist perfekt für mittelständische Teams, die keine großen IT-Ressourcen haben. Ein Modul ist einfacher zu verstehen, zu implementieren und zu betreiben als ein großes Allzweck-System.
Kostet das nicht am Ende mehr, wenn ich mehrere Tools brauchte statt einer Suite?
Nein. Der TCO ist typischerweise 30–50 % niedriger, wenn du die gesamten Kosten (Lizenz, Implementierung, Betrieb, interne Kapazität) über 5 Jahre rechnest. Und der Punkt der Break-Even ist näher.
Kann ich eine Suite nicht auch modular nutzen und einfach Funktionen deaktivieren?
Theoretisch ja. Praktisch führt das zu "feature debt". Die deaktivierten Funktionen erzeugen weiterhin Komplexität, Lizenzkosten und Maintenance-Burden. Echte Modularität ist etwas anderes.
Der Wendepunkt 2026
Composable Procurement ist der Wendepunkt im Einkaufs-Softwaremarkt 2026. Das sagen nicht nur Analisten — das sagen Einkaufsleiter, die wechseln.
Wenn du jetzt eine neue Lösung evaluierst: frag nicht "welche Suite ist das beste?" Frag "welche modularen Komponenten brauche ich für mein konkretes Problem?" und "wie sind sie verbunden?"
Die Antwort wird dich überraschen. Nicht, weil sie technisch komplex ist. Sondern weil sie einfacher ist als das Suite-Versprechen, das du gewohnt bist.
Die Realität ist brutaler.
Die meisten Unternehmen, die eine große S2P-Suite implementiert haben, beschreiben denselben Entwicklungsverlauf: 12–18 Monate Implementierung. 500.000 bis 2 Millionen Euro — oft mehr. Ein halbes Dutzend Berater vor Ort. Jede kleine Anpassung kostet extra. Und am Ende nutzen sie 30 % der Funktionen.
Das ist nicht mehr das Szenario, das 2026 gewinnt.
Das Suite-Versprechen funktioniert nicht mehr
S2P-Suiten wurden für eine andere Zeit gebaut. Eine Zeit, in der Digitalisierung bedeutete: Prozesse in Software abbilden, große Investitionen rechtfertigen sich über lange Amortisationszeiträume, Anbieter konnten Kunden binden, weil es sonst keine Alternativen gab.
Das hat sich geändert. Drei Dinge haben den Markt verschoben:
Erstens: KI-Integration. Die wichtigsten neuen Features im Einkauf — automatisierte Angebotsauswertung, intelligente Lieferanten-Vorqualifizierung, Report-Generierung — laufen über APIs. Proprietäre Suiten, die nicht offen sind, sind blockiert. Sie können diese Features nicht ohne Jahre neuer Entwicklung integrieren.
Zweitens: Lieferketten-Volatilität. Das klassische Suite-Implementierungsprojekt nimmt an, dass Prozesse stabil sind. Du spezifizierst sie, implementierst sie, packst sie in Software. Dann läuft es drei Jahre. 2026 funktioniert das nicht. Zoll-Schocks, Lieferantenausfälle, disruptive Regulierung — alles passiert schneller. Unternehmen brauchen Software, die in Wochen neue Anforderungen aufnehmen kann, nicht in Monaten.
Drittes: Kosten-Bewusstsein. Mittelständler fangen an zu rechnen. Nicht nur Lizenzkosten, sondern alles: Implementierung, erste zwei Jahre Betrieb, interne Kapazität, Berater. Das Gesamtbudget für eine Suite ist oft 3–4x die jährliche Lizenzgebühr. Das Rechnen wird unangenehm, wenn man es konsequent durchzieht.
Was Composable Procurement bedeutet
Composable Procurement ist nicht neu als Konzept — aber es wird erst jetzt realistisch als Alternative.
Das Modell funktioniert so: statt einen großen Monolithen zu bauen, baust du aus modularen Komponenten zusammen. Jede Komponente macht genau eine Sache gut. Eine für Bedarfsmanagement. Eine für Ausschreibungen. Eine für Auktionen. Eine für Lieferantenmanagement.
Diese Module sind verbunden über standardisierte APIs. Daten fließen durch, automatisiert. Wenn später ein neues Anforderung kommt — say, KI-gestützte Angebotsauswertung — addierst du ein neues Modul. Du machst nicht das ganze System neu.
Das Wichtige: Einzelne Module sind austauschbar. Wenn das Bedarfsmanagement-Modul nicht mehr passt, ersetzt du es. Das System bleibt stabil. Das ist möglich, weil die Schnittstellen standardisiert sind.
Ein Vergleich zur älteren Welt: Statt auf einen Server-Raum mit zentralem ERP zu setzen und alles darin zu integrieren — baust du ein Netzwerk von einzelnen, sehr guten Werkzeugen, die miteinander sprechen.
Warum der Mittelstand das perfekt findet
Der Mittelstand hat eine ganz andere Priorität als Konzerne.
Konzerne haben ein IT-Team, 100+ Millionen Einkaufsvolumen, fünf Jahre Implementierungsbudget. Die Suite rechnet sich dort.
Der Mittelstand sagt: Ich will das in zwei Monaten nutzen, nicht in zwei Jahren. Ich will nicht ein System für alles, sondern ein sehr gutes System für das, das ich wirklich brauche. Ich will nicht an einen Anbieter gebunden sein für die nächsten fünf Jahre.
Composable Procurement spricht diese Priorität direkt an.
Schnelle Einführung ist möglich, weil jedes Modul klein ist. Ein Sourcing-Modul kann in Tagen live gehen. Die Nutzer sehen sofort Wert — das motiviert das Team, nicht demotiviert.
Der Nutzen pro Modul ist klar. Du implementierst nicht "ein Einkaufs-System". Du implementierst "automatisierte Angebotsvergleiche". Die Nutzung ist dann nicht optional — sie ist offensichtlich.
Es gibt keinen langfristigen Lock-in. Die meisten Module sind monatlich kündbar. Das bedeutet nicht, dass Kunden kündigen — es bedeutet, dass das Vertrauen größer ist, weil die Abhängigkeit kleiner ist.
Die Preislogik passt zur Größe. Große Suiten haben eine Basis-Lizenzgebühr von 50–100.000 Euro pro Jahr, egal wie groß dein Einkauf ist. Bei modularen Systemen zahlst du für das, das du nutzt. Ein Team mit 50 Millionen Einkaufsvolumen zahlt weniger als eines mit 500 Millionen.
Warum jetzt? Ein Convergence-Punkt
Composable Procurement ist nicht 2026 erfunden worden. Die Architektur existiert seit 2015. Aber der Markt hat bis jetzt auf den Monolithen gesetzt.
2026 verschiebt sich der Punkt. Mehrere Trends konvergieren:
APIs sind Normalfall geworden, nicht Ausnahme. Cloud-Services sprechen selbstverständlich miteinander. Die technische Infrastruktur für Composable Procurement ist reif.
AI-Integration wird erzwungen. Die neuen Funktionen, die den ROI ausmachen, sind KI-native. Offene APIs sind nicht mehr optional. Proprietäre Suiten, die das nicht haben, sind am Rande des Marktes.
TCO-Vergleiche werden sichtbar. Trend-Reports (McKinsey, Deloitte, Inverto) publizieren die Kostenvergleiche — und die zeigen: Composable ist 30–50 % billiger über fünf Jahre, wenn man alles rechnet.
Zoll-Schocks und Lieferkettenverwerfungen schaffen Handlungsdruck. Das erzwingt schnelle Lösungen. 12-Monats-Projekte sind nicht realistisch. Modulare Systeme, die in Wochen skalieren, passen zum Moment.
Was das konkret bedeutet
Wenn du jetzt eine Einkaufssoftware evaluierst, ist die zentrale Frage: Monolith oder Composable?
Die Monolith-Frage ist: Decke ich alle meine Prozesse ab? Die Suite verspricht das. Du kriegst ein System, das eigentlich alles kann — aber viel zu kompliziert für deine konkrete Nutzung ist.
Die Composable-Frage ist: Welche Probleme habe ich heute? Welche Probleme habe ich morgen? Welche davon kann ich mit modularen Best-of-Breed-Lösungen angehen?
Das zweite ist ehrlicher.
Ein Beispiel: Du hast Bedarfsmanagement im ERP. Das funktioniert okay. Aber Ausschreibungen sind noch ein Excel-Marathon, Angebotsvergleich dauert Tage, Lieferantenmanagement ist über drei Systeme verteilt.
Mit Composable: du addierst ein Ausschreibungsmodul (geht schnell live). Dann ein Angebotsvergleich-Modul. Dann ein Lieferantenmanagement-Modul. Jedes ist Independent deployable. Jedes spart Zeit. Jedes ist testbar, bevor es Geld kostet.
Mit Suite: du brauchst all das — aber packst es in einen großen Implementierungsprojekt, weil es eine Suite ist. Kosten steigen. Risiken steigen. Timelines verschieben sich. Nach 18 Monaten läuft das System, hat dein Team sich Workarounds gebaut, die älter sind als das neue System.
cusoso Target als Beispiel für Composable
cusoso Target ist von Anfang an composable gebaut. 13 Module, api-first, jede kann standalone deployt werden.
Das bedeutet konkret: Ein Mittelständler mit 60 Millionen Einkaufsvolumen und 4 Einkäufern kann mit dem Ausschreibungs-Modul starten. Das löst sein Kernproblem. Nach 3 Monaten läuft das stabil. Dann kommt das Lieferantenmanagement-Modul. Dann Spend-Analyse.
Nicht als 12-Monats-Big-Bang-Projekt. Sondern als iterative, risikoarme Erweiterung.
Die Schnittstellen sind offen. Wenn 2027 eine neue KI-Komponente für Angebotsauswertung kommt, lässt sie sich einfach einstöpseln. Das System wird nicht neu geplant, sondern erweitert.
Keine Vendor Lock-in über Jahrzehnte. Monatliche Kündigung ist möglich (und sollte nicht die Norm sein, aber die Option existiert). Das schafft Vertrauen anders als ein Vertrag, der dich für fünf Jahre bindet.
Die häufigsten Fragen
Ist das nicht komplexer, wenn alles modulär ist statt integriert?
Nein, das Gegenteil. Komplexität entsteht, wenn ein System zu viel macht, das du nicht brauchst. Eine Monolith hat Komplexität mit dir. Ein Composable-System hat nur die Komplexität, die du brauchst. Die anderen Module sind einfach nicht da.
Brauche ich dann 5 verschiedene Logins und Interfaces?
Nein. Die Module haben eine einheitliche UX. Die Integration passiert auf API-Ebene, nicht auf UI-Ebene. Der Nutzer sieht ein System.
Was wenn später zwei Module nicht miteinander sprechen?
Das ist ein Design-Fehler. Composable Procurement funktioniert nur mit standardisierten APIs. Wenn zwei Module nicht sprechen, ist die Architektur falsch gewählt.
Ist Composable nicht nur was für große Unternehmen mit IT-Teams?
Im Gegenteil. Es ist perfekt für mittelständische Teams, die keine großen IT-Ressourcen haben. Ein Modul ist einfacher zu verstehen, zu implementieren und zu betreiben als ein großes Allzweck-System.
Kostet das nicht am Ende mehr, wenn ich mehrere Tools brauchte statt einer Suite?
Nein. Der TCO ist typischerweise 30–50 % niedriger, wenn du die gesamten Kosten (Lizenz, Implementierung, Betrieb, interne Kapazität) über 5 Jahre rechnest. Und der Punkt der Break-Even ist näher.
Kann ich eine Suite nicht auch modular nutzen und einfach Funktionen deaktivieren?
Theoretisch ja. Praktisch führt das zu "feature debt". Die deaktivierten Funktionen erzeugen weiterhin Komplexität, Lizenzkosten und Maintenance-Burden. Echte Modularität ist etwas anderes.
Der Wendepunkt 2026
Composable Procurement ist der Wendepunkt im Einkaufs-Softwaremarkt 2026. Das sagen nicht nur Analisten — das sagen Einkaufsleiter, die wechseln.
Wenn du jetzt eine neue Lösung evaluierst: frag nicht "welche Suite ist das beste?" Frag "welche modularen Komponenten brauche ich für mein konkretes Problem?" und "wie sind sie verbunden?"
Die Antwort wird dich überraschen. Nicht, weil sie technisch komplex ist. Sondern weil sie einfacher ist als das Suite-Versprechen, das du gewohnt bist.