ERP ist nicht mehr das Zentrum: Warum Steuerung im Layer darüber entsteht
Viele Unternehmen denken ihre Systemlandschaft gerade neu. Treiber sind selten „Technologie um der Technologie willen“, sondern strukturelle Realität: volatile Märkte, mehr Varianten, mehr Kanäle, kürzere Entscheidungszyklen – und ein Best-of-Breed-Ansatz, der fachlich sinnvoll ist, aber organisatorisch nur dann skaliert, wenn Steuerung bewusst designt wird.
Kernthese: Das ERP bleibt wichtig als System of Record. Aber die entscheidende Steuerungsfähigkeit entsteht zunehmend im Layer darüber: in Integrationslogik, Prozess-Orchestrierung, Policies/Regeln, Monitoring/Signalen und einer Decision Cadence, die Signale in Entscheidungen und Maßnahmen übersetzt.
Dieser Beitrag eröffnet den Diskurs: nicht über Anbieter, sondern über Prinzipien, die Best-of-Breed dauerhaft steuerbar machen.
In diesem Beitrag
Das Missverständnis: „Composable“ ist ein API-Thema
Wenn Unternehmen „Composable ERP“ oder „Composable Architecture“ diskutieren, wird die Debatte oft technisch geführt: APIs, iPaaS, Eventing, Microservices.
Das ist wichtig – aber nicht entscheidend.
Composable scheitert in der Praxis selten an Schnittstellen. Es scheitert an:
- fehlenden Standards (jeder Bereich macht es „ein bisschen anders“),
- unklaren Verantwortlichkeiten (wer entscheidet, wer betreibt, wer trägt Risiken?),
- ausufernden Ausnahmen (die jedes Automatisierungs- oder KI-Vorhaben aushebeln),
- und einer fehlenden Entscheidungsmechanik (Insights ohne Interventionen).
Merksatz: Composable Architektur ist zuerst eine Organisations- und Steuerungsfrage – erst danach eine Technologiefrage.
Was „ERP ist nicht mehr das Zentrum“ konkret bedeutet
„Nicht mehr das Zentrum“ heißt nicht: „ERP ist unwichtig.“ Es heißt: ERP ist nicht mehr der Ort, an dem die End-to-End-Logik vollständig lebt.
In modernen Best-of-Breed-Landschaften ist das ERP typischerweise:
- System of Record: Buchungen, Compliance, Kernstammdaten, finanzielle Wahrheit
- Stabilitätsanker: robuste Prozesse für Standardfälle
Die End-to-End-Wirkung entsteht jedoch über mehrere Systeme hinweg: Commerce, CRM, WMS, MES, Service, Planung, BI, Automatisierung, KI-Komponenten. Das bedeutet:
- Prozesslogik verteilt sich.
- Daten entstehen und verändern sich an mehreren Stellen.
- Entscheidungen müssen cross-funktional getroffen werden.
- Ausnahmen nehmen zu (Kunden-/Produkt-/Channel-Spezifika).
Die Konsequenz: Steuerung muss als eigene Schicht gedacht werden – unabhängig von der Frage, ob ein ERP „modern“ ist.
Das Steuerungsmodell: Der Layer über dem Tool-Stack
Wenn Sie Best-of-Breed strategisch verfolgen (oder bereits leben), brauchen Sie einen Steuerungs-Layer, der fünf Bausteine zusammenführt:
Baustein A: Integrationslogik (Flüsse, Events, Verträge)
Nicht als Projektartefakt, sondern als Betriebsobjekt:
- definierte Datenverträge
- Monitoring & SLAs
- Change-Prozess für Schnittstellen
- Ownership pro Integrationsdomäne
Baustein B: Prozess-Orchestrierung (End-to-End statt Systemgrenzen)
Ein End-to-End-Prozess „Order-to-Cash“ oder „Plan-to-Produce“ ist keine ERP-Funktion, sondern ein organisationsübergreifender Ablauf. Der Layer definiert:
- Prozessgrenzen, Verantwortlichkeiten, Übergaben
- Standardpfade vs Ausnahmewege
- Eskalationen und Entscheidungszeitpunkte
Baustein C: Policy-/Rule-Layer (Guardrails statt Bauchgefühl)
Steuerung wird operierbar, wenn Regeln explizit sind:
- Schwellenwerte (Trigger)
- Freigabelogiken
- Entscheidungsrechte (Delegationsrahmen)
- Ausnahme-Kategorien
Baustein D: Observability & Signals (Leading Indicators)
Nicht „mehr Dashboard“, sondern wenige Signale, die Handlungen auslösen:
- KPI-Definitionen, Datenquellen, Owners
- Leading Indicators je Domäne (Cash, Forecast, Margin, Servicelevel)
- Maßnahmenstatus (nicht nur Kennzahlen)
Baustein E: Decision Cadence (Rituale mit Output)
Der zentrale Unterschied zwischen Reporting und Steuerung:
- feste Entscheidungsrituale
- Decision Log (Entscheidung, Owner, Maßnahme, Deadline, Wirkung)
- Lernschleifen (Ausnahmen reduzieren, Regeln verbessern)
Kurzformel:
Signal → Entscheidung → Maßnahme (verankert über Rollen, Regeln, Rituale)
Warum Best-of-Breed ohne Steuerungs-Layer teurer wird als erwartet
Best-of-Breed ist fachlich attraktiv: bessere Fit, schnellere Innovation, geringere Vendor-Lock-in-Risiken. Trotzdem kippt der Nutzen häufig, wenn Governance und Operating Model nicht mitwachsen.
Typische Symptome:
- Integrationskosten steigen exponentiell, weil Änderungen nicht standardisiert sind.
- KPI-Diskussionen werden politisch, weil Definitionen variieren („Welche Marge ist die richtige?“).
- Automatisierung/KI bleibt im Piloten, weil Ausnahmen dominieren.
- Time-to-change sinkt, weil jede Veränderung Abstimmungschaos erzeugt.
Wichtig: Das ist kein Argument gegen Best-of-Breed. Es ist ein Argument dafür, Best-of-Breed als Systemdesign zu behandeln – nicht als Tool-Sammlung.
Standard vs Ausnahme: Der unterschätzte Kern von Composable
In modularen Landschaften entscheidet sich Skalierbarkeit an einem Punkt: Wie konsequent trennen Sie Standard und Ausnahme?
Standard (muss stabil sein)
- klare Definitionen
- automatisierbare Pfade
- wenige Varianten
- messbar, überwacht, verbessert
Ausnahme (muss steuerbar sein)
- klassifiziert (Kategorie, Ursache, Risiko)
- Playbook-gesteuert (Trigger, Owner, Maßnahme)
- dokumentiert (Entscheidung, Begründung)
- lernfähig (Reduktion wiederkehrender Ausnahmen)
Wenn Ausnahmen „einfach passieren“, entsteht Schattenlogik: manuelle Workarounds, Sonderprozesse, individuelle Integrationen. Das verhindert genau die Effekte, die Best-of-Breed verspricht.
Ein pragmatischer Einstieg: „Minimum Viable Steering Layer“ in 6 Wochen
Sie müssen nicht „alles neu“ bauen. Starten Sie mit einem steuerbaren Minimum.
Woche 1–2: Fokus & Scope
- 1 End-to-End-Prozess wählen (z. B. Order-to-Cash)
- 5–8 Steuerungs-KPIs definieren (inkl. Definitionen)
- Top-5 Ausnahme-Kategorien festlegen
Woche 3–4: Ownership & Regeln
- Owner pro KPI/Signal und pro Ausnahme-Kategorie benennen
- Trigger/Korridore definieren (ab wann ist Intervention erforderlich?)
- Delegationsrahmen und Freigaben festlegen
Woche 5: Decision Cadence
- 1 wöchentliches Steering-Ritual einführen (30–45 Min)
- Decision Log etablieren (entscheidungsorientierte Protokollierung)
Woche 6: Integrationsbetrieb „in klein“
- 1–2 kritische Datenflüsse als „Produkte“ definieren (Owner, SLA, Monitoring)
- Change-Prozess für Anpassungen festlegen
Ergebnis: Ein erstes steuerbares Operating Model, das Sie iterativ auf weitere Prozesse ausweiten können.
Quick Self-Assessment:
Best-of-Breed ohne Steuerungsverlust
Beantworten Sie die Fragen mit Ja/Nein:
Gibt es eine klare Definition, wo Standard gilt – und wann Ausnahmen erlaubt sind?
Haben Sie feste Rituale, in denen Signale zu Entscheidungen und Maßnahmen werden?
Sind Integrationen und Datenflüsse owned (SLA, Monitoring, Change-Prozess)?
Können Sie Ihre zentralen KPIs einheitlich erklären (Definition, Quelle, Owner)?
Reduzieren Sie wiederkehrende Ausnahmen systematisch (Lernschleife, Playbooks)?
Wenn Sie bei 3+ Fragen „Nein“ antworten, ist Best-of-Breed nicht das Problem – sondern eine fehlende Steuerungsmechanik.
Architecture & Operating Model Check (45 Min)
In 45 Minuten identifizieren wir gemeinsam die wichtigsten Hebel, um Ihre Best-of-Breed-Landschaft steuerbar zu machen:
Standard-/Ausnahme-Logik und Playbooks
Decision Cadence & Verantwortlichkeiten
Integrations- und Daten-Governance als Betriebsmodell