Softwareauswahl Schritt 4: Detailevaluierung

10.12.2019, Autorin: Regina Schmidt

Jedes fünfte Unternehmen spart sich den kompletten Softwareauswahlprozess. Doch gerade die Detailevaluierung bietet viele Vorzüge. In diesem Schritt untersucht oder testet das Projektteam die Lösungen der Short List im Detail, bevor sich das Unternehmen für ein Produkt entscheidet.

Der BI Survey zeigt Jahr für Jahr, dass Lösungen die detailliert und gründlich bewertet wurden, einen positiveren Geschäftsnutzen erbringen als Lösungen, bei denen dieser Schritt eingespart wurde.

Stellen Sie vor der eigentlichen Detailevaluierung jedem Anbieter ein Dokument bereit, das Sachverhalte, notwendige Bedingungen und Aufgaben beinhaltet, die Ihre Softwarelösung erfüllen muss. Inhaltlich sollten Sie dem Anbieter neben der Ausgangslage und der Zielsetzung auch die Infrastruktur, Ausstattung und Datenquellen beschreiben sowie einen Zeitplan für die Evaluierung liefern. Zudem sollte das Dokument drei bis fünf Aufgabenstellungen enthalten, die jeder Anbieter bei der Evaluierung umsetzen sollte.

Achten Sie bei der Konzeption der Aufgabenstellungen auf Testfälle mit breiter Abdeckung aller geforderten Szenarien und gestalten Sie diese umfangreich. Orientieren Sie sich am Kriterienkatalog aus der Anforderungsaufnahme und gehen Sie bei Bedarf ins Detail. Achten Sie zudem auf gleiche Bedingungen und stellen Sie das Dokument den Anbietern jeweils mit identischer Vorlaufzeit zur Verfügung.

Sind die Aufgaben verteilt und der Zeitraum für die Evaluierung festgelegt, existieren drei verbreite Wege, die Detailevaluierung durchzuführen:

Die strukturierte Anbieterpräsentation

Jeder Anbieter präsentiert seine Lösung und die zuvor gestellten Aufgabenstellungen mitsamt der Lösungswege. Die strukturierte Anbieterpräsentation findet bei Ihnen vor Ort statt. Diese Art der Detailevaluierung eignet sich gut für überschaubare Aufgabenstellungen, die dem Anbieter vorab zur Verfügung gestellt werden.

Das Testen

Mitarbeiter testen die potentielle Software im Unternehmen für einen bestimmten Zeitraum. Der Vorteil besteht darin, dass die User die Software sofort selbst beurteilen können. Andererseits bindet ein Test die Ressourcen der Mitarbeiter.

Der Proof of Concept (PoC)

Im Vergleich zum Testen setzt der Anbieter oder dessen Partner die Aufgabenstellung um. Charakteristisch für den PoC ist die prototypische Umsetzung einer Teilaufgabe der Gesamtaufgabenstellung des Kunden. Dazu gehört nicht nur die Einbettung in die bereits vorhandene IT-Landschaft, sondern auch inwiefern funktionale Kriterien aus dem Kriterienkatalog umgesetzt werden können.

BARC-Tipp:

Bedenken Sie: Die Software ist das tägliche Handwerkszeug des Anbieters, prüfen Sie deshalb auch seine Fachkompetenz und Eignung hinsichtlich Ihrer Zusammenarbeit.

Checkliste: In 10 Schritten vom Proof of Concept zur Softwareauswahl

1. Gute Vorbereitung und Struktur: Unter Einbezug des Projektteams wird während des Proof of Concept (PoC) untersucht, welcher Hersteller den größten Projekterfolg verspricht. Je nach Kriterien, IT-Landschaft und Ressourcen kann dieser Prozess zur großen Herausforderung werden. Deshalb ist eine gute Vorbereitung und strukturierte Durchführung für den Erfolg eines PoCs entscheidend.

Für eine lückenlose Planung und einwandfreie Umsetzung des PoC ist es geschickt, zunächst einen Projektplan aufzustellen, in dem Sie Zeitrahmen, Vorbereitungsmaßnahmen, nötige Dokumente und Ansprechpartner festhalten. Zur Vorbereitung gehört auch die Erstellung des Dokuments, das alle Anbieter im Vorfeld erhalten.

Je nach Aufgabenstellung dauert ein PoC typischerweise drei bis fünf Tage. 5-Tages-Evaluierungen führen wir bei BARC-Projekten für Szenarien mit einer breiten und komplexeren Anforderungsbasis durch. Überschaubare Szenarien können in drei Tagen umgesetzt werden.

2. Die Softwareinstallation der Anbieter sollten Sie in der Woche vor dem PoC durchführen, um mögliche Verzögerungen oder Probleme vor dem PoC lösen zu können.

3. Die PoC-Tage bestehen neben der prototypischen Implementierung Ihrer Anforderungen typischerweise aus mehreren Workshops des Anbieters. Gestartet wird mit einem Kick-Off Workshop, in dem sich das Kernteam und der Anbieter kennenlernen. Fachanwendermeetings ermöglichen einem erweiterten Anwenderkreis den Anbieter und die Software während der PoC-Umsetzung kennen zu lernen und bereits erste Fragen zu stellen.

4. Der Architekturworkshop wird meist nur zwischen Beteiligten der IT und dem Anbieter abgehalten und dient dazu zu prüfen, ob das Werkzeug die technischen Kriterien aus dem Katalog erfüllt. Die Ergebnisse beider Workshops können bewertet werden und in die Gesamtbewertung des PoC mit einfließen.

5. Zum Abschluss der PoC-Tage wird der Anbieter zur Ergebnispräsentation gebeten.

6. Ein bewährtes Vorgehen nach BARC-Methodik ist der Einsatz von unterschiedlichen Bewertungsbögen. Das Kernteam beurteilt die Umsetzung der Aufgabenstellung des jeweiligen Anbieters, während andere Stakeholder ihren subjektiven Eindruck vermitteln.

7. Ergänzend zu dieser eher fachlichen Bewertung empfehlen wir im Rahmen der PoC-Tage mögliche Kosten zu bewerten – diese können Sie in einem Lizenzworkshop erfragen. Bitten Sie den Anbieter um eine Kostenschätzung und Informationen zum Lizenzmodell.

8. Für die gesamte Ergebnisaufbereitung Ihrer PoC-Tage sollten Sie Ihre Einschätzungen in vier Kategorien zusammenfassen:

Die fachliche Bewertung des erweiterten Projektteams
Die fachliche Bewertung des Kern-Teams
Die Bewertung der Architektur und Security
Die Bewertung der Lizenz- und laufenden Kosten

Mit diesem Vorgehen stellen Sie sicher, dass Sie alle relevanten Aspekte betrachtet haben.

9. Ihre fundierte Entscheidung basiert nicht nur auf der eingeschränkten Meinung eines Einzelnen, sondern auf der kollektiven Beurteilung aller involvierten Personen. Der Evaluationsprozess setzt außerdem ein realistisches Maß an Erwartungen dieser Stakeholder voraus, was mit einer bestimmten Lösung erreicht werden kann.

10. Nach der Entscheidung für eine Lösung, profitieren Sie von dem bereits erstellen Prototypen. So können Sie schneller in die Implementierungsphase starten und den während des PoC entwickelten Prototypen als Startpunkt nutzen.

BARC-Tipp:

Ein vergleichender PoC stellt die sicherste Variante für die Detailevaluierung dar: Im Vergleich zur strukturierten Präsentation zeigt der Anbieter genau auf, wie die Aufgaben gelöst werden. So kann der Anbieter aufgrund seiner Expertenkenntnis Workarounds aufzeigen.