So hat der CRM-Rollout Erfolg – Planung und  Implementierung

Ohne das System auch aus administrativer Sicht ganz genau zu kennen, kommt es schnell zur falschen Einschätzung und somit auch zur fehlerhaften Implementierung von Anforderungen. In vielen Fällen gibt es Anforderungen, die durch die Standard-Administration oder Set-up des Systems mit nur ein paar Klicks umgesetzt werden können. Ist dies aber nicht bekannt, werden unnötig viele Ressourcen in die Programmierung der Anforderung gesteckt, die letztendlich möglicher Weise sogar so implementiert ist, dass andere Funktionalitäten dadurch be- oder verhindert werden. 

Alle Projektmitglieder sollten dazu verpflichtet sein, je nach Rolle, an Trainings zu dem ausgewählten System teilzunehmen, um bereits vor Start der Implementierung ein Basis-Systemwissen – auch aus administrativer Sicht – sicherzustellen. Somit kann gleich zu Beginn unnötiger Mehraufwand vermieden werden. Um genügend Systemwissen sicherzustellen, empfiehlt es sich bei komplexeren Rollouts zusätzlich einen Mitarbeiter der Firma des gewählten CRM-Systems an Bord zu holen, auf den bei Fragen stets zugegangen werden kann und der bei der Anforderungsbewertung unterstützt.

Innerhalb des Implementierungsprozesses werden durch die einzelnen Stakeholder, beispielsweise Fachbereiche, Marktverantwortliche, Endanwender, die benötigten Anforderungen zur Systementwicklung eingesteuert. Bestehen für das Anforderungsmanagement keine klaren Regeln erfolgt ein unkoordiniertes und wildes Einsteuern durch die einzelnen Stakeholder. Zusätzlich kann es innerhalb der Anforderungspriorisierung zu kurzfristigen Änderungen kommen, wenn keine klaren Regeln und Verantwortlichkeiten definiert sind. Diese Entwicklung führt früher oder später nicht nur zu einer Überforderung und Frustration des Entwicklungsteams, sondern auch zu einer Unzufriedenheit des Anforderers (Requester), da keine zeitgerechte Umsetzung der angeforderten Funktionalitäten erfolgt.

Um dies zu vermeiden muss eine zentrale Requirements Management Funktion implementiert werden, die den Input der Stakeholder qualifiziert, quantifiziert und priorisiert. Des Weiteren machen viele unserer Kunden gute Erfahrungen mit dem "Kernel-Ansatz", d.h.: 80 Prozent der Systemfunktionalitäten sind standardisiert und somit nicht veränderbar. Wohingegen die restlichen 20 Prozent Raum für markt- und anwenderspezifische Funktionalitäten lassen. Dafür ist natürlich ein gewisses Grundverständnis der User-Bedürfnisse und Anforderungen an das System nötig. Denn auch bei den standardisierten Systemfunktionalitäten muss sichergestellt sein, dass diese die wichtigsten User Stories – die wichtigsten Features aus End-User Sicht – abdecken.

Das agile Requirements Management mit seinen Methoden bietet hierfür vielversprechende Ansätze. Diese helfen, beispielsweise durch User Story Writing, Requirement Breakdown und Vorabdefinition von Acceptance Criteria, nicht nur die Anforderungen verständlich zu beschreiben, sondern durch agile Priorisierungstechniken (z.B. Magic Prioritization) und „Definition of Ready“ auch Entscheidungen bzgl. Umsetzung und dessen Planung oder Nicht-Umsetzung zu treffen.

Das Einbeziehen der Stakeholder folgt der Devise, das goldene Mittelmaß zu finden: Auf der einen Seite sind die Stakeholder aus den verschiedenen betroffenen Bereichen einzubeziehen, auf der anderen Seite, sollen diese nicht den gesamten Prozess durch zu viele Anforderungen sprengen. Auch spielt hier das Erwartungsmanagement eine entscheidende Rolle, da durch zu viele unterschiedliche Anforderungen der Requirements-Management-Prozess stark beansprucht wird und nach der Priorisierung die Umsetzung erst später oder gar nicht erfolgen kann. 

Dies muss innerhalb des Erwartungsmanagements als Teil von Change Management an die Stakeholder kommuniziert werden. Sprich, es ist für die Anforderer wichtig, den Requirements-Management-Prozess zu kennen, zu wissen wie Anforderungen adäquat gestellt werden und Transparenz über die Bewertung und Timeline zu bekommen. Wenn Anforderer nur zufällig herausfinden, dass ihre Funktionalitäten gar nicht, unzureichend oder zu spät implementiert werden, sinkt die Motivation für das Projekt und folglich die Nutzung des Systems. Zusätzlich die Vollständigkeit bei der Auswahl der Stakeholder ein kritischer Erfolgsfaktor, da Exkludieren bzw. Vergessen wichtiger Stakeholder im Nachhinein zu schweren Folgen führen kann. Oft wird der Fehler gemacht, dass Stakeholder, die entweder nur selten oder erst zu einem späteren Zeitpunkt nach Einführung des Systems mit diesem arbeiten, nicht mit in die Definition der Anforderungen einbezogen werden. Allerdings hängen die benötigten Funktionalitäten oft auch mit den Kernfunktionalitäten der Hauptnutzergruppe zusammen und somit können folglich hohe Kosten aufgrund von benötigten ad hoc Umprogrammierungen entstehen.

Deshalb empfehlen wir beispielsweise direkt zu Beginn des Projektes in einem interaktiven Workshop mit verschiedenen Projektmitgliedern eine Stakeholder Map zu definieren. Mithilfe dieser Stakeholder Map können unterschiedliche Stakeholder Gruppen identifiziert und folglich die jeweiligen Kommunikationsmaßnahmen in einer Communication Roadmap definiert und terminiert werden. Durch stetiges Informieren und ggf. auch Einbeziehen der jeweiligen Stakeholder wird das Risiko der Projekt-Ablehnung erheblich verringert.

Viele komplexe Systeme überzeugen nicht unbedingt mit einer attraktiven und intuitiven User Interface (UI). Neue Nutzer sind somit oft schon beim Öffnen des Systems überfordert und unmotiviert. Manchmal sind es jedoch Kleinigkeiten, die für mehr Akzeptanz sorgen. So sollte zum Beispiel möglichst die Corporate Identity des Unternehmens inklusive Logo verwendet werden, damit sich die Nutzer schneller mit dem neuen System identifizieren. In vielen Fällen kann die Systemkomplexität ohne großen Aufwand reduziert werden. Hier muss zunächst nur mal hinterfragt werden, ob Klick-Pfade optimiert oder die UI verschlankt werden können. Es sollte nur zu sehen sein, was auch wirklich gebraucht wird. Oft kann somit z.B. ein drittes Adressfeld oder Ähnliches einfach ausgeblendet werden. Seltener auftretende Fälle und Funktionalitäten können für eine initiale Vereinfachung nach erfolgreichem Go-Live in Angriff genommen werden.

Wenn zudem noch gewisse kulturelle Aspekte für die intuitive Nutzung des Systems berücksichtigt werden, fällt es den Nutzern einfacher, sich mit dem System vertraut zu machen und es dementsprechend schneller effizient zu nutzen. Beispiele, wie die Tatsache, dass in Spanien die Hausnummer immer vor dem Straßennahmen, oder dass in den Niederlanden ein Namenszusatz wie "van" eingegeben wird, sind relevant für die korrekte Nutzung des Systems und somit auch förderlich für die Akzeptanz. 

Kennen wir das nicht alle? Gerade erst hat man an einer Excel-Schulung teilgenommen, die Formeln konnte man während der Übungen noch prima anwenden. Drei Wochen später starrt man auf die Excel-Tabelle und man weiß  nicht mehr wie die Formeln funktionieren. Kein Wunder, denn man hat die Formeln in den letzten drei Wochen ja auch nicht benutzt. Daher empfehlen wir, die Nutzer erst unmittelbar vor dem Go-Live auf das neue System zu schulen – zunächst erst die Basisfunktionen. Denn wie in der Excel-Schulung: Was vielleicht während des Trainings einfach erscheint, findet sonst, nach zu langer Zeit zwischen Schulung und Go-Live, beim Arbeiten mit dem System keine Anwendung mehr. Etwa eine Woche nach der Schulung hat man nur noch nur noch 20 Prozent des Wissens behalten.

Daher muss das Gelernte nicht nur wiederholt und angewendet werden, sondern sollten anspruchsvollere Funktionalitäten erst nach dem Go-Live geschult werden und zwar basierend auf dem Wissenstand und dem Arbeitsbereich der einzelnen Mitarbeiter oder der unterschiedlichen User-Gruppen. Unserer Erfahrung nach lernen die Nutzer eines neuen CRM-Systems die Funktionalitäten am besten und schnellsten durch das direkte Ausprobieren im System. Das klappt natürlich nur, wenn sie dadurch nichts "kaputt" machen können, sprich entweder in einer Testumgebung oder in der Produktivumgebung nur mit entsprechender Führung und idealerweise für Echt-Szenarien. Letzteres lässt sich spielend leicht mithilfe von "Digital Adoption Platforms", wie WalkMe.

Gerade haben die Nutzer verstanden, wie sie das neue System nutzen und dann wachen sie eines Morgens auf und es hat sich einiges im System verändert. Frustration und Ablehnungshaltung kehren zurück. Um dies zu verhindern, sollten Sie rechtzeitig neue Funktionalitäten von Releases kommunizieren und ggf. trainieren. Auch hier hilft eine WalkMe Integration. Funktionalitäten von neuen Releases werden hier rechtzeitig hinterlegt, sodass die Nutzer keinen Schreck bekommen. Im Gegenteil, dank WalkMe werden sie einfach direkt während der Nutzung des Systems durch die jeweilige neue Funktionalität geführt. Die Zeiten nach neuen Releases, in denen die Support Hotline überflutet wird, sind somit vorbei. Weitere Möglichkeiten für rechtzeitiges Kommunizieren der Neuerungen sind, je nach Umfang, beispielsweise Webinare, kurze How-to-Video, Info-E-Mails mit Kurzanleitungen und das Nutzen von "Change Agents" als Vermittler und Support vor Ort.

Durch unsere Partnerschaft mit WalkMe und unsere umfangreiche Erfahrung in System Rollouts und Change Management freuen wir uns, Sie bei Ihren Fragen und Problematiken beraten zu dürfen. Kontaktieren Sie uns gerne.