Ein neues System kann technisch funktionieren und trotzdem im Arbeitsalltag scheitern. Häufig beginnt das Problem lange vor dem Rollout: Die Menschen, die später damit arbeiten oder Verantwortung übernehmen sollen, werden erst einbezogen, nachdem die wesentlichen Entscheidungen bereits gefallen sind.
Beteiligung im Vorhaben einordnenKostenfrei · 30 Minuten · remote
Mitarbeiterbeteiligung bei Digitalisierung bedeutet, dass die Rollen, deren Arbeit, Verantwortung oder Risiko sich durch ein Vorhaben verändert, bereits vor der Toolauswahl und den wesentlichen Gestaltungsentscheidungen eingebunden werden, nicht erst bei Pilot oder Schulung. Das schließt Vollkonsens nicht ein: Die Projektleitung behält ihren Entscheidungsauftrag, Beteiligung verbessert die Grundlage, auf der entschieden wird.
Beteiligung endet nicht mit dem Rollout. Ohne einen sichtbaren Prozess für Rückmeldungen und Anpassungen nach dem Start bleibt Verantwortung formal zugewiesen, aber nicht wirklich übernommen.
Wirtschaftlich ist das kein Soft-Thema: Anforderungen, die erst nach Vertragsabschluss oder im laufenden Rollout auffallen, lassen sich in der Regel nur mit Mehraufwand nachrüsten, nicht mehr durch einfache Konfiguration vor dem Start.
Frühe Beteiligung zeigt ihre Wirkung nicht in der Anzahl der Workshops, sondern darin, ob Menschen ihre Rolle kennen und Verantwortung übernehmen können. Das Muster gilt unabhängig von der Unternehmensgröße: Es zeigt sich ebenso in einem 30-köpfigen Fachbereich wie im hier beschriebenen 1.500-Personen-Rollout. Die Beispiele sind anonymisiert.
Als IT-Projektmanager begleitete ich die Einführung. Nach dem Systemwechsel standen die Zuständigkeiten zwar auf dem Papier, trotzdem fühlte sich niemand wirklich verantwortlich.
„Ist nicht meins.“
Das System war eingeführt. Organisatorische Mitverantwortung war damit noch nicht entstanden.
Bei dieser Einführung wurden alle Beteiligten früh eingebunden. Die neuen Rollen waren bekannt und die Menschen konnten sich gezielt auf ihre Aufgaben vorbereiten.
Rollen waren vor dem Start klar.
Das Vorhaben funktionierte dadurch im Arbeitsalltag deutlich besser.
Anforderer und Entwickler arbeiteten direkt an einem Tisch. Die Anforderer sammelten regelmäßig Wünsche und Anforderungen in ihrem Nutzerkreis und stimmten sie dort ab.
Der tatsächliche Bedarf blieb im Projekt sichtbar.
Durch die kurze Rückkopplung zwischen Nutzerkreis, Anforderern und Entwicklung funktionierte die Zusammenarbeit sehr gut.
Verantwortung lässt sich formal zuweisen. Echte Mitverantwortung entsteht jedoch schwer, wenn die später Verantwortlichen an den prägenden Entscheidungen nicht beteiligt waren.
Das deckt sich mit branchenweiten Daten: Die Chaos-Studie der Standish Group nennt die Einbindung der Endnutzerinnen und Endnutzer als einen von drei Haupterfolgsfaktoren in IT-Projekten. Eine aktuelle Bitkom-Publikation beschreibt zusätzlich Kulturmuster wie „Widerstand lohnt sich“, die selbst technisch gute Lösungen im Betrieb scheitern lassen.
Frühe Beteiligung wird manchmal mit endlosen Abstimmungen oder Entscheidungen im Vollkonsens verwechselt. Beides ist nicht nötig. Je nach Phase kann Beteiligung unterschiedlich aussehen:
Diese fünf Phasen folgen dem Grundprinzip nutzerzentrierter Gestaltung nach ISO 9241-210: Anforderungen, Gestaltung und Bewertung wiederholt mit den Nutzenden abstimmen, statt einmalig am Ende zu testen.
Fünf Phasen, in denen betroffene Rollen mitwirken, bevor Annahmen, Abläufe und Schnittstellen festgeschrieben werden.
Von der Ausgangslage bis zur verankerten Verantwortung
Die späteren Nutzerinnen und Nutzer kennen Varianten, Ausnahmen und Engpässe, die in Prozessbeschreibungen häufig fehlen. Dieses Wissen gehört in die Analyse, bevor eine Lösung festgelegt wird.
Leitfrage: Welche Arbeit findet tatsächlich statt und nicht nur laut Prozesshandbuch?
Noch vor der Toolauswahl muss geklärt werden, welches Ergebnis für Fachbereich, Betrieb, IT und Führung tragfähig ist.
Leitfrage: Woran erkennen die betroffenen Rollen, dass der neue Ablauf ihre Arbeit wirklich verbessert?
Nicht jede Person muss jede technische Entscheidung treffen. Betroffene Rollen sollten aber die prägenden Annahmen, Abläufe und Schnittstellen prüfen können, bevor sie festgeschrieben werden.
Leitfrage: Welche Entscheidung lässt sich später nur teuer oder mit hohem Aufwand korrigieren?
Ein Pilot ist mehr als ein technischer Funktionstest. Er muss zeigen, ob Zuständigkeiten, Ausnahmen, Datenwege und tägliche Arbeit zusammenpassen.
Leitfrage: Was passiert im echten Betrieb, wenn Zeitdruck, Vertretung oder ein Sonderfall hinzukommen?
Mit dem Start endet die Beteiligung nicht. Es braucht einen sichtbaren Prozess für Rückmeldungen, Änderungen und Entscheidungen.
Leitfrage: Wer beobachtet die Wirkung und darf den Ablauf nach dem Start verändern?
Diese Phasenlogik lässt sich auch mit etablierter Change-Management-Methodik verbinden, etwa mit Kotters 8-Stufen-Modell, das eine geführte Koalition und sichtbare kurzfristige Erfolge als eigene Etappen vorsieht.
Die konkrete Besetzung hängt vom Vorhaben ab. Nicht jede Rolle muss dauerhaft in jedem Termin sitzen. Wichtig ist eine nachvollziehbare Architektur: Wer wird wann informiert, angehört, beteiligt oder entscheidet?
Kennen den tatsächlichen Arbeitsablauf, einschließlich Ausnahmen und Umwegen.
Tragen Ergebnis, Qualität und Schnittstellen des betroffenen Prozesses.
Bewerten Integration, Betrieb und Risiken der geplanten Lösung.
Klären Ziel, Priorität, Ressourcen und Entscheidungsräume.
Bringt, sofern vorhanden und betroffen, Mitbestimmungs- und Beschäftigtenperspektiven ein.
Diese Pflichten ersetzen keine eigene Beteiligungsarchitektur, setzen aber einen rechtlichen Mindestrahmen, sofern eine betriebliche Interessenvertretung besteht.
Wenn der Fachbereich erstmals nach Vertragsabschluss beteiligt wird, können grundlegende Anforderungen kaum noch ohne Mehrkosten berücksichtigt werden.
Eine Einweisung kurz vor dem Start vermittelt Bedienung, aber keine Mitgestaltung und kein gemeinsames Verständnis des Zielbildes.
Wenn Rückmeldungen gesammelt, aber Entscheidungen weder angepasst noch begründet werden, sinkt die Bereitschaft, sich weiter einzubringen.
Ohne Prozess- oder Produktverantwortung bleiben Fehler, Verbesserungen und Regeländerungen zwischen Fachbereich und IT liegen.
Eigene Listen, Nebenprozesse oder manuelle Korrekturen zeigen oft, dass der offizielle Ablauf wichtige Anforderungen nicht erfüllt.
Klassische Software verändert sich meist durch geplante Releases. Bei KI-Systemen können zusätzlich Modelle, Datenquellen, Prompts, Regeln und Nutzungskontexte die Ergebnisse verändern.
Deshalb braucht ein KI-Vorhaben nicht nur Beteiligung vor dem Start, sondern wiederkehrende Lern- und Entscheidungszyklen im Betrieb.
Dazu passende Forschung: Das Fraunhofer IAO/IAT hat 2024 ein Instrument entwickelt, mit dem Betriebsräte KI-Auswirkungen auf Beschäftigte bewerten. AlgorithmWatch fordert prozessbegleitende Mitsprache bereits während Entwicklung und Einführung. Fallstudien der OECD, unter anderem aus Deutschland und Österreich, zeigen, dass direkte Einbindung Ängste senkt und Akzeptanz erhöht. Die ILO bezeichnet „worker voice“ 2025 als notwendige Voraussetzung für ein funktionierendes KI-Design.
Beteiligung allein garantiert noch keine Nutzung. Sie muss an reale Entscheidungen, konkrete Arbeitsabläufe und sichtbare Folgen gekoppelt sein.
Eine Untersuchung zur Einführung von Kollaborationssystemen fand keinen einfachen direkten Zusammenhang zwischen Partizipation und Nutzungsabsicht. Relevant waren unter anderem konkrete Arbeitsgestaltung und technische Vorerfahrungen. Eine Dissertation zur Einführung der elektronischen Akte im öffentlichen Sektor fand dagegen einen Zusammenhang zwischen Beteiligung und IT-Akzeptanz.
Die praktische Konsequenz: nicht einfach mehr Termine, sondern frühe Gestaltungsspielräume, klare Führung, passende Qualifizierung und Rückmeldung über getroffene Entscheidungen.
Quellen: Zeitschrift für Arbeitswissenschaft und Universität Bremen.
Steht bei Ihnen ein Systemwechsel, eine Automatisierung oder ein KI-Vorhaben an? Wir ordnen die wichtigsten Rollen und Entscheidungspunkte ein.
Remote und unverbindlich. Keine vollständige Stakeholder- oder Change-Analyse.
Über den Autor: Daniel BlaschkeSenior Consultant für digitale Transformation und angewandte KI. Mehr als 20 Jahre IT- und Projekterfahrung in Business Analyse, Product Ownership, IT-Projektmanagement, Prozessgestaltung und Umsetzungsbegleitung.
Sobald Problem, Zielbild und wesentliche Anforderungen geklärt werden. Erfolgt die erste Beteiligung erst bei Pilot oder Schulung, sind wichtige Entscheidungen häufig bereits schwer veränderbar.
Nein. Der Entscheidungsauftrag bleibt klar zugeordnet. Betroffene Rollen wirken dort mit, wo ihr Arbeitswissen, ihre Verantwortung oder die Folgen für ihre Arbeit relevant sind.
Sie sind hilfreich, bilden aber nicht automatisch alle relevanten Perspektiven ab. Auswahl, Mandat und Rückkopplung in die betroffenen Teams müssen bewusst gestaltet werden.
Durch klare Rollen, konkrete Fragestellungen, begrenzte Entscheidungsräume und zeitlich passende Formate. Beteiligung wird ineffizient, wenn unklar bleibt, worüber gesprochen und was anschließend entschieden wird.
Modelle, Datenquellen und Regeln können sich im Betrieb verändern. Deshalb müssen Nutzung, Ergebnisse, Risiken und Verantwortlichkeiten wiederholt überprüft werden.
Wir betrachten betroffene Rollen, kritische Entscheidungspunkte und die vorgesehene Verantwortung nach dem Start. Danach wissen Sie, ob eine vertiefte Analyse sinnvoll ist.
Diese Seite wird bei neuen Praxiserkenntnissen überprüft und aktualisiert. Letzte inhaltliche Prüfung: . Sie ersetzt keine vollständige Stakeholder- oder Change-Analyse.
Eine erste Einschätzung zu Rollen, Beteiligungszeitpunkten und Verantwortung erhalten Sie im kostenfreien 30-Minuten-Gespräch.
Vorhaben einordnen