Die Software ist fertig, getestet, live. Drei Monate später merkst du, dass die Hälfte vom Team noch immer die alte Excel pflegt. Das Projekt ist nicht am Code gescheitert. Es ist am Umstieg gescheitert, und den plant fast niemand.
Es ist ein unangenehmer Moment, und er kommt häufiger vor, als man denkt. Du hast Zeit und Geld in eine Lösung gesteckt, die genau das tut, was sie soll. Sie läuft. Nur: Benutzt wird sie halb. Ein paar Leute sind umgestiegen, der Rest macht weiter wie immer, weil es wie immer eben funktioniert. Eine Software zu bauen ist das eine. Dass ein Team sie wirklich in den Alltag nimmt, ist das andere, und dieser Teil bekommt im Projektplan meistens null Zeilen.
Eine Software, die keiner nutzt, ist teurer als gar keine
Das klingt hart, stimmt aber. Solange die Hälfte beim Alten bleibt, führst du zwei Welten parallel. Die neuen Daten stehen im neuen System, die alten in der Excel, und nach ein paar Wochen weiss keiner mehr, welche Liste die richtige ist.
Du zahlst dann doppelt: einmal für die Software, die du gebaut hast, und einmal für den Aufwand, zwei Stände von Hand zusammenzuhalten. Ein Werkzeug, das nur halb benutzt wird, ist nicht neutral. Es macht die Arbeit komplizierter statt einfacher, und genau das wolltest du ja vermeiden.
Warum Leute beim Alten bleiben
Das hat selten mit Sturheit zu tun. Der alte Weg funktioniert für die Leute, die ihn täglich gehen. Sie kennen jeden Trick, jede Abkürzung, jeden Umweg um die Macken herum. Der neue Weg ist unbekannt, und unbekannt heisst erstmal langsamer. Jeder Umstieg kostet Energie, bevor er etwas zurückgibt.
Dahinter steckt eine einfache Mechanik. Wenn das neue System für die fünf Handgriffe, die jemand fünfzig Mal am Tag macht, auch nur einen Tick umständlicher ist, wird er drumherum arbeiten. Nicht aus Trotz, sondern weil es sich im Moment lohnt. Ein Umstieg braucht einen Grund, den die Leute spüren, nicht einen, den man ihnen sagt.
Die Einführung beginnt vor der ersten Zeile Code
Hier passiert der häufigste Fehler. Ausgesucht und bestellt wird die Software oft von der Chefin oder dem Abteilungsleiter. Bedient wird sie von den Leuten am Schalter, im Lager, im Büro nebenan. Wenn diese Leute die Software zum ersten Mal am Tag des Starts sehen, hast du schon verloren.
Wir wollen die zwei, drei Personen, die das Ding wirklich täglich bedienen werden, früh am Tisch haben. Nicht um sie zu fragen, welche Farbe der Knopf bekommt, sondern um zu verstehen, wie ihr Tag tatsächlich abläuft. Daraus wird Software, die sich anfühlt, als hätte jemand zugehört. Das hängt eng mit dem zusammen, was gute Oberflächen ausmacht, und mit der Mitarbeit, die wir von dir brauchen.
Die Brücke steht. Gegangen wird trotzdem der alte Pfad
Eine neue Brücke nützt nichts, solange der alte Trampelpfad bequemer erreichbar ist. Mit Software ist es genauso. Es reicht nicht, dass der bessere Weg existiert. Er muss im Alltag der naheliegende sein, sonst nehmen die Leute weiter den Weg, den sie kennen. Einführung heisst, den alten Pfad bewusst zu schliessen und den neuen leicht begehbar zu machen.
Der Umstieg ist ein Stichtag, kein Zustand
"Wir lassen beides mal eine Weile parallel laufen" klingt vernünftig und ist eine der zuverlässigsten Arten, einen Umstieg zu verschleppen. Ohne Stichtag wird das Parallele zum Dauerzustand. Jeder hat einen guten Grund, den alten Weg noch kurz zu nehmen, und kurz wird nie vorbei.
Besser ist ein klares Datum. Bis dahin wird vorbereitet, geübt und werden die Daten übernommen. Ab dann läuft es über das neue System, und das alte wird abgeschaltet. Ein Netz für den Notfall darf bleiben, aber mit einem Ablaufdatum, nicht als offene Tür. Wie so ein sauberer Wechsel aussieht, ohne dass der Betrieb stillsteht, steht im Weg aus dem Altsystem.
Der Umstieg scheitert selten an der Software. Er scheitert daran, dass niemand ihn geplant hat.
Was wir konkret dafür tun
Einführung ist bei uns kein PDF-Handbuch, das keiner liest. Es ist eine kurze Schulung mit den echten Leuten an ihren echten Fällen. Es ist ein Spickzettel mit den fünf Dingen, die sie wirklich brauchen, nicht vierzig Seiten für alles. Und es ist Erreichbarkeit in den ersten Wochen, wenn die Fragen kommen, die im Trockenen nie auftauchen.
Vor allem schauen wir in dieser Zeit hin. Wo stockt es, wo klickt jemand dreimal, wo kommt dieselbe Frage von mehreren Leuten? Das sind keine Schulungsprobleme, das sind Hinweise auf raue Kanten in der Software, und die schleifen wir schnell ab. Software ist nach dem Launch nicht fertig, und die ersten Wochen im echten Betrieb sind die wertvollste Rückmeldung, die du kriegen kannst.
Die Faustregel
Plane die Einführung wie ein Feature, nicht wie eine Fussnote. Hol die zwei, drei Leute, die das Ding täglich bedienen, von Anfang an dazu. Setz einen Stichtag für den Umstieg und schalt das Alte danach wirklich ab. Ein Werkzeug, das man ausprobieren darf, aber nie muss, bleibt liegen.
Die beste Software der Welt bringt dir nichts, wenn sie im Alltag umgangen wird. Der Code ist der kleinere Teil der Arbeit. Der grössere ist, dass aus einem neuen Werkzeug eine neue Gewohnheit wird, und das passiert nicht von allein.
Du planst eine neue Software und willst, dass dein Team sie am Ende auch benutzt? Lass uns über die Einführung reden, nicht erst über den Code.
Jule
Co-Founder & Product · FlowCode Bern. Schreibt über das, was beim Bauen wirklich passiert.
