Software richtig einführen

Die Statistik ist ernüchternd: Die Mehrheit aller Software-Implementierungen liefert nicht das, was ursprünglich versprochen wurde. Dabei liegt es selten an der Technologie selbst. Die häufigsten Ursachen sind systemischer Natur:

• Unklare Zielsetzung: Das Projekt startet ohne ein gemeinsames Verständnis davon, welches Geschäftsproblem eigentlich gelöst werden soll
• Scope Creep: Anforderungen wachsen unkontrolliert, weil es an Priorisierung und Governance fehlt
• Fehlende Stakeholder-Einbindung: Entscheider werden zu spät oder zu selten eingebunden – und verlieren das Vertrauen in das Projekt
• Unterschätzter Change: Die technische Lösung steht, aber die Organisation ist nicht bereit, sie zu nutzen
• Vendor Lock-in: Abhängigkeiten von einzelnen Anbietern schaffen Risiken, die erst spät sichtbar werden

Wer diese Muster kennt, kann gegensteuern – vorausgesetzt, man setzt an den richtigen Hebeln an.

Der grösste Fallstrick lauert ganz am Anfang: bei der Definition der Anforderungen. Zu oft werden Lastenheft und Pflichtenheft als bürokratische Pflichtübung behandelt, statt als strategisches Werkzeug.

Geschäftsziele vor Features: Jede Anforderung muss auf ein messbares Geschäftsziel einzahlen. Die Frage ist nicht „Was soll die Software können?“, sondern „Welches Ergebnis wollen wir erzielen?“

Nutzer einbeziehen – früh und konsequent: Anforderungen, die am Schreibtisch entstehen, bilden selten die Realität ab. Interviews, Workshops und Prototypen mit den tatsächlichen Anwendern sind unverzichtbar.

Priorisieren statt sammeln: Ein Backlog mit 500 gleichwertigen Anforderungen ist kein Backlog – es ist eine Wunschliste. Wirksame Priorisierung unterscheidet zwischen dem, was den grössten Geschäftswert liefert, und dem, was warten kann.

Living Documents: Anforderungen sind nicht statisch. Sie müssen sich mit dem Projektfortschritt und neuen Erkenntnissen weiterentwickeln dürfen – in einem kontrollierten Prozess.

Big Bang oder iterativ? Diese Entscheidung hat weitreichende Konsequenzen – und wird zu oft aus dem Bauch heraus getroffen.

Big Bang: Alles auf einmal live schalten. Funktioniert in der Theorie, scheitert in der Praxis an Komplexität, unvorhergesehenen Abhängigkeiten und der Unmöglichkeit, alles gleichzeitig zu testen. Das Risiko ist maximal.

Iterativ und inkrementell: Kleine, funktionsfähige Inkremente liefern, testen, lernen und anpassen. Das Risiko wird auf viele kleine Schritte verteilt. Jedes Inkrement liefert bereits Geschäftswert.

Parallel-Betrieb: Das neue System läuft für einen definierten Zeitraum parallel zum bestehenden. Daten und Ergebnisse werden abgeglichen. Erst wenn die Qualität stimmt, wird umgeschaltet.

Unsere Erfahrung zeigt: Der iterative Ansatz ist in den allermeisten Fällen überlegen. Er erfordert zwar mehr Disziplin in der Planung, reduziert aber das Projektrisiko erheblich und ermöglicht frühe Kurskorrekturen.

Die beste Software nützt nichts, wenn sie nicht angenommen wird. Change Management ist kein „Nice to have“ – es ist die Voraussetzung dafür, dass eine Implementierung ihren Geschäftswert entfaltet.

Früh kommunizieren: Betroffene müssen frühzeitig verstehen, warum die Veränderung stattfindet und was sie konkret für ihren Arbeitsalltag bedeutet. Informationsvakuum führt zu Widerstand.

Multiplikatoren gewinnen: In jeder Organisation gibt es Schlüsselpersonen, deren Meinung andere beeinflusst. Diese Multiplikatoren müssen früh eingebunden und als Befürworter gewonnen werden.

Schulung ist nicht gleich Enablement: Ein zweistündiges Training reicht nicht aus. Nachhaltiges Enablement umfasst Schulungen, Begleitmaterialien, Support-Strukturen und regelmässige Check-ins auch nach dem Go-live.

Widerstand ernst nehmen: Widerstand gegen Veränderung ist normal und oft sogar berechtigt. Wer Einwände ernst nimmt und in Lösungen übersetzt, gewinnt Vertrauen und verbessert gleichzeitig das Ergebnis.

Software-Implementierungen involvieren fast immer externe Partner – ob Softwareanbieter, Systemintegratoren oder spezialisierte Berater. Die Qualität dieser Zusammenarbeit entscheidet massgeblich über den Projekterfolg.

• Klare Verantwortlichkeiten: Wer liefert was bis wann? Ein RACI-Modell schützt vor dem klassischen „Das war doch euer Part“-Syndrom
• Vertragliche Flexibilität: Festpreisverträge für agile Projekte sind ein Widerspruch in sich. Time-and-Material mit definierten Meilensteinen und Quality Gates bieten die nötige Balance zwischen Kontrolle und Flexibilität
• Wissenstransfer sicherstellen: Externe dürfen keine Black Box schaffen. Dokumentation, Pair Programming und gemeinsame Code Reviews stellen sicher, dass das Know-how im Unternehmen bleibt
• Exit-Strategie definieren: Wie lässt sich der Anbieter wechseln, wenn die Zusammenarbeit nicht funktioniert? Diese Frage muss vor Projektstart beantwortet sein – nicht erst, wenn es zu spät ist

Ein Projekt ohne definierte Erfolgskriterien kann per Definition nicht erfolgreich sein. Dennoch starten erstaunlich viele Implementierungen ohne klare KPIs.

Vor dem Projektstart definieren:

• Welche Kennzahlen verbessern sich durch die neue Lösung?
• Was ist die Baseline – wo stehen wir heute?
• Welche Verbesserung ist realistisch und in welchem Zeitraum?

Mehrdimensional messen:

• Time to Value: Wie schnell liefert die Implementierung messbaren Geschäftswert?
• Adoption Rate: Wie viele der Zielnutzer arbeiten tatsächlich mit der neuen Lösung?
• Prozesseffizienz: Welche manuellen Schritte entfallen, welche Durchlaufzeiten verkürzen sich?
• Nutzerzufriedenheit: Wie bewerten die Anwender die neue Lösung im Vergleich zur alten?

Kontinuierlich tracken: Erfolgsmessung ist kein einmaliges Event nach dem Go-live. Regelmässige Reviews – nach 30, 90 und 180 Tagen – zeigen, ob die erwarteten Effekte eintreten und wo nachjustiert werden muss.