Eine unklare oder umstrittene Problemsituation mit mehreren Perspektiven liegt vor, in der unterschiedliche Stakeholder das System unterschiedlich verstehen.
CATWOE Analysis
Vorbedingung
Was vorher fertig sein muss
Die Stakeholder sind identifiziert und ihre Rollen grob bekannt, sodass Customers, Actors und Owners zuordenbar werden.
Vorbereitung
Was vor Start vorliegen muss
Whiteboard oder geteiltes Board mit sechs Sektionen (Customers, Actors, Transformation, Worldview, Owners, Environment); Vorlage für Root Definition; Marker; Stakeholder-Übersicht.
Ein Facilitator mit SSM- oder CATWOE-Erfahrung; 4-8 Personen mit unterschiedlichen Perspektiven auf die Situation; ein Scribe für Annahmen und Differenzen; optional Vertretende der Hauptperspektiven.
Problemsituation in zwei bis drei Sätzen; Hinweis, dass CATWOE Teil von Soft Systems Methodology ist; Beispiele für Root Definitions; bekannte Konfliktlinien.
90-150 min
Sechs Sektionen am Board: Customers (Beneficiaries oder Victims), Actors (Ausführende), Transformation (Input zu Output), Worldview (Weltbild), Owners (Stop-Macht), Environment (Constraints). Anweisung: pro Sektion drei bis fünf konkrete Einträge. Bei mehreren Perspektiven mehrere Sätze von CATWOE.
Kernfrage
Die eine Frage, die diese Methode beantwortet
Aus welchen Perspektiven betrachten die Stakeholder das System, welche unterschiedlichen Root Definitions ergeben sich, und welche dieser Lesarten ist für die nächste Iteration handlungsleitend?
Ablauf
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Situationsklärung | 15-20 min | Problemsituation auf Board, Erwartungen klären, CATWOE-Schema einführen. Hinweis, dass mehrere Root Definitions möglich und gewünscht sind. | Wenn Teilnehmende erwarten, dass eine richtige Antwort herauskommt, ist die Methode nicht passend. CATWOE bringt mehrere Lesarten parallel, Entscheidung über Lesart folgt erst danach. |
2Phase 2: Solo-CATWOE | 20-25 min | Jeder Teilnehmer füllt für sich eine CATWOE-Vorlage aus, ohne Diskussion. Sechs Sektionen mit drei bis fünf Einträgen. | Solo-Phase verhindert Konvergenz auf Konsens-Worldview. Wenn alle dieselbe CATWOE hätten, wäre kein Perspektivenkonflikt da. |
3Phase 3: Vergleich und Worldviews | 30-45 min | Solo-CATWOEs am Board zusammentragen. Differenzen sichtbar, vor allem in Customers, Worldview und Transformation. Pro Worldview eigene Root Definition formulieren. | Worldview ist der häufigste Differenzpunkt. Wenn Teilnehmende dasselbe System unterschiedlich rahmen („Effizienzmaximierung“ vs. „Bürgerservice“), entstehen ganz andere Anforderungen. |
4Phase 4: Root Definitions formulieren | 20-30 min | Pro Worldview eine Root Definition als ein Satz: „Ein System, das von A betrieben wird, um T für C unter den Constraints E im Sinne der Owners O auszuführen, basierend auf der Annahme W.“ | Root Definition ist nicht Beschreibung, sondern hypothetisches System. Wenn Satz zu lang oder unklar, CATWOE-Elemente schärfen. Mehrere RDs nebeneinander sind erlaubt. |
5Phase 5: Entscheidung über Lesart | 20-30 min | Welche Root Definition wird für die nächste Iteration handlungsleitend, welche bleibt Alternative. Begründung dokumentieren. Implikationen für Anforderungen, Prozess oder Stakeholder ableiten. | Entscheidung muss explizit sein, nicht implizit durch Mehrheit. Wenn keine Lesart entschieden, bleibt CATWOE Diagnose ohne Konsequenz. Sponsor oder Owner entscheidet, nicht Workshop. |
Artefakt
Was am Ende rauskommt
CATWOE-Tabelle mit allen sechs Elementen pro Perspektive, ein bis drei Root Definitions als Sätze, Entscheidung über handlungsleitende RD mit Begründung, Implikationen für Anforderungen und Stakeholder.
- Miro- oder Mural-Board mit CATWOE-Template
- Confluence-Seite mit Tabelle und RD-Sektion
- Notion-Seite mit Datenbank pro Element
- Markdown im Repo unter docs/analysis/catwoe-<thema>.md
Datum, Situation und Teilnehmende im Header. Bei Folge-Workshops Bezug zur vorherigen RD und Veränderungen explizit dokumentieren. Wenn Worldview sich verändert, neue Iteration mit Begründung.
CATWOE Analysis Arbeitsvorlage
Kompakte Arbeitsvorlage für CATWOE Analysis mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# CATWOE Analysis 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
- CATWOE Canvas:
- Root Definition:
- Stakeholder-Perspektiven:
- Constraints:
## Offene Fragen
- ...
## Nächster Schritt
Owner, Datum, Erfolgssignal.Beispielausgabe
Konkret gefülltes Szenario
## CATWOE — Online-Bürgerportal Stadt Hamburg, Stelle „Anmeldung neuer Wohnsitz“, 25.06.2026
**Teilnehmende**: 6 Personen aus IT, Bürgeramt, Datenschutz, Bürgerbeirat.
### Perspektive A: Effizienz-Worldview (IT, Verwaltungsleitung)
- C: Bürger:innen, Bürgeramt-Mitarbeitende.
- A: IT, Bürgeramt-Vorderbüro.
- T: Antrag (analog/digital) zu registriertem Wohnsitz mit gedruckter Bescheinigung.
- W: Verwaltungseffizienz und Durchsatz sind Hauptmaß.
- O: Stadtdirektion, Finanzressort.
- E: Bundesmeldegesetz, IT-Budget, Datenschutz, Personalkapazität.
- RD: System, das von Bürgeramt und IT betrieben wird, um Wohnsitzanmeldungen mit minimaler Bearbeitungszeit für Bürger:innen zu registrieren, unter Datenschutz- und Meldegesetz, im Sinne der Stadtdirektion.
### Perspektive B: Teilhabe-Worldview (Bürgerbeirat, Datenschutz)
- C: Bürger:innen, vor allem nicht-digital affine Gruppen.
- A: Bürgeramt-Mitarbeitende, ehrenamtliche Helfer:innen.
- T: Anmeldebedarf zu inklusiv verfügbarer Bescheinigung mit echter Wahlmöglichkeit analog/digital.
- W: Teilhabe und Barrierefreiheit haben Priorität, auch wenn weniger effizient.
- O: Bürgerbeirat, Datenschutzbeauftragte.
- E: Bundesmeldegesetz, Barrierefreiheits-Stärkungsgesetz, ehrenamtliche Ressourcen.
- RD: System, das von Bürgeramt mit Unterstützung Ehrenamt betrieben wird, um Wohnsitzanmeldungen für alle Gruppen mit echter Wahlmöglichkeit verfügbar zu machen, unter Meldegesetz und Barrierefreiheits-Anforderungen.
### Entscheidung
Für Phase 1 (2026-2027) wird Worldview B leitend, Effizienz-Aspekte als Constraint berücksichtigt. Folgeworkshop zur Anforderungserhebung mit Bürgerbeirat-Vertretung am 15.07.Stolperfallen
Symptome erkennen, gegensteuern
Eine richtige Antwort gesucht
Workshop versucht, eine einzige korrekte CATWOE zu erarbeiten, Differenzen werden weichgespült.
Mehrere Perspektiven explizit zulassen. Pro Worldview eigene CATWOE. Konsens ist nicht Ziel der Methode, sondern Sichtbarmachung der Konfliktlinien.
Customers und Actors vermischt
Bürgeramt-Mitarbeitende stehen sowohl als C als auch A in derselben CATWOE, Rollenklärung fehlt.
C = wer profitiert oder erleidet das Ergebnis; A = wer führt die Transformation aus. Pro Element auf Verbnähe achten: Customers passiv, Actors aktiv.
Worldview oberflächlich
W enthält Floskeln wie „gute Verwaltung“, kein konkretes Wertesystem oder Annahme.
Worldview als Annahme formulieren: „Wir glauben, dass X wichtiger ist als Y.“ Bei mehreren Stakeholdern unterschiedliche Worldviews explizit benennen.
Root Definition als Anforderungsliste
RD ist eine Liste von Anforderungen, kein konzeptueller Satz mit allen sechs Elementen.
RD-Form strikt: „System, das von A betrieben wird, um T für C unter E im Sinne von O, basierend auf W.“ Alle sechs Elemente in einem Satz.
Keine Entscheidung über Lesart
Workshop endet mit drei RDs nebeneinander, keine wird handlungsleitend, Workshop bleibt folgenlos.
Sponsor oder Owner entscheidet vor Workshop-Ende. Begründung dokumentieren. Alternative RDs als Beobachtungs-Punkt für Folge-Iterationen aufheben, nicht in Mülleimer.
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.