Immer wieder laufen SuccessFactors-Projekte zeitlich und kostenseitig aus dem Ruder. Oliver Brück überrascht das nicht: „Viele Unternehmen starten mit dem Anspruch, bestehende Prozesse aus dem gewachsenen Altsystem 1 zu 1 zu übernehmen.“ Anstatt diese über Jahre, Jahrzehnte gewachsene Komplexität von Beginn an bewusst zu reduzieren, würden sie einfach in die Cloud verlagert.
„Das Ergebnis sind individuelle Sonderlösungen, die den Aufwand treiben, Entscheidungsprozesse verlangsamen und das Projekt in eine permanente Abstimmungsschleife zwingen“, so Brück. Wer dies vermeiden möchte, sollte vor dem Go-Live folgende Punkte klären:
1. Kein Projektstart ohne klares HR-Zielbild
Das HR-Zielbild ist das Fundament jeder SuccessFactors-Einführung. Ohne es fehlt dem Projekt die Orientierung für alle nachgelagerten Entscheidungen. Was soll das System leisten? Welche Prozesse aus dem Altsystem werden abgelöst? Welche bleiben bewusst im On-Premise-Betrieb? Was ändert sich für Mitarbeitende und Führungskräfte in der täglichen Arbeit?
Fragen, die selbstverständlich klingen, in der Praxis erfahrungsgemäß aber häufig erst im Projektverlauf beantwortet werden. „Das ist zu spät“, warnt Brück. Wer hingegen vor dem Projektstart explizit klärt, welche Module eingeführt werden und welche Kernprozesse vorerst im bestehenden HCM-System verbleiben sollen, hält den Scope beherrschbar und ermöglicht strukturierte Entscheidungen während der Implementierung.
Brück empfiehlt, das Zielbild als lebendiges Dokument zu behandeln, das sich im Projektverlauf schärfen darf, aber nie ganz offen bleiben sollte. „Wer ohne strategische Vorbereitung startet, erhöht Komplexität, Projektrisiko und Kosten.“
2. Chancen und Grenzen der Cloud frühzeitig verstehen
Eine SuccessFactors-Einführung ist ein Transformationsprojekt. Entsprechend wichtig ist es, Möglichkeiten und Grenzen des Cloud-Systems bereits in der Vorbereitungsphase gründlich auszuloten. „Nur so können Verantwortliche, Entscheidungen treffen, welche Anforderungen umgesetzt werden können und welche nicht“, so Brück. Für ihn sollte die frühzeitige Einführung des Projektteams in die neue Lösung entsprechend intensiv angegangen werden.
Das bedeutet konkret: Best-Practice-Konfigurationen werden früh im Kundensystem bereitgestellt und alle relevanten Prozesse gemeinsam mit dem Implementierungspartner durchlaufen. Das macht Standardprozesse sichtbar, Grenzen des Systems erkennbar und den eigenen Anforderungskatalog realistischer. „Unternehmen, die diesen Schritt überspringen, verlieren später womöglich viel Zeit mit Anforderungen, die sich bei früherer Systemkenntnis als obsolet erwiesen hätten“, so Brücks Erfahrung.
3. Standardisierung als strategische Entscheidung treffen
Standardisierung wird im Cloud-Kontext oft mit Funktionsverzicht gleichgesetzt. Das erzeugt Widerstände und kann Projekte ausbremsen. „Dabei heißt Standard nicht, per se auf alles Bekannte zu verzichten. Vielmehr steht Standardisierung für die bewusste Entscheidung, erprobte, vorgegebene Prozesse zu implementieren“, differenziert Brück. Seiner Erfahrung nach liegt ein realistischer Standardisierungsgrad zwischen 50 und 70 Prozent. Mehr sei in gewachsenen Systemlandschaften selten erreichbar.
Daher sollten sich Projektteams bei jeder Sonderanforderung diese kritische Frage stellen: Ist diese Abweichung vom Standard für den Go-Live wirklich zwingend notwendig oder handelt es sich um ein Nice-to-have, das in einem zweiten Release nachgezogen werden kann? „Je konsequenter dieser Filter angewendet wird, desto stabiler, wartungsärmer und zukunftssicherer wird die resultierende Lösung.“