Ich persönlich war schon oft in Auswahlprozesse für Software involviert. Manchmal war die Entscheidung "Make or buy" noch gar nicht getroffen, manchmal ging es aber auch nur noch um die Auswahl eines konkreten Anbieters.
Ein solcher Prozess ist im Prinzip nichts Besonderes. Meist habe ich Folgendes gemacht: Ich habe die Anforderungen ermittelt, indem ich in Fachabteilungen gefragt oder die bisherige Lösung analysiert habe. Anhand dieser Analyse habe ich dann einen Kriterienkatalog erstellt, oftmals mit Soll-Kriterien, Kann-Optionen und Show-Stoppern. Wenn es noch weiter geht, werden diese auch mit einem Faktor gewichtet. Bei Software, die man im Unternehmenskontext einsetzt, kommt dann auch noch der potenzielle Aufwand für die individuelle Anpassung hinzu. Oft war an dieser Stelle gewünscht, auch einen Dienstleister zu evaluieren, der das Produkt entsprechend präsentiert. Manchmal sind es auch mehrere und ich habe einen regelrechten Pitch veranstaltet.
Wenn dieser Schritt abgeschlossen war, hat mein Kunde versucht, eine objektive Entscheidung zu treffen. Die Features in der Liste wurden mit der Gewichtung multipliziert und mit dem Preis des Produktes ins Verhältnis gesetzt. Der Aufwand der Anpassung wird mit dem Tagessatz des Dienstleisters multipliziert,anschließend wird noch die Wartung der ersten drei Jahre einkalkuliert.
Eine solche Bewertung ist prinzipiell kein schlechter Gedanke, man muss sich aber bewusst sein, dass hier Annahmen zugrunde liegen, die oftmals nicht zutreffend sind.
Bereits bei der Anforderungsanalyse muss man beachten, dass Mitarbeiter, besonders wenn sie lang im Unternehmen sind, gar keine anderen Prozesse kennen. Sie werden versuchen eine Software zu finden, die ihre bisherigen Prozesse (bzw. die ihrer Abteilung) besser abbildet. Damit unterliegen sie aber der Problematik, dass keine wirklich fundamentalen Verbesserungen erzielt werden können. Henry Ford wird (fälschlicherweise) das Zitat "Wenn ich die Leute gefragt hätte, was sie wollen, hätten sie gesagt: »schnellere Pferde«" zugeschrieben. Eine Software beinhaltet neben dem reinen Werkzeug auch immer Wissen über Prozesse. Ich versuche bei der Einführung neuer Software deswegen die Prozesse ebenfalls neu zu denken. Das geht oftmals mit organisatorischer Veränderung einher. Gerade in größeren, gewachsenen Organisationen ist das nicht einfach. Aber nur so kann neue Software wirklich ihr gesamtes Potenzial entfalten. Sprich: Der Kriterienkatalog, der in der klassischen Software-Evaluation aufgestellt wird, ist nicht komplett falsch, aber gerne unzureichend.
Ein weiterer Kritikpunkt der klassischen Anforderungsanalyse ist, dass ein statisches Bild vermittelt wird. Sie stellt lediglich die aktuellen Anforderungen dar. Wenn Arbeitsumgebungen sich aber immer schneller ändern, ändern sich auch die Anforderungen an Software. Einige Kriterien des ursprünglichen Anforderungskataloges sind bei der Inbetriebnahme oft schon überholt, andere sind neu hinzugekommen. Nun kann ich natürlich nicht sagen, welche Anforderungen in einem Unternehmen in drei Jahren bestehen werden, geschweige denn welche Software diese dann erfüllt. Daher schaue ich mir immer die vergangenen Versionen der Software an: Hier lässt sich oft ein roter Faden erkennen. Wie oft gab es Updates und in welchem Bereich, welche Funktionalität wurde ausgebaut, welche eher vernachlässigt? Letzteres ist für mich übrigens oft ein Pluspunkt, denn ein Produkt mit klarem Fokus ist meist deutlich hilfreicher als eines, das alles nur ein bisschen kann.
Der nächste Punkt ist die Usability (UX). Hier sind generelle Richtlinien schwer, aber ich versuche mir immer klarzumachen, wer wie mit der Software arbeiten muss. Sind es wenige Mitarbeiter, die dann aber viel Zeit damit verbringen? Dann ist eine umfangreiche Oberfläche, die aber sehr schnell viele Informationen und Funktionalität bietet, hilfreich. Wird die Software hingegen von sehr vielen Mitarbeitern, aber dafür nicht so oft verwendet, ist eher eine einfache "Schritt für Schritt"-Oberfläche sinnvoll. Hier versuche ich mich so gut wie möglich in den Anwender hineinzuversetzen. Wertvoll ist natürlich immer eine Demoversion. Wenn man diese nicht hat, können hier auch YouTube-Videos gut weiterhelfen. Ungern verlasse ich mich auf eine Live Präsentation des jeweiligen Anbieters. Die Szenarien hier sind oft künstlich optimiert und man bekommt eher einen Eindruck der Fähigkeit des Präsentierenden als der eigentlichen Software.
Worauf ich auch achte, sind offene Schnittstellen. Software muss heute vielfach mit anderen Systemen interagieren, deswegen werden offene Schnittstellen immer wichtiger. Insbesondere ein Application Programming Interface (API) oder ein Software Development Kit (SDK) ermöglicht es nicht nur dem Hersteller, sondern auch Drittparteien, Anpassungen und Ergänzungen vorzunehmen. Man bleibt hier unabhängig und kann entweder durch eigene Mitarbeiter oder externe Partner die Funktionalität realisieren, die man sich wünscht. Im Idealfall sind die Schnittstellen sogar als Open Source verfügbar. Hier geht es weniger um die Lizenz, die man ohnehin kaufen muss, sondern um die Tatsache, dass bei Open Source Schnittstellen oft viele Beispiele vorhanden sind, die als Musterlösungen dienen können. Dieses und die Tatsache, dass offene Lösungen auch viel einfacher im technischen Support sind, reduziert langfristig die Integrationsaufwände.
Zu guter Letzt sollte man auch prüfen, ob die Kultur und Philosophie des Herstellers zu den eigenen Prinzipien und Werten passt. Im Prinzip kauft man nur ein Produkt, allerdings geht man doch eine relativ langfristige Bindung ein. Zum einen schaue ich, ob die ethischen Werte mit den eigenen Unternehmenswerten vereinbar sind. Zum anderen ist aber auch das Verständnis von Zusammenarbeit wichtig. Wenn das eigene Unternehmen eher unbürokratisch auf Basis von Werten und Zielen geführt wird, wird man nicht erfolgreich mit einem Hersteller zusammenarbeiten können, der für jede Rückfrage oder potentiellen Bug einen fünfstufigen Prozess wünscht.
Unterm Strich wird jede eingeführte Software ein Teil der eigenen Wertschöpfungskette. Ich kann den Wunsch nach einer nüchternen, objektiven Betrachtung verstehen, aber Software wird nicht nur von Menschen gemacht, sondern auch von Menschen benutzt. Eine Software, die nicht die Akzeptanz der eigenen Mitarbeiter findet, wird auch dem Unternehmen nicht zum Erfolg verhelfen.
