Vom elektronischen Berichtswesen zum echten Außendienststeuerungstool
24 Außendienstmitarbeiter. Vier Regionen. Vier Regionalleiter. Zwei bereits gescheiterte Berichtssysteme – und eine gerade fertiggestellte Software. Dazu mein bis dahin wohl schwierigstes Projekt, gemessen an den Widerständen.
Ausgangslage
Die Anwendung trug zwar den Namen Außendienststeuerung, wurde von vielen späteren Nutzern aber vor allem als neues Berichtssystem wahrgenommen. Genau das war das Problem: Es hatte bereits zwei gescheiterte Anläufe gegeben. Berichte wurden geschrieben, aber der Nutzen für die Menschen im Außendienst war kaum sichtbar.
Die Software war technisch weitgehend fertig, als ich das Projekt übernahm. Statt sie einfach auszurollen, wollte ich zunächst verstehen, wie ein Arbeitstag beim Händler tatsächlich aussieht und wo das System helfen – oder stören – würde.
Erst verstehen, dann ändern
Ich fuhr einen vollständigen Arbeitstag mit einem Außendienstmitarbeiter mit und führte anschließend Workshops in den Regionen durch. Widerstände wurden dabei nicht als Störung des Projekts behandelt, sondern als Information: Warum lehnen Nutzer etwas ab? Welche zusätzliche Arbeit entsteht? Welche Information fehlt ihnen selbst?
Aus dieser Perspektive wurde klar, dass Berichtswesen nur dann akzeptiert wird, wenn das System dem Außendienst gleichzeitig Arbeit abnimmt. Deshalb rückten Händlerdaten, aktuelle Kommunikation, Besuchshistorie, Kennzahlen und Vertretungsfähigkeit stärker in den Vordergrund.
Aus Berichtspflicht wird Arbeitsinstrument
Das Dashboard bündelte Informationen, die vor oder während eines Händlerbesuchs gebraucht wurden. Besuchsdokumentation und Berichtswesen konnten unmittelbar beim Kunden erledigt werden; zusätzliche Nacharbeit am Abend wurde reduziert. Auch Urlaubs- oder Krankheitsvertretungen wurden einfacher, weil der bisherige Stand nicht erst telefonisch rekonstruiert werden musste.
Ein weiterer Punkt war das Management: Ein System lebt nur, wenn auch die Führungsebenen es tatsächlich benutzen. Deshalb gehörte zur Einführung nicht nur Schulung, sondern auch die Veränderung von Informationswegen – weg von parallelen Telefonketten, hin zu einer gemeinsamen Informationsbasis.
Technik und Rollout
Die Anwendung musste auf der damaligen mobilen Infrastruktur flüssig funktionieren. 2G war deshalb ein echter technischer Maßstab. Ich koordinierte Anforderungen und externen Dienstleister, testete die Rollen und Rechte manuell aus verschiedenen Nutzerperspektiven und begleitete die fachliche Abnahme.
Nach einer Pilotphase in einer Region folgte der vollständige Rollout auf vier Regionen mit 24 Außendienstmitarbeitern und vier Regionalleitern sowie den übergeordneten Sales- und Managementfunktionen.
Was für mich der eigentliche Erfolg war
Der Projekterfolg bestand nicht darin, dass eine weitere Software installiert wurde. Entscheidend war, dass aus einer negativ besetzten Berichtspflicht ein Werkzeug wurde, das im Arbeitsalltag einen erkennbaren Nutzen hatte. Genau diese Art von Veränderung interessiert mich bis heute: Technik so zu gestalten und einzuführen, dass sie nicht nur funktioniert, sondern verwendet wird.