Systemakzeptanz: Warum IT-Einführungen scheitern
Was Sie vorher anders machen können, damit ein neues System im Betrieb auch benutzt wird.
Bevor Sie anfangen
Kurz gesagt
Nicht ob Mitarbeitende beteiligt werden, sondern wie gut, entscheidet über die spätere Akzeptanz eines Systems. Widerstand ist selten Bequemlichkeit, meist ein Hinweis auf etwas, das im neuen Ablauf nicht bedacht wurde. Wer mitgestalten darf, verteidigt das Ergebnis.
Dieser Leitfaden verkauft Ihnen keine Software. Ich verkaufe keine Lizenzen und bekomme von keinem Hersteller Provision. Deshalb steht auf den folgenden Seiten kein Produktname.
Es geht um etwas anderes: um den Grund, aus dem gute Software in Betrieben liegen bleibt. Der Zusammenhang zwischen der Einbindung von Mitarbeitenden und dem Erfolg von IT-Einführungen war das Thema meiner Bachelorarbeit in Wirtschaftsinformatik. Was ich dabei gelernt habe, steht hier in der Fassung, die Ihnen im Betrieb nützt.
Lesezeit: etwa fünfzehn Minuten. Der Selbsttest in Kapitel 5 dauert weitere zehn.
1. Das Muster
Der Ablauf ist in fast jedem Betrieb derselbe, und er ist an keiner Stelle böswillig.
Die Geschäftsführung erkennt ein Problem und sucht eine Lösung. Es werden Angebote eingeholt, Demos angesehen, verglichen. Die Entscheidung fällt. Das System wird eingerichtet, es gibt einen Einführungstermin und eine Schulung. Alle nicken.
Dann passiert nichts.
Nach drei Monaten arbeitet ein Teil des Teams mit dem neuen System, ein Teil mit der alten Excel-Liste und ein Teil mit beidem. Die Zahlen stimmen nirgends. Wer fragt, bekommt Antworten wie „das dauert damit länger" oder „das kann das nicht". Die Geschäftsführung hält das für Bequemlichkeit. Das Team hält die Geschäftsführung für ahnungslos.
Beide haben ein Stück weit recht, und niemand redet darüber. Am Ende läuft die Lizenz weiter, das Projekt gilt als gescheitert, und die nächste Anschaffung wird mit noch mehr Misstrauen betrachtet.
Der wichtigste Satz dieses Leitfadens: Das System ist nicht an der Technik gescheitert. Es ist daran gescheitert, dass die Menschen, die damit arbeiten sollen, keinen Anlass hatten, es zu wollen.
2. Warum Menschen ein System annehmen oder nicht
Die Forschung zur Akzeptanz von Technik ist sich in einem Punkt bemerkenswert einig: Ob ein System benutzt wird, hängt vor allem an zwei Wahrnehmungen der Person, die es benutzen soll.
Erstens: Bringt mir das etwas?
Nicht dem Unternehmen. Nicht der Geschäftsführung. Der Person selbst, an ihrem Arbeitstag. Ein System, das die Auswertung für die Chefin verbessert und für die Sachbearbeiterin drei Klicks mehr bedeutet, hat für die Sachbearbeiterin keinen Nutzen. Sie wird es genau so behandeln.
Zweitens: Komme ich damit zurecht?
Nicht objektiv, sondern gefühlt. Wer beim ersten Versuch scheitert und sich dabei dumm vorkommt, versucht es seltener ein zweites Mal. Das hat nichts mit Alter oder Technikbegeisterung zu tun, sondern damit, ob jemand einen sicheren Rahmen zum Ausprobieren hatte.
Beides ist Wahrnehmung, nicht Tatsache. Und Wahrnehmung entsteht lange vor der Schulung. Sie entsteht in dem Moment, in dem jemand zum ersten Mal von dem Vorhaben hört, und daran, ob er gefragt wurde oder informiert.
Wer mitgestalten darf, verteidigt das Ergebnis.
Wer es vorgesetzt bekommt, sucht Umwege.
3. Widerstand ist eine Information
Der zweite Denkfehler nach „die sollen sich nicht so anstellen" ist der Versuch, Widerstand wegzuargumentieren.
Widerstand gegen ein neues System ist in den meisten Fällen kein Verteidigen der Bequemlichkeit. Er ist ein Hinweis auf etwas Konkretes, das im neuen Ablauf nicht bedacht wurde. Die Person, die sich am lautesten wehrt, ist häufig die, die den Ablauf am besten kennt.
Typische Sätze und was tatsächlich dahintersteckt:
Die letzte Zeile ist die gefährlichste. Wer schweigt, hat sich schon entschieden.
Praktische Folge: Sammeln Sie diese Sätze, statt sie zu widerlegen. Jeder davon ist eine Anforderung, die Sie vor der Einführung günstig lösen können und nach der Einführung teuer.
4. Die fünf Momente, in denen es sich entscheidet
Akzeptanz entsteht nicht bei der Schulung. Sie entsteht an fünf früheren Punkten.
Moment 1: Bevor überhaupt gesucht wird
Fragen Sie die Leute, die den Ablauf ausführen, wo es hakt. Nicht als Umfrage, sondern im Gespräch. Diese Aufnahme kostet Sie zwei Stunden und ist der wertvollste Teil des ganzen Projekts.
Woran Sie erkennen, dass es fehlt: Die Anforderungsliste stammt vollständig aus der Geschäftsführung.
Moment 2: Bei der Auswahl
Lassen Sie mindestens eine Person, die täglich damit arbeiten wird, bei den Demos dabei sein. Nicht als Zuhörerin, sondern mit dem ausdrücklichen Auftrag, kritische Fragen zu stellen.
Woran Sie erkennen, dass es fehlt: Die Entscheidung wurde von Personen getroffen, die das System selbst nicht benutzen werden.
Moment 3: Bevor eingeführt wird
Sagen Sie offen, was sich für wen ändert, und zwar auch das Unangenehme. Was fällt weg? Wird jemand kontrolliert, der es vorher nicht war? Was passiert mit den Aufgaben, die wegfallen? Wenn Sie diese Fragen nicht beantworten, beantwortet sie das Team selbst, und zwar pessimistisch.
Woran Sie erkennen, dass es fehlt: Die erste Information an das Team ist die Einladung zur Schulung.
Moment 4: Bei der Einführung
Bestimmen Sie ein bis zwei Personen aus dem Team, die früher Zugriff bekommen, mehr lernen und danach die erste Anlaufstelle für Fragen sind. Menschen fragen lieber die Kollegin als die Hotline, und sie geben vor der Kollegin eher zu, dass sie etwas nicht verstehen.
Woran Sie erkennen, dass es fehlt: Alle Fragen landen bei der Geschäftsführung oder beim externen Dienstleister.
Moment 5: In den ersten Wochen danach
Fragen Sie nach. Nicht „läuft es?", sondern „was nervt?". Und ändern Sie mindestens eine Sache, die zurückkommt, sichtbar für alle. Das ist der Beweis dafür, dass Rückmeldungen etwas bewirken. Ohne diesen Beweis hören die Rückmeldungen auf, und was bleibt, sind Umwege.
Woran Sie erkennen, dass es fehlt: Nach dem Einführungstermin hat niemand mehr strukturiert gefragt.
5. Selbsttest: läuft Ihre Einführung auf Ablehnung zu?
Für ein laufendes oder geplantes Vorhaben. Jedes Nein ist ein Warnsignal.
Auswertung
8 bis 10 Ja: Sie haben gute Voraussetzungen. Halten Sie Moment 5 aus Kapitel 4 durch, dort brechen die meisten ab.
5 bis 7 Ja: Es wird funktionieren, aber langsamer und mit Reibung. Die fehlenden Punkte lassen sich nachholen, solange die Einführung nicht lange her ist.
Unter 5 Ja: Rechnen Sie mit Ablehnung, unabhängig davon, wie gut die Software ist. Kapitel 6 ist für Sie.
6. Wenn es schon passiert ist
Der häufigste Fall in der Praxis: Das System ist da, bezahlt, und es wird nicht benutzt. Was jetzt?
Zuerst: nicht abschalten und nicht durchdrücken. Beides ist teuer. Abschalten verbrennt die Investition und bestätigt allen, dass solche Projekte nichts bringen. Durchdrücken erzeugt Scheinnutzung, bei der das System zwar befüllt wird, aber mit Daten, denen niemand traut.
Der Weg dazwischen, in vier Schritten:
1. Herausfinden, was tatsächlich läuft.
Nicht fragen, ob das System benutzt wird, sondern sich zeigen lassen, wie ein konkreter Vorgang heute wirklich abgewickelt wird. Vom ersten Kontakt bis zur Rechnung. Die Umwege sind nicht das Problem, sie sind die Diagnose.
2. Zuhören, ohne zu verteidigen.
Der Punkt, an dem es meistens kippt. Wenn die erste Reaktion auf einen Einwand eine Erklärung ist, warum der Einwand falsch ist, hört das Zuhören auf. Sammeln, nicht kommentieren.
3. Eine Sache reparieren, sichtbar.
Nehmen Sie den am häufigsten genannten Ärgernispunkt und lösen Sie ihn. Auch wenn er klein ist. Besonders wenn er klein ist. Das ändert die Erzählung im Betrieb von „das wird uns aufgezwungen" zu „da tut sich was".
4. Erst dann über Nutzung reden.
Verbindlichkeit funktioniert, aber erst nachdem die Leute erlebt haben, dass ihre Einwände etwas bewirken. In dieser Reihenfolge, nie umgekehrt.
Ein System, das nach sechs Monaten wiederbelebt wurde, ist in fast allen Fällen billiger als ein neues. Und der Betrieb lernt dabei etwas, das bei der nächsten Einführung Geld spart.
7. Die drei häufigsten Fehler
Schulung mit Akzeptanz verwechseln. Eine Schulung vermittelt Bedienung. Sie beantwortet nicht die Frage, warum jemand das tun soll. Wer nach der Schulung nicht arbeitet, hat kein Wissensproblem.
Die lauteste Kritikerin als Störfaktor behandeln. Diese Person kennt den Ablauf meistens am besten. Wenn Sie sie gewinnen, gewinnen Sie das Team. Wenn Sie sie übergehen, verlieren Sie beide.
Etwas hinzufügen, ohne etwas wegzunehmen. Solange die alte Liste noch existiert, wird sie benutzt. Wo solche Parallel-Listen entstehen, steht im Leitfaden zu Doppelarbeit. Ein Ablauf, bei dem nach der Einführung niemand weniger Arbeit hat, war keine Verbesserung.
8. Wie es weitergehen kann
Mit diesem Leitfaden können Sie den ersten Schritt selbst machen. Der Selbsttest zeigt Ihnen, wo Sie stehen, und Kapitel 6 gibt Ihnen einen Weg, wenn schon etwas schiefgelaufen ist. Viele Betriebe kommen damit gut zurecht.
Es gibt einen Punkt, an dem es von außen leichter geht: Wenn die Fronten verhärtet sind, sagt niemand der Geschäftsführung mehr ehrlich, was nicht funktioniert. Dann braucht es jemanden, dem beide Seiten sagen können, wie es wirklich ist, und der daraus einen tragfähigen Ablauf macht.
Genau das ist meine Arbeit. Ich komme aus der Wirtschaftsinformatik und stehe damit zwischen den beiden Welten: Ich verstehe die Technik, und ich weiß, dass sie nur funktioniert, wenn die Menschen mitgehen.
Diesen Leitfaden als PDF
Elf Seiten, ohne Registrierung. Der eigentliche Wert liegt darin, dass Sie ihn weiterleiten können, an die Geschäftsführung, an die Kollegin, die den Ablauf am besten kennt, oder ins ganze Team.
Ein kostenloses Erstgespräch, 30 Minuten.
Wir schauen uns Ihre Situation an, und ich sage Ihnen ehrlich, ob und wie ich helfen kann. Wenn nicht, sage ich Ihnen auch das.
Vollständige Arbeit: „Systemakzeptanz durch Beteiligung der Mitarbeitenden? Der Zusammenhang der Mitarbeitenden-Einbindung mit erfolgreicher IT-Einführung“, Bachelorarbeit in Wirtschaftsinformatik. Eine kurze Zusammenfassung finden Sie unter Über mich.
Marvin Ritter, BSc Wirtschaftsinformatik, ITIL Foundation. Über acht Jahre Business-IT als Techniker, in der IT-Leitung und als Berater. Dieser Leitfaden ersetzt keine individuelle Beratung. Alle Angaben nach bestem Wissen, ohne Gewähr.