Vor einigen Jahren durften wir ein Intranet realisieren. Es ging dabei nicht nur um ein neues System, sondern um einen kulturellen Wandel im Unternehmen. 

Das Projektteam war entsprechend aufgestellt und machte vieles richtig: Stakeholder wurden früh eingebunden, es gab Rückhalt aus wichtigen Bereichen, interne Promotoren wurden gewonnen und haben das Intranet schon vor dem offiziellen Go-Live mit Inhalten gefüllt. Man hatte sich intensiv überlegt, wie Akzeptanz entsteht und wie man sie aktiv fördern kann. 

Zum Start stellte das Unternehmen das Intranet auf einer Veranstaltung vor. Der Vorstand stand auf der Bühne. Das System lief auf der großen Leinwand. Alles war vorbereitet. Während seiner Präsentation klickte sich der Vorstand durch die ersten Inhalte. Dann blieb er bei einem Beitrag aus der HR-Abteilung stehen. 

Sein Kommentar, halb im Scherz: „Naja, der hat halt auch Zeit für sowas.“ 

Ein einziger Satz sendete eine klare Botschaft: Wer dieses System nutzt, hat offenbar nichts Wichtigeres zu tun. Monate der Vorbereitung fielen diesem Satz zum Opfer. Das war sicher ein Worst-Case-Szenario, das sich danach nur schwer noch einfangen ließ.

Jedes große Software-Projekt ist auch ein Change-Prozess. Dazu gehört immer auch der Blick auf Risiken. Seither fragen wir uns in solchen Prozessen nicht nur, wer ein Software-Projekt promoten könnte, sondern auch, wer es am effektivsten beschädigen kann – und auf welche Weise. 

Abstrahiert man den Fall, wird klar: In der Roll-out-Phase entscheidet sich die Akzeptanz einer Lösung weniger an den Funktionen als an Kommunikation und Verhalten, vor allem durch Führung. Aus unserer Erfahrung gibt es in dieser Phase einige typische Risikofaktoren, die oft unterschätzt werden: 

• Inkonsistente Signale aus der Führung 
  Was Führungskräfte sagen, tun oder beiläufig kommentieren, prägt die Wahrnehmung stärker als jede geplante Kommunikation. Wenn zum Beispiel Schlüsselpersonen das System nicht sichtbar nutzen, entsteht ein impliziter Standard: Man kommt auch ohne aus. 
• Unklare Einordnung der Lösung 
  Ist das ein „nice to have“ oder Teil der Arbeitsrealität? Diese Frage wird selten explizit beantwortet, aber ständig implizit. Wenn nicht klar ist, wann und warum man das System konkret nutzt, bleibt es optional und damit verzichtbar. 
• Unklare Erwartungen an Nutzung und Verhalten 
  Bleibt die zentrale Frage unbeantwortet, was durch ein Software-Projekt eigentlich besser werden soll, fehlt meist jede Motivation, daran teilzuhaben. 
• Überbetonung des Go-Live-Moments 
  Der Start wird inszeniert, aber die Wochen danach bleiben ungesteuert. Dabei entsteht Akzeptanz genau dort, wo die Software im Alltag spürbar wird. Bei großen Lösungen sollte man die Nutzung 12–24 Monate beobachten und aktiv Feedback einholen. Und es auch berücksichtigen! 

Die eigentliche Frage ist deshalb nicht, wie gut eine Lösung konzipiert oder vorbereitet ist. Entscheidend ist, welche Signale im entscheidenden Moment gesendet werden.

Technisch kann vieles gut gelöst sein. Am Ende zählt, wie darüber gesprochen wird und von wem.