Was vorher fertig sein muss
Ein zu kartierender Systembereich ist abgegrenzt (z. B. Logistikkette, Onboarding-Prozess, Plattform-Oekosystem) mit Start- und Endkriterien.
Wesentliche Stakeholder im Systembereich sind identifiziert.
Was vor Start vorliegen muss
Whiteboard oder Miro-Board mit grossflaechigem Platz; Stickies in mehreren Farben fuer Komponenten, Akteure, Fluesse, Grenzen; Pfeile mit Beschriftung; Legende sichtbar.
Ein Facilitator; 4-10 Teilnehmende mit unterschiedlichen Perspektiven (intern, extern, technisch, Business); ein Scribe; optional ein Aussenstehender als Challenger.
Beschreibung des Systembereichs; bekannte Komponenten, Akteure und Beziehungen; aktuelle Pain Points; Daten zu Fluessen (Material, Information, Geld); externe Einflussfaktoren.
3-4 h
Grenzen des Systems schriftlich definieren (was ist innen, was aussen). Legende anbringen. Regel: Verschiedene Elementtypen verschiedene Farben. Pfeile beschriften (was fliesst).
Die eine Frage, die diese Methode beantwortet
Welche Komponenten, Akteure und Beziehungen formen das System, wo liegen Grenzen, und welche Hebel sind innerhalb der Grenze veraenderbar?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Grenzen und Zweck | 30 min | Systemzweck und Grenze schriftlich. Was gehoert zum System (innen), was ist Umwelt (aussen). Zeithorizont festlegen. | Wenn Grenzen verschwimmen, ist die Map politisch. Klare Entscheidung mit Decider, sonst zieht jeder Stakeholder die Grenze anders. |
2Phase 2: Komponenten und Akteure | 45 min | Stickies fuer Komponenten (z. B. Systeme, Tools, Prozesse) und Akteure (z. B. Teams, Kunden, Lieferanten). Innerhalb und ausserhalb der Grenze anordnen. | Wenn 50 Komponenten entstehen, ist Aggregation noetig. Gleichartige Komponenten zusammenfassen, Detail in Sub-Map. |
3Phase 3: Fluesse und Beziehungen | 60 min | Pfeile zwischen Komponenten. Pfeil-Beschriftung: was fliesst (Material, Information, Geld, Vertrauen). Farbe pro Fluss-Typ. | Wenn alle Pfeile gleich aussehen, ist die Map unleserlich. Mindestens drei Fluss-Typen unterscheiden, gefaerbt oder gestrichelt. |
4Phase 4: Pain Points und Constraints | 30 min | Pain Points (rot) markieren: Engpaesse, Konflikte, Doppelarbeit. Externe Constraints (z. B. Regulierung, Marktlage) am Rand der Grenze. | Pain Points machen Map handlungsrelevant. Map ohne Pain Points ist Inventar. Mindestens drei Pain Points pflicht. |
5Phase 5: Hebel und Aktionen | 30 min | Hebelpunkte innerhalb der Grenze identifizieren. Pro Top-Pain einen Hebel und konkrete Folgeaktion mit Owner und Frist. | Hebel ausserhalb der Grenze sind nicht beeinflussbar. Wenn alle Hebel aussen liegen, ist die Grenze falsch geschnitten. |
Was am Ende rauskommt
Systems Map als Bild plus Markdown-Begleitung mit Grenzen, Komponentenliste, Akteursliste, Flussliste, Pain Points, Constraints, Hebeln und Aktionsliste mit Owner und Frist.
Pro Iteration eigene Version mit Datum. Aenderungen an Grenzen oder Komponenten dokumentieren. Bei Folgeworkshops Vorgaenger-Map referenzieren.
Kompakte Arbeitsvorlage für Systems Mapping mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Systems Mapping 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
- System Map:
- Dependencies:
- Leverage Points:
## Offene Fragen
- ...
## Nächster Schritt
Owner, Datum, Erfolgssignal.Konkret gefülltes Szenario
## Systems Map - Beleg-Eingang Steuerkanzlei Bertram, Mai 2026
**Grenze**: Vom Beleg-Versand des Mandanten bis zur DATEV-Buchung. Zeithorizont 12 Monate.
**Komponenten (Auszug)**
- Mandanten-Postfach (E-Mail, Briefkasten, App).
- Belegannahme-Postfach Kanzlei (5 Quellen).
- DATEV Unternehmen Online.
- Internes Ablagesystem (Ordnerstruktur auf NAS).
- Belegerkennung (manuell durch Jana).
**Akteure**
- Mandanten (innerhalb der Beziehung, ausserhalb der Kanzleigrenze).
- Sabine (Inhaberin).
- Jana (Fachangestellte).
- DATEV-Support (extern).
**Fluesse**
- Material (Papierbelege): Mandant -> Briefkasten -> Jana.
- Information (Digital): Mandant -> E-Mail -> Jana -> DATEV.
- Geld: Mandant -> Kanzlei (Honorar).
- Vertrauen: bidirektional, abhaengig von Reaktionszeit.
**Pain Points**
- Fuenf Belegquellen, keine kanonische Eingangsstelle.
- Manuelle Sortierung dauert 4 h/Woche.
- Mandanten wissen oft nicht, welcher Beleg fehlt.
**Constraints (extern)**
- DSGVO-Aufbewahrungspflicht.
- DATEV-Schnittstellen-Format.
**Hebel und Aktionen**
- SM-01: Kanonische Eingangs-App fuer Mandanten (Owner: Sabine, bis 31.07.).
- SM-02: Belegcheckliste pro Mandant (Owner: Jana, bis 30.06.).
- SM-03: Quartals-Review der Eingangsstellen (Owner: Sabine).Symptome erkennen, gegensteuern
Map waechst, Diskussion wandert ab, niemand weiss, was noch dazugehoert.
Decider entscheidet Grenze vor Beginn. Bei Drift Facilitator unterbricht. Externes wird klar am Rand markiert.
Akteure fehlen, Map wirkt wie Architekturdiagramm.
Pflichtphase Akteure. Pro Komponente fragen: wer interagiert. Mindestens fuenf Akteure pro Map.
Linien zwischen Komponenten ohne klaren Fluss-Typ, Map unleserlich.
Pfeile pflicht beschriften. Was fliesst, in welche Richtung, in welcher Frequenz. Farben fuer Fluss-Typen.
Map ist sauber, niemand fuehlt sich angesprochen, keine Folgeaktion entsteht.
Pain-Point-Phase explizit. Gezielt fragen: wo entsteht Reibung, wo gibt es Wartezeit, wo Doppelarbeit. Mindestens drei rot markierte Stellen.
Empfohlene Hebel betreffen Faktoren, die nicht beeinflusst werden koennen.
Pro Hebel pruefen: liegt er innerhalb der Grenze. Wenn nein, entweder Grenze neu schneiden oder Aktion verwerfen.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.