Stakeholder-Management bezeichnet die systematische Identifikation, Analyse und gezielte Einbindung aller Personen und Gruppen, die von einem Projekt oder einer Veränderung betroffen sind oder Einfluss darauf haben – Stakeholder. Ziel ist, deren Interessen, Erwartungen und Bedenken zu verstehen und so zu managen, dass das Projekt die notwendige Unterstützung bekommt und Widerstände frühzeitig erkannt und adressiert werden. Stakeholder-Management ist politische Intelligenz im besten Sinne: verstehen, wer was will, und entsprechend kommunizieren und handeln.
In Automatisierungsprojekten gibt es typischerweise ein breites Stakeholder-Spektrum: von enthusiastischen Sponsoren, die Budget freigeben, über skeptische Fachbereichsleiter, die um die Arbeitsplätze ihrer Teams besorgt sind, bis zu IT-Verantwortlichen, die Sicherheitsbedenken haben. Jeder dieser Stakeholder braucht eine maßgeschneiderte Einbindung – nicht eine Einheitskommunikation.
Stakeholder-Map: Einfluss × Betroffenheit
Hoher Einfluss, hohe Betroffenheit → Aktiv einbinden
Sponsor, CFO, betroffener Abteilungsleiter. Regelmäßige Abstimmung, Mitgestaltung ermöglichen, früh informieren. Kritischste Stakeholder-Gruppe.
Hoher Einfluss, niedrige Betroffenheit → Zufrieden halten
IT-Sicherheit, Datenschutzbeauftragter, Betriebsrat. Regelmäßige Information, bei relevanten Entscheidungen konsultieren, nie überraschen.
Niedriger Einfluss, hohe Betroffenheit → Informieren & einbeziehen
Endnutzer, operative Mitarbeiter. Transparent über Änderungen informieren, Feedback aktiv einholen, Change-Champions aus dieser Gruppe gewinnen.
Niedriger Einfluss, niedrige Betroffenheit → Beobachten
Periphere Abteilungen, externe Partner ohne direkten Systemzugang. Regelmäßige Newsletter-Updates, kein aktiver Einbindungsaufwand notwendig.
Praxisbeispiel
Ein Automationsdienstleister führt zu Projektbeginn eine Stakeholder-Analyse durch. Identifizierte Stakeholder: CFO (Sponsor, hoher Einfluss, niedrige direkte Betroffenheit) → wöchentlicher Status-Report, monatliches SteerCo. Buchhaltungsleiter (hoher Einfluss, hohe Betroffenheit, skeptisch) → aktiv in die Anforderungsphase eingebunden, Designentscheidungen erklärt, 2× wöchentlich Jour Fixe. Buchhaltungs-Team (niedriger Einfluss, hohe Betroffenheit, verängstigt) → Reskilling-Plan kommuniziert in Woche 1, 3 Personen als UAT-Tester aktiv eingebunden. IT-Leiter (hoher Einfluss, mittlere Betroffenheit, sicherheitsbewusst) → Sicherheitsarchitektur frühzeitig vorgestellt und abgenommen. Betriebsrat (hoher Einfluss, niedrige direkte Betroffenheit) → frühzeitig informiert, Reskilling-Zusage gegeben, keine Entlassungen. Ergebnis: Kein Widerstand in den Genehmigungsrunden. Budget-Freigabe in Woche 2 statt geplanter Woche 4.
