
Softwareanbieter prüfen. Sicherheit, Integration und Eigentum
Eine Prüfliste für Sicherheit, Integrationen, Datenrollen, Eigentum, Support und Ausstieg vor dem Softwarevertrag.
Wählen Sie keinen Partner nach einer überzeugenden Präsentation oder dem niedrigsten Angebot. Wählen Sie ein Team, das Ihr Problem nachvollziehbar versteht, ähnliche Arbeit zeigen kann und Verantwortung für Ergebnis, Sicherheit und Übergabe übernimmt. Ein Angebot für Software, Automatisierung, Design oder Modernisierung ist zunächst eine Annahme. Prüfen Sie diese mit Belegen.
Der 6sense Bericht von 2025 zeigt, dass Einkaufsgruppen ihre Shortlist oft vor dem ersten Gespräch ordnen. Gartner berichtete 2025, dass 61 Prozent der B2B-Käufer insgesamt ein rep-freies Kauferlebnis bevorzugen. Bereiten Sie die Gespräche deshalb mit eigenen Kriterien vor, statt auf Überzeugungskraft zu reagieren. Den Kontext beschreibt die Gartner-Mitteilung.
Beschreiben Sie vor dem RFP die Entscheidung, die das System verbessern soll. Wer arbeitet heute manuell, woher kommen die Daten, welcher Fehler kostet Geld, und woran erkennen Sie die Veränderung nach dem Start. Nennen Sie Grenzen des Umfangs, einen internen Verantwortlichen, Budget, Termin und Abhängigkeiten. Schreiben Sie auch auf, was die Lösung nicht leisten soll.
Ein RFP muss nicht lang sein. Gleiche Anforderungen, Nutzungsszenarien, Integrationen, Datenzugang, Betriebsmodell und Abnahmeweg geben jedem Lieferanten die gleiche Grundlage.
Wählen Sie drei bis fünf Kandidaten. Notieren Sie Belege statt Eindrücke. Halten Sie fest, wie das Team den Prozess versteht, wer tatsächlich liefert, welches vergleichbare Problem es gelöst hat, was offen bleibt und was Discovery klären muss.
Auf kleineren Bildschirmen lässt sich die Tabelle horizontal verschieben.
| Kriterium | Beleg | Gewicht |
|---|---|---|
| Problemverständnis | Schriftliche Zusammenfassung von Prozess und Risiken | 20 |
| Lieferung und Verantwortung | Team, Meilensteine, Repository, Übergabe | 20 |
| Architektur und Betrieb | Entscheidungen, Tests, Monitoring, Support | 20 |
| Sicherheit und Daten | Zugriffe, Vertrag, Vorfälle, Backups | 20 |
| Preis und TCO | Annahmen, Änderungen, Betriebskosten | 20 |
Ein glaubwürdiger Partner behauptet nicht vor Discovery eine genaue Lösung. Er dokumentiert Annahmen, offene Fragen, Risiken und den Discovery-Ertrag. Die Schätzung trennt bestätigte Arbeit von Reserve. Fragen Sie, wer Workshops führt, wie Entscheidungen entstehen und was Sie erhalten, falls Sie danach nicht fortfahren.
Klären Sie die Verantwortung für Backlog, Qualität, Deployment und Support nach der Übergabe. Fragen Sie konkret, wo Daten liegen, wie Zugriffe verwaltet werden, wie Änderungen getestet werden, wer Störungen erkennt und wie der Dienst nach einem Vorfall wiederhergestellt wird. Verlangen Sie einen Testauszug, ein anonymisiertes Release-Beispiel und einen Betriebsplan.
Vereinbaren Sie Eigentum an Quellcode, Designs, Konten, Domains, Cloud-Mandant und Lizenzen. Benennen Sie einen Kontoadministrator und ein Verfahren zum Entzug von Zugriff. Der Vertrag soll Vertraulichkeit, personenbezogene Daten, Unterauftragnehmer, Vorfallsmeldungen, Backups, Dokumentation und Übergabe beim Ende der Zusammenarbeit regeln.
Das NCSC empfiehlt Kunden, Belege für Sicherheitsbehauptungen von Lieferanten anzufordern und diese regelmäßig zu prüfen. Die NIST-Leitlinie behandelt Softwareprüfung, Schwachstellen und Komponenten im Lieferkettenrisiko. Passen Sie Fragen dem Risiko an. Ein System mit sensiblen Daten braucht mehr Prüfung als eine öffentliche Informationsseite.
Vergleichen Sie denselben Umfang. Ein Budget muss Discovery, Umsetzung, Tests, Deployment, Lizenzen, Cloud, Support und Änderungswünsche benennen. TCO umfasst nicht nur den ersten Release. Dazu gehören Betrieb, interne Zeit, Schulung, Wartung, Änderungsaufwand und das Risiko einer schlechten Integration.
Bei unsicherem Umfang ist ein bezahlter Pilot sinnvoll. Er braucht ein begrenztes Ziel, messbare Abnahmekriterien, Zugang zu nötigen Daten und eine klare Entscheidung nach seinem Ende. Ein Pilot ist kein billiger Prototyp ohne Verantwortung.
Fragen Sie bei jeder Referenz nach Kontext, Rolle des Lieferanten, Problem, Umfang, Ergebnis und Zusammenarbeit. Sprechen Sie wenn möglich ohne den Lieferanten mit dem Kunden. Bewerten Sie Kandidaten getrennt vor der gemeinsamen Diskussion. Vergleichen Sie dann die Unterschiede zwischen Betrieb, Finanzen, Sicherheit und Nutzern.
Warnsignale sind ein unklarer Umfang, Druck zur Unterschrift, eine Schätzung ohne Annahmen, unklare Eigentumsverhältnisse, fehlende Tests, unbestimmter Support und eine Referenz ohne überprüfbaren Kontext. Bestätigen Sie vor der Auswahl Problem, Kriterien, Budget, Risiken, Entscheider und den Plan für die ersten 90 Tage.
Lesen Sie unseren Ablauf, den Leistungsüberblick, die Sicherheitsseite, die Preise und die Bedingungen. Nutzen Sie den Rechner, bereiten Sie die Matrix vor und besuchen Sie weitere Entscheidungshilfen im Blog. Danach kann die Shortlist zur gemeinsamen Discovery kommen.

Eine Prüfliste für Sicherheit, Integrationen, Datenrollen, Eigentum, Support und Ausstieg vor dem Softwarevertrag.

Erstellen Sie einen Business Case für Software oder Automatisierung aus gemessenen Prozesskosten, TCO, Szenarien, Sensitivität und Abbruchkriterien.

Praxisnah erklären wir Semantik, Tastaturbedienung, Fokus, Kontrast, Formulare, Reflow, reduzierte Bewegung und die Grenzen automatischer Tests bei Rise.sk.