18. August 2026 · Morten Babakhani
Cloud-HR-Suiten liefern regelmäßig neue Releases, unabhängig davon, ob Sie sie wollen. Bei SAP SuccessFactors bedeutet das: zweimal im Jahr ein großes Release, dazu laufend kleinere Änderungen. Wer darauf nicht vorbereitet ist, merkt Änderungen daran, dass der Betriebsrat anruft.
Was Sie tatsächlich prüfen müssen
Nicht alles. Der übliche Fehler ist ein Regressionstest über den gesamten Funktionsumfang — das schafft niemand halbjährlich und wird nach dem zweiten Mal stillschweigend übersprungen.
Prüfen Sie stattdessen konsequent drei Bereiche.
Alles, was Sie konfiguriert haben. Eigene Felder, Geschäftsregeln, Berechtigungsrollen, Workflows. Standard testet der Hersteller; Ihre Konfiguration testet niemand außer Ihnen.
Alle Schnittstellen. Payroll, Zeitwirtschaft, Identity Management, Dokumentenmanagement. Feldlängen und Wertelisten ändern sich seltener, aber wenn, dann lautlos.
Alles, was rechtlich relevant ist. Entgeltdaten, Fristen, Berechtigungen, Protokolle. Ein stiller Wechsel einer Standardberechtigung ist der Fehler, der Sie wirklich Zeit kostet.
Was sich automatisieren lässt
Der Aufwand liegt nicht im Klicken, sondern im Erkennen von Abweichungen. Deshalb lohnen sich zwei Automatisierungen, die viele unterschätzen.
Erstens: Konfigurationsvergleiche. Ziehen Sie vor und nach dem Release einen Auszug Ihrer Konfiguration und vergleichen Sie automatisch. Was sich geändert hat, ohne dass Sie es geändert haben, ist Ihre Testliste.
Zweitens: Schnittstellenabgleiche. Ein Skript, das Datensätze in Quelle und Ziel zählt und Stichproben feldweise vergleicht, findet mehr als eine Klickstrecke.
Oberflächentests sind teuer und brechen bei jeder Layoutänderung. Wir automatisieren dort nur die Wege, deren Ausfall den Betrieb stoppt — Anmeldung, Antragstellung, Genehmigung.
Der Terminplan, der funktioniert
Vier Wochen vor dem Release: Release-Notes lesen und je Änderung entscheiden, ob sie Sie betrifft. Diese Sitzung dauert zwei Stunden und ersetzt zwei Wochen Nacharbeit.
Drei Wochen vorher: Testfälle anpassen und in der Vorschau-Instanz durchgehen.
Zwei Wochen vorher: Fachbereiche über sichtbare Änderungen informieren. Nicht mit den Release-Notes des Herstellers, sondern mit drei Sätzen zu dem, was auf ihrem Bildschirm anders aussieht.
Nach dem Release: eine Woche mit erhöhter Aufmerksamkeit im Service, dann Nachbereitung mit Aktualisierung der Dokumentation.
Die Änderungen, die niemand mitteilt
Manche Anpassungen betreffen nur die Standardwerte neuer Objekte oder eine Beschriftung. Für Sie können sie erheblich sein, wenn Ihre Prozessdokumentation genau diese Beschriftung zitiert oder Ihre Schulungsunterlagen diesen Klickweg zeigen.
Deshalb gehört in den Nachlauf jedes Releases eine Aufgabe, die gern vergessen wird: die Dokumentation nachziehen. Wer sie einmal ausfallen lässt, hat nach zwei Jahren Unterlagen, die niemand mehr glaubt.
Wer im Release-Termin sitzt
Der Termin, in dem über die Release-Notes gesprochen wird, entscheidet über den Aufwand danach. Vier Rollen gehören hinein: die Person, die die Konfiguration kennt, jemand aus dem Fachbereich, der die Prozesse verantwortet, die Schnittstellenverantwortung und — bei Änderungen an Berechtigungen oder Auswertungen — der Datenschutz.
Zwei Stunden mit diesen vier Personen ersetzen zwei Wochen Nacharbeit. Ohne den Fachbereich werden Änderungen übersehen, die auf dem Bildschirm sichtbar sind; ohne die Schnittstellenverantwortung fällt der Feldwechsel erst im nächtlichen Lauf auf.
Ergebnis des Termins ist eine Liste mit drei Spalten: betrifft uns, betrifft uns nicht, unklar. Nur die dritte Spalte kostet danach noch Zeit.