User Adoption bei Einkaufssoftware – wo liegt das Problem?

Eine Nutzerakzeptanz von 100 % ist Teil jeder ROI-Berechnung, die meist vor der Entscheidung für eine Einkaufslösung erstellt wird. Insofern steht sie schon vor der eigentlichen Softwareentscheidung im Fokus, bekommt im weiteren Verlauf aber oft nicht genug Aufmerksamkeit.

Was ist User Adoption?

User Adoption (Nutzerakzeptanz) ist der Prozess, in dem sich neue Nutzer an ein Produkt oder eine Dienstleistung gewöhnen und entscheiden, es weiter nutzen zu wollen. Nutzer akzeptieren ein Produkt nur, wenn es ihnen hilft, ein Ziel zu erreichen – sei es, Anfragen einfacher an Lieferanten zu verschicken oder Werkzeuge schneller in einem Webshop zu bestellen.

Mitunter wird versucht, die Nutzerakzeptanz über entsprechende Ziele in einer Zielvereinbarung als Teil des Gehalts zu beeinflussen. Das ist aber oft nicht nachhaltig, weil die Nutzer das Tool nicht freiwillig verwenden.

Meist wird nicht nur eine neue Software eingeführt, sondern gleichzeitig der Prozess neu gestaltet oder zumindest verändert. Für den Endanwender heißt das: Er muss sich nicht nur an die Software gewöhnen, sondern zugleich an den neuen Prozess.

Das wissen Einkaufsleitungen und die Kolleginnen und Kollegen, die für neue Tools und Prozesse zuständig sind, natürlich. Manchmal wird aber der falsche Schluss daraus gezogen. Man geht nämlich davon aus, dass es besser ist, den Prozess so wenig wie möglich zu ändern, damit sich der Nutzer nur an die neue Software und nicht an eine neue Prozessgestaltung gewöhnen muss. Das wird bei der Softwareeinführung oft zum Problem, wenn die Software den einen oder anderen Prozess nicht genau so abbilden kann wie bisher.

Was ist die beste Strategie für eine hohe Nutzerakzeptanz?

Es gibt nicht die eine Zauberformel; eine hohe Nutzerakzeptanz ist vielmehr das Zusammenspiel vieler Faktoren. Hier einige davon:

1. Klare Definition der Projektziele: Sobald die Einführung einer Software beschlossen ist, sollten die Ziele der Einführung klar kommuniziert werden. Aussagen wie „Wir automatisieren die Prozesse komplett“ sollten vermieden werden, da sie oft nicht der Realität entsprechen und bei den Endanwendern Erwartungen wecken, die zu langen und teuren Projekten führen. Stattdessen sollten realistische Kennzahlen, die erreicht werden sollen, in den Vordergrund gestellt werden. Manchmal ist es auch von Vorteil, gleich zu Beginn zu kommunizieren, dass das Projekt agil umgesetzt wird und es deshalb anfangs nur eine Minimalvariante (ein MVP – Minimum Viable Product) gibt, die Endanwender aber in die Optimierung eingebunden werden.
2. Projektmarketing ist viel wichtiger, als oft angenommen wird. Zum Projektmarketing gehört auch die Kommunikation an andere Abteilungen, Lieferanten und Partner, die später in das Projekt eingebunden werden. Für das Projektmarketing sollten auch Give-aways produziert werden, die das Projekt allgegenwärtig erscheinen lassen und so die Aufmerksamkeit der Nutzer erhöhen.
3. Einbindung der Endanwender in die Entscheidung: Werden die Nutzer in die Entscheidung eingebunden, steigt meist die spätere Akzeptanz. Wichtig ist dabei, dass die Endanwender nicht technische Funktionen bewerten, sondern das Look and Feel der Software. In der Praxis hat sich gezeigt, dass es am besten ist, wenn der mögliche Anbieter bestimmte Prozesse in der Software vorführt oder – noch besser – die Endanwender diese Prozesse für eine begrenzte Zeit selbst ausprobieren können. Finden sie sich allein und ohne Unterstützung zurecht, kann man zu Recht sagen, dass die Software gut bedienbar ist.
4. Bewertung der Benutzerfreundlichkeit: Lösungen mit guter Benutzerfreundlichkeit lassen sich wie Amazon oder Facebook ohne Online-Hilfe oder fremde Unterstützung bedienen. Das ist besonders wichtig bei Prozessen, in denen der Endanwender die Software nicht täglich nutzt (und daher vergessen kann, wie die Bedienung funktioniert). Stellt der Softwareanbieter die Lösung vor, sollte man nur bewerten, was man tatsächlich sieht, und nicht davon ausgehen, dass der Anbieter „das schon kann“. Denn die Frage ist nicht, ob der Anbieter einen bestimmten Prozess unterstützt, sondern wie einfach diese Prozessunterstützung für den Endanwender ist. Die meisten Einkaufslösungen am Markt haben bereits BPM-Funktionen integriert (Business-Process-Management-Lösungen bilden Workflows sehr generisch ab), mit denen sich fast jeder Prozess abbilden lässt. Die Bedienung ist aber oft so kompliziert, dass der Prozess später in der Praxis nicht genutzt wird – was natürlich vermieden werden muss. Zudem sollten auch Erstellung und Pflege dieser Workflows getestet und bewertet werden, denn nicht nur die Benutzerfreundlichkeit für den Endanwender, sondern auch für Key User und Projektleitung muss bewertet werden. Kann der Kunde Funktionen nicht einfach selbst pflegen, sondern braucht immer einen externen Partner, steigen die Kosten im laufenden Betrieb deutlich (was sich wiederum erheblich auf Projektkennzahlen und ROI auswirkt).
5. Bewertung der Schnittstellen: Dieser Punkt hat zwei Komponenten, nämlich die Schnittstellen zu externen Systemen (wie ERP-Systemen) und die internen Schnittstellen (in der Anwendung selbst). Schnittstellen zu externen Systemen sollten so weit automatisiert und standardisiert sein, dass doppelte Eingaben vermieden werden. Schnittstellen über APIs (Application Programming Interfaces) sind vorzuziehen; gibt es keine API-Schnittstellen, kann auch RPA (Robotic Process Automation) in Betracht kommen. Die „internen“ Schnittstellen werden oft unterschätzt und sind deshalb eine Hürde im Projekt. Viele Anbieter haben ihr Produktportfolio durch Zukäufe erweitert, und diese Zukäufe sind oft unzureichend integriert. Das führt zu einer anderen Benutzeroberfläche oder komplexen Datensynchronisationen, was sich oft sehr negativ auf die Benutzerfreundlichkeit für den Endanwender und damit auf die Nutzerakzeptanz auswirkt.
6. Eigene interne Projektverantwortliche: Damit kommen wir zum nächsten Punkt, den internen Verantwortlichen. Größere Unternehmen haben eigene Teams für Tools & Prozesse oder sogar sogenannte Centers of Excellence (CoE), die sich laufend mit Prozessverbesserungen und Tooleinführungen beschäftigen. Gibt es ein solches größeres, erfahrenes Team nicht, muss vermieden werden, dass der Projektverantwortliche neu im Unternehmen ist und die internen Prozesse und Endanwender nicht kennt – das kann zu schwierigen Projektsituationen führen. Da eine direkte Diskussion zwischen Toolanbieter und Endanwendern vermieden werden sollte, muss die Projektleitung die eigenen Prozesse auf die Möglichkeiten des Toolanbieters abbilden und den internen Veränderungsprozess nicht nur begleiten, sondern auch verantworten. Um mit den Endanwendern diskutieren zu können, inwieweit eine Prozessänderung sinnvoll ist oder nicht, ist die Kenntnis der internen Prozesse unerlässlich.
7. Prozesse neu gestalten und die Möglichkeiten des Anbieters berücksichtigen: Jeder etablierte Toolanbieter am Markt kann einen bestimmten Prozess einfach und schlank oder kompliziert abbilden. Projekte, bei denen der Toolanbieter anbietet, alle Kundenanforderungen abzubilden, sind oft nicht effektiv, weil sie sehr lange dauern und die Projektbudgets sprengen. Wichtig sind hier Projektleiter auf Seiten des Toolanbieters, die aus ihrer Erfahrung heraus auch „Nein“ zu Kundenanforderungen sagen, und Projektleiter auf Kundenseite, die dieses „Nein“ auch akzeptieren.
8. Kurze Projektlaufzeiten: Die Projektdauer ist ein oft unterschätztes Kriterium für die Nutzerakzeptanz. Projekte, die länger als 6 Monate dauern, sind oft kritisch, weil der positive Spirit verloren geht. Projekte, die länger als 12 Monate dauern, sind oft nicht erfolgreich, weil niemand mehr an den Erfolg glaubt und man sich in endlosen Diskussionen verliert. Wichtig ist, das Projekt in mehrere Teilschritte zu gliedern und mit dem Team zu beginnen, das den Veränderungsprozess am ehesten unterstützt. Das ist erfolgversprechender als ein Rollout, der mit der größten Warengruppe oder der größten Region beginnt. Die erfolgreichsten Projekte werden heute agil umgesetzt, also in kleinen Iterationsschleifen: Man startet mit einem MVP (Minimum Viable Product), nutzt diese MVP-Variante mindestens 3 Monate tatsächlich und plant die nächste Optimierungsschleife erst nach Ablauf dieser 3-monatigen Lernkurve.
9. Eigener Support durch interne Mitarbeitende (z. B. das CoE-Team): Besonders in der Anfangsphase direkt ab dem Go-live sollte ein internes Supportteam bereitstehen, unterstützt durch externe Hypercare. Der Fokus sollte auf kurzen Reaktionszeiten liegen, denn gerade zu Projektbeginn ist es wichtig, dass Endanwender schnell Rückmeldung bekommen. Bekommen sie in dieser Phase keine Unterstützung, nutzen sie das Tool nicht und bilden sich sofort eine negative Meinung, auch wenn diese nur auf Unwissen beruht. Diese negative Stimmung lässt sich später nur schwer in einen positiven Spirit verwandeln.
10. Externe Projektunterstützung durch Personen, die solche Projekte bereits erfolgreich umgesetzt haben, kann in vielerlei Hinsicht äußerst hilfreich sein. Gemeint sind hier nicht typische Beratungsunternehmen, sondern ehemalige Einkaufsleiter, die in ihren eigenen Unternehmen bereits erfolgreich Projekte etabliert haben und nicht nur die technische Seite, sondern auch Stakeholdermanagement und Projektmarketing sehr gut kennen. Der Vorteil solcher Personen ist, dass sie kritische Fragen leichter stellen können und im Change-Management-Prozess niemandem wirklich verpflichtet sind (außer dem Projekterfolg). Externe Berater genießen bei den Nutzern den Ruf von Experten, denen man vertrauen kann, die viele verschiedene Szenarien gesehen haben und neue Ideen und Methoden einbringen können. Das hat den weiteren Vorteil, dass das interne Team nicht mehr alles selbst erfinden muss, sondern auf Erfahrungen in Form von Vorlagen zurückgreifen kann.
11. Berücksichtigung von Anforderungen der Endanwender nur im Rahmen der zu Projektbeginn definierten Kennzahlen: Entstehen während des Projekts neue Anforderungen von Kunden oder Endanwendern, sind diese an den zu Projektbeginn definierten Kennzahlen zu messen. Wie ist das zu verstehen? Bei neuen Anforderungen sollte geprüft werden, ob sie die Kennzahlen wesentlich beeinflussen; andernfalls sollten sie abgelehnt werden, da sie nur zusätzlichen Aufwand in der Projektumsetzung ohne großen Nutzen bedeuten. Es ist normal, dass im Projekt zusätzliche Anforderungen auftauchen, die zu Projektbeginn nicht bekannt waren oder unzureichend kommuniziert wurden. Besonders wenn diese Anforderungen Sonderprozesse betreffen, die nur in 10 % oder 20 % der Fälle vorkommen, lässt sich eigentlich leicht berechnen, ob ihre Umsetzung die Projektkennzahlen wesentlich beeinflusst oder nicht. Ein Beispiel: Genehmigungsprozesse im eProcurement haben oft komplexe Ausprägungen, doch nur sehr wenige davon schaffen tatsächlich Mehrwert – sie bilden lediglich bestehende Berichtslinien ab.

Wie sichert man die Nutzerakzeptanz langfristig?

Software lässt sich nur nachhaltig einführen, wenn die Nutzer selbst den Nutzen der Lösung erkennen und vorantreiben. Um den Nutzen belegen zu können, sollten Kennzahlen in regelmäßigen Abständen gemessen und intern kommuniziert werden, denn diese Kennzahlen sind unabhängig vom „Gefühl“ der Nutzer, ob die Software einen Mehrwert bietet oder nicht. Eine Kommunikation auf Basis klarer Fakten trägt meist erheblich zur internen Meinungsbildung bei.

Wichtig ist auch die interne Unterstützung durch Nutzer, die mit Veränderungsprozessen weniger Probleme haben und IT-affin sind. Indirekt ziehen diese Mitarbeitenden die anderen mit, da sie mit der steigenden Nutzung auch einen „Proof of Concept“ liefern, dass die einst geplanten Einsparungen oder Kennzahlen tatsächlich erreicht werden können.

Das Wichtigste in Kürze:

Nutzerakzeptanz ist nicht nur eine Frage der Benutzerfreundlichkeit der Software und der Unterstützung der Endanwender bei der richtigen Bedienung, sondern eine Frage des richtigen Change Managements.

Die interne Projektleitung ist für mindestens 50 % des Projekterfolgs verantwortlich, da sie für Projektmarketing, Projektkennzahlen, Projektdauer und den Umfang des Change Managements zuständig ist.

Die Benutzerfreundlichkeit einer Software sollte für die umzusetzenden Prozesse vorab im Detail geprüft werden. Die Endanwender müssen in diese Prüfung eingebunden werden, und die internen und externen Schnittstellen und ihr Einfluss auf die mögliche Nutzerakzeptanz müssen immer bewertet werden.

Externe Experten können den Erfolg erheblich beeinflussen, indem sie interne Diskussionen beschleunigen, den Projektaufwand senken und die Nutzerakzeptanz durch die richtige interne Kommunikation und Schulung erhöhen. Als Beispiel nennen wir Jacob Gorm Larsen, ehemaliger Director of Digital Procurement bei Maersk und Gründer von Moneyball CPH, oder Nico Bac, Senior Director Purchasing bei P&G und Gründer von Digital Procurement Now, die genau diese Erfahrung haben.