Knappe eineinhalb Jahre vor Inbetriebnahme des Campus WU werden aktuell zahlreiche Softwareprodukte unterschiedlicher Größe beschafft. Software ist durch ihre nicht überschaubaren Anwendungsmöglichkeiten komplex, die Auswahl des richtigen Produkts daher keine triviale Aufgabe.
Im Zuge der Beschaffung eines Geoinformationssystems (GIS) fand allerdings ein Bilderbuchbeispiel für einen strukturierten Entscheidungsprozess seinen Weg bis zur Vertragsunterzeichnung; ein Beispiel, das ich in abstrakter Form hier gerne teile.
Ausgangspunkt
Wir kaufen also Unternehmens-Software: Diese ist im Jahr 2012 beinahe immer webbasiert, oder zumindest in einer three tier architecture umgesetzt. Das Unternehmen möchte die Gesamtkosten (total cost of ownership) minimieren, dabei aber dennoch eine ausreichend gute Software einführen.
Im Studium lernte ich die Nutzwertanalyse als Werkzeug bei derartigen Entscheidungsprozessen kennen. Als ich sie vor Jahren zum ersten Mal anwenden wollte, erlebte ich allerdings zahlreiche Probleme: Die Punktevergabe samt Gewichtung gaukelt ein genaueres, transparenteres Ergebnis vor, als es tatsächlich ist. Gewichtungen werden oft auch noch nachträglich verändert. Die Betriebswirtschaftslehre nennt das Sensitivitätsanalyse, in der Praxis ist das eher ein Hintricksen zum gewünschten Ergebnis.
Was ich an Methoden agilen Projektmanagements mag, ist weniger die Fähigkeit, Prozesse vielleicht besser steuern zu können, sondern die im Lieferumfang enthaltene Transparenz mit der Unsicherheit und Ungenauigkeit nach außen hin als solche deklariert werden.
Soll heißen: Ich präsentiere hier eine absichtlich zur Checklist verkommene Nutzwertanalyse, weil jedes mehr an Datenpunkten, lediglich mehr Zahlenspiel als sinnvolle Entscheidungsgrundlage bedeutet. Anstatt Punkten und Gewichtungen treten nur noch drei Zustände: KO, entscheidend, relevant. Während KO als Filter zu sehen ist, sind die beiden letzteren rein qualitative Aussagen: “Dieses Kriterium ist entscheidend und Anbieter A ist da wohl ein wenig besser” – mehr ist nicht möglich.
Nutzwertanalyse “light”
Zuerst zur Software selbst
- Erfüllt die Software alle meine mir jetzt bekannten Anforderungen? Gibt es zumutbare Workarounds für fehlende Anforderungen?
(KO-Kriterium) - Kann die Software deutlich mehr, als ich es will? Paradox: Je mehr unnötige Funktionalität geboten wird, desto schlechter!
(siehe: Complexity kills!, entscheidend) - Können alle künftigen Endanwender den Client verwenden oder gibt es Einschränkungen bei Browserversionen und/oder Betriebssystemen? Gilt dies auch noch künftig in meinem Unternehmen?
(KO-Kriterium) - Falls ein mobiles Szenario existiert: Ist der Service mobil nutzbar?
(relevant) - Ist eine zentrale Authentisierung (Login mit unternehmensweitem Passwort) möglich?
(KO-Kriterium) - Ist eine zentrale Autorisierung (Übernahme zentral gepflegter Berechtigungen) möglich?
(relevant) - Falls ein älteres System abgelöst wird: Können Daten übernommen werden?
(entscheidend) - Wie schätze ich die wirtschaftliche Situation des Anbieters ein? Wird es ihn in fünf Jahren noch geben? Ist sein angebotenes Produkt für ihn selbst wichtig oder wird mir ein Auslaufmodell angeboten? (Product Roadmap) Wie stark ist letztlich meine Abhängigkeit?
(entscheidend)
ODER
Handelt es sich um Open-Source Software? Gibt es andere Anbieter, die auf Basis dieser Software Dienstleistungen anbieten?
(relevant. Das bedeutet, dass dieser Punkt im Falle von OSS weniger Tragweite erhält.) - Liegen die Daten in einem lesbaren Format vor, oder sind sie im System des Anbieters gefangen?
(entscheidend) - Kann ich das System (notfalls) selbst administrieren? Gibt es ausreichend Angebote für Dienstleistungen (Beratung, Support, Administration), wenn möglich auch von anderen Anbietern?
(entscheidend) - Gibt es Referenzen? Habe ich Erfahrung von anderen Installationen des Anbieters in meiner Branche? Welches Feedback ergibt eine Netz-Recherche?
(relevant) - Was sagen meine Endanwender? Hat Ihnen die Produktpräsentation gefallen? Gefällt ihnen die Software?
(arrogant, aber: beinahe irrelevant) - Bietet das System offene Schnittstellen für Daten und/oder Automatisierung?
(entscheidend) - Erfüllt das System meine Sicherheitsanforderungen hinsichtlich Architektur, Datenhaltung, Verschlüsselung, usw.? Ist das Angebot “in der Cloud” bzw. gebe ich unternehmenskritische oder datenschutzrechtlich sensible Daten in fremde Hände?
(KO-Kriterium) - Darf ich das System in dieser Form einsetzen, oder spricht geltendes Datenschutz-Recht dagegen? Besitze ich eine Meldung beim DVR oder ist gar mit einer Ablehnung zu rechnen?
(realistischerweise lediglich relevant) - Passt die vom Anbieter vorgeschlagene Vorgehensweise bei der Einführung zu Kultur und Ressourcen meines Unternehmens? Sind etwa Schulungen zeitlich möglich? Wissen alle Stakeholder überhaupt von ihren künftigen Rollen?
(relevant)
Man sieht, in meiner Auflistung fehlen zentrale Punkte, die normalerweise (stärker) repräsentiert sind. Dazu zählen etwa die Zufriedenheit der Nutzer oder die technische Ausgereiftheit des Produkts.
Bei einer Produktpräsentation etwa bewerten Endanwender eher die sympathische Art des Beraters, nicht aber das Produkt selbst. Bewerten sie in Ausnahmesituationen doch die Software anstatt der Powerpoint-Präsentation, lassen sie sich vom GUI blenden und schaffen es de facto nie, das Gezeigte zu abstrahieren und in ihre Arbeitswelt zu überführen.
Doch auch IT-Spezialisten sind schlecht im Bewerten: In zehn Jahren IT habe ich festgestellt, dass in Systeme nicht hineingesehen werden kann. Die traurige Nachricht lautet, dass man alle Probleme am eigenen Leib erleben wird, bevor man sie mühsam lösen muss. Dabei gibt es kaum Unterschiede zwischen Open Source und kommerzieller Software: Bei ersterer ist tendenziell mehr Expertenwissen bei der Problemlösung vonnöten – bei höheren Erfolgsaussichten -, bei zweiterer sind zeitlicher Aufwand (Support-Hotline!) und monetärer Einsatz (Beratertage) weitaus größer.
Den Reifegrad einer Software anhand des Namedroppings von Programmiersprachen, Protokollen, Datenbanksystemen, Dateiformaten, usw. feststellen zu wollen, ist blanker Unsinn. Verwendete Technologie und Qualität korrelieren äußerst schwach. Die Eckpunkte von Softwarequalität lauten Entwicklungsprozess, automatisiertes Testen, Sourcecodemanagement, Erfahrung & Motivation, … – alles Dinge, die von außen gänzlich unsichtbar sind.
… und dann das Geld
Nun zu den Kosten: Diese sind bei Hardware und Lizenzen zwar noch vergleichbar, aber oft stellen Schulungen, Beratungsleistungen, Support u.ä. ein großes Problem dar. Veranschlagt ein Anbieter etwa das Doppelte für Beratungsleistung, kann es gleich mehrere Gründe dafür geben: Das System ist schwieriger einzuführen, die Berater sind teurer, der Anbieter ist vorsichtiger bezüglich des Projektfortschritts, usw.
Ein möglicher Ausweg ist die Aufschlüsselung der Kosten in angebotene Gesamtstunden und Stundensatz. Der Median der angebotenen Stunden (über alle Angebote hinweg) ist zunächst die beste Näherung für den Aufwand. Mit dem jeweiligem Stundensatz multipliziert kommt man so zu normierten Angeboten hinsichtlich der Dienstleistungen.
Diese so errechneten (fiktiven!) Angebote sollten Basis eines Preisvergleichs sein.
Eine Pattstellung zwischen zwei Anbietern ist aufgrund der bestehenden Unsicherheit nach wie vor äußerst wahrscheinlich. Möglicher Ausweg hier: Beauftragung beider Anbieter mit einer in maximal acht Wochen durchführbaren Pilotphase bei voller Transparenz des Modus und fairen Bedingungen.
Diese Vorgehensweise stellt die beiden Anbieter in direkten Wettbewerb. Man kann davon ausgehen, dass die “Motivation” auf beiden Seiten hoch sein wird. Auch im nachfolgenden (Groß-)Projekt – wenn dann die Auswahl letztlich getroffen ist – kann das Ergebnis der Pilotphase als Qualitätsreferenz dienen. (Der Anbieter legt sich selbst eine hohe Latte.)
Während die Methode bei kleineren Beauftragungen übertrieben scheint, stellt sie bei wichtigen Projekten eine probate Möglichkeit dar, Entscheidungsunsicherheit tatsächlich zu reduzieren.
About