Zwiebeldiagramm

Zweck

Das Zwiebeldiagramm beantwortet eine Frage der Distanz: wer die Lösung direkt berührt, wessen Arbeit sich mit ihrer Einführung ändert, wer sie umgibt, ohne sie zu berühren, und wer sie von ausserhalb des Unternehmens zu spüren bekommt. Es ordnet die Stakeholder in konzentrischen Ringen um die entstehende Lösung an, und diese Position bestimmt anschliessend die Art des Kontakts, von der täglichen Zusammenarbeit mit dem inneren Ring bis zur formellen Konsultation des äusseren.

Zwei Entscheidungen hängen daran. Die erste ist der Lösungsumfang: das Zentrum muss benannt sein, bevor der erste Stakeholder-Name gesetzt wird, und die Zuordnung erzwingt eine Klärung dessen, was die Lösung umfasst, denn jeder Name wird an seiner Distanz zu diesem Zentrum gemessen. Die zweite ist der Engagement-Plan: wen man direkt befragt, wen man am Arbeitsplatz beobachtet, wen man informiert, wen man über eine Vertretung erreicht. Der Ring liefert die Standardantwort auf diese Frage, noch bevor irgendjemandes Macht gewogen wurde.

Sein eigener Beitrag ist die Vollständigkeit. Ein Team benennt von sich aus jene, die die Lösung bauen, und jene, die sie täglich nutzen werden. Regulatoren, Lieferanten, Integrationspartner und Endkunden kommen spät, oft erst nachdem die Architektur ohne sie festgezurrt wurde. Das Diagramm macht diese Lücke sichtbar: ein leerer äusserer Ring ist eine Frage an den Raum.

Das Ergebnis ist eine Seite: vier beschriftete Ringe, jeder mit benannten Rollen gefüllt, die Lösung im Zentrum. Sie ist auf einen Blick lesbar und ebenso schnell bestreitbar. Macht und Interesse liest man auf der Stakeholder-Matrix, das Register der Namen, Rollen und Interessen stammt aus der Stakeholderliste, die die Zwiebel speist, und der Nutzerarchetyp, der Designentscheide trägt, ist die Persona.

Einsatz

Wann einsetzen

• Lösungsumfang noch offen: das Zuordnen der Stakeholder zwingt dazu, den Inhalt des Zentrums auszusprechen.
• Mehrere Schichten organisatorischer Distanz: Team, betroffene Einheit, Unternehmen, Aussenwelt, jeder Ring trägt Leute.
• Vor der Planung der Elizitation: die Distanz zum Zentrum bestimmt, wen man direkt befragt und wen man informiert.
• Stakeholderliste bereits erstellt: die Zwiebel positioniert sie in einer Sitzung, ohne sie neu aufzubauen.
• Zweifel an der Vollständigkeit: ein leerer äusserer Ring ist sichtbar und bestreitbar, Regulator, Lieferant, Hosting-Anbieter.
• Uneinigkeit über das Wort «Benutzer»: das Setzen der Namen trennt den internen Sachbearbeiter vom Endkunden.
• Wesentliche Änderung des Umfangs: ein neuer Integrationspartner füllt einen Ring neu, die Karte wird überarbeitet.

Beschreibung

Das Zentrum und die vier Ringe

Das Zentrum trägt die Lösung, definiert durch ihre Grenze: was das System tut, was es ersetzt, was es draussen lässt. Solange diese Grenze nicht ausgesprochen und vom Auftraggeber akzeptiert ist, wird die Zuordnung im luftleeren Raum diskutiert, denn die Frage an jeden Namen ist seine Distanz zu diesem Zentrum.

Der BABOK setzt vier Ringe, vom Zentrum nach aussen. Jeder ist durch den Test definiert, der einen Stakeholder für ihn qualifiziert.

• Ring 1, Lösungslieferung (solution delivery): die Personen, die direkt an der Herstellung der Lösung beteiligt sind. Projektleiter, Business Analyst, Architekt, Entwickler, Tester, User-Experience-Designer. Der qualifizierende Test ist der Akt des Herstellens: konzipiert, baut, testet oder liefert diese Person die Lösung selbst? Der Betrieb der Lösung nach ihrer Auslieferung gehört in einen anderen Ring: der Support, der sie am Laufen hält, sieht seine Arbeit sich ändern, und er sitzt in Ring 2. Ein externer Dienstleister, der die Lösung entwickelt, sitzt hingegen in Ring 1, obwohl er ausserhalb des Unternehmens steht, denn dieser Ring qualifiziert über die Tätigkeit.
• Ring 2, betroffene Organisationseinheit (affected organizational unit): die Personen, deren tägliche Arbeit sich ändert, wenn die Lösung ausgeliefert wird. Fachanwender, Schaltermitarbeitende, Support, die direkte Führung dieser Teams. Der qualifizierende Test ist die Änderung der Arbeit: wird diese Person ihren Beruf am Montagmorgen anders ausüben?
• Ring 3, Organisation oder Unternehmen (organization or enterprise): die Personen im Unternehmen, die mit der betroffenen Einheit interagieren, ohne dass sich ihre eigene Arbeit ändert. Auftraggeber, Geschäftsleitung, Fachexperten, Rechtsdienst, Compliance, Finanzen, interne Revision. Der qualifizierende Test ist die Interaktion ohne Veränderung: diese Person steuert, entscheidet, berät oder kontrolliert die Einheit aus Ring 2 und geht am Abend mit denselben Aufgaben nach Hause wie zuvor.
• Ring 4, betroffene externe Stakeholder (affected external stakeholders): die Parteien ausserhalb der Organisation, die von den Wirkungen der Lösung erreicht werden. Kunden, Lieferanten, Integrationspartner, Hosting-Anbieter, Regulatoren, Berufsverbände. Der qualifizierende Test ist die Unternehmensgrenze: steht dieser Stakeholder draussen?

Die Zuordnung entscheidet sich, indem man diese Tests der Reihe nach stellt, und das erste Ja ordnet den Stakeholder ein. Konzipiert, baut, testet oder liefert sie die Lösung? Ring 1. Wenn nein, ändert sich ihre tägliche Arbeit? Ring 2. Wenn nein, gehört sie zum Unternehmen, das die betroffene Einheit beauftragt oder beaufsichtigt? Ring 3. Wenn nein, steht sie draussen, und das ist Ring 4. Die Reihenfolge macht den Test entscheidbar: ein externer Integrator ist zugleich Hersteller und Aussenstehender, und die erste Frage entscheidet, bevor die letzte überhaupt gestellt wird. Ein Stakeholder besetzt genau einen Ring, und wenn sich zwei Ringe um einen Namen streiten, dann ist die Rolle eine doppelte. Das Mittel ist dann, die Rolle aufzuteilen.

Das Modell hat einen dokumentierten Ursprung. Ian Alexander veröffentlicht die Form 2004: ein Kern, der das Produkt trägt und keine Personen, dann unser System, also das Produkt und jene, die es betreiben, dann das umgebende System, dann die weitere Umwelt, mit benannten Rollenplätzen innerhalb jedes Rings (normaler Betreiber, Wartungsbetreiber, funktionaler Nutzniesser, Käufer, Förderer, Regulator, Entwickler). Die beiden Modelle gehen in einem Punkt auseinander: Alexander stellt die Betreiber in seinen zweiten Ring, der BABOK stellt nur die Hersteller in seinen ersten. Zu reproduzieren sind die Ringnamen und die Tests des BABOK, denn sie sind es, die der Leser im Standard wiederfindet. Die Volere-Methode von Suzanne und James Robertson macht aus dem Modell eine Vorlage für die Stakeholder-Analyse. Zwei Begriffe aus dieser Linie dienen im Alltag. Der leere Rollenplatz: ein vorgesehener Platz, den niemand besetzt, gilt als gestellte Frage, und die typische Formulierung lautet «sind Sie sicher, dass kein Regulator diese Lösung berührt?». Der negative Stakeholder: wer durch die Lösung benachteiligt wird oder sich ihr widersetzen wird, existiert und wird behandelt, auch wenn sein Name nicht an der Wand des Workshops steht.

Die Übung durchführen

1. Das Zentrum mit dem Auftraggeber schriftlich festlegen, vor der Sitzung. Ein Satz genügt, aber er muss benennen, was die Lösung ersetzt und was sie draussen lässt. Die Mehrzahl der Zuordnungsstreitigkeiten sind verkleidete Umfangsstreitigkeiten, und sie werden hier geregelt oder nirgends.
2. Die Stakeholderliste als Rohmaterial mitbringen. Die Zwiebel positioniert bestehende Namen; als Brainstorming auf leerem Blatt funktioniert sie schlecht.
3. Die vier Ringe grossformatig zeichnen, physisch oder digital, und sie beschriften, bevor der erste Name gesetzt wird. Ein unbeschrifteter Ring füllt sich nach der Intuition jedes Einzelnen.
4. Ring 1 füllen, indem man die einzige Frage stellt, die für ihn qualifiziert: wer konzipiert, baut, testet oder liefert diese Lösung? Die Antwort ist kurz und wird selten bestritten, was sie zu einem guten Einstieg macht.
5. Ring 2 füllen, indem man jeden verbleibenden Namen durch den Test der Arbeitsänderung schickt. Eine Rolle, von der niemand sagen kann, was sich in ihrem Arbeitstag ändert, gehört nicht in diesen Ring, und die Frage hat dann bereits ihre Information geliefert.
6. Ring 3 mit jenen füllen, die die betroffene Einheit steuern, entscheiden, beraten oder kontrollieren. Der Auftraggeber sitzt fast immer dort, was überrascht und in der Sitzung erklärt werden sollte.
7. Ring 4 nach Kategorien abfragen, laut: Kunden, Lieferanten, Integrationspartner, Hosting-Anbieter, Branchenregulator, Datenschutzbehörde, öffentliche Körperschaften, die die Leistung mitfinanzieren, Berufsverbände. Der Durchgang nach Kategorien findet, was das Gedächtnis nicht findet.
8. Nach Lücken suchen. Ein dünner Ring oder ein unbesetzter Rollenplatz wird bestritten, bevor man abschliesst. Das Fehlen eines Regulators in einem regulierten Feld ist eine zu prüfende Annahme.
9. Die Karte mit dem Auftraggeber und einer Auswahl der benannten Personen validieren. Uneinigkeit über eine Zuordnung ist eine Information: sie signalisiert fast immer eine Unschärfe im Umfang und wird als solche eskaliert.
10. Die Karte datieren und bei jeder wesentlichen Änderung des Umfangs überarbeiten. Die Stakeholder-Analyse ist im BABOK iterativ, und die Zwiebel ist ihr am schnellsten korrigierbares Hilfsmittel.

Was die Übung scheitern lässt

Macht mit Nähe verwechseln

Das ist der häufigste Zuordnungsfehler, und er kommt öfter vom Analysten als aus dem Raum: der Auftraggeber entscheidet alles, also stellt man ihn ins Zentrum. Der Test weist ihn ab, denn er stellt die Lösung nicht her, und er sitzt in Ring 3. Macht liest man auf der Stakeholder-Matrix.

Distanz als Wichtigkeit lesen

Das ist derselbe Fehler, vom äusseren Ring aus gesehen, und er kostet mehr. Ein Regulator aus Ring 4 kann eine Inbetriebnahme stoppen, die das ganze Team aus Ring 1 freigegeben hat. Der Ring verortet einen Stakeholder gegenüber der Lösung, und die Priorität des Engagements wird auf der Matrix entschieden.

Den äusseren Ring leer lassen

Das Team denkt zuerst an jene, die bauen, und an jene, die nutzen, und hört auf zu suchen, sobald diese beiden Ringe voll sind. Regulatoren, Datenschutzbehörden, Lieferanten und Integrationspartner werden dann spät entdeckt, nachdem die Schnittstellen bereits festgelegt sind. Der Durchgang nach Kategorien aus Schritt 7, laut geführt, ist das einzige Mittel, das wirkt, und er kostet zehn Minuten.

Das Wort «Benutzer» durchgehen lassen

Es deckt mindestens zwei Rollen ab, die in verschiedenen Ringen liegen: die Leistungssachbearbeiterin, die acht Stunden am Tag im Portal arbeitet (Ring 2), und der Versicherte, der dort zweimal im Jahr eine Rechnung einreicht (Ring 4). Ihre Bedürfnisse, ihre Toleranz für Komplexität und ihr Engagement-Plan haben nichts gemeinsam. Die Rolle statt der Kategorie zu benennen bringt den Unterschied zum Vorschein.

Die Ringhierarchie mit dem Organigramm verwechseln

Ein Geschäftsführer sitzt in Ring 3 und ein Junior-Entwickler in Ring 1: die Ringe messen eine Distanz zur Lösung, das Organigramm misst eine Autorität, und nichts zwingt beide zur Deckung.

HERMES, die Projektmanagementmethode des Bundes, ist ein Beispiel dafür: Sein Rollenmodell ordnet jede Projektrolle zwei Achsen zugleich zu. Die erste ist die Partnergruppe (§6.1.3.2): der Anwender, der seine Anforderungen definiert, testet und abnimmt; der Ersteller, der die Lösung entwickelt und integriert; der Betreiber, der die Betriebsinfrastruktur bereitstellt und das System betreibt. Die zweite ist die Hierarchieebene (§6.1.3.3): Steuerung, Führung oder Ausführung. Der Auftraggeber gehört zur Steuerung und sitzt in Ring 3, denn er baut nichts; eine Ausführungsrolle fällt in Ring 1 oder in Ring 2, je nachdem, ob sie die Lösung baut oder sie später nutzen wird. Das Rollenraster in die Ringe zu übertragen ergibt eine falsche Karte.

Die Karte nur einmal zeichnen

Ein Integrationspartner kommt in den Umfang, ein Lieferant fällt heraus, ein neuer Regulator lädt sich ein und die Karte wird falsch, ohne dass irgendetwas es meldet. Sie wird datiert und bei jeder Umfangsprüfung überarbeitet. Eine achtzehn Monate alte Stakeholder-Karte dokumentiert das Projekt von vor achtzehn Monaten.

KI-Überlegungen

Der ertragreichste Einsatz eines Sprachmodells betrifft die äusseren Ringe, dort, wo das Gedächtnis des Teams versagt. Gespeist mit der Rahmennotiz, den geltenden Verträgen, dem Organigramm und dem Verzeichnis der anwendbaren Regulierungen, liefert es eine Kandidatenliste für die Ringe 3 und 4, die den Durchgang aus Schritt 7 speist. Derselbe Mechanismus funktioniert als Kontrollfrage: «welche Kategorien externer Stakeholder sind bei einem Rückerstattungsportal einer Schweizer Krankenkasse üblicherweise betroffen?» Die Antwort ist eine Liste, die man dem realen Projekt gegenüberstellt, und ihr Wert liegt darin, dass sie Kategorien benennt, die niemand im Raum vorgeschlagen hätte.

Einen zweiten Dienst leistet es beim Wort «Benutzer». Ein Modell, das die verschiedenen Rollen hinter einer generischen Bezeichnung aufzählen soll (Benutzer, Kunde, Partner, Dienstleister), liefert in Sekunden die Aufschlüsselung, für die ein Workshop eine halbe Stunde braucht, und das Zuordnen dieser getrennten Rollen in ihre Ringe erledigt den Rest der Arbeit.

Die Zuordnung selbst entzieht sich der Maschine. Ob sich die tägliche Arbeit einer Abteilung ändert (Ring 2) oder ob sie lediglich mit der betroffenen Abteilung interagiert (Ring 3), hängt von organisationsinternen Tatsachen ab, die ein Modell nicht hat und die es plausibel erfinden wird, wenn man es reale Personen zuordnen lässt. Das Risiko ist auf Ring 4 am grössten, wo das Modell die Lücken mit generischem Branchenwissen füllt: es schlägt einen plausiblen Regulator vor, den es nicht gibt, oder es vergisst die kantonale Behörde, die es sehr wohl gibt. Jeder Vorschlag zu einem Regulator wird an der Quelle geprüft. Und einen Stakeholder als Gegner zu bezeichnen ist ein besonders schützenswertes Personendatum: diese Notiz bleibt in einem intern freigegebenen Werkzeug, oder sie wird vor dem Verlassen anonymisiert, und sie wird keinem öffentlichen Modell in namentlicher Form vorgelegt.

Beispiele

Eine Schweizer Krankenkasse, tätig in der obligatorischen Krankenpflegeversicherung nach KVG, nimmt ein Online-Rückerstattungsportal in Betrieb. Das Zentrum wurde vor der Sitzung mit der Geschäftsleitung schriftlich festgelegt, und es trägt drei Dinge: das Self-Service-Portal, in dem die Versicherten ihre Anträge einreichen, den automatisierten Eingang der Rechnungen der Leistungserbringer (Physiotherapeuten, Arztpraxen, Spitäler) und das digitale Leistungsdossier, das die internen Rollen zur Bearbeitung des Falls öffnen. Das Papier verschwindet aus dem Ablauf. Das Diagramm ist das Ergebnis der Rahmensitzung, vor der Planung der Elizitation.

Das Bundesamt für Gesundheit (BAG), Aufsicht über die obligatorische Krankenpflegeversicherung, und die Versicherten, die die Kunden sind, teilen sich Ring 4. Sie stehen in derselben Distanz zur Lösung und wiegen nicht gleich schwer: das eine kann die Inbetriebnahme stoppen, die anderen sind jene, für die sie gemacht ist.

Visualisierungen

Die Verschachtelung sagt die Distanz: ein Stakeholder in Ring 3 erscheint weiter vom Zentrum entfernt als jene in Ring 2, ohne dass eine Legende es erklären müsste.

Der Ring legt den Standardmodus des Kontakts fest. Seine Frequenz und seine Intensität werden anschliessend auf der Stakeholder-Matrix eingestellt, die Macht und Interesse jedes Einzelnen wiegt.

Aufwand

Der Aufwand liegt in der vorgängigen Einigung über die Grenze der Lösung. Das Zeichnen selbst geht schnell, und es ist der Unterhalt der Karte, der auf Dauer kostet.

Werkzeuge

Das ursprüngliche Format bleibt für die Sitzung selbst das wirksamste: vier mit dem Marker auf ein Whiteboard oder ein Flipchart gezeichnete Kreise und Haftnotizen mit je einer Rolle. Der physische Träger macht das Verschieben eines Namens von einem Ring in den anderen trivial, was zählt, denn das Verschieben ist der zentrale Akt der Übung, und er stellt alle gemeinsam um dasselbe Objekt. Die Eintrittskosten sind null.

Aus der Distanz oder hybrid bewahren kollaborative Whiteboards (Miro, Mural, FigJam) die Metapher der Haftnotiz und ergänzen sie um Persistenz, Versionierung und Abstimmung. Sie sind die richtige Wahl, sobald die Karte die Sitzung überleben soll, was der Regelfall ist. Allgemeine Diagrammwerkzeuge (diagrams.net, Lucidchart, Visio, eine Folie mit vier verschachtelten Kreisen) eignen sich für die Reinschrift des Ergebnisses, moderieren den Workshop selbst aber schlecht, denn eine Form zu verschieben verlangt dort eine Absicht, während das Verschieben einer Haftnotiz keine verlangt.

Auf der spezialisierten Seite liefert die Vorlage zur Stakeholder-Analyse der Volere-Methode (Atlantic Systems Guild) ein gebrauchsfertiges Zwiebeldiagramm mit benannten Rollenplätzen zum Ausfüllen. Ihr Nutzen ist das Gegenteil eines Whiteboards: sie erzwingt eine Checkliste von Rollen, macht also den leeren Platz sichtbar, und ihr Formalismus zahlt sich aus, wenn die Karte in einem Programm mehrere Monate leben muss. Manche Werkzeuge für Anforderungsmanagement und Unternehmensarchitektur bieten eine Stakeholder-Kartenansicht, die denselben Vorteil hat und die Karte mit dem übrigen Repository verbindet, was ihre Kosten nur dann rechtfertigt, wenn dieses Repository bereits existiert.

Quellen

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.43 Stakeholder List, Map, or Personas (Abbildung 10.43.2, Stakeholder Onion Diagram).
• Ian F. Alexander, A Better Fit: Characterising the Stakeholders, Workshop REBPS 2004, CAiSE'04, Riga: Primärquelle des Zwiebelmodells, des Begriffs des negativen Stakeholders und der Validierung über leere Rollenplätze.
• Ian F. Alexander, A Taxonomy of Stakeholders: Human Roles in System Development, International Journal of Technology and Human Interaction, Bd. 1, Nr. 1 (2005), S. 23-59: Taxonomie der Ringe und der Rollen sowie dokumentierte Fallstricke (das überladene Wort «Benutzer», Distanz als Wichtigkeit gelesen, Verwechslung mit dem Organigramm).
• Suzanne Robertson und James Robertson, Requirements: A Socio-Technical Discipline, Atlantic Systems Guild (Volere): die Vorlage zur Stakeholder-Analyse und ihr Gebrauch für die Identifikation.
• Schweizerische Eidgenossenschaft, Bundeskanzlei, HERMES 2022, Referenzhandbuch Projektmanagement, Kap. 6 Rollen, §6.1.3.2 Partnergruppen und §6.1.3.3 Hierarchieebenen: das Rollenmodell der Methode des Bundes, das jede Projektrolle einer oder mehreren Partnergruppen (Anwender, Ersteller, Betreiber) und einer Hierarchieebene (Steuerung, Führung, Ausführung) zuordnet, zwei Achsen, von denen keine die Distanz zur Lösung misst.