Toolevaluationen
Viktoria König
Verschiedene Tools evaluieren – so gehen Sie vor
In der sich immer rasanter verändernden technologischen Umwelt, haben sich IT-Verantwortliche Rollen immer wieder mit den folgenden Szenarien auseinanderzusetzen: Die Applikation ist «end-of-life» oder wir möchten durch die Implementation einer neuen Applikation Kern- und Unterstützungsprozesse automatisieren. Dabei sehen sich die verantwortlichen Rollen mit einer Flut von möglichen Lösungen konfrontiert. Lässt man eine Individualsoftware entwickeln oder greift man auf eine der zahllosen Standardsoftwares zurück?
Falls letztere Option gewählt wird, wie finden wir heraus, welche Applikation für meine Institution, Prozesse und Mitarbeiter:innen die beste Lösung darstellt? Eine erfolgreiche Toolevaluation ist ein wichtiger Schritt bei der Suche nach einem neuen Tool. Doch wie gehen Sie dabei am besten vor? In diesem Artikel werden wir das systematische Vorgehen bei einer Toolevaluation anhand folgender Kapitel erläutern: IST-Situation, Zielbild, Ausschreibung, Bewertung, Risikobewertung und Auswahl.
Neben der Auswahl des optimalen Tools, erreicht man durch ein strukturiertes Vorgehen ein weiteres Ziel. Denn durch die Nachvollziehbarkeit im Auswahlprozess, wird zeitgleich die Basis für eine gelungene Stakeholder-Kommunikation geschaffen. Die Entscheidung basiert auf Fakten und ist für alle nachvollziehbar.
IST-Situation
Eine Beschaffung wird immer von einer Schwäche in der IST-Situation ausgelöst. Dies zu klären und genau festzustellen, wo die Differenzen zwischen Bedarf und gegenwärtiger Situation sind, sollte man schon eine strukturierte Situationsanalyse machen. Wieso muss ich ein neues Tool beschaffen?
Mögliche Gründe für eine Toolevaluation können sein:
Das bestehende Tool erfüllt die Anforderungen nicht mehr vollständig
Das bestehende Tool ist veraltet und bietet keine Updates oder Unterstützung mehr
Das bestehende Tool ist zu teuer oder bietet nicht das beste Preis-Leistungs-Verhältnis
Das Unternehmen wächst und benötigt ein Tool mit höherer Skalierbarkeit oder Leistungsfähigkeit.
So findet man schnell und sicher, wo die konkreten Herausforderungen stecken und wie diese auf dem Weg zum SOLL minimiert werden können? Das Schema wird mit dem Akronym «SULZ» abgekürzt und liest sich wie folgt:
S: Systembezogene Aspekte
Was ist das Problem / der Schwachpunkt im System?U: Umgebungsorientierte Aspekte
Wie wirkt sich der Fehler im Umfeld aus (Input/Output)L: Leistungsbezogene Aspekte
Wie wirkt sich der Fehler auf die Performance aus? Wie schnell ist der «Niedergang»?Z: Zeitbezogene Aspekte
Wie lange können wir weitermachen, wenn wir nichts machen?
Was passiert kurz-, mittel- und langfristig?
Zielbild
Das Zielbild legt fest, welche Anforderungen das neue Tool erfüllen muss. Eine sorgfältige Analyse der IST-Situation ist dabei von entscheidender Bedeutung, um alle wichtigen Anforderungen zu berücksichtigen. Das Zielbild kann in drei Kategorien unterteilt werden: nutzenrelevante Ziele, systemrelevante Ziele und durchführungsrelevante Ziele.
1. Nutzenrelevante Ziele
Nutzenrelevante Ziele beschreiben, welche Vorteile das neue Tool für Ihr Unternehmen bieten soll. Dies kann beispielsweise die Verbesserung von Geschäftsprozessen, die Steigerung der Effizienz oder die Erhöhung der Kund:innenzufriedenheit sein. Sie sollten sich überlegen, welche spezifischen Ergebnisse Sie durch den Einsatz des neuen Tools erreichen möchten und wie Sie den Erfolg messen werden. Es geht also um Wirkung.
2. Systemrelevante Ziele
Systemrelevante Ziele beschreiben, was das neue System alles (besser) können muss. Es geht hier also um Leistungsparameter, die das Erreichen der nutzenrelevanten Ziele ermöglichen sollen. Zu diesem Bereich gehört aber auch, welche Anforderungen die IT-Infrastruktur Ihres Unternehmens an das neue Tool stellt. Dazu gehören beispielsweise die Kompatibilität mit anderen Systemen, die Anforderungen an die Netzwerk- und Speicherinfrastruktur oder die Integration in bestehende IT-Systeme. Es ist wichtig, dass das neue Tool nahtlos in die bestehende IT-Infrastruktur integriert werden kann, um reibungslose Arbeitsabläufe zu gewährleisten.
3. Durchführungsrelevante Ziele
Durchführungsrelevante Ziele beschreiben, welche Anforderungen an die Evaluation, den Einbau und die Einführung im Sinne eines Projekts gestellt werden. Dazu gehören beispielsweise die Dauer der Implementierung, der Aufwand für die Schulung der Mitarbeiter:innen oder die Verfügbarkeit von Support und Schulungsressourcen. Es ist wichtig, diese Anforderungen zu berücksichtigen, um sicherzustellen, dass die Evaluierung und Implementierung des neuen Tools innerhalb des vorgegebenen Zeitrahmens und Budgets durchgeführt werden können.
Durch die Festlegung von nutzenrelevanten Zielen, systemrelevanten Zielen und durchführungsrelevanten Zielen können Sie sicherstellen, dass das neue Tool den Anforderungen Ihres Unternehmens entspricht und die gewünschten Ergebnisse liefert. Es ist wichtig, dass Sie alle relevanten Stakeholder in diesem Prozess einbeziehen, um sicherzustellen, dass die Anforderungen aller beteiligten Abteilungen und Interessengruppen berücksichtigt werden.
Anforderungserhebung
Erste Anforderungen werden anhand von Weisungen, Prozessen und vorhandenen Dokumentationen abgeleitet oder vorgegeben. Nicht zuletzt können gesetzliche Vorgaben verantwortlich für die Aufnahme der einen oder anderen Anforderung sein.
Erfahrungsgemäss sind jedoch die Durchführungen von Anforderungsworkshops mit den Fachverantwortungs- und Führungsrollen für die Aufnahme von Anforderungen am wertvollsten. Denn diese Rollen sollen als Enduser selbst entscheiden, wie die zukünftige Applikation auszusehen hat. Dabei ist es wichtig, dass Anforderungen anhand eines bestimmten Musters und auf eine stringente Art und Weise aufgenommen werden, damit später genau klar ist, was es braucht und wie es daherkommen soll.
Die Anforderungen sollten in MUSS-Kriterien und Wunsch-Kriterien unterteilt werden. MUSS-Kriterien sind die minimalen Anforderungen, die das neue Tool erfüllen muss, um dem Zweck der Beschaffung überhaupt gerecht zu werden. Ohne ihre Erfüllung wäre die Beschaffung eines Objekts sinnlos. Wunsch-Kriterien gehen darüber hinaus. Sie dienen der Differenzierung der Bewertung der eingehenden Angebote dadurch, dass Sie die Aspekte der MUSS-Kriterien noch weiter ausdefinieren oder zusätzliche Kriterien einführen, die über das blosse Minimum der MUSS-Kriterien hinausgehen.
Wenn man beispielsweise an die Beschaffung eines Druckers in einem Grossraumbüro eines Grafik-Unternehmens denkt, so könnte als MUSS-Kriterium festgelegt werden, dass der Drucker minimal 2000 Blatt Fassungsvermögen haben soll. Dies, um bei einem gemessenen Durchschnittsverbrauch von 1000-1400 Blatt pro Tag nur einmal am Morgen Papier auffüllen zu müssen.
Anbieter:innen mit Geräten, die ein Fassungsvermögen unter 2000 Blatt haben, können sich also die Mühe der Offertenstellung sparen. Sie würden aus dem Rennen fallen, weil ihr Gerät die grundlegende Eignungsprüfung nicht besteht.
Besteht allerdings der Wunsch, möglichst selten Papier auffüllen zu wollen, so wäre ein möglichst grosses Fassungsvermögen als Wunsch-Kriterium gegeben. Danach würden die Anbieter:innen die besten Punkte bekommen, dessen Gerät am meisten Blatt Fassungsvermögen anbietet. In diesem Fall könnte man die Angebote so bewerten, dass Geräte mit steigendem Fassungsvermögen je 1000 Blatt einen Punkt mehr bekommen. Setzt man als Schulnoten von 1 bis 6 als Bewertung voraus, so bekäme ein Gerät mit 3000 Blatt 1 Punkt, 4000 Blatt 2 Punkte, 5000 Blatt 3 Punkte und so weiter, bis ab 8000 Blatt aufwärts 6 Punkte vergeben würden.
Mit diesem zweistufigen Verfahren kann man mit den MUSS-Kriterien (Eignung) ungenügende Angebote sicher und objektiv ausfiltern und hat nachher nur noch Angebote gegen die Wunsch-Kriterien zu bewerten, die auch tatsächlich das Mindestmass an Businessnutzen bieten.
Die Kriterien und Bewertungsmechanismen sollten VOR der Ausschreibung festgelegt werden, um die Objektivität der Bewertung zu wahren. Sie sollen sich an den Bedürfnissen des Business orientieren und nicht an der Schönheit glänzender Prospekte.
Bei der Aufnahme von Anforderungen soll immer gleich vorgegangen werden:
Die MUSS- und Wunsch-Anforderungen werden wie folgt gegliedert:
Funktionale Anforderungen
Nicht-Funktionale Anforderungen
Umgebungsorientierte Anforderungen oder Schnittstellenbezogene Anforderungen
Hersteller- oder Anbieterorientierte Anforderungen
Übergeordnete Systemanforderungen
Projektbezogene Anforderungen
Die ersten drei Aspekte beschreiben die eigentlichen Eigenschaften des gewünschten Objekts und sind im Grunde die Grundlage der Evaluation. Da geht es u.a. um Funktionen, Leistung und Effizienz und um die Schnittstellen zu notwendigen Umsystemen.
Hersteller:innen- und Anbieter:innen-orientierte Aspekte kommen ins Spiel, wenn für die Hersteller:innen bestimmte Anforderungen wie «Schweizer Firma», «zertifiziert nach ISO 27001» o.ä. gestellt werden.
Gelegentlich gibt es Situationen, wo Vertragliche Aspekte mit bewertet werden sollten. Beschafft man zum Beispiel ein sehr grosses Service-Management System, so ist man oft gar nicht in der Lage, dieses von Anfang an umfassend zu nutzen. Hier wäre es sinnvoll, die Anforderung zu stellen, die Lizenzkosten staffeln zu können, damit nur das gezahlt werden muss, was man effektiv nutzt. So könnte man die Projektkosten bis zum vollständigen Einbau des Systems und der Erstellung der dafür notwendigen Prozesse deutlich mindern.
Manchmal ist es notwendig, dass die Anbieter:innen auch bei Implementation und Inbetriebnahme helfen. Hier ergeben sich möglicherweise Anforderungen, die beschreiben, wie und inwieweit das Projekt in der Implementationsphase unterstützt werden soll.
Ausschreiben: Potenzielle Anbieter:innen identifizieren
Die Anforderungen sollen ohne Einfluss von Anbieter:innen erstellt werden, um objektiv die Bedürfnisse der Organisation abzubilden. Sobald die Anforderungen definiert sind, sollten potenzielle Anbieter:innen identifiziert werden. Hierfür können Sie eine Ausschreibung erstellen und diese an verschiedene Anbieter:innen, beispielsweise als RfI (request for information) oder RfP (request for proposal) zustellen.
Aufgrund der klaren Trennung von MUSS- und Wunsch-Anforderungen, wird sichergestellt, dass die Anbieter:innen verstehen, welche Anforderungen der gewünschte Beschaffungsgegenstand erfüllen muss. Dabei kann ein: Anbieter:in bereits selbst angehalten sein, nur auf die Ausschreibung zu reagieren, wenn er denn auch alle MUSS-Kriterien vollständig abdecken kann.
Aus der Long-List der Anbieter:innen werden nun nur noch die Unternehmen ausgewählt, die alle MUSS-Kriterien vollständig erfüllen.
Bewerten
Wunsch-Kriterien gewichten
Im Gegensatz zu den MUSS-Kriterien ist die Bewertung der Wunsch-Kriterien nicht schwarz/weiss oder ja/nein. Sie können auch nur zu einem Teil erfüllt sein und die eine Anforderung kann auch durchaus wichtiger sein als eine andere. Es ist also durchaus sinnvoll, die Wunsch-Kriterien auch noch zu gewichten.
Tool einsetzen
Durch das Abfüllen aller Anforderungen in einem Evaluationstool, kann auf solche Aspekte Rücksicht genommen werden. Durch implementierte Formeln, kann somit pro Applikation ein Wert (beispielsweise der Erfüllungsgrad der Anforderungen in % errechnet werden). Durch die Bereitstellung eines standardisierten Tools, lassen sich diese Anforderungen somit gewichten und der echte Erfüllungsgrad lässt sich errechnen.
Bewerten der Angebote
Diese Einteilung kommt dann bei der Bewertung wieder zum Tragen, wo die verschiedenen Angebote verglichen werden. Die Bewertung eben dieser Wunsch-Kriterien durch das Projektteam, ergibt im Anschluss eine Rangliste der verbleibenden Unternehmen in der Shortlist. Am Ende gibt es eine:n Anbieter:in mit dem besten Nutzwert und sicher auch eine:n zweite:n Sieger:in.
Risiko mit einbeziehen
Bevor eine endgültige Entscheidung getroffen wird, sollten potenzielle Risiken analysiert werden. Hierzu sollten Sie eine Risikobewertung durchführen und mögliche Risiken identifizieren und bewerten. Mögliche Risiken können beispielsweise sein:
Anbieter:in kommt aus der EU und unterliegt anderen rechtlichen Grundlagen
Anbieter:in ist eine sehr kleine Firma, deren Überleben während der geplanten Einsatzdauer nicht sicher ist
Klumpenrisiko – durch die Beschaffung bei einem bzw. einer Anbieter:in, der bzw. die schon sehr viel für die Organisation macht, entsteht ein Abhängigkeitsverhältnis, das es (evtl. aus regulatorischen Gründen) zu vermeiden gilt.
Sicherheitsrisiken – Anbieter:in steht im Verdacht Daten, die während der Nutzung seiner Geräte oder Software anfallen, in das Herstellerland zu senden
Etc.
Entscheiden
Aufgrund der Risikobewertung wird entschieden, welche:r Anbieter:in für die Umsetzung letztlich ausgewählt wird. Es ist wichtig, dass Sie bei der Entscheidung alle relevanten Faktoren berücksichtigen, einschliesslich Kosten, Nutzen, Benutzerfreundlichkeit und Support.
Es ist auch ratsam, den Beschaffungsgegenstand während der Einführungsphase in einer Testumgebung zu evaluieren oder in einem PoC (Proof of Concept) zu prüfen bevor Sie es endgültig kaufen oder in Produktion bringen. Auf diese Weise wird sichergestellt, dass den Anforderungen Ihres Unternehmens umfassend entsprochen wird und die erwarteten Ergebnisse geliefert werden.
Fazit
Die Auswahl des richtigen IT-Tools erfordert eine sorgfältige Analyse und eine systematische Vorgehensweise. Die Evaluierung von MUSS- und Wunsch-Kriterien, die Identifizierung von potenziellen Anbieter:innen, die Bewertung von Angeboten und die Risikobewertung sind entscheidende Schritte bei der Evaluation. Mit einer fundierten Entscheidung und einer sorgfältigen Implementierung können Sie sicherstellen, dass der Beschaffungsgegenstand den Anforderungen Ihres Unternehmens entspricht und den angestrebten Mehrwert bietet.
