methodatlas
Run SheetSystems ThinkingConstraint Analysis

Current Reality Tree

KomplexitätHigh
Zeit2-6 h
Teilnehmende3-8
FormatWorkshop
MaturityCanonical
01

Vorbedingung

Was vorher fertig sein muss

Vorher abschließenStakeholder Mappingnicht im Katalog

Die relevanten Funktionsbereiche, die unerwünschte Effekte (UDEs) wahrnehmen, sind benannt und im Workshop vertreten.

Ohne: Ohne Querschnittsperspektive bleibt der Baum auf eine Abteilung beschränkt und der Kernkonflikt entgeht.

Mindestens eine Person versteht ToC-Logik und kann „Sufficient Cause“ und „Necessary Condition“ unterscheiden.

Ohne: Ohne diese Disziplin werden Verbindungen lose und der Baum wird ein Mindmap ohne kausale Aussagekraft.
02

Vorbereitung

Was vor Start vorliegen muss

Materialien

Großes Whiteboard oder Miro-Board (mindestens 6 m horizontal); Haftnotizen in zwei Farben (UDEs, Zwischen-Ursachen); Pfeile/Marker für Kausalpfeile; Timer; geteilte Definition von UDE.

Personen / Rollen

Ein Facilitator mit ToC-Erfahrung, der Logikprüfungen durchführt; drei bis acht Teilnehmer aus verschiedenen Funktionen (Sales, Operations, Engineering, Support); ein Scribe für Annahmen und Logikprüfungen.

Vorabinfos

Bereichs- oder Systemabgrenzung; Liste bekannter Probleme aus den letzten Quartalen; bekannte Verbesserungsinitiativen, die nicht gewirkt haben; Definition „unerwünschter Effekt“ (UDE).

Zeitbedarf

2-6 h

Setup

UDE-Bereich rechts am Board markieren (UDEs oben), Kausalkette nach links (Tiefer ins System). Beispiel-UDE und Beispiel-Kausalpfeil als Vorlage kleben. Telefone weg, ein Block Zeit ohne Unterbrechung.

03

Kernfrage

Die eine Frage, die diese Methode beantwortet

Welche wenigen Kernursachen liegen unter den unerwünschten Effekten des Systems, und an welchen Hebelpunkten würde eine Intervention die meisten UDEs gleichzeitig auflösen?

04

Ablauf

Marker: Phase

SchrittDauerAktionHinweis
1Phase 1: UDEs sammeln
30-45 minSolo-Sketching 10 min: jede Person schreibt mindestens fünf UDEs (negative, messbar erlebte Effekte). Gemeinsam clustern, Duplikate zusammenführen, auf 10-15 UDEs verdichten. Jeder UDE als kompletter Satz formulieren.UDEs sind keine Ursachen, sondern beobachtete Effekte. „Onboarding ist schlecht“ ist Diagnose, „Zwei von fünf Neukunden brechen in Woche 1 ab“ ist UDE.
2Phase 2: Kausale Verbindungen formulieren
60-90 minPro UDE rückwärts fragen: was muss zutreffen, damit dieser Effekt entsteht? Hypothesen als Zwischenknoten kleben, mit Pfeilen verbinden. Pfeile haben Logik-Aussagen („Wenn A, dann B“).Jeder Pfeil wird durch CLR (Categories of Legitimate Reservation) geprüft: Klarheit, Existenz, Kausalität, Genügsamkeit, Vorhersagbarkeit. Wer Pfeile setzt, muss erklären.
3Phase 3: Logik prüfen
30-45 minGemeinsamer Walkthrough von unten nach oben. Pro Pfeil fragen: gibt es Gegenbeispiele? Reicht die Ursache aus oder fehlt eine zusätzliche Bedingung? Schwache Pfeile mit Annahmensticker markieren.Logikprüfung ist die teuerste Phase und der eigentliche Wert der Methode. Wer hier abkürzt, hat am Ende ein Mindmap, kein CRT.
4Phase 4: Kernursachen identifizieren
20-30 minPfade rückverfolgen, gemeinsame Wurzeln markieren. Eine Ursache, die mehrere UDEs erklärt, ist Kandidat für Kernursache. Top 1-3 Kernursachen kennzeichnen.Wenn jede UDE eine eigene Wurzel hat, ist der Baum unvollständig oder die UDEs liegen in unterschiedlichen Systemen. Im ersten Fall weiter verbinden, im zweiten Bereich verengen.
5Phase 5: Interventionen und Followups
20-30 minPro Kernursache Interventionsideen sammeln. Pro Idee benennen, welche UDEs sie auflösen würde. Owner, nächster Schritt und Termin für eine Review festhalten.Interventionen werden in der Folge mit Future Reality Tree validiert. CRT ist Diagnose, FRT ist Therapieentwurf, beide gehören zusammen.
05

Artefakt

Was am Ende rauskommt

Form

CRT-Diagramm (Bild oder Miro-Frame) plus strukturiertes Dokument mit UDE-Liste, vollständigem Kausal-Graph in Textform, identifizierten Kernursachen, Annahmensticker-Liste und Interventionsideen mit Owner.

Tool-Alternativen
  • Miro oder FigJam mit CRT-Template
  • Whiteboard mit Foto-Export
  • draw.io mit gerichtetem Graph
  • Konzept-Tools wie Flying Logic für ToC-Bäume
Versionierung / Ownership

Pro Diagnoselauf eigener Eintrag mit Datum, Bereich und Teilnehmern. Folge-Iterationen nicht überschreiben; Änderungen am Baum als Delta-Liste am Ende des Dokuments führen.

canvas

Current Reality Tree Arbeitsvorlage

Kompakte Arbeitsvorlage für Current Reality Tree mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.

# Current Reality Tree Canvas

## Kontext

Wofür wird die Methode eingesetzt?

## Kernfrage

Welche Frage soll am Ende beantwortet sein?

## Input

Welche Daten, Beobachtungen oder Materialien liegen vor?

## Arbeitsfläche

- Bereich 1:
- Bereich 2:
- Bereich 3:
- Beziehungen / Muster:

## Ergebnisartefakte
- Current Reality Tree:
- Core Problems:
- Intervention Ideas:

## Offene Fragen

- ...

## Nächster Schritt

Owner, Datum, Erfolgssignal.
06

Beispielausgabe

Konkret gefülltes Szenario

current-reality-tree-beispiel.md
markdown
## Current Reality Tree — Customer Success bei einer Software-Beratung (20.05.2026)

**Bereich**: Customer Success Team, 12 Personen, 80 aktive Kundenkonten.

**UDEs (Auszug, 12 insgesamt)**:
- 30% der Renewals werden in den letzten 30 Tagen vor Ablauf verhandelt.
- Time-to-First-Value für Neukunden liegt bei 6 Wochen statt 2.
- Drei von vier Eskalationen kommen vom selben Account.
- Onboarding-Playbook wird in 40% der Fälle nicht durchlaufen.

**Kausal-Auszug** (Pfeile von unten nach oben):
- Kernursache: Account-Owner-Rolle ist nicht klar definiert (CS, Sales und PM teilen sich Verantwortung).
  → kein konsistenter Onboarding-Playbook-Owner
  → Playbook wird ausgelassen
  → Time-to-First-Value lang
  → Wahrnehmung „Produkt schwer“ beim Kunden
  → späte Renewal-Verhandlung

**Interventionen**:
- DACI-Klärung für Account-Owner-Rolle. Owner: @marcus, bis 30.05.
- Renewals-Cadence 90 Tage vor Ablauf. Owner: @lisa, ab Q3.

**Annahmensticker**: Drei Pfeile mit „nicht ausreichend belegt“, Spike auf CRM-Daten geplant.
07

Stolperfallen

Symptome erkennen, gegensteuern

Falle

UDEs sind Diagnosen statt Effekte

Symptom

Einträge wie „Prozess unklar“ oder „Tool fehlt“ stehen als UDEs, beobachtbare Effekte fehlen.

Was tun

Phase 1 strikt: UDE braucht Akteur, Häufigkeit, Auswirkung. Wer Diagnose schreibt, formuliert neu als beobachtetes Symptom.

Falle

Lose Pfeile ohne Logik

Symptom

Pfeile verbinden Knoten, aber niemand kann den „Wenn A, dann B“-Satz formulieren.

Was tun

Pro Pfeil Logiksatz verlangen. CLR-Prüfung in Phase 3 durchziehen. Pfeile ohne Logiksatz entfernen oder mit Annahmensticker versehen.

Falle

Baum bleibt einseitig

Symptom

Alle UDEs hängen an einer einzigen Kette, andere Wurzeln werden nicht aufgemacht.

Was tun

Facilitator verlangt mindestens zwei alternative Pfade pro UDE. Wer behauptet, andere Pfade gäbe es nicht, muss das belegen.

Falle

Personifizierung

Symptom

Knoten enthalten Namen oder Schuldzuweisungen.

Was tun

Pro Knoten reformulieren als Systemverhalten. „X kommuniziert nicht“ wird zu „Kommunikationskanal zwischen Funktion A und B nicht etabliert“.

Falle

Workshop bricht vor Phase 4 ab

Symptom

UDE-Sammlung und Verzweigung passieren, aber Kernursachen werden nicht identifiziert.

Was tun

Zeitbudget vorab realistisch ansetzen (mindestens 3 h). Wenn nicht durchführbar, in zwei Sessions splitten, aber Phase 4 zwingend in einer der Sessions abschließen.

08

Abbruchkriterien

Done-Signale, in unter einer Minute prüfbar

UDE-Sammlung bleibt unter 5 Einträgen, Systemverständnis ist zu dünn.
Nur eine Funktion vertreten, Querschnittssicht fehlt.
Kein Facilitator mit ToC-Disziplin, Pfeile bleiben lose Mindmap-Verbindungen.
Workshop unter 90 min angesetzt, fünf Phasen nicht durchführbar.
Probleme verteilen sich auf mehrere unverbundene Systeme, Bereich nicht abgegrenzt.
Gruppe weigert sich, Personifizierungen aufzulösen, Baum bleibt politisch.

Run Sheet durchgearbeitet?

Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.