Kundenbericht | NASA JPL's präziser Prozess für die Bewertung und Auswahl eines ESM-Tools

[0:05] Lynn: Frank ist IT-Experte am Jet Propulsion Laboratory der NASA, wo er sich mit der Gestaltung von Geschäftsprozessen, Webprogrammierung, Datenbankdesign und -entwicklung, SQL-Programmierung, Systemengineering, der Erfassung von Systemanforderungen sowie IT-Projekten befasst. Seine Karriere begann vor etwa dreißig Jahren als Mainframe-Computeroperator. Von dort aus stieg er zum technischen Projektmanager auf, wo er Datenbanken für den interbibliothekarischen Leihverkehr aufbaute. Einige Jahre später wechselte er als IT-Leiter zum JPL. Bevor ich hier zu sehr vom Thema abschweife, übergebe ich das Wort an Frank. Bitte sehr.

[0:51] Frank: Vielen Dank und herzlich willkommen an alle, die an diesem Webinar teilnehmen. Ich freue mich sehr darauf, Ihnen diese Informationen zu präsentieren. Ich hoffe, Sie finden sie genauso interessant wie ich. Lassen Sie uns also gleich loslegen, okay? Meine Präsentation wird eine informelle Zusammenfassung des Prozesses sein, den wir durchlaufen haben, um Produkte zur Nutzungserfassung zu suchen, zu finden und zu bewerten. Ich werde Ihnen die Präsentation so präsentieren, wie sie ablief, als wir sie selbst durchgeführt haben. IchIch werde euch zeigen, wie ich die Studie zur Bewertung durchgeführt habe – in der Reihenfolge, in der ich vorgegangen bin –, und ich werde euch einige der Unterlagen präsentieren, die ich im Rahmen der Erstellung des Abschlussberichts erstellt habe. Ich muss euch jedoch darauf hinweisen, dass es beim JPL die Richtlinie gibt, keine bestimmten Produkte zu empfehlen. Daher werde ich, wenn ich Informationen zu den von uns bewerteten Anbietern präsentiere, deren Namen nicht nennen. Lasstsprechen wir über die Tagesordnung für das heutige Webinar: Ich werde Ihnen die Ziele erläutern, die wir zu Beginn der Studie hatten, als wir nach einem geeigneten Produkt suchten; ich werde Ihnen die Anbieter vorstellen, die wir ausgewählt haben, und Ihnen berichten, welche Erkenntnisse wir im Laufe der Studie über diese Anbieter gewonnen haben; ich werde Ihnen erklären, wie wir die Bewertung vorgenommen haben – das bezieht sich darauf, wie wir die eigentliche Bewertung der ausgewählten Anbieter durchgeführt haben; ichIch werde Ihnen zeigen, wie wir die Ergebnisse unserer Bewertungen dargestellt haben – darunter auch, wie die einzelnen Anbieter abgeschnitten haben. Ich werde Ihnen die Ergebnisse der Studie erläutern, einschließlich des aktuellen Stands im gesamten Prozess, und am Ende werden wir etwas Zeit für Fragen einräumen. Ich muss Sie jedoch darauf hinweisen, dass die Richtlinien für die Freigabe von Informationen durch das JPL streng sind, weshalb ichdie Fragen auf Themen beschränken, die mit dem aktuellen Webinar in Zusammenhang stehen. Wenn ich also über die Produkte und Anbieter in dieser von uns durchgeführten Studie spreche: Wenn ich von einem Anbieter spreche, meine ich die Unternehmen, die Nutzungslösungen bereitstellen, und wenn ich von einem Produkt spreche, meine ich die Software, die wir verwalten, warten und an unsere Kunden ausliefern – also genau die Produkte, die Sie intern verwalten, warten und an Ihre Kunden ausliefernintern verwalten, warten und an Ihre Kunden ausliefern – verwenden wir diese Begriffe synonym. Ich werde mich daher während des Seminars bemühen, mich genau an diese Begriffe zu halten, und sollte mir ein Fehler unterlaufen, werde ich mich korrigieren.

[3:58] Okay, fangen wir also mit dem Kern der Präsentation an und sprechen wir über die Ziele der Studie. Unser erstes Ziel war es, die Qualität – Verzeihung, die Quantität – unserer Nutzungsdaten zu erhöhen. Wir hatten festgestellt, dass in unserem hauseigenen Tool, das wir zur Erfassung der Nutzung entwickelt hatten, viele unserer Produkte Protokolldaten erzeugten. Wir nutzten diese Protokolldaten, um die Nutzungsdaten zu erfassen, zu verwalten und anschließend in unsereminternen Tool zur Erstellung unserer Grafiken darzustellen. Dabei stellten wir fest, dass die Verwendung dieser Protokolldaten wirklich problematisch war: Die Protokolle liefen manchmal schief, wenn die Anbieter die Daten nicht aus ihrem Puffer in das Protokoll übertrugen, und wir mussten diese Daten im Nachhinein erneut verarbeiten. Das führte zu Problemen in unseren Auslastungsberichten, die wir regelmäßig korrigieren mussten. Aus diesem Grund verloren unsere internen Stakeholder zunehmend das Vertrauen in die Daten, denn wenn wirzurückgehen und die Daten neu verarbeiten mussten, hatten sie den Eindruck, dass die Stabilität unseres Datenerfassungssystems nicht so hoch war, wie sie sein könnte. Das war also auch einer der Gründe, warum wir diese Studie durchgeführt haben, um herauszufinden, wie wir die Qualität verbessern und das Vertrauen stärken können. Nun haben wir festgestellt, dass die Daten nicht ganz so schlecht waren, wie die Stakeholder sie wahrgenommen hatten, aber diese Wahrnehmung war definitiv etwas, das wir ebenfalls in den Griff bekommen mussten.

[5:36] Im Rahmen dieses Prozesses haben wir erkannt, dass wir die Benutzerfreundlichkeit unseres hauseigenen Tools verbessern wollten. Wir wollten unser Tool stärker zu einem Tool mit serviceorientierter Architektur ausbauen, bei dem die Nutzer weniger auf mich und meine anderen Entwickler angewiesen sind, um Berichte für sie anhand der Nutzungsdaten aus dem Backend zu programmieren, und bei dem sie selbst auf das Tool zugreifen und mehr dieser Berichte abrufen können. Da wir im Rahmen dieser Studie bereits über ein-Haus-Tool, das für uns im Rahmen dieser Studie gut funktionierte, wollten wir sicherstellen, dass dies auch das Tool war, das wir weiterhin nutzen wollten. Als wir unser hauseigenes Tool ursprünglich entwickelt hatten, gab es in der Branche kein geeignetes Tool, mit dem wir die gewünschte Auslastung ermitteln konnten, und so haben wir unser eigenes entwickelt. Der wichtigste Teil dieser Studie bestand dann darin, einen sogenannten „Build-versus-Buy“-Bericht zu erstellen – eine Bewertung, ob unsereigene Tool und unsere internen Ressourcen die bessere Lösung wären oder ob ein bereits vorhandenes und derzeit verfügbares Produkt aus der Branche besser geeignet wäre, um unsere Studienanforderungen und unsere internen Anforderungen zu erfüllen.

[7:15] Okay, wir werden nun einen kurzen Überblick über alles geben, was wir zur Durchführung der Studie unternommen haben. Zu Beginn haben wir also zunächst ermittelt, welche Anforderungen wir an die Nutzungsberichterstattung hatten. Wir haben unsere Anforderungen zusammengetragen, wobei es wichtig ist, sich vor Augen zu halten, dass wir die Anforderungen nicht auf der Grundlage unseres bestehenden– andernfalls hätte es zwar alle Anforderungen erfüllt –, sondern wir haben ganz von vorne angefangen und uns gefragt: „Okay, wenn wir alles hätten, was wir uns wünschen, wie würde das aussehen? Was suchen wir wirklich? Welche Anforderungen fehlen in unserem aktuellen Tool, die wir für unsere hauseigenen Berichtsanforderungen erfüllen müssen?“ Ich habe mich dann im Internet umgesehen und war überrascht festzustellen, dass es mittlerweile eine ganze Reihe von Anbietern gibt, die Nutzungsberichte anbieten. Also haben wir diese Anbieter identifiziert, ihre Websites durchgesehen und ihre gesamte Online-Dokumentation gelesen. Allein anhand ihres öffentlichen Auftritts konnten wir uns ein gutes Bild von den Anbietern machen, und daraus haben wir einige ausgewählt, die unserer Meinung nach für die Art von Berichterstattung, die wir wollten, in Frage kamen. Wir haben ihnen Informationsanfragen geschickt, einschließlich unserer Anforderungen. Wichtig dabei war, dass wir, als wir uns schließlich mit jedem der Anbieter trafen und mit deren Vertriebs- und Technikmitarbeitern sprachen, hatten wir ihnen unsere Anforderungen bereits übermittelt. Bei den ersten Treffen war es großartig, dass wir uns wirklich auf unsere konkreten Fragen konzentrieren konnten und direkt auf einzelne Fragen und Anforderungen eingehen konnten. Die Präsentationen der einzelnen Anbieter bestanden daher darin, dass diese auf alle Anforderungskataloge eingingen und uns erläuterten, inwiefern sie die jeweiligen spezifischen Anforderungskataloge erfüllten oder nicht erfüllten.

[9:36] Bei den Anbietern, bei denen wir beschlossen hatten, Pilotversionen der Software zu testen, wollten wir nicht nur die Demos sehen, die uns die Vertriebs- und Technikmitarbeiter präsentierten, sondern auch, wie diese Produkte mit unseren Daten aussehen. Das gab mir zudem die Möglichkeit, in jedem der Produkte spezifische Berichte zu erstellen. Im Rahmen dieses gesamten Prozesses konnten wir dann jeden Anbieter anhand unserer eigenen Daten bewerten und selbst anhand unserer Anforderungen benoten Der abschließende Teil der Studie bestand darin, all diese Bewertungen sowie die Endergebnisse unserer „Build-versus-Buy“-Studie an unsere Stakeholder zu übermitteln.

[10:39] In diesem Zusammenhang habe ich auch meinen System-Engineering-Prozess durchgeführt, wozu die Erstellung gängiger System-Engineering-Anforderungsdokumente gehörte, wie beispielsweise die Anforderungsdokumente, das Kontextdokument und die Ergebnisse der Studien. Anschließend habe ich all diese Dokumente zusammengefasst und sie als einen umfassenden Bericht an meine Führungskräfte übergeben. Ein Punkt, den ich besonders hervorheben möchte, ist, dass es für uns unglaublich wertvoll war, als wirbei der Erfassung unserer Anforderungen mit allen Teammitgliedern gesprochen haben. Wir haben mit unserer Geschäftsleitung gesprochen, wir haben mit den Mitarbeitern aus dem Lizenzmanagement gesprochen – also mit denjenigen, die die Änderungen an Lizenzdateien und die Bereitstellung dieser Dienste verwalten –, wir haben mit unseren Produktleitern gesprochen – das sind die Personen, die speziell einzelne Produkte betreuen, die wir an unseren Kundenstamm liefern –, und schließlich haben wir mit unseren Fachbereichsleitern gesprochen. Für uns ist der Fachbereich unsere Gruppe von Stakeholdern, bestehend aus den Managementteams für unsere mechanischen Werkzeuge, den Maschinenbauingenieuren und unsere Elektrowerkzeuge für die Elektroingenieure sowie unsere Softwaresystem-Werkzeuge. Wir haben also alle ihre Informationen gesammelt, und manwerden dann feststellen – so wie wir es getan haben –, dass jeder nach etwas anderen Informationen suchte. Ein Beispiel: Die Manager suchten nach mehr Informationen zur Auslastung im Zeitverlauf – wie wurden unsere Lizenzen genutzt? Haben wir genügend Lizenzen? Die Produkt-Support-Leiter interessierten sich eher dafür, wie viele Ablehnungen es gab, wer davon betroffen war und wodurch die Ablehnungen verursacht wurden. Das hat dann unsere Anforderungen an das Tool selbst bestimmt. Daher empfehle ich Ihnen, Ihre Anforderungen von allen zu sammeln, die ein Interesse daran haben, was die Nutzungsberichte ihnen vermitteln werden.

[12:56] Nachdem wir also unsere Anforderungen erfasst hatten, begannen wir mit der Durchführung der Pilotprojekte. Die Untersuchung ergab, dass wir bei dem von uns ausgewählten Produkt sicherstellen müssen, dass es eine beträchtliche Anzahl von Produkten unterstützt, und dies hängt mit dem Problem zusammen, das wir hatten: Unserinterne Tool die Lizenzbereitstellungssoftware anhand der Protokolle nicht unterstützte. Wir wollten ein Produkt, das unser bestehendes Produkt ersetzen kann, falls wir uns dafür entscheiden sollten, mehr Produkte zu unterstützen. Wir haben gelernt, dass wir bei jedem der von uns ausgewählten Anbieter sicherstellen müssen, dass dieser die nichtnicht unterstützten Produktdaten importieren können. Dabei ist es wichtig, dass wir sicherstellen, dass wir für jedes Produkt, das wir unserem Kundenstamm zur Verfügung stellen, eine Möglichkeit haben, Nutzungsdaten in das Tool des Anbieters zu übertragen. Wir konnten nicht sagen, dass es für ein bestimmtes von uns angebotenes Produkt keine Möglichkeit gab, Nutzungsdaten in das Produkt des Anbieters zu übertragen, es sei denn, das von uns angebotene Produkt erzeugte keine Protokolle.

[14:32] Wir haben erkannt, dass wir viele personalisierte Berichte benötigen, was sich daran zeigt, dass wir so viele Interessengruppen haben, die die Daten auf so viele verschiedene Arten betrachten. Wir mussten daher sicherstellen, dass das Tool robust genug ist, um alle Anforderungen unserer Interessengruppen zu erfüllen. Wir haben festgestellt, dass unsere Interessengruppennicht immer das Tool aufrufen wollten, um sich anzumelden und einen Bericht zu erstellen – sie wollten, dass die Daten zu ihnen kommen. Deshalb wollten wir, dass sie morgens ihren geplanten Bericht per E-Mail erhalten; das kann ein Tagesbericht sein, manche von ihnen wünschen sich wöchentliche Berichte – das war also eine unserer wichtigsten Anforderungen.

[15:24] Wir wollten außerdem sicherstellen, dass die Berichte, die mit dem Tool des Anbieters erstellt wurden, unsere Personalinformationen enthielten. Wichtig dabei war, dass wir festgestellt hatten, dass die Berichte, die wir erstellen wollten, eine Betrachtung der Daten aus der Perspektive enthalten sollten, welche Gruppen in unserer Personalabteilung und unserer Abteilungsstruktur beispielsweise die Tools konkret wie nutzen – und die Nutzungsdaten in ihrer Rohformenthalten diese Informationen nicht. Daher mussten wir sicherstellen, dass das Tool des Anbieters diese Informationen zusammenführt, damit wir anschließend Abfragen und Berichte aus der Perspektive der Einrichtung erstellen können.

[16:13] Wir wollten sicherstellen, dass wir eine wirklich gute Berichterstattung über Ablehnungen haben, und diese Berichterstattung musste zielgerichtet sein, damit man – wie Sie wissen, wenn man sich Ablehnungen ansieht – je nach Produkt und der Art und Weise, wie es Ablehnungen erfasst, erkennen kann, dass ein Produkt manchmal Ablehnungen erfasst, bevor es zur Freigabe einer Lizenz übergeht. Wir wollten sicherstellen, dass die Berichterstattung über Ablehnungen innerhalb des Produkts des Anbieters die verschiedenen Arten von Ablehnungen, die auftreten, abdecken kann. Einer unserer Stakeholder war sehr daran interessiert, Echtzeit-Informationen– also darüber, was gerade im System geschieht, wer gerade angemeldet ist – und diese Informationen mit den HR-Daten abzugleichen, um festzustellen, zu welcher Gruppe oder Abteilung die Personen gehören.

[17:18] Okay, an dieser Stelle der Studie haben wir also unsere Anforderungen zusammengestellt, wir haben mit den Anbietern gesprochen, wir haben Anbieter für Pilotprojekte ausgewählt, wir haben unsere eigenen Daten im System, und eshat sich ein erster Überblick darüber ergeben, was wir von einem Nutzungstool erwarten, und deshalb möchte ich kurz auf einige Erkenntnisse eingehen, die wir über die Anbieter gewonnen haben, die die Pilotprojekte durchgeführt haben. Anbieter A hatte also eine sehr übersichtliche, moderne Benutzeroberfläche – ich werde nicht auf jeden einzelnen Punkt eingehen, aber wichtig war, dass sie eine übersichtliche, moderne Benutzeroberfläche hatten. Mit diesem Produkt konnten wir zwar kein Pilotprojekt vor Ort durchführen, aber es gab eine gutgestaltete Online-Oberfläche, über die wir zahlreiche Daten in Berichten auswerten konnten. Was uns bei Anbieter A besonders wichtig erschien und was wir gelernt haben, ist der letzte Punkt: Die Darstellung der Daten erfolgte aus Serverperspektive. Das war insofern wichtig, als man bei unseren Triad-Systemen keine Berichte über alle drei Triaden gleichzeitig erstellen konnte – es gab also eine Einschränkung in dieser Berichtsperspektive. Dieser Anbieter hatte zudem ein Problem bei der Filterung seiner Ablehnungen.

[18:58] Und genau das war problematisch. Unser Anbieter B – das sind die Erkenntnisse, die wir gewonnen haben, und das war das Wichtige an ihm: Das Produkt von Anbieter BProdukt von Anbieter B war sehr schlank und übersichtlich; es gab nicht viel JavaScript, die erzeugten Bilder waren sehr einfach, aber es bot alles, was wir brauchten – alles war vorhanden. Im Vergleich zu Anbieter A bot es die Möglichkeit, die Ablehnungen zu filtern; wir konnten die Berichterstattung dort einschränken. Interessant an Anbieter B war jedoch, dass wir aufgrund dieser schlanken Struktur abwägen mussten, ob Anbieter B in der Lage sein würde, die Studienanforderung zu erfüllen, nämlich den Umfang unserer Berichterstattung zu erhöhen.

[20:01] Folgendes haben wir über Anbieter C erfahren: Er verfügte über eine wirklich gut gestaltete Benutzeroberfläche. Was uns bei Anbieter C besonders wichtig war, waren die lokal gespeicherten LDAP-Daten. Der Vorteil dabei war, dass dadurch einige Ressourcen unseres institutionellen LDAP-Systems entlastet wurden, sodass der Anbieternicht ständig auf unser LDAP-System zugreifen musste, um Informationen zu sammeln. Außerdem speicherte der Anbieter diese Personalinformationen und deren Änderungen im Laufe der Zeit, sodass sich beispielsweise bei einer Änderung der Personenzahl in einer Gruppe auch diese Informationen entsprechend änderten. Das ist wichtig, um dann verfolgen zu können, wie sich die Trends in den Gruppeninformationen ebenfalls verändern. Anbieter C unterstützte im Vergleich zu den anderen Anbietern zudem eine große Anzahl von Lizenzservern – insgesamt 25 verschiedene Lizenzanbieter. Außerdem verfügte Anbieter C über eine Funktion, die wir auch in unserem– und die uns ebenfalls gefiel: die Erstellung von Pseudo-Anbietern. Was wir damit meinen: Diejenigen unter Ihnen, die sich mit Lizenzmanagement beschäftigen, wissen, dass manche Produktanbieter Ihnen eine Lizenzdatei senden, in der sie ihre Produkte in einer einzigen Lizenzdatei bündeln. Man muss in der Lage sein, diese Daten herauszufiltern und die Nutzung als separate Produkte darzustellen, die man seinem Kundenstamm bereitstellt. Anbieter C verfügte über diese Funktion, was wir sehr schätzten.

[21:46] Wir haben also unsere Anbieter bewertet, die unsere Daten gesammelt haben, und als wir das Gefühl hatten, dass wir an einem Punkt angelangt waren, an dem wir die Fähigkeiten der Anbieter sowie unsere Bedürfnisse und Anforderungen fundiert gegeneinander abwägen konnten, haben wir einen Bewertungsprozess durchgeführt, und hierso lief das ab: Als Erstes haben wir jeder Anforderung eine Gewichtung zugewiesen, die auf einer Skala von 1 bis 10 erfolgte. Ich habe mich bewusst für eine Skala von 2 bis 10 statt von 1 bis 5 entschieden, weil ich sicherstellen wollte, dass Anforderungen der Stufen 8 und 10 – sofern sie erfüllt wurden – diese wichtigen Elemente stärker gewichten und dass die niedrigeren Anforderungen – die 2er und die FVieren, die nicht erfüllt wurden, die Punktzahl nach unten verzerren würden. Ich glaube, das war mein erstes Ziel. Mein zweites Ziel war es, am Ende eine aussagekräftigere Gesamtbewertung für meine Geschäftsleitung und meine Stakeholder zu erhalten. Für jede dieser gewichteten Anforderungen haben wir die Anbieter bewertet und ihnen dann für jede Anforderung eine Punktzahl zugewiesen. Diese Punktzahl haben wir anschließend mit der Gewichtung multipliziert, und das ergab die Endnote für jeden Anbieter bei jeder dieser Anforderungen.

[23:41] Hier ist also ein Beispiel: Was wir hier sehen, ist eines der Artefakte, die ich im Rahmen meines Gesamtberichts erstellt habe. Es handelt sich um Anforderung Nummer 36 – TUR steht für „Tool Utilization Reporting“ (Berichterstattung zur Tool-Nutzung). Bei dieser Anforderung geht es um die Fähigkeit des Produkts des Anbieters, einen benutzerdefinierten Bericht zu erstellen. Unser internes Tool erfüllte diese Anforderung, und zwar deshalb, weil ich das System von Anfang-End-System entworfen hatte und die Datenbanktabellen bereits existierten, wusste ich, wie ich meine eigenen SQL-Abfragen für mein System schreiben konnte, sodass ich diese Anforderung erfüllte. Anbieter A gab an, diese Anforderung nicht zu erfüllen, aber ich habe ihm tatsächlich eine höhere Bewertung gegeben, da ich während der Bewertung feststellte, dass er über eine Web-GUI-Oberfläche verfügte, mit der sich SQL-Anweisungen erstellen ließen, die dann in das System eingespeist werden konnten. Daher habe ich ihm eine höhere Bewertung gegeben. Bei Anbieter B habe ich ebenso verfahren und ihm die Bewertung „teilweise erfüllt“ gegeben, da ich auf seine Back-End-Datenbank zugreifen-End-Datenbank zugreifen und mir das Datenbankschema ansehen konnte; ich fand es nicht allzu kompliziert und war der Meinung, dass wir uns mit dieser Datenbanktabelle vertraut machen und dann unsere eigenen SQL-Anweisungen für die direkten Rohdaten schreiben könnten. Anbieter C erfüllte diese Anforderung ebenfalls und verfügte über ein robustes System mit vorgefertigten Berichten, die bereits in das System integriert waren. Rückblickend hätte ich Anbieter C wahrscheinlich als „über den Anforderungen liegend“ bewerten sollen, aber am Ende erhielt er die Note 12 – na gut.

[25:44] Hier ist also ein Beispiel für einen weiteren Bericht, den ich erstellt habe – das ist meine visuelle Darstellung der Bewertung. Ich habe das so gestaltet, damit ihr euch schnell und einfach einen Überblick über die Punktzahl der einzelnen Anbieter verschaffen könnt. Wie ihr seht, handelt es sich um Gewichtungen von 10. Beachtet, dass ich nur die Zusammenfassung zeige, nicht die eigentliche Anforderung – man würde eine Anforderung ja nicht in dieser Sprache formulieren. Aber ihr seht, dass die Anbieter A und B einige dieser Anforderungen nicht erfüllt haben, und obwohl sie zu unseren „Must-haves“ gehören, werden sich die Stakeholder das dennoch ansehen und sich fragen, ob dies Anforderungen sind, auf die sie verzichten können, sollten wir uns für dieses Tool entscheiden.

[26:36] Hier ist also eine Skala mit den Ergebnissen für alle unsere Anforderungen mit der Gewichtung 10 – das sind unsere Must-haves. Wir hatten 15 davon, und ich habe den Eindruck, dass es unter den Anforderungen mit der Gewichtung 10 eine Reihe gab, von denen man erwarten sollte, dass alle Anbieter in der Branche sie erfüllen können. Zum Beispiel gab es eine Anforderung, die besagte, dass ein Bericht über die Auslastung im Zeitverlauf erstellt werden kann, und aus Sicht der Anforderungserfassungist eine wichtige Anforderung, aber genau das bedeutet, dass alle Anbieter bei Ihren Anforderungen mit Gewichtung 10 eine etwas höhere Punktzahl erzielen werden. Sie werden jedoch feststellen, dass Anbieter A bei diesen Anforderungen mit Gewichtung 10 nicht ganz so hoch abgeschnitten hat, wie ich es erwartet hätte. Wenn ich mir Anbieter A noch einmal anschaue, glaube ich, dass dies daran lag, dass sie ihre Daten aus der Serverperspektive präsentierten, wodurch wirnicht alle anderen Berichte für die Gesamtheit unserer drei Systeme abrufen konnten. Unser hauseigenes Tool hat zum Beispiel sehr gut abgeschnitten, und das lag daran, dass wir es selbst entwickelt haben; somit erfüllten wir offensichtlich alle unsere wichtigen Anforderungen. Denn unsere Anforderungen mit der Gewichtung 8 – das sind die Anforderungen, die von hoher Bedeutung waren – es gab 14 davon, und esist interessant festzustellen, dass Anbieter A zu diesem Zeitpunkt bei der Erfüllung dieser Anforderungen deutlich ins Hintertreffen geriet. Diese Anforderungen gingen über die Grundlagen hinaus; hier fangen wir erst richtig an, die Benutzerfreundlichkeit zu verbessern und die Bedürfnisse unserer Einrichtung über das Grundlegende hinaus zu erfüllen. Bei diesen Anforderungen wird nun deutlich, inwieweit sie unseren geschäftlichen Anforderungen gerecht werden. Man sieht, dass unsereigene Tool nicht alle diese Anforderungen erfüllte. Was das genau bedeutet, geht aus unserem „Build-versus-Buy“-Bericht hervor. In diesem Teil der Studie handelt es sich um den Bereich, in dem wir in unser eigenes Tool investieren müssen, um diese Anforderungen zu erfüllen. Hier sehen Sie, dass Anbieter C extrem gut abgeschnitten hat und sogar besser schnitt als unser hauseigenes Tool.

[29:15] Hier sind die Ergebnisse der Anforderungen mit der Gewichtung 6, und auch in diesem Bereich ist Anbieter B ziemlich weit zurückgefallen, und unser hauseigenes Tool hat ebenfalls nicht besonders gut abgeschnitten. Genau hier gibt es einen großen Bereich, in dem wir eine interne Lösung entwickeln sollten – das wird einen erheblichen Teil unserer internen Investitionen ausmachen. Bei unseren Anforderungen mit der Gewichtung 4 fiel Anbieter B erneut zurück; Anbieter C schnitt hier besser ab als unser hauseigenes Tool. Es gibt sieben dieser Anforderungen mit der Gewichtung 4 – das sind relativ wichtige Anforderungen –, und es gab nur zwei Anforderungen mit der Gewichtung 2, weshalb ich diese Grafik nicht aufgenommen habe. Hier ist jedoch die Endwertung: Sie können sehen, dass Anbieter C hier besser abgeschnitten hat als unser-eigenen Tool. Sie sehen hier, dass keiner der Anbieter oder das hauseigene Tool alle unsere Anforderungen erfüllt hat. Es gibt also einen Bereich, in dem unsere Stakeholder bewerten müssen, welche Anforderungen fehlen, und die Auswirkungen dieser fehlenden Anforderungen auf unsere internen Prozesse ermitteln müssen. Diese Tabelle mit den Endergebnissen zeigt Ihnen, dass die Entscheidung tatsächlich zwischen unserem hauseigenen Tool und Anbieter C fallen wird.

[31:11] Hier sehen Sie also eine Heatmap aller Anforderungen. Diese bietet Ihnen einen sehr schnellen und übersichtlichen Überblick über die Leistung der einzelnen Anbieter sowie unseres hauseigenen Tools. Was ich besonders interessant fand, war, dass ich die Kategorie „Übertrifft die Anforderungen“ angelegt hatte undnicht so viele Einträge hatte, wie ich erwartet hatte. Ich gehe davon aus, dass es mehr Fälle geben wird, in denen Anforderungen übertroffen werden. Und natürlich bedeutet Grün, dass die Anforderung erfüllt wurde, Gelb, dass sie teilweise erfüllt wurde, und Rot, dass sie nicht erfüllt wurde. Ich denke, das Wichtige an dieser Grafik ist auch, dass man erkennen kann, dass es bei den Anforderungen der Stufe 4 diesen großen roten Block sowohl bei Anbieter B und Anbieter C als auch bei unseremeigenen Tool die Anforderungen nicht erfüllt haben. Der Branchenanbieter A hat zwar einige davon erfüllt, aber das ist ein Bereich, in dem wir noch einmal zurückgehen und uns diese Anforderungen genauer ansehen müssen, um uns zu fragen: Sind das wirklich Fragen, die wir stellen sollten? Denn wir stellen fest, dass die Branchen-Tools diese Fragen nicht beantworten.

[32:39] Okay, wir haben also die Produkte bewertet und benotet, und nun ist es an der Zeit, den letzten Schritt der „Build-versus-Buy“-Studie durchzuführen, nämlich die Ergebnisse der Bewertung mit den Investitionskosten zu vergleichen. Hier ist das Ergebnis: Die Linie im Kaufdiagramm bezieht sich auf sich selbst – ichmöchte nicht, dass ihr euch die Bewertung anschaut und daraus irgendwelche Kosten ableiten könnt – daher sind die Kosten verschleiert; sie sind relativ zum Umfang, werden aber genau dargestellt. Wenn ihr euch das anschaut, bekommt ihr ein konkretes Gefühl dafür, wie hoch die Investition für jedes der Tools gewesen wäre und welche Kosten unser-Haus-Tool die Kosten für das, was wir voraussichtlich intern investieren müssten, um die Anforderungen zu erfüllen. Ich möchte Sie außerdem darauf hinweisen, dass die hier angegebenen Kosten die laufenden Personalkosten nicht enthalten, da wir davon ausgingen, dass es sich dabei um Fixkosten handelt, die für jedes der Tools gleich bleiben würden.

[34:13] Okay, also das Fazit der Studie: Wir haben festgestellt, dass Anbieter C – wie Sie in der vorherigen Grafik sehen können – in diesem Bereich mehr Funktionen pro investiertem Dollar bot; wir haben also festgestellt, dass Anbieter C eine bessere Kapitalrendite für unser Geld bieten würde als sogar unserWir haben festgestellt, dass Anbieter C über Funktionen verfügte, die in unseren ursprünglichen Anforderungen gar nicht enthalten waren. Das Endergebnis war, dass wir die Kostendifferenz zwischen der Investition in die Neuentwicklung unseres hauseigenen Tools und dem Kauf des Produkts von Anbieter C nicht rechtfertigen konnten. Das Ergebnis der Abwägung zwischen „selbst entwickeln“ und „kaufen“ lautete daher „kaufen“, und wir haben das Produkt von Anbieter C erworben.

[35:17] Und wo stehen wir nun? Wir haben gerade die erste Implementierungsphase des Anbieters abgeschlossen. Dazu gehörte die Installation aller von uns unterstützten, lizenzierten Anbieter, die nativ vom Produkt des Anbieters unterstützt werden – was überraschenderweise eine beträchtliche Anzahl der Tools umfasste, die wir unserem Kundenstamm zur Verfügung stellen. Während wir derzeit unsere Daten erfassen, setzen wir unser internes Tool und Anbieter C parallel ein, und im Laufe der Zeit werden wir dann unser-eigenen Tool schrittweise auslaufen lassen, während wir die Schulung unserer internen Stakeholder fortsetzen – wie man das Tool nutzt und wie man die Berichte findet und versteht. Außerdem durchlaufen wir gerade den Prozess der Erstellung unserer personalisierten Berichte, die unsere Stakeholder benötigen werden.

[36:29] Der Prozess, den wir hier durchlaufen haben, ist keine eigene Erfindung von mir, sondern eine gängige Praxis im Bereich der Systemsoftware-Entwicklung. Eine Referenz zu diesem Prozess findet sich in diesem Buch; erwird speziell in Kapitel 22 behandelt. Daher empfehle ich, sich mit dem Prozess der Anbieterbewertung im Zusammenhang mit Softwareanforderungen auseinanderzusetzen. Es war unglaublich hilfreich, einen Branchenstandard für die Durchführung der Bewertung zu kennen und anzuwenden. Das hat mein Selbstvertrauen bei der Durchführung dieser Bewertung gestärkt, und das Wissen, dass der Bericht, den ich für meine Geschäftsleitung erstellte, Teil einer bewährten Branchenpraxis war. Ich möchte mich bei allen bedanken, die heute gekommen sind und zugehört haben, und ich hoffe, dass ihr es interessant fandet. Ich hoffe, ihr seid inspiriert, diese Art von Prozess selbst auszuprobieren.