Adaptions-Paradoxon (Martec’s Law): Warum Organisationen der eigentliche Engpass sind
Die technologische Entwicklung ist inzwischen so schnell, dass sie in vielen Unternehmen nicht mehr als „Wettbewerbsfaktor“, sondern als permanente Umweltbedingung wirkt. Neue Tools, neue Automatisierung, neue KI-Funktionen: Die Möglichkeiten wachsen schnell – und werden zugleich immer zugänglicher.
Gleichzeitig bleibt eine zweite Entwicklung stabil: Organisationen verändern sich langsam. Verantwortlichkeiten, Routinen, Entscheidungswege, Standards, Lernkurven – all das folgt nicht dem Tempo von Technologie.
Diese Diskrepanz wird häufig mit Martec’s Law beschrieben: Technologie verändert sich exponentiell, Organisationen verändern sich deutlich langsamer.
Das führt zu einem Adaptions-Paradoxon: Je mehr technisch möglich wird, desto stärker wird die Organisation selbst zum Engpass.
Dieser Beitrag zeigt, was das konkret bedeutet – und warum Adoption Engineering und Day-2-Betrieb künftig zentrale Erfolgsfaktoren sind.
Executive Summary
Organisationen sind zunehmend der limitierende Faktor, weil Technologie schneller wächst als die Fähigkeit, Veränderung im Betrieb aufzunehmen. Die Folge sind Pilotitis, Variantenexplosion und sinkende Durchsetzbarkeit. Wer Wirkung skalieren will, braucht weniger „mehr Tool“ und mehr Operating Model: klare Standards und Ausnahmen, Decision Rights, Kontrollen, operative Cadence sowie Adoption Metrics und ein Day-2-Backlog. Ohne diese Mechanik bleibt Fortschritt punktuell.
Für Entscheider: Drei Konsequenzen
Die knappste Ressource ist Aufnahmefähigkeit. Nicht die Technik limitiert, sondern die Fähigkeit, Veränderung zu verarbeiten – im Tagesgeschäft.
Skalierung ist ein Operating-Model-Problem. Standards, Verantwortlichkeiten, Routinen und Kontrollen entscheiden, ob Innovation im Betrieb ankommt.
Day-2 ist der ROI-Hebel. Ohne Messbarkeit und Betriebsroutinen fällt Nutzung zurück, Ausnahmequoten steigen und der Nutzen verpufft.
Checkliste (90 Sekunden):
- Gibt es ein klares Standard-/Ausnahme-Modell – inklusive Freigaben und Eskalation?
- Ist festgelegt, wer was entscheiden darf (Decision Rights) – und in welcher Cadence?
- Messen wir Adoption (Nutzung, Exceptions, Rework, Datenqualität) – oder nur Projektmeilensteine?
In diesem Beitrag
Martec’s Law in der Praxis: Wo der Engpass sichtbar wird
In Gesprächen zeigt sich Martec’s Law selten als theoretische Kurve – sondern als konkreter Alltag:
- Es gibt zu viele Initiativen parallel, aber wenig belastbare Priorisierung.
- Es werden neue Funktionen ausgerollt, aber nicht konsequent genutzt.
- Prozesse sind dokumentiert, aber nicht durchgesetzt.
- „Ausnahmen“ sind nicht Ausnahme, sondern Normalzustand.
- Datenqualität sinkt, sobald Projektenergie nachlässt.
- Teams sind überfordert – nicht weil sie unfähig sind, sondern weil Veränderung ohne Betriebsmechanik zusätzliche kognitive Last erzeugt.
Der zentrale Punkt: Technologie liefert Möglichkeiten. Organisationen brauchen Mechanik.
Wenn Mechanik fehlt, erzeugen neue Möglichkeiten vor allem Komplexität.
Martec’s Law in der Praxis: Wo der Engpass sichtbar wird
Organisationen sind keine Software. Sie verändern sich nicht durch ein Update, sondern durch:
- neue Verantwortlichkeiten, die akzeptiert werden müssen
- Routinen, die gelernt und wiederholt werden müssen
- Standards, die Konflikte auslösen (weil sie Freiheit reduzieren)
- Entscheidungen, die Macht und Zuständigkeit berühren
- Lernkurven und Fehler, die Zeit benötigen
Hinzu kommt: Viele Veränderungen kollidieren miteinander. Ein Team kann nicht gleichzeitig:
- neue Systeme nutzen,
- neue KPIs übernehmen,
- neue Prozesslogik leben,
- neue Governance akzeptieren,
- und nebenbei das Tagesgeschäft auf gleichem Niveau halten.
Aufnahmefähigkeit ist endlich.
Und genau das macht Martec’s Law aktuell so relevant: Die Anzahl der möglichen Veränderungen steigt schneller als die Fähigkeit, sie zu verarbeiten.
Was passiert, wenn man Martec’s Law ignoriert
Wenn man versucht, das Problem durch „mehr Umsetzung“ zu lösen, entstehen typische Gegenreaktionen:
Pilotitis und Schattenbetrieb
PoCs entstehen schnell, die Skalierung bleibt aus. Gleichzeitig entstehen Schattenprozesse:
- Excel als Steuerungsinstrument
- manuelle Umgehungen
- lokale „Workarounds“, die sich verfestigen
Variantenexplosion
Ohne Standards und Ausnahmen explodieren Varianten:
- jede Abteilung „braucht es anders“
- jede Region „macht es anders“
- jedes Team entwickelt eigene Regeln
Steuerungsverlust
Mit zunehmender Variantenvielfalt sinkt Steuerbarkeit:
- KPIs sind nicht vergleichbar
- Ursache-Wirkung wird intransparent
- Entscheidungen werden politisch statt datenbasiert
Das ist keine Ausnahme – es ist eine typische Folge, wenn Organisation und Betriebssystem nicht mitwachsen.
Der Perspektivwechsel: Von Projektlogik zu Betriebslogik
Viele Unternehmen führen Veränderungen als Projekte. Das ist verständlich, aber begrenzt.
Projektlogik ist auf Abschluss optimiert: Scope, Budget, Go-live.
Betriebslogik ist auf Wiederholbarkeit optimiert: Standards, Routinen, Kontrollen, Messbarkeit.
In einer Welt schneller Technologie ist Betriebslogik entscheidend, weil Veränderung nicht mehr episodisch ist, sondern kontinuierlich.
Das bedeutet:
- Nicht nur „implementieren“, sondern betreiben.
- Nicht nur „trainieren“, sondern durchsetzen.
- Nicht nur „Go-live“, sondern Day-2.
Die Kernkomponenten eines Operating Models für Veränderung
Um Martec’s Law zu „entschärfen“, braucht es ein Operating Model, das Veränderung aufnahmefähig macht. In der Praxis sind fünf Komponenten zentral:
Standards und Ausnahmen (mit Verantwortung)
- Was ist Standard?
- Was gilt als Ausnahme?
- Wer darf Ausnahmen genehmigen?
- Wie werden Ausnahmen sichtbar gemacht (und reduziert)?
Ohne diese Logik kann keine Automatisierung stabil laufen – und keine Organisation skalieren.
Decision Rights (wer entscheidet was, wann)
„Entscheidungen“ sind häufig der stille Engpass: zu langsam, zu spät, zu unklar.
Ein funktionierendes Modell definiert:
- welche Entscheidungen regelmäßig getroffen werden
- welche Rollen beteiligt sind
- welche Schwellenwerte Eskalation auslösen
- welche Entscheidungen delegiert sind – und welche nicht
Operative Cadence (Routinen, nicht Ad-hoc)
Veränderung braucht Rhythmus. Nicht als Meeting-Marathon, sondern als schlanke Cadence:
- Ops Review (operativ)
- Steering Review (steuernd)
- Change/Release Review (Änderungen)
- Exception Review (Ausnahmen)
Kontrollen und Quality Gates (Skalierung braucht Leitplanken)
Kontrollen sind kein Misstrauen, sondern Betriebsmechanik:
- Datenqualitätschecks
- Freigaben an sinnvollen Stellen
- Auditierbarkeit von Entscheidungen (insbesondere bei KI)
Adoption Engineering (Durchsetzbarkeit als Engineering)
Adoption Engineering liefert die Brücke vom „Design“ zur Nutzung im Alltag:
- Rollen und Verantwortlichkeiten (auch im Betrieb)
- Leitplanken (Standard/Ausnahme)
- Messung (Adoption Metrics)
- Backlog und Routinen (Day-2)
Day-2: Der Ort, an dem Martec’s Law entschieden wird
Day-2 bezeichnet den Betrieb nach dem Go-live – und ist der Ort, an dem sich entscheidet, ob Veränderung Bestand hat.
Im Day-2 passiert typischerweise Folgendes, wenn Mechanik fehlt:
- Nutzung fällt zurück („Wir machen es wieder wie vorher“)
- Datenqualität sinkt (weil Kontrollen fehlen)
- Ausnahmen werden zur Norm (weil Standard nicht verteidigt wird)
- Automatisierung wird manuell übersteuert
- KPI-Interpretationen divergieren
Der zentrale Punkt: Day-2 ist kein nachgelagerter Schritt. Day-2 muss mitgedacht und konstruiert werden.
Adoption Metrics: Messen, was im Alltag tatsächlich passiert
Viele Organisationen messen Projektfortschritt (Meilensteine), aber nicht Adoption. Das ist in einer schnellen Technologiewelt zu wenig.
Typische Adoption Metrics, die in der Praxis funktionieren:
- Nutzung: Anteil Vorgänge im Standardprozess / in der neuen Lösung
- Exception Rate: Anteil Ausnahmen / manuelle Eingriffe
- Rework: Rückläufer, Nacharbeit, Korrekturen
- Datenqualität: Fehlerquoten, Pflichtfelder, Dubletten, Stammdaten-Disziplin
- Durchlaufzeit / Servicelevel (operativ): direkte Prozessperformance
Der Wert liegt nicht in der Kennzahl an sich, sondern darin, dass Kennzahlen Maßnahmen triggern: wer reagiert, wann, wie.
Was das für KI im Unternehmen bedeutet
KI verstärkt Martec’s Law, weil sie Output und Veränderungsrate erhöht. Gleichzeitig erhöht KI die Anforderungen an Governance:
- Was darf KI empfehlen, was darf sie entscheiden?
- Wo muss Human-in-the-loop verpflichtend sein?
- Wie wird Nachvollziehbarkeit hergestellt (Decision Logs, Audit Trail)?
- Wie wird Qualität überwacht (Monitoring, Drift, Releases)?
Ohne ein Operating Model führt KI häufig zu einem Paradox:
- Mehr Fähigkeiten,
- aber weniger Kontrollierbarkeit,
- und am Ende geringere Akzeptanz.
Der Weg in den Regelbetrieb beginnt daher nicht mit dem Modell, sondern mit Leitplanken.
Praktischer Start: Wie man Martec’s Law handhabbar macht
Ein pragmatischer Einstieg ist kein Großprogramm, sondern eine kurze Sequenz, die Betriebsfähigkeit herstellt:
- End-to-End klären: Standard/Ausnahme, Ownership, Schnittstellen
- Steuerung definieren: KPI-/Treiberlogik + Cadence + Schwellenwerte
- Governance festziehen: Decision Rights + Quality Gates + Kontrollen
- Day-2 aufsetzen: Adoption Metrics + Backlog + Reviews
Das Ziel ist nicht „perfekt“, sondern betriebsfähig: klar genug, um zu skalieren.
Die drei Artefakte, die den Unterschied machen
Aus der Praxis sind drei Artefakte besonders wirksam, um den Engpass „Organisation“ zu adressieren:
- Steering Blueprint: KPI-/Treiberlogik, Cadence, Entscheidungsregeln
- Governance & Control Map: Rollen, Decision Rights, Controls, Auditierbarkeit
- Adoption Metrics & Day-2 Backlog: Messlogik + priorisierte Umsetzung im Betrieb
Diese Artefakte sind der „Übersetzer“ zwischen technologischer Möglichkeit und organisationaler Realität.
Fazit: Nicht mehr Technologie löst das Problem – sondern Betriebsmechanik
Martec’s Law ist kein pessimistischer Satz über Organisationen. Es ist eine realistische Beschreibung dessen, wie Veränderung funktioniert.
Die Konsequenz ist nicht „langsamer werden“, sondern „anders steuern“:
Wenn Technik schneller wird, braucht die Organisation ein besseres Betriebssystem.
Wer Standards, Governance, Cadence und Adoption Engineering aufbaut, kann technologische Entwicklung absorbieren und in Wirkung übersetzen. Wer das nicht tut, wird trotz moderner Tools immer wieder an der gleichen Stelle stehen: viele Initiativen – wenig Regelbetrieb.
Wenn Sie Ihre Ausgangslage einordnen möchten:
Dauer: 20–30 Minuten. Unverbindlich.