Change Management in IT-Projekten – warum die Technik allein nichts verändert

Es gibt ein Muster, das sich in IT-Projekten mit erstaunlicher Regelmässigkeit wiederholt. Ein Unternehmen investiert in ein neues System, eine neue Plattform oder eine neue Software. Die technische Umsetzung läuft ordentlich, der Go-live findet statt, die Schulungen sind gebucht. Und dann passiert etwas Ernüchterndes: Die Mitarbeitenden arbeiten weiter wie vorher. Die Excel-Listen verschwinden nicht. Die alten Prozesse laufen parallel. Das neue System wird bestenfalls geduldet, schlimmstenfalls aktiv umgangen.

Das ist kein Einzelfall. Studien und Praxiserfahrung zeigen übereinstimmend, dass ein erheblicher Anteil aller IT- und Digitalisierungsprojekte nicht an der Technik scheitert, sondern an der fehlenden Veränderungsbereitschaft im Unternehmen. Die Software funktioniert. Die Menschen arbeiten trotzdem nicht damit. Und der Grund dafür ist fast immer derselbe: Niemand hat sich ernsthaft darum gekümmert, die Veränderung zu begleiten.

Warum Technik allein keine Veränderung bewirkt

Jedes IT-Projekt, das über eine rein technische Infrastrukturänderung hinausgeht, ist im Kern ein Veränderungsprojekt. Wenn ein Unternehmen ein neues CRM einführt, ein ERP ablöst, auf Microsoft 365 umstellt oder Prozesse digitalisiert, dann verändert sich nicht nur die Technologie. Es verändern sich Arbeitsabläufe, Zuständigkeiten, Informationsflüsse und oft auch die Zusammenarbeit zwischen Abteilungen.

Das Problem ist, dass viele Unternehmen diese Projekte rein technisch denken. Der Fokus liegt auf Systemauswahl, Konfiguration, Datenmigration und Schnittstellen. Das sind wichtige Themen. Aber sie decken nur eine Hälfte des Projekts ab. Die andere Hälfte besteht aus Menschen, die morgen anders arbeiten sollen als heute. Und Menschen ändern ihr Verhalten nicht, weil jemand eine neue Software installiert hat.

Das hat nichts mit Sturheit oder mangelnder Intelligenz zu tun. Es hat damit zu tun, wie Veränderung funktioniert. Menschen brauchen einen Grund, etwas anders zu machen. Sie brauchen das Vertrauen, dass das Neue besser ist als das Alte. Sie brauchen Zeit, um sich umzugewöhnen. Und sie brauchen Unterstützung, wenn es dabei hakt. Wenn all das fehlt, ist Widerstand keine Störung, sondern eine völlig nachvollziehbare Reaktion.

Was Change Management in IT-Projekten bedeutet

Change Management klingt nach Grosskonzern, nach teuren Beratungsprogrammen und nach Methoden mit komplizierten Abkürzungen. In der Realität geht es um etwas deutlich Bodenständigeres. Es geht darum, die betroffenen Menschen mitzunehmen. Nicht als Nachgedanken, sondern als festen Bestandteil des Projekts.

Konkret bedeutet das drei Dinge.

Erstens: Frühzeitig kommunizieren. Die meisten Menschen haben kein Problem mit Veränderung. Sie haben ein Problem damit, von Veränderung überrascht zu werden. Wenn Mitarbeitende erst am Tag der Einführung erfahren, dass sich ihr Arbeitswerkzeug ändert, ist Widerstand vorprogrammiert. Wer hingegen frühzeitig erklärt, warum eine Veränderung kommt, was sie für den Einzelnen bedeutet und wie der Zeitplan aussieht, schafft die Grundlage für Akzeptanz. Das muss keine aufwändige Kommunikationskampagne sein. Ein kurzes, ehrliches Update zur richtigen Zeit wirkt mehr als eine Hochglanzpräsentation im letzten Moment.

Zweitens: Betroffene einbinden. Menschen akzeptieren Veränderungen deutlich leichter, wenn sie das Gefühl haben, gehört zu werden. Das heisst nicht, dass jeder Mitarbeitende bei jeder Entscheidung mitreden muss. Aber es heisst, dass die Personen, die am Ende mit dem neuen System arbeiten, frühzeitig in den Prozess eingebunden werden sollten. Sei es durch Feedback zu Anforderungen, durch Teilnahme an Pilotphasen oder durch die Rolle als Ansprechperson im eigenen Team. Wer mitgestaltet, trägt das Ergebnis eher mit.

Drittens: Unterstützung über den Go-live hinaus. Der grösste Fehler im Change Management ist die Annahme, dass mit dem Go-live alles erledigt ist. In Wahrheit beginnt die eigentliche Veränderung erst danach. Die ersten Wochen nach der Einführung sind entscheidend. Hier zeigt sich, ob die Schulung ausreicht, ob die Prozesse in der Praxis funktionieren und wo nachgebessert werden muss. Unternehmen, die in dieser Phase Unterstützung bieten – durch Ansprechpersonen, durch kurze Nachschulungen, durch offene Rückmelde-Kanäle – haben eine massiv höhere Adoptionsrate als solche, die nach dem Go-live zum Tagesgeschäft übergehen.

Die typischen Fehler – und warum sie so verbreitet sind

Veränderung wird als technisches Problem behandelt. Der häufigste Fehler ist, IT-Projekte ausschliesslich aus technischer Perspektive zu planen und zu steuern. Die Frage lautet dann: Funktioniert das System? Statt: Arbeiten die Menschen damit? Das eine lässt sich mit Tests und Abnahmen prüfen. Das andere nicht. Viele Unternehmen merken den Unterschied erst, wenn die Nutzungszahlen nach dem Go-live einbrechen.

Schulung wird mit Change Management verwechselt. Eine Schulung erklärt, wie ein System funktioniert. Change Management erklärt, warum es eingeführt wird, was sich dadurch ändert und wie der Übergang begleitet wird. Schulung ist ein Teil von Change Management, aber bei weitem nicht alles. Wer nur schult, ohne zu kommunizieren und einzubinden, trainiert Fertigkeiten ohne Motivation. Und Fertigkeiten ohne Motivation führen zu einem System, das zwar bedient werden kann, aber nicht bedient wird.

Widerstand wird als Fehlverhalten gewertet. Wenn Mitarbeitende sich gegen ein neues System sträuben, ist die erste Reaktion in vielen Unternehmen Unverständnis oder Ungeduld. Die Geschäftsleitung hat das Projekt freigegeben, das Budget steht, das System ist da – warum arbeitet ihr nicht damit? Diese Haltung verkennt, dass Widerstand fast immer ein Signal ist. Er zeigt an, wo Information fehlt, wo Bedenken nicht adressiert wurden oder wo das System an der Realität der täglichen Arbeit vorbeigeht. Unternehmen, die Widerstand als Feedback ernst nehmen, verbessern nicht nur die Akzeptanz, sondern oft auch das System selbst.

Die Führungsebene delegiert die Veränderung nach unten. Change Management funktioniert nur, wenn die Führung dahintersteht. Nicht als Lippenbekenntnis, sondern sichtbar und konkret. Wenn die Geschäftsleitung ein neues System einführt, aber selbst weiterhin die alten Reports per E-Mail verlangt, sendet das ein deutliches Signal. Veränderung beginnt oben. Wenn die Führung das neue Werkzeug nicht nutzt, werden es die Mitarbeitenden auch nicht tun.

Change Management im KMU – pragmatisch statt aufwändig

Viele KMU schrecken vor dem Begriff Change Management zurück, weil er nach etwas klingt, das nur Grossunternehmen brauchen. Tatsächlich ist das Gegenteil der Fall. In einem KMU hat jede Veränderung eine direktere Wirkung auf den Arbeitsalltag. Es gibt weniger Puffer, weniger Ausweichmöglichkeiten und weniger Toleranz für Systeme, die im Alltag nicht funktionieren. Gerade deshalb ist es wichtig, den menschlichen Faktor bewusst zu adressieren.

Die gute Nachricht: In einem KMU braucht Change Management keinen eigenen Projektstream mit eigener Budgetlinie. Es braucht Aufmerksamkeit, gesunden Menschenverstand und ein paar bewährte Massnahmen.

Einen internen Champion benennen. Nicht jeder muss vom neuen System begeistert sein. Aber es braucht mindestens eine Person pro betroffener Abteilung, die das Projekt versteht, dahintersteht und als Ansprechperson für die Kolleginnen und Kollegen dient. Diese Person muss keine offizielle Rolle haben. Sie muss jemand sein, dem die anderen vertrauen und der oder die bereit ist, Fragen zu beantworten und Probleme weiterzugeben.

Das Warum vor dem Wie kommunizieren. Bevor jemand lernt, wie ein neues System funktioniert, muss er oder sie verstehen, warum es eingeführt wird. Und zwar nicht in der Sprache des IT-Projekts, sondern in der Sprache des eigenen Arbeitsalltags. Was wird einfacher? Was fällt weg? Was wird anders? Wer diese Fragen ehrlich beantwortet – auch wenn die Antwort lautet, dass die Umstellung anfangs Aufwand bedeutet –, schafft Glaubwürdigkeit.

Einen Feedback-Kanal schaffen. Mitarbeitende, die Probleme melden können und erleben, dass ihre Rückmeldungen ernst genommen werden, akzeptieren Veränderungen deutlich besser als solche, die das Gefühl haben, vor vollendete Tatsachen gestellt zu werden. Dieser Kanal muss nicht formell sein. Ein regelmässiges kurzes Standup, ein Teams-Kanal oder auch ein einfaches Dokument, in dem offene Punkte gesammelt werden, reicht in den meisten Fällen aus.

Die Einführung stufenweise planen. Nicht alles muss auf einmal live gehen. Wer ein neues System zuerst mit einer kleinen Gruppe testet, lernt aus deren Erfahrungen und kann die breitere Einführung gezielter gestalten. Das reduziert das Risiko, verbessert die Qualität der Schulungen und gibt den Erstanwendern die Möglichkeit, als Multiplikatoren zu wirken.

Der richtige Zeitpunkt: Change Management beginnt vor dem Projekt

Ein verbreiteter Irrtum ist, dass Change Management erst beginnt, wenn das System fertig ist und eingeführt werden soll. In Wahrheit beginnt es mit der ersten Kommunikation über das Projekt. Sobald Mitarbeitende erfahren, dass sich etwas ändert – und sie erfahren es meistens früher, als die Geschäftsleitung denkt –, beginnt der Veränderungsprozess in ihren Köpfen. Wenn zu diesem Zeitpunkt keine Information da ist, füllen Gerüchte, Befürchtungen und Worst-Case-Szenarien die Lücke.

Deshalb ist es sinnvoll, die Kommunikation und Einbindung von Anfang an mitzudenken. Nicht als Zusatzaufwand, sondern als fester Bestandteil der Projektplanung. Wer benennt die Veränderung gegenüber dem Team? Wann und wie werden Betroffene informiert? Welche Rückmelde-Möglichkeiten gibt es? Wer steht nach dem Go-live als Ansprechperson bereit? Das sind Fragen, die am Anfang des Projekts geklärt werden sollten, nicht am Ende.

In der Praxis reicht es oft, diese Punkte in zwei oder drei Absätzen im Projektplan festzuhalten. Es braucht kein eigenes Change-Konzept mit 30 Seiten. Es braucht Klarheit darüber, dass die menschliche Seite des Projekts genauso ernst genommen wird wie die technische.

Was gutes Change Management bewirkt

Unternehmen, die den menschlichen Faktor in IT-Projekten bewusst adressieren, erleben in der Regel drei Effekte. Erstens steigt die Nutzungsrate der neuen Systeme deutlich schneller. Die Investition beginnt sich früher zu lohnen, weil die Mitarbeitenden tatsächlich damit arbeiten. Zweitens sinkt der Nachbesserungsaufwand, weil Probleme früher erkannt und adressiert werden. Drittens verbessert sich die grundsätzliche Haltung gegenüber Veränderung im Unternehmen. Wer einmal erlebt hat, dass eine Umstellung gut begleitet wurde, ist beim nächsten Mal offener.

Das ist keine Theorie. Das ist die Erfahrung aus Dutzenden von IT-Projekten, in denen der Unterschied zwischen Erfolg und Scheitern nicht in der Technologie lag, sondern in der Frage, ob die betroffenen Menschen mitgenommen wurden.

Die Technik ist selten das Problem. Die Einführung ist es. Und Einführung bedeutet nicht Go-live. Einführung bedeutet, dass die Menschen im Unternehmen die Veränderung verstehen, mittragen und in ihrem Arbeitsalltag umsetzen. Wer das als festen Bestandteil jedes IT-Projekts versteht, spart sich nicht nur Nachbesserungen und Frustration. Er schafft die Grundlage dafür, dass Technologie tatsächlich den Nutzen bringt, für den sie gedacht war.