Checkliste für IT-Projekte

Projekt-Neustart nach dem Scheitern

24.08.2010 von Christiane Pütter
Ein CIO stattet Außendienstler mit GPS-fähigen Endgeräten aus. Die erwarteten Vorteile blieben aus. Er hatte zu wenig mit den Leuten über ihren Arbeitsalltag gesprochen. Erst eine Computer-Simulation brachte Erfolg.
Ganz einfach: Damit IT-Projekte nicht scheitern, sollten die Anforderungen der Anwender richtig eingeschätzt werden.
Foto: MEV Verlag

Es hätte so schön sein können: Der COO (Chief Operating Officer) eines großen US-Unternehmens wollte den technischen Außendienst durch Automation unterstützen und setze sich dafür mit der IT zusammen. Gemeinsam suchte man ein Terminplanungs- und Dispatching-System aus, verteilte GPS-fähige Handhelds unter den Service-Technikern und schulte Techniker wie Dispatcher monatelang im Umgang mit dem neuen System. Doch das Projekt scheiterte, wie ein Report von McKinsey beschreibt.

Scheitern heißt: Die Außendienst-Mitarbeiter steigerten ihre Produktivität entgegen aller Erwartungen nicht. Die Kunden erhielten auf ihre Anfragen auch nicht schneller Antwort als zuvor. Was die Erfahrungen der Endnutzer mit der neuen Anwendung betrifft, waren die Meinungen gespalten: Die einen freuten sich über weniger Administrations-Aufwand, die anderen klagten, das System habe mit ihrem Arbeitsalltag nichts zu tun. Obendrein sei es aufwändig.

COO und CIO mussten also von vorn anfangen. Beim Neustart machten sie es schlauer: Sie suchten sich einen einzelnen Bereich heraus und beschlossen, die Software vor einem großen Roll-Out zu testen. Am Rechner simulierten sie Abläufe und mögliche Veränderungen durch Automation.

Dabei zeigte sich, dass die 20 beobachteten Außendienstmitarbeiter zum Beispiel kein GPS brauchen. Selbst dann, wenn sie in den Stammgebieten von Kollegen aushelfen, weil dort Not am Mann ist, kennen sie die Gegend gut genug. Das war denn auch einer der Punkte gewesen, der die Anwender genervt hatte.

Die IT verstand, dass das neue System beim ersten Versuch zu viele Funktionen angeboten hatte. Infolgedessen blockten manche Anwender - trotz der langen Schulung - ab. Wichtige Informationen, zum Beispiel über die unterschiedlichen Skills der einzelnen Service-Techniker, konnten daher gar nicht genutzt werden.

Die Anfangsfehler in diesem Musterfall laufen letztlich darauf hinaus, dass das System zu wenig über die beteiligten Menschen wusste. Die IT-Mitarbeiter hatten sich kaum mit den Außendienstlern über ihren Alltag unterhalten. Das Projekt war an mangelnder Kommunikation gescheitert.

Akzeptanz trotz Kontrollverlust

Durch die Versuche mit der Computersimulation konnten CIO und COO solche Schwierigkeiten beheben. Beispiel Terminplanung: Als die Anwendung verbessert und Termine automatisiert vergeben wurden, brauchten die Außendienstler nicht mehr so viele Überstunden zu machen. Damit wuchs die Akzeptanz der Lösung - auch, wenn die Service-Techniker Kontrolle über ihre Terminpläne abgeben mussten.

Nach Darstellung von McKinsey stieg die Produktivität der Außendienst-Mitarbeiter. Sie stellen nun ein Fünftel mehr Aufträge pro Monat fertig. Das Unternehmen konnten ausgelagerte Arbeiten ins Haus zurückholen und spart mehrere zehntausend US-Dollar jährlich.

Der größte Vorteil aus Sicht des CIOs besteht darin, dass sein Team Algorithmen aus dem Test-Projekt für den großen Roll-Out nutzen konnte. Das sparte Zeit und Kosten.

McKinsey leitet aus diesem Beispiel eine Checkliste für CIOs und COOs ab. Wer Prozesse automatisieren will, sollte folgende Punkte klären:

1. Geeignete Bereiche identifizieren: Ob Lieferkette, Back Office, mobile Mitarbeiterschaften oder zentralisierte Teams - Entscheider müssen genau untersuchen, wo die IT Wettbewerbsvorteile generieren kann.

2. Erfolg definieren: Vor dem Start muss klar sein, wie die IT helfen soll, Produktivität und Service Levels zu steigern. Alle Beteiligten müssen wissen, welche Veränderungen Automation mit sich bringt.

3. Nicht ohne Piloten starten: Die Menge an Features macht ein System nicht zu einem guten System. Die Software muss zu dem Unternehmen und den Anwendern passen. Entscheider sollten ein Pilot-Projekt ausführen, bevor sie einen großen Roll-Out starten.

Der Pilot kann mit SaaS starten

4. Das Budget gering halten: Mc Kinsey rät, beim Pilot-Projekt möglichst viel mit kostengünstigen Modellen wie Software-as-a-Service (SaaS) zu arbeiten.

5. Nur implementieren, was nötig ist: Die Ergebnisse des Pilot-Projektes dienen als Entscheidungsgrundlage dafür, welche Funktionen das Unternehmen wirklich braucht.

6. Immer auf die Endanwender achten: Automation von Prozessen ist immer mit Change verbunden. Mit einmaligen Trainings ist es oft nicht getan. CIOs und COOs müssen sichergehen, dass die potenziellen Nutzer verstehen, warum und wie sie welche Systeme anwenden sollen.