Struktur schafft Klarheit bei Führung, Entscheidungen und Zusammenarbeit. Ein Operating Model beschreibt, wie Organisationen tatsächlich arbeiten: Wer übernimmt welche Rolle? Wer entscheidet? Und in welchem Takt wird geplant und geliefert? Wer ohne ein solches Modell führt, kompensiert Strukturlücken mit persönlichem Einsatz – das funktioniert, aber nur solange die Belastung tragbar bleibt.
Was ist ein Operating Model?
Ein Operating Model beantwortet die Fragen, die in vielen Teams unausgesprochen bleiben: Wer entscheidet was? Wer ist wofür verantwortlich? In welchem Rhythmus wird geplant und gesteuert? Und woran erkennt die Organisation, ob sie auf Kurs ist?
Der Begriff klingt nach Konzernsprache, dabei ist das Prinzip einfach: Ein Operating Model macht die Spielregeln der Zusammenarbeit sichtbar. Es reicht von der strategischen Richtung bis zum operativen Takt.
Kein Operating Model zu haben heißt nicht, keine Regeln zu haben. Es heißt, dass die Regeln implizit sind, von Person zu Person unterschiedlich interpretiert werden und bei jeder Veränderung neu verhandelt werden müssen. Das kostet Zeit und erzeugt Reibung, die sich vermeiden ließe.
Ein gutes Operating Model gibt Orientierung, ohne jede Situation vorab regeln zu wollen. Es klärt, was stabil bleiben soll – etwa Entscheidungswege und Meetingrhythmen – und wo Teams eigene Lösungen finden können.
Warum die meisten Führungsprobleme Strukturprobleme sind
In vielen Organisationen werden Führungsprobleme als Personalprobleme behandelt: Die Teamleitung kommuniziere nicht klar genug, die Abteilungen arbeiteten nicht gut zusammen, Entscheidungen dauerten zu lange, weil niemand Verantwortung übernehme.
Die Diagnose landet fast immer bei den Menschen. Die Therapie lautet dann: Coaching, Teambuilding, bessere Kommunikation. Das hilft bei echten Kompetenzlücken. Wenn das Problem aber in der Struktur liegt, ändert sich durch Coaching wenig.
Ein Beispiel: Zwei Teams arbeiten am selben Produkt, aber mit unterschiedlichen Prioritäten. Beide haben engagierte Leads, beide liefern. Trotzdem gibt es ständig Konflikte, weil unklar ist, wer bei Zielkonflikten entscheidet. Das sieht aus wie ein Kommunikationsproblem. Tatsächlich fehlt eine Entscheidungslogik.
Oder: Eine Führungskraft verbringt den Großteil ihrer Woche in Abstimmungsmeetings. Die Arbeit bleibt liegen, das Team wartet auf Richtungsentscheidungen. Die Diagnose lautet Überlastung. Die eigentliche Ursache: Es gibt keinen Meetingrhythmus, der zwischen operativer Abstimmung und strategischer Steuerung unterscheidet. Alles landet im selben Termin.
Solche Muster wiederholen sich – und sie lassen sich durch bessere Strukturen lösen, oft wirksamer als durch den Austausch von Personen. Ein einfacher Test: Wenn dasselbe Problem bei verschiedenen Personen in derselben Rolle auftritt, lohnt sich ein Blick auf die Struktur.
Drei Ebenen, sechs Layer: Wie das Betriebsmodell CALM strukturiert
Das Betriebsmodell CALM wirkt auf drei Ebenen: Strategie setzt die Richtung, Taktik plant Releases und Initiativen, die operative Ebene liefert und lernt. Jede Ebene hat einen eigenen Rhythmus und eigene Entscheidungslogiken.
Quer zu diesen Ebenen liegen sechs Layer. Jeder beantwortet eine Frage, die in vielen Organisationen ungeklärt ist. Die Kombination aus Ebenen und Layern ergibt das Gesamtbild: wer auf welcher Ebene welche Verantwortung trägt, wie entschieden wird und in welchem Takt gearbeitet wird.
Layer 1: Strategie & Value Streams
Frage: Woher kommt die Richtung und wie wird sie in Arbeit übersetzt?
Strategie wird oft als Foliensatz behandelt, der einmal im Jahr entsteht und dann liegen bleibt. Hier ist sie der Ausgangspunkt für alles Weitere: Aus der strategischen Richtung entstehen Value Streams, aus Value Streams entstehen Teamschnitte, aus Teamschnitten entstehen Arbeitsroutinen. Ohne diesen Zusammenhang bleibt Strategie Absichtserklärung.
Vertiefung: Strategie & Value Streams
Layer 2: Team Architecture
Frage: Welche Teamformen braucht die Organisation und wie hängen sie zusammen?
CALM unterscheidet fünf Teamformen: Task Force, Zielteam, Projektteam, Produktteam und Linienteam. Jede Form hat einen eigenen Zweck, eine eigene Lebensdauer und eine eigene Führungslogik. Die Wahl der Teamform bestimmt, wie Verantwortung verteilt wird, welcher Rhythmus passt und welche Art von Ergebnis erwartet werden kann.
Vertiefung: Team Architecture: Die 5 Teamformen
Layer 3: Rollen & Verantwortlichkeiten
Frage: Wer ist wofür verantwortlich und wer entscheidet in Zweifelsfällen?
Unklare Rollen erzeugen Reibung, weil niemand weiß, wer was entscheiden darf. Statt Jobtitel zu definieren, werden drei Funktionen benannt, die in jeder Organisation vorhanden sind – bewusst oder unbewusst:
- Richtung geben. Wer entscheidet, was wichtig ist? Verantwortet Ziele, Prioritäten und Fokus und ist letzte Instanz bei Zielkonflikten. Pro Ziel oder Value Stream trägt genau eine Person diese Funktion – geteilte Richtungsverantwortung führt zuverlässig zu Lähmung.
- Ergebnis verantworten. Wer steht für das Resultat gerade? Erste Ansprechperson bei Scope, Blockern und Priorität innerhalb der Delivery. Das ist das einzige nicht-optionale Element: Jede Arbeit hat genau eine ergebnisverantwortliche Person.
- Fluss erhalten. Wer sorgt dafür, dass die Zusammenarbeit funktioniert? Hält Routinen, Rhythmus und Abhängigkeiten im Blick und moderiert Entscheidungsprozesse, ohne sie selbst zu treffen. Diese Funktion ist optional – notwendig wird sie, sobald ein Team mehr koordiniert als liefert.
Welcher Titel dazu passt, ist kontextabhängig: Ein Product Owner kann Richtungs- oder Ergebnisverantwortung tragen, ein Scrum Master ist eine klassische Ausprägung der Flussverantwortung.
Das Minimalprinzip: Richtungs- und Flussverantwortung werden nur dann explizit benannt, wenn ihre Abwesenheit zu Reibung führt – nicht als Standard-Overhead.
Vertiefung: Rollen & Verantwortlichkeiten
Layer 4: Arbeitsroutinen & Meetings
Frage: Welche Regeltermine braucht die Organisation auf welcher Ebene und mit welchem Zweck?
Zu viele Meetings sind oft das Symptom eines fehlenden Systems. Die Lösung liegt nicht in weniger Meetings, sondern im richtigen Rhythmus auf der richtigen Ebene. Wer operative Abstimmung, taktische Planung und strategische Steuerung im selben Termin vermischt, bekommt Meetings, in denen alles besprochen und nichts entschieden wird.
Dazu kommt eine Planungszwiebel mit rollierender Planung: Nahe Iterationen werden detailliert geplant, weiter entfernte Zeiträume bleiben bewusst grob.
Vertiefung: Arbeitsroutinen & Meetings
Layer 5: Entscheidungsmechanismen
Frage: Wer entscheidet was, in welchem Modus, und wann geht eine Entscheidung nach oben?
Viele Meetings, wenige Entscheidungen – dieses Muster entsteht, wenn Entscheidungswege nicht explizit sind. Vier Modi bilden dafür ein gemeinsames Vokabular, nicht als starre Kategorien, sondern als bewusst gewählte Haltung je nach Situation, Teamform und Tragweite:
- Autonom – das Team entscheidet selbst und informiert.
- Delegiert – die Entscheidung ist bewusst und benannt an eine Rolle übergeben.
- Konsultativ – eine Person entscheidet, holt vorher aber verbindlich Input ein.
- Direktiv – die Führung entscheidet und begründet.
Die Zuordnung folgt der Tragweite: Operative Entscheidungen (Umsetzungsdetails, Tagesgeschäft) laufen autonom oder delegiert, taktische (Quartalspriorisierung, Scope-Anpassung, Teamzuschnitt) delegiert oder konsultativ, strategische (Investitionsrichtung, Make-or-buy, Plattformwechsel) konsultativ oder direktiv. Je operativer die Entscheidung, desto mehr Autonomie beim Team; je strategischer, desto klarer muss der Entscheidungsträger benannt sein.
Der praktische Einstieg ist klein: die vier Begriffe einführen und für die zehn häufigsten Entscheidungstypen im eigenen Bereich festlegen, welcher Modus gilt.
Vertiefung: Entscheidungsmechanismen
Layer 6: Führung & Zusammenarbeit
Frage: Wie wird geführt und wie arbeiten Teams über Grenzen hinweg zusammen?
Der Führungsstil hängt von Teamform, Situation und Ebene ab. Dieser Layer definiert, welche Leadership Essentials gelten, wie Führung über Teamgrenzen koordiniert wird und wie Teams zusammenarbeiten, ohne dass alles über eine zentrale Stelle laufen muss.
Vertiefung: Führung & Zusammenarbeit
Wirkungsmessung
Wirkungsmessung ist kein eigener Layer, sondern zieht sich durch alle sechs. Fünf Minimal-Metriken zeigen über alle Ebenen hinweg, ob das System funktioniert:
- Forecast-Genauigkeit je Iteration (Plan gegen Ist)
- Anteil ungeplanter Arbeit
- Lead Time
- Blocker-Zeit durch Abhängigkeiten
- Entscheidungsoutput pro Meeting
Optional kommen Meetingzeit gegen Focus Time, WIP-Limits und Eskalationsquote dazu. Die Logik dahinter: Gemessen wird Wirkung (Outcome), nicht Aktivität (Output). Zahlen ersetzen keine Führung, aber sie machen Abweichungen sichtbar, bevor sie zum Problem werden.
✉ Newsletter
Praxiswissen direkt ins Postfach
Neue Artikel, Leadership-Impulse und kostenlose Downloads, kompakt und direkt umsetzbar.
Wann ein Operating Model Review sinnvoll ist
Nicht jede Organisation braucht sofort ein neues Operating Model. Aber bestimmte Signale zeigen, dass die bestehende Struktur an ihre Grenzen stößt.
Entscheidungsstau: Themen wandern von Meeting zu Meeting, ohne dass sich etwas bewegt, weil unklar ist, wer sie treffen darf.
Dauerhafte Überlastung einzelner Personen: Wenn bestimmte Rollen systematisch überlastet sind, liegt das selten an mangelnder Kapazität. Häufiger fehlt eine klare Aufgabenteilung oder Entscheidungsdelegation.
Wachstum: Was mit zehn Personen informell funktioniert hat, bricht bei dreißig zusammen. Wachstum erzwingt Struktur, sonst entstehen Parallelstrukturen und Informationssilos. Ein typischer Kipppunkt liegt bei 15 bis 20 Personen.
Wiederholte Konflikte zwischen Teams: Wenn dieselben Reibungspunkte immer wieder auftreten, obwohl die Beteiligten wechseln, ist die Ursache strukturell.
Strategiewechsel: Eine neue strategische Ausrichtung erfordert meist eine Anpassung von Teamarchitektur, Entscheidungswegen und Meetingstruktur. Ohne angepasstes Operating Model bleibt die neue Strategie Absichtserklärung.
Wie ein Operating Model in der Praxis entsteht
Ein Operating Model entsteht nicht am Schreibtisch, sondern in der Auseinandersetzung mit der konkreten Situation: Wie arbeitet die Organisation heute? Wo entstehen Reibungen? Was funktioniert, was nicht? Ein Modell, das auf dem Papier perfekt aussieht, aber nicht zur Realität der Organisation passt, bringt nichts.
Das Vorgehen folgt fünf Bausteinen:
- Analyse & Zielbild. Ein Operating Rhythm Assessment zeigt, wo es bei Rhythmus, Rollen und Entscheidungen hakt. Daraus entsteht ein Zielbild für Strategie, Taktik und operative Ebene.
- Operating Model Blueprint. In Workshops und Interviews werden Ebenen, Rollen, Cadence, Quality Gates und Tool-Mapping entworfen und die sechs Layer auf die Organisation zugeschnitten – auf den nächsten sinnvollen Schritt, nicht auf ein Idealbild.
- Leadership Rhythm. Strategisches Planning, Roadmap- und Portfolio-Sync, Business-Reviews und klare Entscheidungsregeln, damit Führung steuert statt Feuerwehr zu spielen.
- Team-Routinen & Enablement. Refinements, Reviews, Umgang mit Abhängigkeiten, Definition of Ready und Definition of Done im Alltag – leichtgewichtig, aber verbindlich.
- Follow-up & Nachhaltigkeit. Begleitung eines Pilotzyklus, Retros und Minimal-Metriken. Ein Operating Model ist nach der Einführung nicht abgeschlossen, es wird mit der Organisation weiterentwickelt.
Zeitlich heißt das in der Regel: Der Blueprint entsteht in zwei bis drei Wochen, das Enablement mit Pilotzyklus dauert sechs bis zehn Wochen, und bis das Modell stabil läuft und getragen wird, vergehen typischerweise drei bis vier Monate.
Mehr zum Clarity and Leadership Operating Model
Häufige Fragen
Was unterscheidet ein Operating Model von einem Organigramm?
Braucht jede Organisation ein Operating Model?
Wie lange dauert die Einführung eines Operating Models?
Ist CALM ein Framework oder ein Beratungsansatz?
Was passiert, wenn nur einzelne Layer eingeführt werden?
Was ist ein Operating Model einfach erklärt?
Welche drei Funktionen unterscheidet CALM bei Rollen?
Welche vier Entscheidungsmodi gibt es?
Welche Kennzahlen zeigen, ob ein Operating Model funktioniert?
Woran erkenne ich, dass unser Operating Model nicht mehr passt?
War dieser Artikel hilfreich?
Welche Frage zum Thema dürfen wir noch beantworten?
Danke für dein Feedback! 🙏
🧭 CALM-Diagnose
Wo sitzt die Reibung bei euch?
Die Diagnose fragt euren Ist-Stand entlang der Dimensionen des Modells ab und benennt, wo es hakt. Die Auswertung kommt als Seite und als PDF, sobald ihr die Adresse bestätigt habt.
Diagnose starten →Oder zuerst das Paper lesen: Warum SAFe-Einführungen scheitern (PDF, ohne Anmeldung) →