Quick'n'Clever Blog

Software ist zu einem der wichtigsten Produktionsfaktoren in Unternehmen und Organisationen geworden. Entsprechend hohe Bedeutung hat die Evaluation und Auswahl der am Markt angebotenen Lösungen. Betrachtet man die Zahl an (Miss-)Erfolgen von Software-Einführungen, könnte man allerdings zu einem anderen Schluss gelangen.
Was läuft schief bei der Spezifikation und Auswahl von Software? Was ist zu beachten, damit das Werkzeug seine Zielsetzung – einen substanziellen Beitrag an den Erfolg des Unternehmens zu leisten – zu erfüllen vermag? Der folgende Beitrag ist die Zusammenfassung eines umfassenderen Artikels zum Thema.

Frustration nach der Software-Einführung – warum?

Wie kommt es, dass Unternehmen und Anwender nach der Einführung neuer Software-Lösungen ihre Erwartungen immer und immer wieder enttäuscht sehen? Was läuft schief? Woran scheitern diese Projekte und wer macht dabei was falsch? Warum zählt das unten geschilderte Szenario nicht zu den seltenen Betriebsunfällen, sondern zur Tagesordnung?

Gut gemeint…

Anwender und unterstützende IT-Fachkräfte meinen es gut, wenn sie Pflichtenhefte aufstellen. Vielfach leider nur zu gut. Nicht zuletzt Testberichte von Experten werden studiert, in denen verschiedene Lösungen verglichen und die neusten Funktionen angepriesen werden. Und schon stehen Features auf der Liste der Anforderungen an das neue System, die hier eigentlich nichts zu suchen hätten, da sie dem Zweck des neuen Systems – einen Beitrag an die Unternehmensziele zu leisten – überhaupt nicht dienen. Denn selten haben die Tester die Software über eine längere Zeit unter realitätsnahen Bedingungen selber eingesetzt. Die Folge: Tools, die auf das Wesentliche fokussieren und dadurch besonders erfolgversprechend sind, schaffen es häufig nicht einmal auf die Longlist. Da leider nur selten Praxis-Härtetests über den Kauf einer Lösung entscheiden, trimmen vorab potente Hersteller ihre Lösungen auf überzeugende Wirkung bei der Demo und hohe Punktzahl beim Vergleichstest. Die Praxistauglichkeit bleibt dabei auf der Strecke. Denn was bei der Demo leicht bedienbar, durchdacht und sexy wirkt, kann sich in der Realität als das pure Gegenteil herausstellen.

Am Beispiel Projektportfolio-Management-Systeme

Ein Software-Produkt im Bereich Projektmanagement und Projektportfolio-Management ist dazu da, die Erfolgschancen von Projekten zu erhöhen bzw. das Projektportfolio so zu gestalten und zu steuern, dass dieses den grösst möglichen Beitrag an den Unternehmenserfolg leistet. Jede Funktion der Software ist letztlich diesem Ziel unterzuordnen. Entscheidend sind dabei die folgenden Fragen:

• Wie wahrscheinlich ist es, dass die Funktion genutzt wird?
• Welchen konkreten Beitrag vermag die Nutzung der Funktion an den Erfolg des Projektes bzw. an das Unternehmen zu leisten?
• Mit welchem Aufwand / wie effizient lässt sich diese durch den normalen User nutzen?
• Welche Risiken könnte der Einsatz der Funktion bergen (z.B. den Verzicht auf persönliche Kommunikation), welche Nebenwirkungen könnte er auslösen?

Kriterienkataloge, wie sie in Vergleichstests und einschlägigen Studien für professionelle Projektmanagement-Systeme zum Einsatz kommen, werden im Folgenden unter diesen Aspekten einer kritischen Analyse unterzogen. Der Fokus liegt dabei auf dem Projektportfolio-Management (PPM).

• Projektbewertung und -priorisierung. Die Bubble Charts des PPM-Tools mögen ansprechend aussehen. Wenn es jedoch darum geht, die Auswertungen an die spezifischen Bedürfnisse und Vorstellungen des Managements anzupassen, dürfte so viel Zeit in das Customizing fliessen, dass Excel die bessere Wahl gewesen wäre.
• Ressourcenreservationen. Die Reservation von Ressourcen durch den Projektleiter mit automatischer Information des Linienvorgesetzten steht der Kommunikation zwischen den beiden Playern im Weg. Die Qualität der Planung wird in aller Regel besser, wenn die Planungsdaten nach der persönlichen Abstimmung mit dem Projektleiter durch die Linie erfasst werden, da die Ressourcenplanungshohheit bei den Linienmanagern liegt.
• Automatischer Belastungsabgleich. Er ist ein Paradebeispiel für Fehlleitungen durch solche “Evaluationshilfen”. Diese Anforderung lässt sich aufgrund der Komplexität der Aufgabenstellung mittels einer Software praktisch nicht erfüllen¹. Sie suggeriert eine Entscheidungshilfe, die in Wirklichkeit eher eine Hilfe zur Fehlentscheidung ist.
• Weiter zu erwähnen sind quantifizierte Risikoanalysen, .Stakeholder-Analysen, das Management von Change Requests oder auch CRM-Funktionen, die Kampagnen und E-Mailings unterstützen. Solche Aufgaben werden durch die Hausmittel der Officepalette oder dedizierte Lösungen meist wesentlich überzeugender und/oder mit weniger Aufwand unterstützt als mit der lustlos implementierten Nebenfunktion im PPM-Tool.
• Integriertes System. Eine besonders zentrale Thematik ist die starre Kopplung von Einzelprojektplanung und Projektportfolio-Management im selben System, wie sie von einzelnen Theoretikern auch heute noch propagiert wird. Dabei wird die Verantwortung für die Ressourcenplanung dem Projektleiter zugeordnet, und diese erfolgt auf Vorgangsebene. Dass die Anwender dieses integrierten Ansatzes zuerst die Ernüchterung, dann den Absturz erleben müssen, bevor sie realistische Wege beschreiten, zählt zu den Klassikern unter den Evaluationsunfällen bei Projektmanagement-Systemen (vgl. dazu das Konzept der drei Welten im Whitepaper² des Autors).

Die Verantwortung der Experten

Autoren von Vergleichsstudien argumentieren, es sei Sache des künftigen Anwenders, aus ihren Berichten die für sie relevanten Kriterien herauszufiltern und diese ihren Bedürfnissen entsprechend zu gewichten. Das ist nur teilweise korrekt. Denn dabei wird vorausgesetzt, dass die Organisation, die sich auf die Suche nach einem neuen System macht, weiss, welche Bedeutung jede einzelne der unzähligen beschriebenen Funktionen für sie hat. Das trifft jedoch in den wenigsten Fällen zu. Häufig wird Software für Funktionen evaluiert, die professionelles Spezialwissen erfordern, das vielfach sogar in grossen Unternehmen fehlt. Und auch der Berater tappt häufig in dieselbe Falle wie der Anwender, da er sich bei seinen Empfehlungen auf die einschlägigen Studien abstützt. Experten sollten es als ihre edelste Aufgabe sehen, den potenziellen Anwender von kaum relevanten oder gar kontraproduktiven Funktionen fernzuhalten. Es macht keinen Sinn, wenn neun von zehn Anwender die mühsame Erfahrung machen müssen, dass die Bewertung des Projektportfolios mit der integrierten Funktion des PPM-Tools mehr Aufwand erfordert und ein schlechteres Resultat produziert als die bisher genutzte Excel-Tabelle. Die unkommentierte Bewertung einer umfangreichen Kriterienliste ist deshalb nicht nur wenig hilfreich, sie ist gefährlich.
Meist fehlen in Studien und Testberichten zu Business Software in der Regel auch brauchbare Anhaltspunkte zur Nutzungseffizienz. Im praktischen Einsatz ist entscheidend, wie direkt und schnell Eingriffe im System möglich sind. Studien testen an solchen zentralen Fähigkeiten meist vorbei.

Was ist gute Software?

Die Qualität einer Software-Lösung misst sich an der Frage, mit welchem Aufwand durch den Einsatz des Systems welcher Nutzen für das Unternehmen oder die Organisation erzielt werden kann. Relevant ist hierbei nicht der Anfangsnutzen, sondern der Nutzen über die gesamte Dauer des Betriebs. Dieser drückt sich in besseren Entscheiden, geringerem Aufwand, besseren sachlichen Resultaten, aber auch zusätzlich generierten Erträgen, gewonnenen Kunden etc. aus. übersteigt der Nutzen nicht klar den Aufwand, muss die Systemeinführung als Misserfolg gewertet werden.
Auch wenn sich Qualität von Software nicht objektiv messen lässt – die Fragen in der Box können als Gradmesser für den Nutzen dienen, den eine bestimmte Softwarefunktion stiftet.

Was ist zu tun?

Vergleichsstudien und Testberichte können wertvolle Anhaltspunkte bei der Evaluation einer Software-Lösung liefern. Mehr nicht. Um bei der Evaluation und Einführung von Software-Anwendungen Flops zu vermeiden, bieten sich ergänzend oder alternativ die folgenden Möglichkeiten an:

• Besprechung mit Referenzanwendern. Hier ist allerdings grosse Vorsicht geboten. Die Hersteller verstehen sich darin, die “richtigen” Kunden auszuwählen, wenn es darum geht, ihr System im besten Licht erscheinen zu lassen.
• Präsentation durch den Hersteller aufgrund präziser Aufgabenstellungen und Fragen. Dieses Vorgehen eignet sich sehr gut, die kritischen Aspekte bezüglich Funktionalität und vor allem deren Implementation aufzudecken. Vorausetzung ist, dass der künftige Anwender bei der Definition seiner Anforderungen die in diesem Beitrag beschriebenen Fehler vermeidet.
• Laboranalysen. Hier werden repräsentative, praxisrelevante Aufgabenstellungen vorgegeben, die durch die späteren Anwender zu lösen sind. Dies erfordert einigen Aufwand, kann sich bei grösseren Anschaffungen indessen lohnen.
• Pilotbetrieb. Nichts kommt bezüglich der Aussagefähigkeit an den Test einer oder weniger Lösungen durch den Kunden mit dem realen Tool unter realen Bedingungen heran. Dabei sind repräsentative Anwender einzuladen, was auch solche einschliesst, die zu dieser Rolle überredet werden müssen.
• Eigener Kriterienkatalog. Die Anforderungen und der Kriterienkatalog sollten aufgrund der (geplanten oder schon bestehenden) Nutzung der Funktionen im realen Betrieb abgeleitet werden. Ein Pilotbetrieb kann diesen Prozess ideal unterstützen.
• Berater sollten sehr sorgfältig ausgewählt werden. Kompetenzen und Haltung des Beraters sind an den in diesem Beitrag aufgezeigten Zusammenhängen kritisch zu prüfen.
• Benutzerdokumentation. Der Kunde sollte die zentralen Punkte für eine erfolgreiche Anwendung der Software in einer knappen Dokumentation zusammenstellen. Diese soll nicht nur Zweck, Einsatzmöglichkeiten und die wichtigsten Handgriffe beinhalten, sondern vor allem auch praktische Hinweise und Hilfen zu einer sinnvollen Nutzung bieten. Dazu gehört auch, den User davor bewahren, fragwürdige Funktionen zu nutzen.

Werden diese Grundsätze beachtet, ist die Wahrscheinlichkeit für erfolgreiche Software-Einführungsprojekte massiv höher als bei der Beschränkung auf Vergleichstests, Demos und Expertenmeinungen.

Fazit

Der Schaden, den fehlgeleitete Software-Evaluationen in Unternehmen, Organisationen und ganzen Volkswirtschaften anrichten, ist immens. Einen erheblichen Anteil an dieser Situation haben fragwürdige Studien und Vergleichstests, die an den wahren Bedürfnissen der Anwender vorbeizielen und die Software-Hersteller dazu animieren, bei der Weiterentwicklung ihrer Lösungen die falschen Prioritäten zu setzen.
Die Software-Industrie darf sich davon nicht beirren lassen. Sie muss sich den Anwendernutzen als den zentralen Massstab für ihr Handeln auf die Fahne schreiben (vgl. Kasten). Auf eine kurze Formel gebracht, ist Software-Qualität die Summe des Nutzens, den alle implementierten Funktion erzielen minus die Belastungen, die Unnötiges und Fragwürdiges dem Anwender auferlegen.

Die Fachmedien müssen das Gewicht sehr viel mehr auf die Kernfunktionen legen sowie darauf, wie diese implementiert sind, statt sich mit News über neue fantastische Features zu übertrumpfen, die kaum ein Anwender je nutzen wird. Dies ist nicht nur für den Anwender wichtig. Ebenso geht es darum, der Software-Industrie, nicht die falschen Entwicklungsanreize zu liefern.

Wer für die Einführung einer neuen Software-Anwendung verantwortlich ist, möge die Anregungen nutzen, um bei der Vorauswahl und Evaluation von Software-Systemen die richtigen Entscheide zu fällen.

Quellen und Vertiefungsmöglichkeit

¹ Fachbuch Kompetenzbasiertes Projektmanagement (PM3) der GPM Deutsche Gesellschaft für Projektmanagement und spm swiss project management association, Kapitel 1.12 Ressourcen, Heinz Scheuring, ISBN 9783-924841-40-9.

² Whitepaper Projektmanagement-Software: vom Albtraum zum Erfolg von Heinz Scheuring, 2013 (Informationsmaterial auf www.ressolution.ch)

Lesen Sie den ausführlichen Artikel zu diesem Thema. Hier können Sie diesen herunterladen:
Software Evaluation: Mit Vollgas Ins Verderben