Software einführen – aber systemisch gedacht
„Warum sind die Mitarbeitenden zu doof für die neue Software?“
Diese Frage taucht in Projekten häufiger auf – und führt “natürlich” in die falsche Richtung.
In der aktuellen Folge unseres Podcasts „Antiintuitiv“ sprechen Holger Schlichting, Svenja Buckow, systemische Organisationsentwicklerin und agile Coach bei PRAXISFELD und Tim Bohlen (MINDACT Consulting & Content GmbH) darüber, warum Software-Einführungen selten am Können scheitern, sondern an Erwartungen, Rollen, Routinen und Rahmenbedingungen.
Svenja bringt dazu ein Beispiel aus einer großen Dokumentenmanagement-Einführung in einem kirchlichen Umfeld mit vielen Standorten und Nutzer:innen ein.
Und Tim zeigt, warum Appelle an „Haltung“ zwar plausibel klingen, aber organisatorisch wenig verändern.
Jede neue Anwendung erhöht zunächst die Komplexität: mehr Möglichkeiten, mehr Schnittstellen, mehr Transparenz – und damit auch mehr Entscheidungsdruck im Alltag.
Die Lösung lautet deshalb nicht „noch mehr Schulung“, sondern: das System rund um die Software gestalten.
Dauer: 1:32 Std.
1) Ziele klären, bevor Funktionen erklärt werden
- Wofür wird die Software eingeführt – und was soll danach anders sein?
- Welche Entscheidungen werden dadurch schneller, sicherer oder nachvollziehbarer?
- Und: Was wird für manche Rollen zunächst mühsamer, bevor es besser wird?
2) Projektorganisation ist keine Nebensache
Eine wirksame Einführung braucht klare Zuständigkeiten: für Prozesse, Administration, Schulung und technischen Support.
Gerade schneller Support und das rasche Beheben von „Kinderkrankheiten“ entscheiden oft darüber, ob Akzeptanz entsteht oder Frust überwiegt. Ebenfalls wichtig ist aber auch, ein solches Projekt als Veränderungsprojekt zu sehen, das viele Einflüsse auf die Sozialdimension hat. Sorgen und Zweifel werden so oder so kommuniziert; entweder indem man sie aufgreift und dadurch bearbeitbar macht oder indem sie in der Kaffeeküche stattfinden und zu Sand im Getriebe werden.
3) Anwendungsfälle statt Appelle
Wer nur am „Mindset“ drehen will, greift zu kurz.
Besser: konkrete Anwendungsfälle (Use Case) so gestalten, dass Mitarbeitende im Alltag einen spürbaren Nutzen erleben.
Wenn ein Anwendungsfall funktioniert, entsteht häufig eine Eigendynamik – der nächste ergibt sich „wie Perlen an einer Kette“.
4) Nutzen balancieren statt einseitig optimieren
Hilfreich ist das Nutzen-Dreieck: Organisation – Mitarbeitende – Kundschaft.
Wer nur Organisationsnutzen maximiert, produziert Umgehungslösungen; wer nur Individualwünsche erfüllt, verliert Standards und Vergleichbarkeit.
5) Standardisierung vs. Vielfalt bewusst entscheiden
Software macht Prozessunterschiede sichtbar – manchmal schmerzhaft.
Dann braucht es Führung: Welche Vielfalt ist sinnvoll, welche ist Ballast? Und wer entscheidet das mit welcher Legitimation?
6) Fokus auf die, die wollen
Eine wichtige Erfahrung von Svenja Buckow ist, dass das PRAXISFELD “Fence Sitter” Modell zuverlässig funktioniert. In Kurzform: Arbeite dich nicht an denen ab, die nichts von den Neuerungen halten, sondern arbeite mit denen, die wollen. Nach und nach gewinnt man dann (wenn der Rest auch stimmt), immer mehr User für die Anwendung.
Mini-Check: drei Fragen für deinen Projektstart
- Welche Routine soll am Ende wirklich anders laufen?
- Woran merken Anwender:innen einen konkreten Vorteil?
- Wie schnell werden Probleme gelöst, wenn es im Echtbetrieb hakt?
Fazit
Software-Einführung ist Organisationsentwicklung: Strukturen schaffen, in denen Nutzung naheliegt.