Das Onion Model – die Akteure eines Systems darstellen

Als Projektleiter, Produktverantwortlicher oder Systementwickler bzw. deren Berater bist Du mit folgenden Fragen konfrontiert:

• Welche Stakeholder besitzt das neu bzw. weiter zu entwickelnde System?
• Auf welche Weise stehen diese Akteure mit dem System in Beziehung?
• Welche Visualisierung unterstützt uns beim Finden und Klassifizieren von Stakeholdern?

Unterstützung findest Du im Onion Model und dem Verfahren des visuellen Stakeholderanalyse.

Ergebnis: Stakeholder eines Systems identifiziert und in drei Kategorien unterteilt

Teilnehmer: mind. 1

Dauer: 20 – 45 Minuten (je Zahl der Stakeholder und Größe des Systems)

Utensilien: Whiteboard/Flipchart/Metaplan-Wand, Stifte & Klebekarten oder Notebook & Office Software

Zweck

Das Onion Model hilft Dir die Stakeholder eines soziotechnischen Systems systematisch und visuell zu identifizieren sowie in drei Kategorien einzuteilen.

• Den Kern des Modells bilden die Stakeholder des Systems.
• In Schicht 2 findest Du die Stakeholder der direkten Umgebung.
• Schließlich bildet Schicht 3 die Stakeholder der weiten Umgebung.

Anders als die Stakeholder-Matrix, die Du eher im Alleingang erstellst, eignet sich das Onion Model für die Arbeit im Team. Verwende das visuelle Konzept, sobald es um das gemeinsame Finden und Klassifizieren aller für ein System relevanten Akteure geht.

Synonyme für das Onion Model sind die deutschen Bezeichnungen Zwiebelmodell, Zwiebelschalenmodell oder Zwiebeldiagramm, teilweise auch mit einem trennenden Bindestrich nach ‚Zwiebel‘ geschrieben.

Aufbau

System – „Was ist der Gegenstand unserer Betrachtung?“

Mit dem Onion Model unterteilst Du die Stakeholder eines Systems analog einer Zwiebel in drei Schichten (= Sphären, Ebenen, Ringen): Stakeholder des Systems, der direkten Umgebung und der weiten Umgebung.

Unter dem Begriff ‚System‘ ist dabei nicht nur ein rein technisches System zu verstehen. Prinzipiell kann jede definierte Menge von Elementen, ihren Eigenschaften und Wechselwirkungen ein System ausmachen. Denke beispielsweise an einen Geschäftsprozess, ein Produkt, eine Produktionsmaschine, ein Bürogebäude, eine Dienstleistung oder eine Business Software.

Gleichsam muss das System nicht komplett neu sein. Auch wenn Du ein System änderst, weiterentwickelst oder ablöst existieren Stakeholder, die von den Anpassungen betroffen sind bzw. einen direkten und indirekten Einfluss auf dieses haben.

Die Stakeholder des Systems kannst Du auch direkte Stakeholder nennen. Wiederum sind die Stakeholder der direkten und weiten Umgebung die indirekten Stakeholder.

Innerer Ring – „Welche Stakeholder hat das System?“

Diese Stakeholder sind direkt vom neuen bzw. angepassten System betroffen. Das System bestimmt ihre Handlungen und ihren Wirkungsbereich. Anders ausgedrückt: die Stakeholder liegen im unmittelbaren System-Scope.

Bei einem IT-System sind das beispielsweise die Anwender, das Wartungspersonal und die Systemadministratoren. Bei einem Geschäftsprozess kommen der Prozessverantwortliche und die Prozessakteure in Frage.

Mittlerer Ring – „Welche Stakeholder hat die direkte Systemumgebung?“

Hier handelt es sich um alle Stakeholder, die indirekt vom neuen bzw. modifizierten System betroffen sind. Sie agieren im System-Kontext und haben nur gelegentlich bzw. mittelbar mit dem System zu tun.

Im Falle eines IT-Systems gehören zum Beispiel die Vorgesetzten der Nutzer, Projektleiter und Sponsor sowie Verantwortliche der benachbarten IT-Systems zu dieser Kategorie. Wird ein Geschäftsprozess neu eingeführt oder umgebaut, sind das die Verantwortlichen der vor- und nachgelagerten Geschäftsprozesse.

Äußerer Ring – „Welche Stakeholder hat die weite Systemumgebung?“

Stakeholder der dritten Schicht haben eine indirekte Beziehung zum neuen bzw. adaptierten System oder dem dazugehörigen Projekt. Sie kennen und nutzen das System nicht, dennoch besteht eine indirekte Verbindung.

Typische Stakeholder der weiten Umgebung eines IT-Systems bzw. Geschäftsprozesses sind der Gesetzgeber, Wettbewerber, Non-Governmental Organizations (NGO), Gewerkschaften, Betriebsräte etc.

Onion Model – „Was sind die Stakeholder eines Systems?“

Für jeden Stakeholder des Systems siehst Du eine Karte vor, die Du auf der entsprechenden Zwiebelschale anordnest. Karten erlauben Dir ein nachträgliches Verschieben, Clustern und Auseinanderdividieren der Akteure. Außerdem halten Karten dazu an, sich kurz zu fassen. Last but not least kannst Du Karten einfärben, beispielsweise um Prioritäten, Typen, Organisationseinheiten oder ähnliches zu kennzeichnen.

Versehe Dein Zwiebelschalenmodell mit Meta-Informationen wie Systemname, Autoren und Datum der letzten Änderung. So weiß ein Leser sofort, welcher Teil der Realität mit dem Modell abgebildet wird.

Anwendung

Bereits die Stakeholderanalyse zeigt Dir das Vorgehen beim Aufspüren von Stakeholdern samt dem Finden der zentralen Wünsche und Bedürfnisse. Nachfolgend daher die Einsatzszenarien des Onion Models ein.

Auf Basis eines definierten Scopes für das System und seine Umgebung kannst Du das Tool allein oder im Team für drei verschiedene Aufgaben heranziehen:

Einsatzszenario 1: Als Denkwerkzeug einsetzen

Betrachte das zu entwickelnde bzw. anzupassende System und überlege Dir für jede der drei Schichten des Onion Models schrittweise die Stakeholder. Starte mit Schicht 1, den direkten Stakeholdern. Alternativ kategorisiert Du die bereits aufgenommenen Stakeholder gemäß des Modells.

Einsatzszenario 2: Als Interviewleitfaden heranziehen

Nutze das Onion Model als Interviewrahmen, um mit Deinem Kollegen gemeinsam die Stakeholder zu identifizieren. Zwiebelschicht für Zwiebelschicht, beginnend im Zentrum, befragst Du die Wissensträger nach den wesentlichen Akteuren.

Einsatzszenario 3: Als Workshop Leitfaden verwenden

Identifiziere alle wesentlichen Stakeholder zusammen mit den Kollegen in einem strukturierten Workshop. Dazu malst Du die drei Schichten des Onion Models auf ein Flipchart. Mittels Brainstorming oder anderen Kreativitätstechniken sucht ihr anschließend nach den wichtigsten Interessensvertretern. Notiert diese auf Karten, heftet diese ans Flipchart und analysiert diese.

Die Beziehungen von Stakeholdern zu einem System ändern sich im Projektverlauf. Auch können neue Stakeholder hinzukommen bzw. bestehende an Relevanz verlieren. Halte das Onion Model daher bedarfsorientiert auf einem aktuellen Stand.

Beispiele

Onion Model für eine Software für das Änderungsmanagement

Untere Abbildung illustriert beispielhaft die drei Schichten eines unvollständigen Onion Models für ein IT-System aus dem Änderungsmanagement.

Vor- & Nachteile

Pro

• Das Onion Model ist ein simples und rasch anzuwendendes Konzept mit denen Stakeholder strukturiert aufgespürt und klassifiziert werden können.
• Kunden und Kollegen verstehen den Ansatz in wenigen Minuten. Fast immer sind diese gerne bereit im Rahmen eines Workshops die Zwiebelschichten des Modells mit konkreten Namen zu füllen.
• Anders als die gewöhnliche Stakeholderanalyse fokussiert das Konzept nicht auf ein Projekt, sondern auf das zu entwickelnde System. Dies ist sinnvoll, bleibt das System auch nach Projektende noch bestehen.
• Bilder bleiben besser in Köpfen von Menschen als nüchterne Tabellen. Großer Trumpf des Onion Models ist seine visuelle Komponente gepaart mit dem schnellen Überblick über alle wesentlichen Stakeholder eines Systems.

Contra

• Das Onion Model lässt offen, nach welcher Methode Du Stakeholder findest und wie Du anschließend mit diesen verfahren solltest.
• Bei zu kleiner Visualisierungsfläche (z.B. einzelne Folie) bzw. bei zu vielen Stakeholdern (z.B. Projektprogramme) wird das Modell schnell unübersichtlich. Andersherum ist das Onion Model auch dann nur nützlich, falls das System fünf oder mehr Stakeholder besitzt.
• Das Konzept erlaubt weder die Stakeholder mit Zielen zu versehen, noch zwischen den Stakeholder Verbindungen zu knüpfen. Besser geeignet dafür ist das Zieldiagramm, die Stakeholder Map oder das Soziogramm.

Praxistipps

Tipp 1 – Mehrere Stakeholder-Quellen nutzen

Identifiziere die Stakeholder auf Basis verschiedener Quellen. Nur ganz selten reicht die einmalige Befragung direkt zum Projektstart aus, um alle wichtigen Akteure aufzuspüren.

Führe mehrere Stakeholder-Identifikations-Interviews durch. Sobald in diesen Gesprächen ein Name mehrmals fällt, kannst Du davon ausgehen, einen neuen bedeutenden Stakeholder gefunden zu haben.

Achte auch auf Stakeholder im Hintergrund, also an die Akteure, auf die Du im Zusammenhang des Systems erst beim vertiefenden Nachdenken kommst.

Tipp 2 – Stakeholder kontinuierlich managen

Das Eine ist das initiale Finden von Stakeholdern zu Projektbeginn, das Andere das fortwährende Managen von Stakeholdern im Projektverlauf. Leite anhand der Projektrolle, dem Bezug zum System sowie den Persönlichkeitsmerkmalen eines Akteurs ab, wie Du mit diesem umgehen solltest.

• Hat der Stakeholder wichtige Informationen zum System?
• Kann er das Projekt unterstützen?
• Besitzt er eigenen Ziele, die dem Projektziel zuwider laufen?

Erarbeite auf Basis der Erkenntnisse eine individuelle Kommunikationsstrategie ab.

Tipp 3 – Nutzer als wichtigsten Stakeholder ansehen

Der wichtigste direkte Stakeholder eines Systems ist der Nutzer. Bei einem IT-System sind das die Anwender, bei einem Geschäftsprozess die Prozessausführenden.

Das System steht und fällt mit dem Nutzer. Selbst ein perfekt umgesetztes System scheitert, falls die Nutzer dieses nicht akzeptieren.

Tipp 4 – Onion Model bedarfsorientiert erweitern

Alle Stakeholder sind identifiziert und befinden sich auf einer der drei Zwiebelschalen? Dann gehe nun den nächsten Schritt.

• Halte im Onion Model den Umgang mit den Akteuren fest. Dazu färbst Du die Karten unterschiedlich ein. Beispielsweise steht der Farbcode blau für ‚informiert halten‘, grün für ‚zu konsultieren‘ und rot für ‚entscheiden lassen‘. Nutze zur Einteilung die Klassen der RACI Matrix oder ein anderes Kategorisierungsschema.
• Ebenfalls nützlich sind die wichtigsten Anforderungen der Stakeholder. Notiere dazu die Top-3-Bedarfe direkt auf der Karte mittels Spiegelstrichen und betrachte auf diese Weise das System aus verschiedenen Blickwinkeln.
• Schließlich kannst Du auch Beziehungen zwischen den Stakeholdern transparent machen. Zeichne dazu Linien mit unterschiedlicher Strichfarbe und/oder -stärke zwischen den Karten. So können Stakeholder mit Bezug auf das System beispielsweise in Konflikt stehen (rote Linie) oder sich unterstützen (blaue Linie).

Tipp 5 – Zwiebelschichten individuell anpassen

Das Onion Model existiert in verschiedenen Varianten, Don Smiths Onion Model of Culture oder das Research Onion Model sind da nur zwei Alternativkandidaten.

Passe die Zahl und Inhalte der Schichten des Zwiebelschalenmodells nach Deinen Aufgaben an. Nutze beispielsweise…

• Organisationsstrukturen wie Team – Abteilung – Tochterunternehmen – Gesamtunternehmen,
• geographische Zonen wie Berlin – Deutschland – International oder
• Projektkommunikationskreise wie Arbeitspaket – Teilprojekt – Gesamtprojekt

als Schichten.

Tipp 6 – Stakeholder beim Namen nennen

Häufig erlebe ich in der Projektarbeit, dass die Karten mit Abteilungsnamen, Organisationseinheiten oder Gremienbezeichnungen ausgefüllt werden. ‚Die IT-Abteilung‘, ‚der Steuerkreis‘ oder ‚das Legal-Department‘ werden dann als Stakeholder des Systems definiert. Prinzipiell ist das richtig.

Die offene Frage: „Wer steht als Repräsentant für eine Gruppe und kann sich zum System äußern?“. Notiere auf die Karten daher auch eine Kontaktperson. Dieser konkrete Akteur ist im Projekt mit einzubeziehen.

Tipp 7 – Modell für andere Sachverhalte nutzen

Der Kerngedanke des Onion Models – die visuelle Anordnung von Stakeholdern in mehreren Schichten um einen Sachverhalt – lässt sich auch auf andere Bereiche anwenden. Einige Anregungen:

• Im Kern steht ein ‚Projekt‚ welches die drei Schichten ‚Team‘, ‚Kunde‘ und ‚Weitere Stakeholder‘ umgeben.
• Das Zentrum bildet der ‚Kunde‚ um den sich die drei Schichten ‚Marketing‘, ‚Vertrieb‘ und ‚After Sales‘ anordnen.
• Der Mittelpunkt ist ein ‚Wertangebot‚ das von den Schichten ‚Nutzer‘, ‚Entscheider‘ und ‚Beeinflusser‘ umschlossen ist.

Spiele mit den identifizierten Stakeholdern einfach kreativ und teste, was bei den Empfängern des Modells gut ankommt.

Ursprung

Das Onion Model geht auf Ian F. Alexanders Publikation A Taxonomy of Stakeholders – Human Roles in System Development. International Journal of Technology and Human Interaction aus dem Jahre 2005 zurück.

Alexander wirkt heute als Unternehmensberater im Feld Requirements Engineering. Im Laufe seiner Karriere arbeitete er mehrere Bücher, Artikel und Trainingskurse zum Thema Erhebung, Dokumentation, Abstimmung und Management von Anforderungen aus.

Bonusmaterial

Christopher Schulz: Auf den Punkt – das Onion Model (5 min) – die wichtigsten Eigenschaften des Onion Models