„Nö! – das Tool nutzen wir nicht!“ – Eine Softwareeinführung ist auch ein Change, der für Erfolg gestaltet werden sollte!

by Fiona Klingels

Im NDR Newsticker wurde am 11.03.2021 darüber berichtet, dass die Gesundheitsämter in Schleswig-Holstein die Anwendung „Sormas“ bzw. eine einheitliche Software nicht nutzen (werden). https://www.ndr.de/nachrichten/schleswig-holstein/coronavirus/Corona-Warum-Gesundheitsaemter-in-SH-Sormas-kaum-nutzen,sormas108.html

Die darin beschriebenen Punkte kennen wir aus eigener Erfahrung und hören auch immer wieder von Mitarbeitenden und Führungskräften aus Unternehmen, egal ob Konzern oder Mittelstand:

  1. es gibt zu einem Thema eine praktikable Lösung (die teilweise seit vielen Jahren „gut“ läuft)
  2. es wird entschieden, eine neue Software anzuschaffen. Warum? Aus vielfältigen Gründen zur Notwendigkeit, aufgrund von Wünschen der Unternehmensleitung bzw. von Kunden/Auftraggebern, dem Erfolg eines richtig guten Vertrieblers eines Softwareunternehmens … Klar ist aber allen Beteiligten: eigen „gestrickte Tools“ können nicht dauerhaft gut instandgehalten werden (Know-how, Updates nicht ewig möglich), Schnittstellenprobleme entstehen durch Customization
  3. Betroffene werden nicht zu Beteiligten gemacht, d.h. bisheriges (und bis dato akzeptiertes oder gar unterstütztes) Tun wird nicht transformiert, lediglich ein wie auch immer geartetes Training auf die neue Software in Aussicht gestellt und dann durchgeführt

Die Einführung und Nutzung der neuen Software werden dann grundsätzlich in Frage gestellt:

  • da ein Parallelbetrieb aufwendig ist, entsteht die Suche nach einem „günstigen Zeitpunkt für die Einführung“, den es aber nicht gibt und es kommt ggf. zur Top Down Anordnung der Einführung, z.B. zum Zeitpunkt der Fertigstellung laut des Softwaredienstleisters („wir sind soweit, es kann losgelegt werden“)
  • Tests in einer Testumgebung spiegeln nicht die realen Prozesse und anderen Vorgehensweisen und Abhängigkeiten (Schnittstellen) dar und daher entstehen nach dem politischen Go-Live Probleme, die die neue Software gänzlich in Frage stellen

Den Mitarbeitenden bleibt nichts anderes übrig und es kommt zu einem „so tun als ob“, zu individuellen Lösungen oder (im besten Fall) zu einer klaren Absage („machen wir nicht basta“ mit ggf. noch Begründung, egal ob real existierend oder nicht).

Was hilft da?

Aus unserer Sicht: ein begleitetes Change Management in Kombination mit einer agilen Vorgehensweise.

Gerade bei Nutzung von vielen unterschiedlichen Programmen und dem Ziel einer Einführung als Vereinheitlichung ist es wichtig, alle Beteiligte an einen Tisch zu holen.

Sinnvoll sind da vor allem Freiwillige, die als Key User fungieren und die notwendige Erfahrung mitbringen. Sie müssen in der Zukunft damit arbeiten und auch wenn sie die Entwicklung nicht finanzieren, gehören sie zum Kreis der Stakeholder.

In diesem Kreis sollte die Dringlichkeit der Entwicklung gemeinsam erarbeitet werden, eine gemeinsame Vision / Ziel entwickelt, um dann die Beteiligung an der fortlaufenden Erstellung zu ebnen. Dazu gehört auch, das Herausarbeiten, was das bisherig eingesetzte individuelle Tool für Möglichkeiten hat, wofür dies dienlich ist und das mit den Zielen vergleichen (Product Owner Aufgabe)

Dann ist eine agile/iterative Vorgehensweise sinnvoll, mit entsprechenden sogenannten Meetings, z.B. aus Kanban oder dem Scrum Framework. Da geht es darum, Hindernisse in der Bearbeitung aus dem Weg zu räumen. Eine stetige Fortschrittsdarlegung der Software an den Kreis der Key-User zu geben und darauf basierend das Feedback einzuholen.

Jede Softwareeinführung (ob nun erstmalig oder eine andere) ist ein Change, der – um erfolgreich zu sein – durch ein Change Management begleitet werden sollte.

Dabei können wir Sie mit unserer langjährigen Expertise durch fachliche Qualifikationen und praktische Einsätze unterstützen:

  • im Change-Prozess durch individuelle Change-Konzept-Entwicklung, Umsetzung des Konzepts durch Moderation von Ereignissen, Teamentwicklung, bei Bedarf einem Konfliktmanagement
  • in der Projektbegleitung (PMO) als Brücke zwischen einem Software Unternehmen als Auftragnehmer und dem zukünftig nutzendem Unternahmen als Auftraggeber oder als Methodencoach, z.B. für Kanban und als Scrum Master.

Wir stehen für ein Kennlerngespräch und für eine Darlegung unseres allgemeinen Vorgehens gerne zur Verfügung.