Die relevanten Funktionsbereiche, die unerwünschte Effekte (UDEs) wahrnehmen, sind benannt und im Workshop vertreten.
Current Reality Tree
Vorbedingung
Was vorher fertig sein muss
Mindestens eine Person versteht ToC-Logik und kann „Sufficient Cause“ und „Necessary Condition“ unterscheiden.
Vorbereitung
Was vor Start vorliegen muss
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.
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.
Bereichs- oder Systemabgrenzung; Liste bekannter Probleme aus den letzten Quartalen; bekannte Verbesserungsinitiativen, die nicht gewirkt haben; Definition „unerwünschter Effekt“ (UDE).
2-6 h
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.
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?
Ablauf
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: UDEs sammeln | 30-45 min | Solo-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 min | Pro 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 min | Gemeinsamer 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 min | Pfade 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 min | Pro 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. |
Artefakt
Was am Ende rauskommt
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.
- 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
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.
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.Beispielausgabe
Konkret gefülltes Szenario
## 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.Stolperfallen
Symptome erkennen, gegensteuern
UDEs sind Diagnosen statt Effekte
Einträge wie „Prozess unklar“ oder „Tool fehlt“ stehen als UDEs, beobachtbare Effekte fehlen.
Phase 1 strikt: UDE braucht Akteur, Häufigkeit, Auswirkung. Wer Diagnose schreibt, formuliert neu als beobachtetes Symptom.
Lose Pfeile ohne Logik
Pfeile verbinden Knoten, aber niemand kann den „Wenn A, dann B“-Satz formulieren.
Pro Pfeil Logiksatz verlangen. CLR-Prüfung in Phase 3 durchziehen. Pfeile ohne Logiksatz entfernen oder mit Annahmensticker versehen.
Baum bleibt einseitig
Alle UDEs hängen an einer einzigen Kette, andere Wurzeln werden nicht aufgemacht.
Facilitator verlangt mindestens zwei alternative Pfade pro UDE. Wer behauptet, andere Pfade gäbe es nicht, muss das belegen.
Personifizierung
Knoten enthalten Namen oder Schuldzuweisungen.
Pro Knoten reformulieren als Systemverhalten. „X kommuniziert nicht“ wird zu „Kommunikationskanal zwischen Funktion A und B nicht etabliert“.
Workshop bricht vor Phase 4 ab
UDE-Sammlung und Verzweigung passieren, aber Kernursachen werden nicht identifiziert.
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.
Abbruchkriterien
Done-Signale, in unter einer Minute prüfbar
Run Sheet durchgearbeitet?
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.