Artikel

Service Design

Stakeholder Map: Anleitung, Praxisbeispiel und Vorlage für Service Design

Die Stakeholder Map Schritt für Schritt: Stakeholder identifizieren, priorisieren und managen mit Praxisbeispiel und Vorlage.

Veroeffentlicht am: 28. März 2026 von SI Labs

Die Stakeholder Map (auch Stakeholder Mapping oder Stakeholder-Analyse) ist ein visuelles Werkzeug zur systematischen Identifikation, Klassifikation und Priorisierung aller Personen und Gruppen, die ein Projekt, einen Service oder eine Organisation beeinflussen oder von ihnen betroffen sind. Das theoretische Fundament legte R. Edward Freeman 1984 mit Strategic Management: A Stakeholder Approach, in dem er Stakeholder definierte als „jede Gruppe oder Einzelperson, die die Erreichung der Organisationsziele beeinflussen kann oder davon betroffen ist” [1].

Was die Stakeholder Map von einer einfachen Kontaktliste unterscheidet: Sie macht Machtdynamiken, Interessenlagen und Beziehungsgeflechte sichtbar. Eine Kontaktliste zeigt, wer involviert ist. Eine Stakeholder Map zeigt, wer blockieren kann, wer treiben kann, wer informiert werden muss und wer ignoriert werden kann. Diese Unterscheidung ist der Unterschied zwischen einem Projekt, das im Konsens versandet, und einem, das gezielt vorangetrieben wird.

Suchst du nach „Stakeholder Map”, findest du Dutzende Ergebnisse mit derselben 2x2-Matrix. Keines erklärt, warum Mendelows Power-Interest-Grid von 1991 für Service-Design-Projekte zu simpel ist. Keines zeigt, wie Backstage-Akteure — IT-Abteilungen, Compliance-Teams, externe Dienstleister — systematisch erfasst werden, obwohl sie die Umsetzbarkeit eines Service-Designs maßgeblich bestimmen. Und keines vergleicht systematisch die drei verbreiteten Stakeholder-Modelle: Power-Interest-Grid, Salience Model und Influence-Interest-Matrix.

Dieser Leitfaden schließt diese Lücken.

Von Freeman zum modernen Service Design: Woher die Methode kommt

R. Edward Freeman (geb. 1951), Professor an der Darden School of Business der University of Virginia, veröffentlichte 1984 Strategic Management: A Stakeholder Approach — das Grundlagenwerk der modernen Stakeholder-Theorie [1]. Freemans zentrale These: Unternehmen, die nur Shareholder-Interessen berücksichtigen, scheitern langfristig. Nachhaltiger Erfolg erfordert die systematische Berücksichtigung aller Stakeholder — Kunden, Mitarbeiter, Lieferanten, Gemeinden, Regulierer.

Was 1984 als strategisches Management-Konzept begann, wurde in den folgenden Jahrzehnten durch mehrere Weiterentwicklungen zum praktischen Werkzeug:

Aubrey Mendelow (1991) entwickelte das Power-Interest-Grid — die bis heute verbreitetste Stakeholder-Visualisierung [2]. Die 2x2-Matrix ordnet Stakeholder nach ihrer Macht (Einfluss auf das Projekt) und ihrem Interesse (Engagement für das Thema) in vier Quadranten ein: Manage Closely, Keep Satisfied, Keep Informed, Monitor.

Mitchell, Agle und Wood (1997) erweiterten das Modell zum Salience Model, das drei Attribute unterscheidet: Power (Macht), Legitimacy (Legitimität) und Urgency (Dringlichkeit) [3]. Stakeholder mit allen drei Attributen sind „Definitive Stakeholders” — sie erfordern sofortige Aufmerksamkeit. Stakeholder mit nur einem Attribut sind „Latent Stakeholders” — sie können ignoriert werden, solange sie kein zweites Attribut gewinnen. Das Salience Model erklärt, warum manche Stakeholder plötzlich relevant werden: Ein Datenschutzbeauftragter (hohe Legitimität, niedrige Macht) wird zum Definitive Stakeholder, sobald eine DSGVO-Verletzung droht (Urgency steigt).

Ackermann und Eden (2011) kombinierten Power und Interest mit dem Konzept der Stakeholder-Dynamik: Stakeholder bewegen sich zwischen Quadranten. Ein zufriedener Großkunde (Keep Satisfied) wird zum aktiven Projektgegner (Manage Closely), wenn sein Feedbackkanal wegfällt [4].

Drei Stakeholder-Modelle im Vergleich

Dimension	Power-Interest-Grid (Mendelow)	Salience Model (Mitchell et al.)	Influence-Interest-Matrix
Achsen/Attribute	Macht × Interesse (2 Dimensionen)	Macht × Legitimität × Dringlichkeit (3 Dimensionen)	Einfluss × Interesse (2 Dimensionen)
Komplexität	Niedrig — schnell erstellbar	Hoch — 7 Stakeholder-Typen	Mittel — ähnlich wie Power-Interest
Am besten für	Schnelle Stakeholder-Priorisierung in Workshops	Komplexe Projekte mit regulatorischen und politischen Stakeholdern	Projekte, bei denen Einfluss und formale Macht auseinanderfallen
Schwäche	Unterscheidet nicht zwischen formaler Macht und informellem Einfluss	Aufwändig — erfordert Bewertung dreier Attribute pro Stakeholder	Ähnlich wie Power-Interest, ohne den etablierten akademischen Rahmen
Herkunft	Mendelow (1991) [2]	Mitchell, Agle & Wood (1997) [3]	Bourne & Walker (2005) [5]

Empfehlung: Starte mit dem Power-Interest-Grid — es ist schnell, intuitiv und reicht für 80 % der Projekte. Wechsle zum Salience Model, wenn regulatorische oder politische Stakeholder eine Rolle spielen und du die Dynamik zwischen Macht, Legitimität und Dringlichkeit verstehen musst. Die Influence-Interest-Matrix ist eine Variante des Power-Interest-Grid, die nützlich ist, wenn informeller Einfluss (z. B. Meinungsführer, interne Champions) relevanter ist als formale Hierarchieposition.

Wann eignet sich die Stakeholder Map?

Nutze die Stakeholder Map, wenn:

Du ein Service-Design-Projekt startest und verstehen willst, wer die Ergebnisse beeinflusst, blockiert oder unterstützt
Du ein cross-funktionales Team zusammenstellst und sicherstellen willst, dass alle relevanten Perspektiven vertreten sind
Du Widerstand erwartest oder erlebst und verstehen willst, woher er kommt und wie du ihn adressieren kannst
Du Kommunikationsprioritäten setzen musst: Wen informierst du wie oft, in welcher Tiefe, über welchen Kanal?
Du die Backstage-Akteure eines Service identifizieren willst — IT, Compliance, externe Dienstleister — die in einer Customer Journey Map nicht auftauchen, aber die Umsetzung bestimmen

Nutze ein anderes Werkzeug, wenn:

Situation	Bessere Alternative	Warum
Du willst Verantwortlichkeiten für konkrete Aufgaben zuweisen	RACI-Matrix	RACI definiert Rollen (Responsible, Accountable, Consulted, Informed) pro Aufgabe; die Stakeholder Map definiert keine Aufgabenverteilung
Du willst die Hierarchie einer Organisation verstehen	Organigramm	Organigramme zeigen formale Berichtslinien; die Stakeholder Map zeigt Einfluss und Interesse, die oft quer zur Hierarchie verlaufen
Du willst verstehen, wie der Kunde einen Service erlebt	Customer Journey Map	Journey Maps sind chronologisch und kundenzentriert; die Stakeholder Map ist relational und projektbezogen
Du willst Konflikte zwischen Stakeholdern bearbeiten	Multi-Stakeholder Design	Multi-Stakeholder Design bietet Konfliktlösungsprotokolle; die Stakeholder Map identifiziert nur die Akteure
Du willst die Nutzertypen deines Service klassifizieren	Empathy Map / Persona	Die Stakeholder Map zeigt Machtdynamiken, nicht Nutzerbedürfnisse

Vergleich: Stakeholder Map vs. RACI vs. Organigramm

Drei Werkzeuge, die oft verwechselt werden — aber unterschiedliche Fragen beantworten:

Dimension	Stakeholder Map	RACI-Matrix	Organigramm
Kernfrage	Wer hat Einfluss und Interesse?	Wer ist für welche Aufgabe verantwortlich?	Wer berichtet an wen?
Fokus	Machtdynamiken und Beziehungen	Aufgabenverteilung und Entscheidungsrechte	Formale Hierarchie und Berichtslinien
Zeitpunkt	Projektstart und regelmäßige Updates	Nach Aufgabendefinition	Dauerhaft (organisationsweit)
Erfasst	Auch informelle Einflussnehmer, externe Akteure	Nur intern zugewiesene Rollen	Nur formale Positionen
Schwäche	Keine Aufgabenzuweisung	Kein Machtgefüge	Keine informellen Einflüsse

Ideale Kombination: Stakeholder Map (Projektstart: Wer ist relevant?) → RACI (Projektplanung: Wer macht was?) → Stakeholder Map Update (Projektmitte: Hat sich die Dynamik verändert?).

Schritt für Schritt: Stakeholder Map in 90 Minuten erstellen

Vorbereitung (vor dem Workshop)

Teilnehmer: 4–8 Personen aus verschiedenen Bereichen — Projektleitung, Fachexperten, jemand mit Kundenkontakt, jemand mit IT-/Operations-Hintergrund. Je mehr Perspektiven, desto vollständiger die Map.
Material: Großes Whiteboard oder Flipchart, Post-its in mindestens 3 Farben (eine pro Stakeholder-Kategorie: intern, extern, Endkunde), Stifte, vorbereitetes Power-Interest-Grid (2x2-Matrix auf dem Whiteboard)
Kontext definieren: Stakeholder Mapping ist kontextabhängig. „Stakeholder des Unternehmens” ist zu breit. „Stakeholder des Neugestaltung des Onboarding-Prozesses für Privatkunden” ist fokussiert genug.

Phase 1: Stakeholder identifizieren (25 Minuten)

Sammle alle Personen und Gruppen, die das Projekt beeinflussen oder davon betroffen sind. Arbeite drei Kategorien systematisch durch:

Kategorie 1: Frontstage-Akteure (direkt sichtbar für den Endkunden)

Endkunden (nach Segmenten differenziert)
Kundenberater / Außendienst
Callcenter-Mitarbeiter
Partner, die den Service co-erbringen

Kategorie 2: Backstage-Akteure (unsichtbar für den Endkunden, aber essenziell)

IT-Abteilung / Systemadministration
Compliance / Datenschutz / Regulierung
Controlling / Finanzabteilung
Produktmanagement
Externe Dienstleister (Logistik, Payment, Cloud-Anbieter)

Kategorie 3: Strategische Akteure (nicht operativ beteiligt, aber entscheidungsmächtig)

Geschäftsführung / Vorstand
Bereichsleitung / Sponsor
Betriebsrat
Externe Regulierer (BaFin, Datenschutzaufsicht)
Branchenverbände

Moderationstipp: Die häufigste Lücke ist Kategorie 2 — Backstage-Akteure. Teams denken zuerst an Kunden und Führungskräfte, vergessen aber die IT-Abteilung, die das neue System implementieren muss, oder den Datenschutzbeauftragten, der eine Freigabe erteilen muss. Frage gezielt: „Wer muss technisch liefern, damit dieser Service funktioniert? Wer muss regulatorisch freigeben?”

Schreibe jeden Stakeholder auf ein Post-it (Farbe nach Kategorie). Ziel: 15–30 Stakeholder. Unter 10 hast du wahrscheinlich Lücken. Über 40 wird die Priorisierung in Phase 2 schwierig.

Phase 2: Stakeholder klassifizieren (25 Minuten)

Ordne jeden Stakeholder im Power-Interest-Grid ein:

	Niedriges Interesse	Hohes Interesse
Hohe Macht	Keep Satisfied — Zufriedenstellen, aber nicht mit Details überfluten. Regelmäßige Statusberichte, strategische Updates. Beispiel: Vorstand, der das Budget freigibt, sich aber nicht für operative Details interessiert.	Manage Closely — Enge Zusammenarbeit, regelmäßiger Austausch, frühzeitig einbinden. Beispiel: Bereichsleitung, die das Projekt sponsort und die Ergebnisse vor dem Vorstand vertritt.
Niedrige Macht	Monitor — Beobachten, aber minimaler Aufwand. Nur reagieren, wenn sich Macht oder Interesse ändern. Beispiel: Branchenverband, der das Thema beobachtet, aber keine direkte Einflussnahme hat.	Keep Informed — Regelmäßig informieren, Feedback einholen, aber keine aktive Steuerung nötig. Beispiel: Callcenter-Team, das den neuen Prozess umsetzen wird und frühzeitig verstehen muss, was sich ändert.

Bewertungskriterien für Macht:

Kann diese Person/Gruppe das Projekt stoppen oder verzögern? (Vetorecht, Budgetentzug, regulatorische Blockade)
Kann sie Ressourcen zuweisen oder entziehen? (Personal, Budget, Systeme)
Hat sie formale Entscheidungsgewalt über relevante Aspekte?

Bewertungskriterien für Interesse:

Ist diese Person/Gruppe direkt betroffen von den Ergebnissen?
Hat sie ein berufliches oder persönliches Interesse am Thema?
Hat sie sich proaktiv geäußert (positiv oder negativ)?

Moderationstipp: Bewerte Macht und Interesse auf einer Skala von 1–5, nicht binär (hoch/niedrig). Das erleichtert die Positionierung im Grid und macht Grenzfälle sichtbar. Wenn sich das Team nicht einig ist, ist die Diskussion wertvoller als das Ergebnis — sie deckt unterschiedliche Wahrnehmungen der Machtdynamik auf.

Phase 3: Beziehungen und Dynamiken analysieren (20 Minuten)

Dieser Schritt fehlt in den meisten Stakeholder-Mapping-Anleitungen — dabei ist er entscheidend:

Allianzen identifizieren: Zeichne Verbindungslinien zwischen Stakeholdern, die zusammenarbeiten oder ähnliche Interessen haben. Grüne Linien für Allianzen, rote für Konflikte.
Gatekeepers identifizieren: Wer kontrolliert den Zugang zu anderen Stakeholdern? Der Assistent der Geschäftsführung hat niedrige formale Macht, aber hohe Gate-Keeping-Funktion.
Dynamiken antizipieren: Wo könnten sich Macht oder Interesse verschieben? Ein IT-Leiter (aktuell: Keep Satisfied) wird zum Manage-Closely-Stakeholder, sobald die Systemintegration beginnt.

Beispiel für eine kritische Dynamik: In einem Krankenhaus-Service-Redesign ist die Pflege (hohes Interesse, niedrige formale Macht) auf die Unterstützung der ärztlichen Direktion (hohe Macht, variables Interesse) angewiesen. Wenn die ärztliche Direktion das Interesse verliert, verliert die Pflege ihren Hebel — obwohl sie am meisten vom neuen Service profitieren würde. Die Stakeholder Map macht diese Abhängigkeit sichtbar.

Phase 4: Engagement-Strategie ableiten (20 Minuten)

Für jeden Quadranten definierst du eine konkrete Kommunikations- und Engagement-Strategie:

Quadrant	Strategie	Frequenz	Format	Beispiel
Manage Closely	Aktive Einbindung, Co-Design, regelmäßige Abstimmung	Wöchentlich	1:1-Meetings, Workshop-Beteiligung, Steering Committee	Projektsponsoring mit Bereichsleitung
Keep Satisfied	Strategische Updates, Risiko-Eskalation	Alle 2–4 Wochen	Executive Summary, Dashboard, Statusbericht	Quartalsreport an den Vorstand
Keep Informed	Regelmäßige Information, Feedback-Kanäle	Alle 2 Wochen	Newsletter, Townhall, Feedback-Sessions	Monatliches Update ans Callcenter-Team
Monitor	Passive Beobachtung, reaktive Kommunikation	Bei Bedarf	Nur bei Änderung von Macht oder Interesse	Branchenverband bei neuer Regulierung informieren

Ergebnis: Eine dokumentierte Stakeholder Map mit (1) allen identifizierten Stakeholdern, (2) ihrer Position im Power-Interest-Grid, (3) den wichtigsten Beziehungen und Dynamiken, (4) einer Engagement-Strategie pro Quadrant.

Beispiel: Stakeholder Map für ein Krankenhaus-Service-Redesign

Kontext: Ein großes DACH-Universitätsklinikum redesignt den Aufnahmeprozess für elektive (geplante) Operationen. Das Ziel: die Zeit von der Aufnahme bis zur OP von durchschnittlich 4,5 Stunden auf 2 Stunden reduzieren, bei gleichbleibender Patientensicherheit. Das Service-Design-Team erstellt eine Stakeholder Map, um alle relevanten Akteure zu identifizieren und die Engagement-Strategie zu planen.

Identifizierte Stakeholder (Auszug):

Stakeholder	Kategorie	Macht	Interesse	Quadrant
Patienten (elektiv)	Frontstage	Niedrig	Hoch	Keep Informed
Aufnahme-Team (Pflege)	Frontstage	Niedrig	Hoch	Keep Informed
Anästhesie-Ärzte	Frontstage	Hoch	Hoch	Manage Closely
Chirurgen	Frontstage	Hoch	Mittel	Keep Satisfied
OP-Planung	Backstage	Hoch	Hoch	Manage Closely
IT-Abteilung (KIS-System)	Backstage	Hoch	Niedrig	Keep Satisfied
Krankenkassen	Extern	Mittel	Niedrig	Monitor
Datenschutzbeauftragter	Backstage	Mittel	Niedrig → Hoch	Monitor → Manage Closely
Klinikdirektion	Strategisch	Hoch	Mittel	Keep Satisfied
Qualitätsmanagement	Backstage	Mittel	Hoch	Keep Informed
Patientenvertreter	Extern	Niedrig	Hoch	Keep Informed
Zuweisende Ärzte (extern)	Extern	Mittel	Mittel	Keep Informed

Kritische Erkenntnisse:

Die OP-Planung ist der zentrale Engpass-Stakeholder: Sie hat hohe Macht (bestimmt die OP-Reihenfolge) und hohes Interesse (leidet unter den aktuellen Ineffizienzen). Sie muss als Co-Design-Partner eingebunden werden — nicht nur als Informationsempfänger.
Die IT-Abteilung ist ein schlafender Riese: Aktuell niedriges Interesse (der Aufnahmeprozess ist „nicht ihr Problem”), aber hohe Macht (jede Prozessänderung erfordert KIS-Anpassungen). Wenn die IT nicht frühzeitig eingebunden wird, scheitert die Umsetzung an technischen Abhängigkeiten. Engagement-Strategie: Frühzeitig einen IT-Ansprechpartner in die Steering Group einladen und technische Machbarkeit parallel zum Service-Design prüfen.
Der Datenschutzbeauftragte verschiebt sich: Aktuell im Monitor-Quadranten (geringe Relevanz). Sobald das Team Patientendaten über neue digitale Kanäle übertragen will (z. B. mobile Aufnahme, Pre-Check-in-App), steigt die Urgency sprunghaft — der Datenschutzbeauftragte wird zum Manage-Closely-Stakeholder. Diese Verschiebung muss antizipiert werden, nicht reaktiv adressiert.
Patienten haben hohes Interesse, aber niedrige Macht: Sie erleben den Aufnahmeprozess als frustrierend (Wartezeiten, Doppelfragen, Orientierungslosigkeit), können aber den Prozess nicht direkt beeinflussen. Das Service-Design-Team muss ihre Stimme aktiv einbringen — durch Patient Advisory Boards oder Co-Design-Workshops. Ohne diese bewusste Einbindung werden Patientenbedürfnisse von den machtvolleren Stakeholdern (Chirurgen, OP-Planung) überstimmt.

Beziehungsdynamik: Die Anästhesie-Ärzte und die Chirurgen haben einen latenten Konflikt: Anästhesisten wollen ausreichend Vorlaufzeit für die Risikobewertung, Chirurgen wollen minimale Wartezeiten zwischen den OPs. Der neue Aufnahmeprozess muss diesen Konflikt adressieren — nicht ignorieren. Das Multi-Stakeholder Design bietet dafür Facilitation-Protokolle.

Hinweis: Dieses Beispiel ist illustrativ konstruiert, um die Methode im Servicekontext zu demonstrieren. Die Stakeholder-Positionen basieren auf typischen Dynamiken in Universitätsklinika.

Stakeholder Map im Service-Design-Prozess

Die Stakeholder Map ist kein einmaliges Workshop-Artefakt — sie ist ein lebendes Dokument, das den gesamten Service-Design-Prozess begleitet:

Phase 1: Discovery

Stakeholder Map erstellen (dieser Leitfaden)
Entscheiden, welche Stakeholder in User Research einbezogen werden
Empathy Maps für die wichtigsten Stakeholder-Gruppen erstellen

Phase 2: Definition

Stakeholder Map aktualisieren: Haben sich Macht und Interesse verändert?
Customer Journey Maps für Endkunden erstellen
Service Blueprint erstellen: Backstage-Akteure aus der Stakeholder Map werden zu Swimlanes im Blueprint

Phase 3: Design & Delivery

Engagement-Strategie umsetzen: Manage-Closely-Stakeholder in Co-Design-Workshops einbinden
Keep-Satisfied-Stakeholder über Fortschritt informieren
Stakeholder Map erneut aktualisieren: Die IT-Abteilung (vorher Keep Satisfied) ist jetzt Manage Closely, weil die Implementierung beginnt

Verbindung zum Service Blueprint: Jeder Backstage-Akteur im Service Blueprint sollte in der Stakeholder Map auftauchen. Wenn ein Blueprint eine „IT-System-Interaktion” zeigt, aber die IT-Abteilung nicht in der Stakeholder Map steht, hast du einen blinden Fleck.

Stakeholder Map: Vorlage zum Sofort-Einsatz

Diese Vorlage kannst du direkt für deinen nächsten Workshop verwenden:

Vorbereitung

Projektkontext klar definiert (nicht „Stakeholder des Unternehmens”, sondern „Stakeholder des Projekts X”)
4–8 Teilnehmer aus verschiedenen Bereichen eingeladen
Power-Interest-Grid auf Whiteboard oder Flipchart vorbereitet
Post-its in 3 Farben bereitgestellt (Frontstage / Backstage / Strategisch-Extern)

Phase 1: Identifikation (25 Min.)

Frontstage-Akteure gesammelt (Endkunden, Berater, Partner)
Backstage-Akteure gesammelt (IT, Compliance, Controlling, Dienstleister)
Strategische Akteure gesammelt (Geschäftsführung, Betriebsrat, Regulierer)
15–30 Stakeholder identifiziert

Phase 2: Klassifikation (25 Min.)

Jeden Stakeholder nach Macht (1–5) und Interesse (1–5) bewertet
Stakeholder im Power-Interest-Grid positioniert
Vier Quadranten mit Stakeholdern befüllt

Phase 3: Beziehungsanalyse (20 Min.)

Allianzen und Konflikte zwischen Stakeholdern identifiziert
Gatekeepers markiert
Dynamiken antizipiert (wer könnte den Quadranten wechseln?)

Phase 4: Engagement-Strategie (20 Min.)

Für jeden Quadranten Kommunikationsstrategie definiert
Frequenz und Format der Kommunikation festgelegt
Verantwortliche für Stakeholder-Management benannt
Nächsten Review-Termin für die Stakeholder Map festgelegt

5 häufige Fehler bei der Stakeholder Map

1. Nur externe Stakeholder berücksichtigen

Symptom: Die Stakeholder Map zeigt Kunden, Partner und Regulierer — aber keine internen Akteure. IT-Abteilung, Controlling, Betriebsrat fehlen.

Warum das schadet: Die meisten Service-Design-Projekte scheitern nicht an der Kundenakzeptanz, sondern an internen Blockaden: Die IT kann nicht liefern, Compliance gibt keine Freigabe, das Budget wird gekürzt. Wer interne Stakeholder ignoriert, entdeckt diese Blockaden zu spät.

Lösung: Arbeite die drei Kategorien (Frontstage, Backstage, Strategisch) systematisch durch. Stelle die Kontrollfrage: „Wer muss technisch liefern, regulatorisch freigeben oder finanziell zustimmen?“

2. Backstage-Akteure vergessen

Symptom: Die Stakeholder Map enthält Endkunden, Berater und Führungskräfte — aber nicht die IT-Abteilung, die das System anpassen muss, den Datenschutzbeauftragten, der die Freigabe erteilt, oder den externen Cloud-Anbieter, dessen API-Limitierung den gesamten Service einschränkt.

Warum das schadet: Backstage-Akteure bestimmen die Umsetzbarkeit eines Service-Designs. Ein perfektes Journey-Design scheitert, wenn die IT 18 Monate Entwicklungszeit braucht oder der Datenschutz die geplante Datenverarbeitung untersagt.

Lösung: Für jeden Frontstage-Touchpoint im Service Blueprint die Frage stellen: „Welche Backstage-Systeme und -Personen stehen dahinter?” Diese gehören in die Stakeholder Map.

3. Stakeholder Map als einmalige Übung behandeln

Symptom: Die Stakeholder Map wird am Projektstart erstellt und dann nie aktualisiert. In Projektmonat 6 hat sich die Machtdynamik verändert — die Map zeigt noch die Realität von Monat 1.

Warum das schadet: Macht und Interesse sind nicht statisch. Ein IT-Leiter, der am Anfang wenig Interesse zeigt (Keep Satisfied), wird hochrelevant, sobald die Implementierung beginnt (Manage Closely). Ein Projektgegner wird neutralisiert, wenn ein neuer Sponsor einsteigt. Wer mit einer veralteten Map arbeitet, kommuniziert mit den falschen Leuten in der falschen Intensität.

Lösung: Aktualisiere die Stakeholder Map bei jedem Phasenübergang im Projekt — mindestens alle 6–8 Wochen. Stelle die Frage: „Wer ist neu hinzugekommen? Wer hat den Quadranten gewechselt?“

4. Macht mit Hierarchie gleichsetzen

Symptom: Der CEO steht ganz oben im Grid, der Sachbearbeiter ganz unten — unabhängig vom konkreten Projektkontext.

Warum das schadet: Macht im Kontext eines Service-Design-Projekts ist nicht identisch mit der Position im Organigramm. Der Sachbearbeiter im Callcenter hat niedrige hierarchische Macht, aber hohe operative Macht: Wenn er den neuen Prozess nicht umsetzt oder sabotiert, scheitert das Projekt. Ein CEO hat hohe formale Macht, aber vielleicht null Interesse an einem operativen Prozessthema — und delegiert die Entscheidung vollständig.

Lösung: Bewerte Macht kontextspezifisch: „Kann diese Person dieses Projekt stoppen, verzögern oder beschleunigen?” — nicht „Wie hoch ist diese Person in der Hierarchie?“

5. Keine Engagement-Strategie ableiten

Symptom: Die Stakeholder Map wird erstellt und an die Wand gehängt. Es gibt keine definierten Kommunikationsmaßnahmen, keine Verantwortlichen, keine Frequenzen.

Warum das schadet: Eine Stakeholder Map ohne Engagement-Strategie ist eine Analyse ohne Konsequenz. Zu wissen, dass die IT-Abteilung „Keep Satisfied” ist, bringt nichts, wenn niemand die regelmäßigen Statusberichte schreibt.

Lösung: Für jeden Quadranten mindestens festlegen: (1) Wer kommuniziert? (2) Wie oft? (3) In welchem Format? (4) Was wird kommuniziert? Die Engagement-Strategie ist das Ergebnis der Stakeholder Map, nicht die Map selbst.

Wann die Stakeholder Map NICHT funktioniert

1. Für tiefe Empathie mit einzelnen Nutzern: Die Stakeholder Map zeigt Machtdynamiken und Beziehungen — nicht, was ein einzelner Nutzer denkt, fühlt und braucht. Für tiefe Nutzerempathie brauchst du eine Empathy Map oder Persona.

2. Für Aufgabenverteilung: Die Stakeholder Map sagt „Die IT-Abteilung hat hohe Macht und niedriges Interesse” — aber nicht, wer in der IT-Abteilung welche Aufgabe übernimmt. Dafür brauchst du eine RACI-Matrix.

3. In politisch hochsensiblen Umgebungen: Wenn das Mapping selbst Konflikte auslöst — z. B. wenn der Projektsponsor sieht, dass er im „Keep Satisfied”-Quadranten steht, nicht im „Manage Closely” — kann die Transparenz kontraproduktiv sein. In solchen Kontexten erstelle die detaillierte Map im Kernteam und kommuniziere nur die Engagement-Strategie nach außen.

4. Für die chronologische Kundenerlebnisanalyse: Die Stakeholder Map ist relational (wer beeinflusst wen), nicht chronologisch (was passiert wann). Für die chronologische Analyse brauchst du eine Customer Journey Map.

Häufig gestellte Fragen

Was ist eine Stakeholder Map?

Eine Stakeholder Map ist ein visuelles Werkzeug zur systematischen Identifikation, Klassifikation und Priorisierung aller Personen und Gruppen, die ein Projekt beeinflussen oder davon betroffen sind. Sie ordnet Stakeholder typischerweise nach Macht und Interesse in einer 2x2-Matrix (Power-Interest-Grid) an und leitet daraus eine Kommunikations- und Engagement-Strategie ab. Das theoretische Fundament stammt von R. Edward Freeman (1984).

Wie erstellt man eine Stakeholder Map?

In vier Phasen: (1) Stakeholder identifizieren — systematisch über Frontstage, Backstage und strategische Akteure. (2) Stakeholder klassifizieren — im Power-Interest-Grid nach Macht und Interesse positionieren. (3) Beziehungen und Dynamiken analysieren — Allianzen, Konflikte, Gatekeepers. (4) Engagement-Strategie ableiten — Kommunikationsmaßnahmen pro Quadrant. Rechne mit 90 Minuten für einen vollständigen Workshop.

Was ist der Unterschied zwischen Stakeholder Map und RACI?

Die Stakeholder Map beantwortet „Wer hat Einfluss und Interesse?” — sie zeigt Machtdynamiken und Beziehungen. Die RACI-Matrix beantwortet „Wer ist für welche Aufgabe verantwortlich?” — sie definiert Rollen (Responsible, Accountable, Consulted, Informed) pro Aufgabe. Beides ergänzt sich: Zuerst Stakeholder Map (wer ist relevant?), dann RACI (wer macht was?).

Was ist der Unterschied zwischen Stakeholder Map und Organigramm?

Das Organigramm zeigt formale Hierarchie und Berichtslinien — wer berichtet an wen. Die Stakeholder Map zeigt Einfluss und Interesse im Kontext eines spezifischen Projekts — quer zur Hierarchie. Ein Sachbearbeiter kann im Organigramm weit unten stehen, aber im Stakeholder Grid im Quadranten „Manage Closely”, weil er das Projekt operativ umsetzen muss.

Welches Stakeholder-Modell sollte ich verwenden?

Starte mit dem Power-Interest-Grid (Mendelow) — es ist schnell, intuitiv und reicht für 80 % der Projekte. Wechsle zum Salience Model (Mitchell et al.), wenn regulatorische oder politische Stakeholder eine Rolle spielen und du die Dynamik zwischen Macht, Legitimität und Dringlichkeit verstehen musst.

Wie oft sollte ich die Stakeholder Map aktualisieren?

Bei jedem Phasenübergang im Projekt — mindestens alle 6–8 Wochen. Macht und Interesse sind nicht statisch: Ein IT-Leiter, der anfangs wenig Interesse zeigt, wird hochrelevant, sobald die Implementierung beginnt. Prüfe bei jedem Update: Wer ist neu? Wer hat den Quadranten gewechselt? Welche Dynamiken haben sich verändert?

Forschungsmethodik

Dieser Artikel synthetisiert Erkenntnisse aus Freemans Stakeholder-Theorie (1984), Mendelows Power-Interest-Grid (1991), dem Salience Model von Mitchell, Agle und Wood (1997), Ackermann und Edens Arbeit zu Stakeholder-Dynamiken (2011), Bourne und Walkers Influence-Interest-Matrix (2005), sowie der Analyse von 10 deutschsprachigen Fachbeiträgen zur Stakeholder-Analyse.

Limitationen: Die akademische Literatur zur Stakeholder-Analyse stammt überwiegend aus dem strategischen Management und dem Projektmanagement. Empirische Studien zur Anwendung im Service Design sind begrenzt. Das Praxisbeispiel (Krankenhaus-Aufnahmeprozess) ist illustrativ konstruiert, nicht eine dokumentierte Fallstudie.

Offenlegung

SI Labs bietet Beratungsleistungen im Bereich Service Innovation an. In der Discovery-Phase des Integrierten Service Entstehungs Prozess (iSEP) setzen wir die Stakeholder Map ein, um das Akteursfeld eines Service-Design-Projekts zu strukturieren, bevor die eigentliche Designarbeit beginnt. Diese Praxiserfahrung informiert die Einordnung der Methode in diesem Artikel. Leser sollten sich der möglichen Perspektivenverzerrung bewusst sein.

Quellenverzeichnis

[1] Freeman, R. Edward. Strategic Management: A Stakeholder Approach. Boston: Pitman, 1984. [Book | Foundational Work | Citations: 70,000+ | Quality: 95/100]

[2] Mendelow, Aubrey. “Environmental Scanning — The Impact of the Stakeholder Concept.” Proceedings of the International Conference on Information Systems (ICIS), 1991. [Conference Paper | Power-Interest Grid Origin | Citations: 3,000+ | Quality: 80/100]

[3] Mitchell, Ronald K., Bradley R. Agle, und Donna J. Wood. “Toward a Theory of Stakeholder Identification and Salience: Defining the Principle of Who and What Really Counts.” Academy of Management Review 22, Nr. 4 (1997): 853-886. DOI: 10.5465/amr.1997.9711022105 [Journal Article | Salience Model | Citations: 15,000+ | Quality: 92/100]

[4] Ackermann, Fran, und Colin Eden. “Strategic Management of Stakeholders: Theory and Practice.” Long Range Planning 44, Nr. 3 (2011): 179-196. DOI: 10.1016/j.lrp.2010.08.001 [Journal Article | Stakeholder Dynamics | Citations: 1,500+ | Quality: 85/100]

[5] Bourne, Lynda, und Derek H.T. Walker. “Visualising and Mapping Stakeholder Influence.” Management Decision 43, Nr. 5 (2005): 649-660. DOI: 10.1108/00251740510597680 [Journal Article | Influence-Interest Matrix | Citations: 800+ | Quality: 78/100]

[6] Stickdorn, Marc, Markus Edgar Hormess, Adam Lawrence, und Jakob Schneider. This Is Service Design Doing. Sebastopol, CA: O’Reilly Media, 2018. [Book | Service Design Practice | Citations: 1,000+ | Quality: 85/100]

[7] Bryson, John M. “What to Do When Stakeholders Matter: Stakeholder Identification and Analysis Techniques.” Public Management Review 6, Nr. 1 (2004): 21-53. DOI: 10.1080/14719030410001675722 [Journal Article | Stakeholder Analysis Techniques | Citations: 3,000+ | Quality: 88/100]

← Alle Artikel