Softwareauswahl-Checkliste: 9 Schritte mit Vorlage

Eine Softwareauswahl-Checkliste hilft dir, Anforderungen zu klären, Anbieter vergleichbar zu prüfen und die Entscheidung nachvollziehbar freizugeben. Sie verringert das Risiko, dass ein guter Demo-Eindruck eine fehlende Integration oder einen unpassenden Vertrag überdeckt. Entscheidend ist nicht allein der Funktionsumfang: Die Lösung muss zum Prozess, zu den Daten, zum Budget und zum späteren Betrieb passen.

Hier bekommst du einen Ablauf für die Auswahl von SaaS und anderer Unternehmenssoftware: neun Schritte, eine kopierbare Checkliste, Fragen für den Demo-Termin, ein Muster für das Testprotokoll und eine kurze Vorlage für die Entscheidung. Die Beispiele sind fiktiv.

Welche Schritte gehören zur Softwareauswahl?

Unser Ablauf für die Auswahl umfasst neun Schritte in vier Phasen. In der Phase Klären (Schritt 1 bis 3) beschreibst du das Problem, benennst die Verantwortung und legst die Anforderungen fest. Beim Eingrenzen (Schritt 4 und 5) prüfst du vorhandene Lösungen, sammelst Anbieter und bildest eine Shortlist. In der Phase Prüfen (Schritt 6 bis 8) testest du die entscheidenden Anwendungsfälle und vergleichst Kosten, Vertrag und Risiken. Beim Entscheiden (Schritt 9) holst du die Freigabe ein und dokumentierst sie. Die Auswahl beginnt, wenn der Bedarf intern angemeldet ist (die Anfrage), und endet mit der Freigabe. Die Einführung folgt als eigener Abschnitt weiter unten.

Schritt	Zentrale Frage	Ergebnis	Verantwortlich
1. Problem	Was soll die Software lösen?	Zielbeschreibung mit Erfolgskriterien	Fachbereich
2. Entscheidung	Wer entscheidet, wer arbeitet mit?	Rollenliste, Entscheidungstermin	Fachbereich
3. Anforderungen	Was ist Pflicht?	Muss-Kriterien mit Akzeptanztest	Fachbereich, IT
4. Anbieter	Welche Lösungen kommen infrage?	Anbieterliste mit Quellen	Einkauf, Fachbereich
5. Shortlist	Wer wird ernsthaft geprüft?	Shortlist mit Ausschlussgründen	Fachbereich, Einkauf
6. Test	Was funktioniert wirklich?	Testprotokoll	Fachbereich, IT
7. Kosten und Vertrag	Was kostet es über die Laufzeit?	Kostenvergleich, Vertragsnotizen	Einkauf, Finance
8. Datenschutz und Sicherheit	Welche Nachweise brauchen wir?	Risikobewertung, offene Punkte	Datenschutz, IT
9. Entscheidung	Wer gibt frei?	Entscheidungsvorlage mit Freigabe	Entscheidungsstelle

Du musst nicht für jedes kleine Teamtool ein aufwendiges Auswahlverfahren aufbauen. Die Tiefe der Prüfung sollte zur Bedeutung der Software passen. Ein interner Notizdienst mit wenigen Anwendern braucht andere Nachweise als eine Plattform, die Zahlungsdaten oder vertrauliche Kundendaten verarbeitet.

Schritt 1: Was soll die Software konkret lösen?

Beschreibe zuerst den bestehenden Arbeitsablauf: wer den Prozess beginnt, welche Informationen benötigt werden, wo heute manuelle Arbeitsschritte oder Fehlerquellen liegen und welche Kennzahl sich verbessern soll. Formuliere Anforderungen nicht als Funktionswunschliste, sondern als zu erledigende Aufgabe.

Schwaches Beispiel: „Die Software soll ein KI-Dashboard bieten.“ Besser: „Die Teamleitung soll jede Woche alle offenen Kundenanfragen nach Verantwortlichen und Fälligkeitsdatum filtern können, ohne Daten aus drei Systemen zu exportieren.“ Der zweite Satz ist überprüfbar und verhindert, dass eine attraktive Funktion ohne messbaren Nutzen gewinnt.

Notiere ein Ziel, die Ausgangssituation und maximal drei Erfolgskriterien. Beziehe die späteren Anwender ein, bevor der Einkauf Angebote anfordert, und frage sie, welche Aufgaben heute die meiste Zeit kosten. Die Antworten fließen in die Erfolgskriterien ein.

Ergebnis: Eine Zielbeschreibung mit Ausgangssituation und höchstens drei Erfolgskriterien.

Schritt 2: Wer entscheidet und wer arbeitet mit?

Lege eine entscheidungsfähige Gruppe fest. Typisch sind eine fachliche Verantwortung, IT, Informationssicherheit, Datenschutz, Einkauf und Finance. In kleinen Teams fallen einzelne Rollen zusammen. Schreibe bei jeder Rolle den Namen auf, bei Doppelrollen beide Aufgaben. Nimm außerdem die betroffenen Teams und Prozesse auf.

Die fachliche Verantwortung bestätigt den Prozessbedarf. Die IT prüft Integration, Berechtigungen und Betriebsaufwand. Einkauf und Finance klären die kommerziellen Bedingungen. Datenschutz und Informationssicherheit prüfen die einschlägigen Risiken. Die Entscheidung gehört genau einer benannten Stelle; die übrigen Rollen liefern Prüfergebnisse und Empfehlungen.

Setze einen verbindlichen Entscheidungstermin. Eine Checkliste lässt sich nicht sinnvoll abarbeiten, wenn laufend neue Sonderwünsche aufgenommen werden und der Auswahlumfang ständig wächst. Nimm spätere Anforderungen nur auf, wenn sie ein Muss-Kriterium betreffen.

Ergebnis: Eine Rollenliste mit benannter Entscheidungsstelle und einem Entscheidungstermin.

Schritt 3: Welche Anforderungen sind wirklich Pflicht?

Trenne Muss-Kriterien, Soll-Kriterien und Wünsche. Eine Software, die ein Muss-Kriterium nicht erfüllt, gewinnt nicht allein wegen einer hohen Punktzahl bei Komfortfunktionen. Lege schon vor der ersten Demo fest, welche Anforderungen zwingend sind.

Muss-Kriterien sind zum Beispiel die Anbindung an ein vorhandenes Benutzerverzeichnis, ein passendes Exportformat oder eine fachlich notwendige Genehmigungsstufe. Soll-Kriterien sind etwa komfortable Berichte oder zusätzliche Automationen. Wünsche berücksichtigst du nur bei Gleichstand der übrigen Kriterien, etwa individuell anpassbare Ansichten.

Für jedes Muss-Kriterium brauchst du einen Akzeptanztest. „Schnittstelle vorhanden“ genügt nicht. Präziser ist: „Eine Testbestellung wird mit den vereinbarten Pflichtfeldern in das vorhandene ERP übertragen, Fehler werden protokolliert und erneut verarbeitet.“ Diesen Test kannst du in der Demo oder im Testzugang direkt durchführen.

Welche nichtfunktionalen Anforderungen gehören dazu?

Berücksichtige Rollen und Rechte, Zugriffsschutz, Protokollierung, Datensicherung, Verfügbarkeit, Support und Exportmöglichkeiten. Frage nach Hosting-Region, Unterauftragsverarbeitern und dem Umgang mit Sicherheitsvorfällen, soweit das für deinen Einsatz relevant ist.

Das US-amerikanische NIST beschreibt in der Veröffentlichung SP 800-161 Rev. 1, wie Organisationen Cybersicherheitsrisiken in der Lieferkette erkennen, bewerten und verringern. Das Dokument ist ein US-Leitfaden und keine Vorgabe für deutsche Unternehmen. Es zeigt lediglich, dass Lieferkettenrisiken ein eigenes Thema sind. Die entsprechenden Fragen zu Anbieter, Vertrag und Sicherheit prüfst du in den Schritten 7 und 8.

Ergebnis: Eine Kriterienliste mit Muss, Soll und Wunsch, pro Muss-Kriterium ein Akzeptanztest.

Schritt 4: Wie findest du geeignete Anbieter?

Beginne mit deinem vorhandenen Softwarebestand und prüfe, ob bestehende interne Lösungen den Anwendungsfall abdecken. Vielleicht deckt ein bereits genutztes System den Anwendungsfall ab. Das spart zusätzliche Verträge und Integrationen. Prüfe den Funktionsumfang aber konkret, statt die Lösung wegen ihrer Bekanntheit vorzuziehen.

Erstelle anschließend eine überschaubare Anbieterliste anhand der Muss-Kriterien. In der ersten Marktübersicht reichen Produktbeschreibung, Integrationshinweise, Dokumentation und eine grobe kaufmännische Einordnung. Bewertungen auf Vergleichsportalen liefern Anhaltspunkte, ersetzen aber keine eigene Prüfung.

Dokumentiere die Quelle jeder wichtigen Anbieterangabe. Weichen Preisliste, Präsentation und Vertragsangebot voneinander ab, zählt für die Bewertung die schriftlich bestätigte Angabe. Halte fest, ob eine Funktion öffentlich dokumentiert, schriftlich bestätigt oder nur in einer Demo erwähnt wurde.

Ergebnis: Eine Anbieterliste, in der jede wichtige Angabe eine Quelle hat.

Schritt 5: Wie baust du eine sinnvolle Shortlist?

Reduziere die Liste auf wenige Anbieter, die die Muss-Kriterien plausibel erfüllen. Schreibe die Ausschlussgründe ins Protokoll. So kommen ausgeschiedene Produkte nicht Wochen später ohne neue Fakten zurück in die Diskussion.

Eine Shortlist sollte unterschiedliche Lösungsansätze abbilden. Vergleiche nicht nur drei Anbieter mit nahezu identischem Umfang, wenn eine einfachere Lösung den Prozess ebenfalls erfüllt. Mehr Angebote sind aber kein Qualitätsmerkmal: Entscheidend ist, ob du die verbleibenden Lösungen ernsthaft testen kannst.

Gib allen Anbietern der Shortlist dieselben Anwendungsfälle und denselben Informationsstand. Bei Demos mit unterschiedlichen Aufgaben entstehen verzerrte Eindrücke. Kläre außerdem, ob gezeigte Funktionen im angebotenen Tarif enthalten sind oder separat lizenziert werden.

Ergebnis: Eine Shortlist mit Ausschlussgründen für alle übrigen Anbieter.

Schritt 6: Wie testest du die Software objektiv?

Plane einen kleinen Praxistest mit realistischen, aber datenschutzgerecht vorbereiteten Testdaten, zum Beispiel erfundenen oder anonymisierten Datensätzen. Verwende für alle Anbieter dieselben Aufgaben. Ein Test kann zum Beispiel so aussehen: Nutzerkonto anlegen, Rolle zuweisen, Datensatz importieren, mehrstufigen Freigabeschritt ausführen und vollständigen Export erstellen.

Lege die Erfolgskriterien im Voraus fest und trage das Ergebnis pro Test in ein Protokoll ein. Das Protokoll kennt vier Ergebnisse: bestanden (Kriterium wie definiert erfüllt), eingeschränkt bestanden (erfüllt, mit einer benannten Abweichung), nicht bestanden (Kriterium nicht erfüllt) und offen (Test nicht durchgeführt oder Aussage nicht belegt). Eine offene Frage gilt nie stillschweigend als bestanden. Verspricht ein Anbieter eine Funktion erst für ein künftiges Release, notierst du das als offen.

Muss-Kriterium (fiktives Beispiel)	Akzeptanztest	Nachweis	Ergebnis	Anmerkung
Rollenbasierte Rechte	Eine Person mit Leserechten versucht, einen Datensatz zu ändern	Screenshot der Fehlermeldung	bestanden	Keine
Vollständiger Datenexport	Export aller Datensätze als CSV, Stichprobe von zehn Zeilen gegen das Original	Exportdatei, Abgleichsnotiz	eingeschränkt bestanden	Alle zehn Zeilen vollständig, das Datumsformat weicht vom Original ab
ERP-Schnittstelle	Testbestellung mit Pflichtfeldern wird übertragen, Fehler erscheinen im Protokoll	Beleg der übertragenen Bestellung im ERP, Fehlerprotokoll	offen	Testumgebung des Anbieters noch nicht freigeschaltet, Test nicht durchgeführt
Mehrstufige Freigabe	Antrag durchläuft zwei Freigabestufen mit Vertretung	Ablaufprotokoll	nicht bestanden	Die Vertretung kann die zweite Stufe nicht freigeben

Prüfe auch den Alltag der Anwender. Sie sollten ihre wichtigsten Aufgaben ohne dauerhafte Hilfe erledigen können, und der Test muss zeigen, wie sich die Software bei Fehlern, bei Berechtigungswechseln und beim Ausfall eines verbundenen Systems verhält. Eine glatte Demo unter Idealbedingungen zeigt das kaum.

Welche Fragen stellst du im Demo-Termin?

Lass dir den wichtigsten Arbeitsablauf konkret durchführen. Bitte um den Datenexport und erkläre, welche Felder du brauchst. Lass eine fehlerhafte Eingabe, eine fehlende Berechtigung und eine Ausnahme zeigen. Kläre, welche Funktionen konfigurierbar sind und welche nur durch zusätzliche Entwicklung möglich werden.

Verlange bei kritischen Aussagen eine schriftliche Bestätigung. Das gilt besonders für Sicherheits- und Vertragsklauseln, Datenlöschung, automatische Verlängerungen sowie die Verfügbarkeit bestimmter APIs oder Supportleistungen.

Ergebnis: Ein Testprotokoll mit Ergebnis, Nachweis und offenen Punkten je Muss-Kriterium.

Schritt 7: Welche Kosten und Vertragsrisiken prüfst du?

Vergleiche nicht nur den Monats- oder Jahrespreis. Berücksichtige Mindestmengen, Implementierung, Support, zusätzliche Module, API- oder Speicherverbrauch, Schulung und den späteren Wechsel. Ein scheinbar günstiger Tarif kann über die Laufzeit teurer werden, wenn wichtige Funktionen als Zusatzmodul abgerechnet werden.

Lege einen einheitlichen Zeitraum fest, etwa drei Jahre, wenn er zur geplanten Nutzungsdauer passt. Rechne jedes Angebot auf denselben Umfang und dieselben Mengenszenarien um. Variable Bestandteile schätzt du getrennt. Währung, Steuern und Abrechnungsintervall müssen klar benannt sein.

Prüfe Laufzeit, Kündigungsfrist, Anpassung der Lizenzmenge, Preisänderungsklauseln und Pflichten nach Vertragsende. Frage nach Exportformaten und einer praktikablen Übergangsphase. Der Ausstieg gehört zur Auswahl, nicht erst zur Kündigung.

Ergebnis: Ein Kostenvergleich über denselben Zeitraum und eine Liste der Vertragspunkte, die vor der Unterschrift geklärt werden.

Schritt 8: Wie prüfst du Datenschutz und Sicherheit?

Sammle den Verarbeitungskontext: welche personenbezogenen Daten in den Dienst fließen, wer Zugriff erhält, welche Drittsysteme verbunden werden und welche Regionen, Dienstleister und Unterauftragsverarbeiter beteiligt sind. Erst mit diesen Angaben kannst du beurteilen, welche vertraglichen und technischen Nachweise du brauchst.

Wird der Anbieter als Auftragsverarbeiter tätig, gelten die Anforderungen aus Artikel 28 DSGVO. Ein Sicherheitszertifikat des Anbieters belegt allein nicht, dass der konkrete Vertrag und die Verarbeitung rechtskonform sind. Kläre die Rolle des Anbieters mit der Datenschutzstelle deines Unternehmens.

Fordere angemessene Nachweise zu Authentifizierung, Rechteverwaltung, Verschlüsselung, Löschung, Datensicherung, Meldung von Sicherheitsvorfällen und Schwachstellenbehandlung. Welche Dokumente nötig sind, hängt vom Risiko ab. Halte auch bei kleinen Tools fest, welche Nachweise du eingesehen hast und welche fehlen.

Ergebnis: Eine Risikobewertung mit den angeforderten Nachweisen und den offenen Punkten.

Schritt 9: Wie dokumentierst du die Entscheidung?

Führe die Ergebnisse in einer kurzen Entscheidungsvorlage zusammen. Sie passt auf eine Seite und enthält diese Felder:

• Ausgangsproblem und Erfolgskriterien (Schritt 1)
• Geprüfte Alternativen und Ausschlussgründe (Schritt 4 und 5)
• Muss-Kriterien mit Testergebnis (Schritt 6)
• Kostenvergleich über den festgelegten Zeitraum (Schritt 7)
• Offene Risiken und angeforderte Nachweise (Schritt 8)
• Empfehlung für einen Anbieter, Name der Entscheidungsstelle, Datum der Freigabe
• Annahmen, die vor der Vertragsunterzeichnung bestätigt werden müssen

Trenne die Empfehlung von der Freigabe. Ein fachlicher Favorit erlaubt noch keine Bestellung, solange Sicherheitsfragen oder Vertragsbedingungen offen sind. Hat sich das Angebot in der Verhandlung gegenüber dem Kostenvergleich geändert, vergleichst du das verhandelte Endangebot vor der Unterschrift erneut mit der Freigabe. Die Einführung folgt danach als eigener Abschnitt.

Ergebnis: Eine Entscheidungsvorlage mit Empfehlung, Freigabe und der Liste offener Annahmen.

Kopierbare Softwareauswahl-Checkliste

Kopiere die Liste in dein Projektboard oder in ein Dokument. Trage pro Punkt einen Verantwortlichen, ein Fälligkeitsdatum und einen Nachweislink ein. Die Reihenfolge entspricht den neun Schritten.

Wie bewertest du Anbieter fair?

Eine gewichtete Entscheidungsmatrix hilft, wenn mehrere geeignete Produkte übrig bleiben. Beispielhafte Kategorien sind Prozessabdeckung, Sicherheit, Integration, Betrieb und Gesamtkosten. Lege die Gewichte vorher fest. Eine hohe Gesamtpunktzahl darf nicht darüber hinwegtäuschen, dass ein Muss-Kriterium nicht erfüllt ist.

Bewerte nur belegte Eigenschaften. Zu jedem Punkt sollte die Quelle sichtbar sein: Testprotokoll, Produktdokumentation oder schriftliche Anbieterantwort. Wurde ein Test nicht durchgeführt, bleibt das Ergebnis offen. Ein durchgeführter, aber nicht bestandener Test zählt als nicht bestanden.

Die Matrix ist ein Hilfsmittel innerhalb der Auswahl. Die interne Anfrage liegt vor dieser Checkliste, Vertrag, Bestellung und Verlängerung folgen nach der Freigabe. Wie der gesamte Beschaffungsablauf organisiert wird, beschreibt der Leitfaden zum Software-Beschaffungsprozess.

Wie läuft die Einführung nach der Auswahl?

Mit der Freigabe ist die Auswahl abgeschlossen, die Einführung ist ein eigener Schritt. Benenne eine verantwortliche Person für die Einführung und erstelle einen Plan für Migration, Benutzerkonten, Berechtigungen, Schulung und Abnahme. Prüfe die Datenqualität vor dem Import und lege fest, wann alte Systeme abgeschaltet werden dürfen.

Plane bei kritischen Anwendungen einen begrenzten Pilotbetrieb. Halte fest, welche Probleme vor der breiten Einführung behoben sein müssen. Das Abnahmeprotokoll enthält dieselben Muss-Kriterien wie die Auswahl, damit die ursprüngliche Entscheidung später überprüfbar bleibt.

Prüfe nach dem Start den Nutzen: Die vereinbarten Aufgaben sollten schneller oder verlässlicher erledigt werden, die laufenden Kosten im erwarteten Rahmen liegen und beim Support keine wiederkehrenden Probleme gemeldet werden. Die erste Vertragsverlängerung ist ein guter Zeitpunkt, um die Annahmen aus der Auswahl erneut zu prüfen.

Häufige Fragen zur Softwareauswahl

Fazit: Erst die Kriterien, dann die Demo

Eine gute Softwareauswahl beginnt mit einem prüfbaren Problem und endet mit einer dokumentierten Freigabe. Lege Muss-Kriterien und Akzeptanztests fest, bevor ein Anbieter seine Demo zeigt, teste alle Kandidaten mit denselben Aufgaben und plane den Ausstieg mit ein. Halte Empfehlung, Freigabe und offene Annahmen schriftlich fest, dann kannst du sie bei der ersten Vertragsverlängerung prüfen.

Quellen (abgerufen am 03.11.2026): NIST SP 800-161 Rev. 1 Update 1 zum Cybersecurity Supply Chain Risk Management und Artikel 28 DSGVO zur Auftragsverarbeitung. Die neun Schritte, das Testprotokoll und die Vorlage sind unser eigener Ablauf und keine Vorgabe aus diesen Quellen. Die Beispiele sind fiktiv.