Wer Software in einen Betrieb bringt, baut nicht nur ein Werkzeug. Er verändert Gewohnheiten, Rollen, das Tempo des Alltags. Sechs Hürden, an denen es regelmäßig stolpert - und warum man sie nicht wegcoden kann.
Die meisten gescheiterten Software-Projekte im Mittelstand scheitern nicht an Bugs, fehlenden Features oder schwacher Architektur. Sie scheitern an Menschen, Gewohnheiten und an dem, was niemand ausgesprochen hat.
Wir reden hier nicht über die Hürden, die jeder Entwickler kennt. Wir reden über die, die sich im Schreibtisch verstecken, im Pausenraum, in den ersten zwei Wochen nach dem Launch. Wer sie kennt, kann sie einplanen. Wer sie übersieht, baut zuverlässig an ihnen vorbei.
Die Menschen
Skepsis, Gewohnheit, Angst vor Sichtbarkeit - das, was kein Pflichtenheft erfasst.
Der Alltag
Tagesgeschäft, Altsysteme, Daten von früher - alles, was schon da ist.
Die Zeit danach
Pflege, Anpassung, Verantwortung - das, was nach dem Launch beginnt.
Die häufigste Diagnose nach einem misslungenen Software-Rollout ist nicht "das Tool war schlecht", sondern "die Leute haben es nicht angenommen". Das klingt nach Trotz - ist aber meistens etwas anderes. Wer im Maschinenraum eines Betriebs zehn Jahre lang einen eigenen Weg entwickelt hat, dem zu sagen "ab morgen läuft das so", ist ein Angriff auf seine Kompetenz, nicht eine Erleichterung.
Skepsis hat selten mit Bequemlichkeit zu tun. Sie hat mit einer leisen Frage zu tun: Werde ich mit dem neuen System noch gebraucht? Diese Frage stellt niemand laut. Aber sie steht im Raum, wenn das neue System eingeführt wird - und sie entscheidet darüber, ob es benutzt wird oder ob ein heimliches Excel-Schattennetz daneben weiterläuft. Wer die Frage nicht beantwortet, baut Software für ein leeres Büro.
Der Befund heißt in der Organisationspsychologie psychologische Sicherheit - geprägt von Amy Edmondson (Harvard Business School) ab 1999. Ihre Studien zeigen: Teams, in denen Mitarbeiter Fehler eingestehen, Fragen stellen und Unsicherheit zugeben dürfen, übernehmen neue Werkzeuge deutlich schneller und nachhaltiger als Teams, in denen das tabu ist. Die Technik des Tools ist dabei zweitrangig.
Der Klassiker dazu ist Everett Rogers' "Diffusion of Innovations" (Erstausgabe 1962). Rogers zeigt, dass jede Neuerung eine vorhersagbare Verteilung von Innovatoren, frühen Anwendern, später Mehrheit und Nachzüglern durchläuft - und dass die spätere Mehrheit nur dann mitgeht, wenn sie sieht, dass die frühen Anwender im eigenen Haus erfolgreich damit sind. Wer den Rollout nur top-down befiehlt, überspringt diese Brücke - und wundert sich, warum auf der anderen Seite niemand ankommt.
Eine neue Software zu installieren dauert eine Stunde. Sie wirklich zur täglichen Arbeitsroutine zu machen, dauert Monate. Diese Lücke unterschätzen alle - der Anbieter, der seine Demo verkauft, der Chef, der den Vertrag unterschreibt, und manchmal auch der Mitarbeiter, der denkt, am Montag ist alles anders. Es ist nichts anders. Es ist nur Druck zusätzlich.
Gewohnheiten werden nicht durch Logins ersetzt, sondern durch Wiederholung mit Erfolg. Wenn das neue System beim ersten Versuch nicht das tut, was man erwartet, kehrt man zur alten Lösung zurück - und nimmt sie als "hat schon immer funktioniert" wieder auf. Deshalb gewinnt der zweite Tag nach dem Launch das ganze Projekt: Wenn es da hakt und niemand auffängt, ist das Werkzeug schon verloren, egal wie gut es technisch ist.
Der Begriff für diese Lücke ist Adoptions-Lücke oder "valley of disillusionment" - sichtbar gemacht in den jährlichen Gartner Hype Cycles: jede neue Technologie hat eine vorhersagbare Phase, in der sie schon installiert ist, aber noch keinen Mehrwert liefert. Wer in dieser Phase die Begleitung abzieht, verliert die Investition fast vollständig.
Eine McKinsey-Auswertung von 2023 zu IT-Transformationen im Mittelstand zeigt: 70 Prozent der Software-Rollouts erreichen die geplante Nutzungsquote nicht - in 80 Prozent der Fälle nicht wegen Software-Mängeln, sondern wegen fehlender Begleitung in den ersten sechs Wochen. Charles Duhigg hat in "The Power of Habit" (2012) die psychologische Mechanik beschrieben: Eine Gewohnheit verändert sich nur, wenn die neue Variante schneller einen Erfolg liefert als die alte. Ansonsten gewinnt der gewohnte Pfad - jedes Mal.
Wenn ein Software-Projekt in einem Betrieb startet, kommt es zum Tagesgeschäft dazu - es ersetzt es nicht. Die Kunden rufen weiter an, die Lieferungen kommen weiter, die Aufträge müssen raus. Das ist die Realität, in der Schulungen, Tests und Datenmigrationen passieren sollen: zwischen zwei Reklamationen und der Mittagspause.
Wer das nicht einplant, plant gegen den Betrieb. Wir reservieren deshalb in jedem Projekt explizite Schonzeiten - kurze, klar umrissene Fenster, in denen wir Material aufnehmen, Tests durchführen, Schulungen abhalten. Ohne diese Fenster passiert beides nicht: das Tagesgeschäft leidet nicht, weil die Software vernachlässigt wird - und die Software wird vernachlässigt, weil das Tagesgeschäft nicht leiden darf. Es ist eine der wenigen Stellen, an denen klare Termine mehr wert sind als Flexibilität.
Der ökonomische Begriff dazu ist Opportunitätskosten: jede Stunde, die ein Mitarbeiter in das neue System investiert, ist eine Stunde, die er nicht im operativen Geschäft verbringt. In Betrieben mit knapper Personaldecke sind das harte Zahlen. Eine Bitkom-Studie von 2024 zeigt: In 64 Prozent der mittelständischen Digitalisierungsprojekte ist "Zeit der eigenen Leute" der limitierende Faktor - nicht Geld, nicht Technik.
Die Engpasstheorie (Eliyahu Goldratt, "The Goal", 1984) erklärt warum. Jeder Betrieb hat ein Nadelöhr - eine Person, eine Maschine, eine Schicht. Wer dieses Nadelöhr für Software-Schulung blockiert, blockiert den ganzen Betrieb. Die Konsequenz ist nicht, Schulung wegzulassen - sondern sie so zu takten, dass das Nadelöhr nicht zugeht.
Jeder Betrieb hat eine Vergangenheit, und die liegt in Excel-Listen, in einem zehn Jahre alten Programm, in einem Outlook-Ordner mit 40.000 Mails. Das alles muss mit. Nicht komplett, aber das Wichtige davon - sonst beginnt das neue System mit leerer Bühne, und keiner findet seine Stammkunden wieder. Datenumzug ist die unsichtbarste, langweiligste und oft teuerste Phase eines Projekts.
Und sie ist die einzige, die nicht aufschiebbar ist. Eine neue Software ohne saubere Datenbasis ist ein leeres Regal: schön gebaut, aber nutzlos. Wir nehmen die alten Datenstände deshalb sehr früh in die Hand, oft noch in der Analysephase. Nicht um sie zu retten - sondern um zu sehen, was an ihnen noch trägt. Manchmal ist die Antwort "viel", manchmal "erstaunlich wenig". Beide Antworten helfen, das Projekt richtig zu dimensionieren.
Der Sammelbegriff dafür ist Legacy-Last - in der akademischen Informatik untersucht etwa durch Michael Feathers ("Working Effectively with Legacy Code", 2004). Sein Befund: In gewachsenen Systemen ist 70 bis 80 Prozent des Aufwands nicht das Bauen des Neuen, sondern das Verstehen des Alten. Das gilt für Code genauso wie für Daten.
Die Standish Group Chaos Reports dokumentieren seit den 1990ern Software-Projekte im Mittelstand. Ein wiederkehrendes Muster: Projekte mit unklarer Datenlage haben eine mehr als doppelt so hohe Scheiterquote wie Projekte, die früh Datenanalyse betreiben. Bei Geoffrey Moore ("Crossing the Chasm", 1991) wird daraus eine Maxime: Die Migration der Bestandsdaten ist nicht das letzte Risiko eines Projekts, sondern das erste.
In der Euphorie des Projekts gerät eine Frage in den Hintergrund: Was passiert in zwei Jahren? Wer pflegt die Software, wer macht Updates, wer baut den nächsten Knopf? Diese Frage hat den unsympathischen Charakter, dass sie sich nach dem Geldausgeben anfühlt. Aber wer sie nicht stellt, kauft sich ein Werkzeug ohne Garantie.
Software ist kein Möbelstück. Sie altert, weil sich das umgebende Internet ändert: Schnittstellen verschieben sich, Browser bekommen Updates, neue Gesetze kommen dazu. Wer eine Software einmal baut und dann sitzen lässt, wird in zwei Jahren feststellen, dass sie nicht mehr funktioniert - nicht, weil sie schlecht war, sondern weil das Drumherum sich gedreht hat. Deshalb gehört für uns zu jedem Projekt die Antwort auf "was passiert danach" dazu - vor dem Vertrag, nicht erst beim ersten Bug.
Der Begriff dafür ist Total Cost of Ownership - geprägt von Gartner Group Ende der 1980er, ursprünglich für IT-Hardware. Die Kernerkenntnis: Der Anschaffungspreis macht typischerweise nur 20 bis 30 Prozent der Lebenszykluskosten aus. Der Rest fällt in Pflege, Anpassung, Schulung, Migration. Wer nur den Anschaffungspreis vergleicht, vergleicht das falsche Drittel.
Im Software-Bereich heißt das gleiche Phänomen Software Entropy - beschrieben unter anderem von Andrew Hunt und David Thomas ("The Pragmatic Programmer", 1999): Jedes Software-System verfällt, wenn es nicht aktiv gepflegt wird. Nicht aus Materialermüdung, sondern weil das Umfeld weiterzieht. Konsequent: Wartung ist kein Bonus zum Kaufpreis - sie ist Teil davon, ob man sie ausweist oder nicht.
Im Mittelstand sitzt das Misstrauen gegen teure Software tief, und das zurecht: zu viele Projekte sind aus dem Ruder gelaufen. Die Reaktion darauf ist oft, am Anfang zu sparen - das günstigste Angebot zu nehmen, die kleinste Variante zu wählen, auf Schulung zu verzichten. Das wirkt sparsam. Es ist aber meistens das Gegenteil.
Was am Anfang gespart wird, taucht später wieder auf - in Form von Workarounds, doppelter Arbeit, Daten, die niemand mehr findet, und einem Tool, das niemand benutzt. Software, die nicht benutzt wird, ist 100 Prozent verloren, egal wie wenig sie gekostet hat. Die Frage ist nicht, wie viel das Projekt kostet, sondern wie viel das ungelöste Problem weiter kostet, wenn man es nicht angeht. Diese Rechnung ist unbequem - aber sie ist meist die ehrlichste Antwort auf die Frage, was man sich leisten kann.
Der psychologische Mechanismus heißt Hyperbolic Discounting (David Laibson, Quarterly Journal of Economics, 1997): Menschen bewerten Kosten heute deutlich höher als Kosten in der Zukunft, auch wenn die zukünftigen Kosten objektiv größer sind. Im Software-Projekt heißt das: Die 3.000 Euro, die ich heute spare, fühlen sich realer an als die 30.000 Euro, die ich in drei Jahren wegen schlechter Datenlage zusätzlich zahlen werde - obwohl die Rechnung im Schnitt genau so aufgeht.
In der IT-Praxis wird das Technical Debt genannt - ein Begriff von Ward Cunningham (1992). Wie bei Finanzschulden wird die heute aufgenommene Abkürzung mit Zinsen zurückgezahlt: jede Anpassung am System wird teurer, bis irgendwann ein Komplettumbau günstiger ist als noch ein Pflaster. Martin Fowler hat den Begriff in den 2000ern populär gemacht und auf eine bittere Faustregel gebracht: Eine Software, die heute eingespart wird, wird mit Zinsen zurückgezahlt - meist von jemand anderem als dem, der die Ersparnis verbucht hat.
Keine davon ist ein technisches Problem. Alle davon entscheiden, ob die Technik am Ende funktioniert.
Wer Software in einen Betrieb bringt, baut nicht an einer Maschine. Er baut an der Stelle, an der Menschen, Routinen und Werkzeuge zusammentreffen. Deshalb braucht ein Projekt nicht nur einen Entwickler - es braucht jemanden, der die Menschen mitnimmt, das Tagesgeschäft respektiert, die alten Daten ehrt und ehrlich über die Zeit danach redet. Das ist das, was wir mit "Begleitung" meinen. Es ist mehr Aufwand als ein reiner Code-Auftrag. Aber es ist der einzige Aufwand, der sich in einem Betrieb wirklich auszahlt.
Mehr darüber, wie wir konkret arbeiten, steht unter Bevor wir bauen, klären wir, was kaputt ist und unter Erst die Werkzeuge, dann die KI. Eine ehrliche Einordnung, was KI im Betrieb riskiert, findest du unter Was KI nicht kann, auch wenn es so wirkt.