Vorher abschließenWiederkehrendes Problemnicht im Katalog
Ein Phaenomen wiederholt sich trotz wiederholter Quick Fixes (mindestens drei Vorkommen mit aehnlichem Muster).
Ohne: Ohne Wiederholung bleibt das Iceberg Model akademisch, ein 5-Whys reicht.
Run SheetSystems ThinkingPattern and Structure Analysis
Iceberg Model
KomplexitätLow
Zeit30-60 min
Teilnehmende2-10
FormatBoth
MaturityEstablished
01
Vorbedingung
Was vorher fertig sein muss
Vorher abschließenTimeline der Events
Eine Timeline der bisherigen Vorkommen mit Daten und Kontext liegt vor, sodass Patterns erkennbar sind.
Ohne: Ohne Timeline werden Patterns vermutet statt belegt, die Analyse bleibt anekdotisch.
02
Vorbereitung
Was vor Start vorliegen muss
Materialien
Whiteboard oder Miro-Board mit vier Ebenen (Events oben, Patterns, Structures, Mental Models unten); Stickies in vier Farben; Timeline-Anhang; Beobachtungen und Daten zu Vorkommen.
Personen / Rollen
Ein Facilitator; 3-6 Teilnehmende mit Systemkenntnis; ein Scribe; idealerweise Personen aus mehreren Ebenen der Organisation (Operations, Lead, Strategie).
Vorabinfos
Drei bis fuenf konkrete Vorkommen mit Daten; bisherige Massnahmen und ihr Erfolg; bekannte Anreize, Regeln und Glaubenssaetze im System.
Zeitbedarf
90-150 min
Setup
Eisbergspitze (Events) oben, Wasserlinie deutlich. Patterns als 1. Tauchebene, Structures als 2. Tauchebene, Mental Models als 3. Tauchebene. Regel: Ebenen werden nacheinander befuellt, nicht durcheinander.
03
Kernfrage
Die eine Frage, die diese Methode beantwortet
Welche Patterns, Strukturen und Mental Models erzeugen die wiederkehrenden Events, und auf welcher Ebene wirkt eine Intervention nachhaltig?
04
Ablauf
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Events sammeln | 20 min | Konkrete Events der letzten 12 Monate auflisten. Datum, was passiert ist, Sofortreaktion. Mindestens drei vergleichbare Vorkommen. | Wenn nur ein Event existiert, ist Iceberg nicht passend. Bei zwei Events Indizien sammeln, ob mehr existieren, oder andere Methode waehlen. |
2Phase 2: Patterns identifizieren | 30 min | Patterns als wiederkehrendes Verhalten ueber Zeit. Frage: was wiederholt sich, was ist die Trend-Aussage. Beispiele: „jedes Quartalsende eskalieren Performance-Probleme“ oder „neue Features brechen alte Funktionen“. | Patterns sind Verallgemeinerungen, keine Einzelereignisse. Wenn die Aussage nur ein Event meint, ist sie zu spezifisch. |
3Phase 3: Structures aufdecken | 40 min | Strukturen sind Anreize, Prozesse, Org-Setups, Tool-Setups, Belohnungen. Frage: welche Struktur macht das Pattern wahrscheinlich. Beispiele: Bonus an Output statt Outcome, fehlende QA-Phase, Reporting-Linien. | Strukturen sind aenderbar, aber unsichtbar. Pattern ohne Struktur landet im Symptom. Mindestens zwei Strukturen pro Pattern explizit machen. |
4Phase 4: Mental Models | 30 min | Glaubenssaetze, Annahmen, Kulturmuster, die die Strukturen rechtfertigen. Beispiele: „Speed schlaegt Qualitaet“, „der Markt belohnt nur Releases“, „wir haben keine Zeit fuer Tests“. | Mental Models sind die unbequemste Ebene. Wenn die Gruppe ausweicht, bleibt Iceberg bei Strukturen. Sicherheit etablieren, Naming statt Schuldzuweisung. |
5Phase 5: Hebel und Aktionen | 20 min | Pro Ebene eine moegliche Aktion: Event (Quick Fix), Pattern (Mustererkennung), Structure (Anreize aendern), Mental Model (Dialog). Empfehlung: mindestens eine Aktion auf Structure- oder MM-Ebene. | Wenn alle Aktionen Events adressieren, lernt das System nicht. Mindestens eine Aktion soll Struktur veraendern, sonst kommt das Pattern wieder. |
05
Artefakt
Was am Ende rauskommt
Form
Iceberg-Diagramm als Bild plus Markdown-Begleitdokument mit Eventliste, Patternliste, Strukturliste, Mental-Models-Liste, abgeleiteten Hebeln und konkreten Aktionen pro Ebene mit Owner und Frist.
Tool-Alternativen
- Miro oder FigJam mit Iceberg-Template
- Notion- oder Confluence-Seite mit vier Sektionen
- Markdown im Repo unter docs/systems/iceberg/
- Lucidchart oder draw.io mit selbst gebauter Iceberg-Vorlage
Versionierung / Ownership
Pro Analyse eigener Eintrag mit Datum und betrachtetem Phaenomen. Aktionen separat verfolgen, sodass die Iceberg-Analyse spaeter aussagekraeftig bleibt. Bei Folge-Iceberg-Workshops Vorgaenger verlinken.
spreadsheet
Iceberg Model Arbeitsvorlage
Kompakte Arbeitsvorlage für Iceberg Model mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Iceberg Model Arbeitsmatrix
| Element | Beschreibung | Bewertung | Evidenz | Owner | Nächster Schritt |
|---|---|---|---|---|---|
| 1 | | | | | |
| 2 | | | | | |
| 3 | | | | | |
## Ergebnisartefakte
- Iceberg Worksheet:
- Pattern Notes:
- Intervention Ideas:
## Entscheidung oder Empfehlung
Welche Konsequenz ergibt sich aus der Matrix?06
Beispielausgabe
Konkret gefülltes Szenario
iceberg-model-beispiel.md
markdown## Iceberg Model - Wiederkehrende Quartals-Outages Workspot, Mai 2026
**Events**
- 31.03.2026: Outage 47 min bei Monatsabschluss.
- 30.06.2025: Outage 1 h 12 min bei Monatsabschluss.
- 31.12.2024: Outage 38 min bei Jahresabschluss.
- 31.03.2025: Performance-Drop ohne kompletten Outage.
**Patterns**
- Reporting-Lastspitze an Monatsenden ueberlastet konsistent die Datenbank.
- Hotfixes nach jedem Ereignis loesen Symptom, Architektur bleibt unveraendert.
**Structures**
- Reporting-Queries laufen auf Produktiv-DB ohne Read-Replica.
- Engineering-Backlog priorisiert Features ueber Plattformresilienz.
- Sales bekommt Bonus auf Monatsabschluss, erhoeht Reporting-Druck genau zur kritischen Zeit.
**Mental Models**
- „Plattform-Arbeit zahlt nicht ein, Kunden zahlen fuer Features.“
- „Hotfix ist guenstiger als Refactoring.“
- „Outages sind unvermeidlich.“
**Aktionen**
- IB-01 (Structure): Read-Replica fuer Reporting bauen. Owner: @marcus, bis 31.07.
- IB-02 (Structure): 20% der Sprint-Kapazitaet fuer Plattform-Resilienz fest reservieren. Owner: @julia (CTO).
- IB-03 (Mental Model): Quartals-Workshop mit Sales und Engineering zu Reporting-Lasten, Owner: @lisa, am 25.06.
- IB-04 (Event): Hotfix-Playbook auf neuesten Stand. Owner: @ben.07
Stolperfallen
Symptome erkennen, gegensteuern
Falle
Stop auf Event-Ebene
Symptom
Workshop liefert Hotfix-Plan, keine Struktur-Veraenderung.
Was tun
Phase 3 und 4 nicht ueberspringen. Aktionsmatrix erzwingt mindestens eine Aktion auf Struktur- oder MM-Ebene.
Falle
Patterns zu spezifisch
Symptom
Pattern wird als „Outage am 31.03.“ formuliert statt als wiederkehrendes Muster.
Was tun
Pattern muss mindestens drei Events generalisieren. Wenn nicht moeglich, mehr Events sammeln oder Iceberg fuer dieses Phaenomen nicht passend.
Falle
Mental Models als Personenkritik
Symptom
MM-Aussagen wie „X glaubt, dass...“ statt systemischer Annahmen.
Was tun
MMs als geteilte Annahmen formulieren. „Wir glauben, dass...“ oder „das System belohnt, dass...“. Personen-Aussagen umformulieren.
Falle
Kein Owner fuer Strukturaktionen
Symptom
Strukturen werden identifiziert, aber niemand hat Mandat, sie zu aendern.
Was tun
Workshop nur mit Personen, die Mandat haben oder eskalieren koennen. Ohne Eskalations-Owner Iceberg bleibt Analyse ohne Folge.
Falle
Wertung als Diagnose
Symptom
Strukturen oder MMs werden als „falsch“ bezeichnet, Diskussion kippt in Schuldgespraech.
Was tun
Diagnose statt Wertung. Eine Struktur ist nicht „falsch“, sondern erzeugt ein Pattern, das wir nicht wollen. Sprachliche Disziplin durch Facilitator.
08
Abbruchkriterien
Done-Signale, in unter einer Minute prüfbar
Nur ein oder zwei Events bekannt, Patterns nicht ableitbar.
Mandat fuer strukturelle Aenderungen fehlt, Workshop bleibt folgenlos.
Psychologische Sicherheit fuer Mental-Model-Diskussion gestoert.
Daten zu Events lueckenhaft, Pattern-Aussage nicht belegbar.
Phaenomen ist akut und braucht sofortige Reaktion, Tiefendiagnose verzoegert kritisches Handeln.
Workshop wird auf unter 60 min komprimiert, Tieftauchen nicht moeglich.
Run Sheet durchgearbeitet?
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.