Das Wichtigste in 30 Sekunden
Ein Softwarewechsel muss neben Kundenanfragen, Bewerbungen und laufenden Einsätzen funktionieren. Eine begrenzte erste Stufe kann das Risiko senken, wenn Daten, Zuständigkeiten und Parallelbetrieb vorher geklärt sind.
- Definiere einen überschaubaren ersten Arbeitsbereich.
- Prüfe Daten und Abläufe vor der Umstellung.
- Lege fest, wer entscheidet und wann der Parallelbetrieb endet.
Warum scheitert der Wechsel an einem Stichtag?
Weil ein Stichtag verlangt, dass alles gleichzeitig fertig ist: Daten, Abläufe, Schulung und Vertretungen. Wenn einer dieser Bereiche später fertig wird, kann das den gemeinsamen Starttermin gefährden. Am Stichtag verschiebt sich dann alles und nicht nur der eine Teil.
Das ist kein Planungsfehler, sondern eine Eigenschaft von Betrieben ohne Projektreserve. Wer fünfzehn Menschen im Innendienst hat, hat keine zwei davon frei. Jede Projektstunde ist eine Stunde, die an einer Anfrage fehlt. Ein Wechsel in Stufen verteilt diese Last, ein Stichtag bündelt sie.
Dazu kommt ein Effekt, der selten eingeplant wird. Am Stichtag arbeiten alle zum ersten Mal produktiv im neuen System. Die Zahl der Fragen ist an diesem einen Tag am höchsten und sie treffen auf ein Team, das gleichzeitig Anfragen bearbeiten muss. Bei einer stufenweisen Umstellung verteilen sich dieselben Fragen über Wochen.
Was lässt sich stufenweise umstellen?
Fast alles, was vor der Abrechnung liegt. Anfragen, Kandidaten, Bewerbungen und Reichweite lassen sich schrittweise in ein neues System bringen, während Lohn, Abrechnung und Verträge zunächst dort bleiben, wo sie sind. Der Bruch entsteht dann nicht an einem Tag, sondern an einer Schnittstelle.
Diese Aufteilung hat einen einfachen Grund. Im Recruiting ist ein Fehler ärgerlich und korrigierbar. In der Abrechnung ist er ein Schaden mit Nachlauf. Deshalb steht die Abrechnung in vielen Wechselprojekten am Ende und nicht am Anfang.
Daraus folgt eine praktische Regel für die erste Stufe. Sie sollte etwas umfassen, das täglich genutzt wird und dessen Fehler am selben Tag auffallen. Die Bearbeitung von Bewerbungen erfüllt beides. Ein Bereich, der nur monatlich genutzt wird, liefert erst nach vier Wochen die erste Rückmeldung.
Wie eine solche Konstellation aussieht, beschreibt die Seite talent360 neben zvoove betreiben. Was vor einer solchen Verbindung geklärt gehört, steht in zvoove API und talent360.
Welche Annahmen halten im Projekt nicht?
Drei kommen regelmäßig vor: dass die Daten sauberer sind als sie sind, dass Abläufe im Kopf aller Beteiligten gleich aussehen und dass Schulung eine einmalige Veranstaltung ist. Jede dieser Annahmen verschiebt einen Zeitplan um Wochen und alle drei zusammen erklären die meisten gescheiterten Projekte.
Auf einen Blick
| Annahme | Was tatsächlich passiert |
|---|---|
| Die Daten sind gepflegt | Ein Drittel der Felder ist leer, doppelt oder frei getippt |
| Alle arbeiten gleich | Jede Niederlassung hat eigene Gewohnheiten, die niemand aufgeschrieben hat |
| Eine Schulung reicht | Der Bedarf entsteht erst in Woche drei, wenn die ersten Sonderfälle auftauchen |
| Das Altsystem kann sofort abgeschaltet werden | Es wird noch Monate für Auskünfte und Nachweise gebraucht |
| Der Export enthält alles | Notizen, Absagegründe und gespeicherte Sichten fehlen häufig |
Die letzte Zeile ist der teuerste Punkt. Der eigentliche Wert eines gewachsenen Systems liegt oft in Informationen, die kein Pflichtfeld sind: warum ein Kunde eine Qualifikation abgelehnt hat, welcher Ansprechpartner tatsächlich entscheidet, welcher Satz durchging.
Was davon übertragen wird, gehört vorher geprüft. Der verlinkte Beitrag Datenmigration beschreibt das Vorgehen.
Die zweite Zeile der Tabelle wird ebenfalls unterschätzt. In Betrieben mit mehreren Niederlassungen arbeitet jede anders, ohne dass das jemand als Abweichung wahrnimmt.
Ein Wechsel macht diese Unterschiede sichtbar und zwingt zu einer Entscheidung. Das ist unangenehm und der eigentliche Nutzen des Projekts, weil danach alle dieselbe Auswertung lesen können.
Was ändert sich 2027 an den Rahmenbedingungen?
Ab dem 12. Januar 2027 entfallen die vom Data Act erfassten Wechselentgelte einschließlich der Entgelte für den Datenabfluss. Ob der konkrete Dienst und die verlangte Leistung darunterfallen, ist vorab zu prüfen.
Daraus folgt kein kostenloses Gesamtprojekt: Einführung, Datenbereinigung und eigenständige Zusatzleistungen müssen gesondert betrachtet werden. Damit entfällt ein Kostenargument, das jahrelang gegen jeden Wechsel angeführt wurde.
Am Aufwand des Projekts selbst ändert diese Regel allerdings nichts.
Das Datum stammt aus der Erläuterung der Europäischen Kommission zum Data Act, der seit dem 12. September 2025 gilt. Wie sich der Stichtag auf Verhandlungen und Verträge auswirkt, behandelt Was der EU Data Act für Softwarewechsel praktisch verändert.
Gleichzeitig liegen im ersten Quartal 2027 zwei andere Termine, die dieselben Personen binden. Der gesetzliche Mindestlohn steigt zum 1. Januar 2027 und die Möglichkeit, sich von elektronischen Entgeltunterlagen befreien zu lassen, endet zum 31.
Dezember 2026. Wer ein Wechselprojekt in dieses Quartal legt, plant drei Vorhaben mit demselben Team.
Das spricht nicht gegen einen Wechsel im Jahr 2027. Es spricht gegen den Januar. Ein Start im zweiten Quartal trifft auf ein Team, das die gesetzlichen Fristen hinter sich hat und Aufmerksamkeit frei hat.
Woran merkst du, dass es zu viel wird?
Warnzeichen im Projekt
An drei Zeichen: Projekttermine werden verschoben statt abgesagt, Fragen aus dem Team bleiben tagelang unbeantwortet liegen und im Tagesgeschäft entstehen die ersten Rückstände bei Anfragen. Das dritte Zeichen ist das teuerste, weil es beim Kunden ankommt und nicht im Projekt.
Die Reaktion darauf ist nicht mehr Anstrengung, sondern weniger Umfang. Eine Stufe wird verschoben, nicht alle Stufen komprimiert. Ein Projekt, das drei Monate länger dauert, kostet weniger als eine Anfrage, die verloren geht, weil niemand Zeit hatte.
Hilfreich ist eine feste Grenze, die vorher vereinbart wird. Zum Beispiel: höchstens ein Projekttag pro Woche je beteiligter Person und keine Stufe startet, solange die vorige nicht abgeschlossen ist. Diese Grenze wirkt nur, wenn sie vor dem Projekt steht und nicht mittendrin.
Hilfreich ist außerdem ein fester wöchentlicher Termin von dreißig Minuten, in dem genau zwei Fragen beantwortet werden: Was ist offen und was hält auf. Längere Runden erzeugen Protokolle. Diese eine Runde erzeugt Entscheidungen und Entscheidungen sind das, woran Wechselprojekte in kleinen Betrieben hängen.
Was solltest du vor dem Start festlegen?
Vier Dinge, alle ohne Anbieter: die Reihenfolge der Stufen, den Umfang der ersten Stufe, das Ende des Parallelbetriebs und die Person, die entscheidet. Die vierte ist die wichtigste, weil ein Wechsel unterwegs Dutzende kleiner Entscheidungen erzeugt, die niemand vorhersehen kann.
- Stufen festlegen. Was zuerst, was danach. Alles vor der Abrechnung ist ein guter Anfang.
- Umfang der ersten Stufe begrenzen. Eine Niederlassung oder eine Berufsgruppe reicht als Start.
- Ende des Parallelbetriebs benennen. Ein festes Datum, ab dem das Altsystem nur noch lesend genutzt wird. Ohne dieses Datum läuft der Parallelbetrieb jahrelang weiter.
- Entscheider benennen. Eine Person, erreichbar, mit Mandat. Ein Gremium bremst jede Stufe aus, weil es nur zu festen Terminen zusammenkommt.
Eine ergänzende Einordnung mit den einzelnen Schritten steht im verlinkten Beitrag Systemwechsel. Dieser Beitrag ergänzt sie um die Erfahrungen, die in keiner Anleitung stehen, weil sie erst im laufenden Betrieb sichtbar werden.
Welche Quellen liegen der Einordnung zugrunde?
Die Datumsangaben stammen aus der Erläuterung der Europäischen Kommission zum Data Act sowie aus dem Gesetzestext zur Mindestlohnanpassung. Die beschriebenen Fehlannahmen sind eine betriebliche Einordnung und kein Messergebnis.
Für Erfolgsquoten von Softwareprojekten in der Personaldienstleistung liegt keine belastbare deutsche Erhebung vor, deshalb nennt dieser Beitrag dazu keine Zahl.
- Data Act explained · Europäische Kommission · Wegfall der Wechselentgelte ab 12. Januar 2027
- § 1 Fünfte Mindestlohnanpassungsverordnung · Bundesministerium der Justiz · Mindestlohn ab 1. Januar 2027
