HR-Softwareauswahl Fehler: Die 11 teuersten Stolpersteine im Auswahlprozess

Die häufigsten Fehler sind eine Bauchentscheidung ohne gewichteten Anforderungskatalog, eine zu kleine oder zu oberflächliche Teststichprobe in der Demo, die Verwechslung von vorhandenem Feature und tatsächlich nutzbarem Feature, ein unterschätzter Datenmigrationsaufwand, eine zu späte Einbindung des Betriebsrats sowie eine zu optimistisch kalkulierte Implementierungsdauer. Keiner dieser Fehler liegt an der Softwarequalität selbst, sondern am Ablauf des Auswahlprozesses.

Weil HR-Software in der Regel für ein bis drei Jahre vertraglich gebunden wird und tief in Personalstammdaten, Payroll und Zeitwirtschaft eingreift. Eine Entscheidung nach Demo-Eindruck statt nach einem gewichteten Anforderungskatalog lässt sich später kaum sauber rechtfertigen und im Zweifel nur mit hohem Aufwand korrigieren, weil ein Anbieterwechsel eine erneute Datenmigration und eine neue Einführung nach sich zieht.

Sofern ein Betriebsrat besteht, gehört er bereits in die Zielbild- und Anforderungsphase, nicht erst in die Wochen vor dem Go-live. Rechtsgrundlage ist die Unterrichtungspflicht aus Paragraf 80 Absatz 2 Betriebsverfassungsgesetz in Verbindung mit dem Mitbestimmungstatbestand aus Paragraf 87 Absatz 1 Nummer 6 Betriebsverfassungsgesetz, sobald die Software zur Kontrolle von Verhalten oder Leistung geeignet ist. Eine verspätete Information verschiebt das Problem lediglich in die Vertragsphase, sie löst es nicht.

Ein Häkchen in der Anbietermatrix beantwortet nur die Frage, ob eine Funktion theoretisch existiert, nicht ob sie im gewünschten Umfang ohne Zusatzkosten und ohne Individualentwicklung nutzbar ist. Zwischen im Standard enthalten und nur über einen Partner verfügbar liegen in der Praxis erhebliche Preis- und Aufwandsunterschiede, die sich erst durch konkreten Nachweis im Demotermin klären lassen.

Weil der Aufwand selten im technischen Datentransfer liegt, sondern in der Qualität der Altdaten. Uneinheitliche Bezeichnungen, doppelte Personalnummern aus früheren Fusionen und fehlende digitale Historien für Elternzeit oder Teilzeitphasen fallen häufig erst bei einem echten Testlauf mit realen Daten auf, und dieser Testlauf wird in vielen Projekten erst nach der Vertragsunterschrift durchgeführt, wenn eine Korrektur bereits teuer ist.

Cloud-Lösungen im Mittelstand werden überwiegend mit Mindestlaufzeiten von zwölf bis vierundzwanzig Monaten angeboten, größere Systeme binden häufig mehrjährig, in der Praxis meist ein bis drei Jahre. Ein früher Ausstieg ist bei den meisten Verträgen kaum vorgesehen, und automatische Verlängerungen sind zu beachten. Wer sich falsch entscheidet, zahlt die Lizenz über die gesamte Restlaufzeit weiter und trägt zusätzlich die bereits investierten Kosten für Migration und Schulung.

Alle Anbieter sollten dieselben Szenarien mit realitätsnahen eigenen Daten durchspielen, nicht mit den Musterdaten des Anbieters. Mehrere Endnutzer aus unterschiedlichen Rollen sollten teilnehmen, ein Pflichtszenario mit einem echten Sonderfall wie einer rückwirkenden Entgeltänderung sollte enthalten sein, und die Bewertung sollte nach einem vorab verteilten, gewichteten Bewertungsbogen erfolgen statt nach dem Gesamteindruck im Raum.

Zu prüfen sind unter anderem ELStAM, das DEÜV-Meldeverfahren, die Sofortmeldung, die Pfändungsberechnung, die betriebliche Altersversorgung, das Kurzarbeitergeld und das Bescheinigungswesen. Bei österreichischer oder Schweizer Beteiligung kommen zusätzliche länderspezifische Anforderungen hinzu. Wird die Abrechnung nur über einen lokalen Partner statt im System selbst abgebildet, entsteht ein zusätzlicher Vertrag mit geteilter Verantwortung im Fehlerfall.

Nach der HR Systems Survey der Sapient Insights Group für 2023/2024 hielt ein Viertel der befragten Organisationen den ursprünglich geplanten Zeitplan ihrer HR-Systemeinführung nicht ein, und 28 Prozent hatten laut derselben Erhebung kein Change-Management-Budget in ihrer HR-Technologieplanung vorgesehen. Ein Realitätspuffer von mindestens zwanzig Prozent auf die vom Anbieter genannte Dauer sowie eine feste, ausreichend freigestellte interne Projektleitung reduzieren dieses Risiko spürbar.

Weil Anbieter ihre Entwicklungsressourcen historisch auf ein bis zwei Kernmodule konzentrieren, meist dort, wo die Suite ursprünglich entstanden ist. Die übrigen Module werden mitgeliefert, um den Vertrag zu vervollständigen, bleiben fachlich aber häufig nur durchschnittlich. Der Vorteil einer Suite liegt in weniger Schnittstellen und einem Vertragspartner, nicht in gleichmäßiger fachlicher Tiefe über alle Module hinweg.

In vielen Projekten gehen Anforderungskatalog, Bewertungsbögen, Rollenkonzept und Demo-Ergebnisse nach der Unterschrift verloren, weil Auswahl- und Einführungsteam personell nicht identisch sind oder die Ergebnisse nicht vertraglich festgeschrieben wurden. Das Einführungsprojekt beginnt dann inhaltlich bei null und verhandelt Punkte neu, die in der Auswahlphase eigentlich bereits geklärt waren. Wer die Ergebnisse als Abnahmekriterien in den Vertrag aufnimmt und möglichst dieselbe Projektleitung durch beide Phasen führt, vermeidet diesen Bruch.

Zur Mindestprüfung gehören ein Auftragsverarbeitungsvertrag nach Artikel 28 DSGVO, der Serverstandort und ein möglicher Drittlandtransfer, insbesondere bei US-Anbietern unter dem Stichwort Schrems II, die vollständige Kette der Sub-Auftragsverarbeiter bei Cloud-Suiten, die technisch-organisatorischen Maßnahmen nach Artikel 32 DSGVO sowie ein Löschkonzept für Personalakten. Bei umfangreicher automatisierter Bewertung von Beschäftigten ist zusätzlich zu prüfen, ob eine Datenschutz-Folgenabschätzung nach Artikel 35 DSGVO erforderlich ist.

Neben dem reinen Lizenzpreis sollten das Preismodell, also pro Kopfzahl oder pro aktivem Nutzer, Mindestabnahmemengen, jährliche Preissteigerungsklauseln, Setup- und Onboarding-Gebühren, die Kosten für höhere Support-Level und zusätzliche Umgebungen sowie mögliche Exit-Kosten beim Datenexport geprüft werden. Erst eine Gesamtkostenbetrachtung über drei bis fünf Jahre macht Angebote unterschiedlicher Anbieter wirklich vergleichbar.

Am zuverlässigsten wirkt eine Kombination aus mehreren Maßnahmen: ein gewichteter Anforderungskatalog mit beobachtbaren Anforderungen statt einer Featureliste, eine strukturierte Demo mit echten Daten und mehreren Testpersonen, eine frühe Einbindung von Betriebsrat, Datenschutz und IT, eine geprüfte DACH-Payroll-Fähigkeit sowie eine belastbare Wirtschaftlichkeitsrechnung über fünf Jahre. Ein KI-gestütztes Matching auf Basis des eigenen Anforderungskatalogs kann diesen Prozess zusätzlich absichern, indem es die Anbieterauswahl von Anfang an auf Basis der tatsächlichen Kriterien statt nach Bekanntheit eingrenzt.

Nachgewiesen werden sollten Single Sign-on, die automatische Benutzerverwaltung nach SCIM (RFC 7643 und RFC 7644), Ereignisse bei Eintritt, Änderung und Austritt sowie der Export an die Lohnabrechnung. Der Nachweis gehört in den Proof-of-Value mit einer Testumgebung und einem klaren Bestanden-oder-nicht-Kriterium. Eine bloße Zusage einer „offenen Schnittstelle“ oder die Ankündigung für ein späteres Release genügt nicht.

Die Verordnung (EU) 2023/2854 gilt seit dem 12. September 2025 für Datenverarbeitungsdienste, Software as a Service eingeschlossen. Nach Art. 25 muss der Vertrag unter anderem eine Kündigungsfrist für den Wechsel von höchstens zwei Monaten und einen Übergangszeitraum von höchstens 30 Tagen vorsehen. Art. 29 untersagt ab dem 12. Januar 2027 Wechselentgelte. Wie das auf ein konkretes Produkt zutrifft, sollte die Rechtsberatung prüfen.

Belastbar wird sie durch drei Bausteine: eine RACI-Matrix, die je Phase festlegt, wer verantwortlich ist, entscheidet und gehört wird, ein Entscheidungsprotokoll mit Ziel, Optionen, Bewertung, Risiko und Empfehlung sowie ein Risikoregister mit Verantwortlichen und Fristen. Zusammen machen sie nachvollziehbar, warum ein Anbieter gewählt wurde, und helfen der Einführung, die Auswahlergebnisse als Abnahmekriterien zu übernehmen.

Sinnvoll sind wenige, eindeutig definierte Kennzahlen je Phase, etwa die Abdeckung der Muss-Kriterien je Finalist, die Zahl offener roter Risiken, die Vollständigkeit der Datenschutzunterlagen, der Anteil bestandener Integrationsszenarien und die Fehlerquote eines Probeexports. Nach dem Go-live kommen die Nutzung der Selbstbedienung und die Abweichung der Gesamtkosten hinzu. Zielwerte legt das Projekt selbst fest, bevor Anbietergespräche beginnen.