Bye-bye, SAP HCM ?

Dans ce nouveau monde hétéroclite, le consultant SAP HCM classique est en train de mourir ; les architectures HCM les plus diverses vont nous accompagner dans les années à venir et exigent une expertise très différente.

Celui qui n'est pas en mesure de suivre est rapidement écarté de la scène. Malgré des questions en suspens, l'architecture HCM "full cloud" séduit par son charme et les clients disposant d'installations HCM vieillissantes, en particulier, s'arment pour le changement.

Seule la douloureuse question des licences freine l'esprit pionnier des entreprises suisses. Pour des raisons de coûts, certaines entreprises optent pour un scénario hybride, dans lequel SAP SuccessFactors est exploité comme une simple suite de gestion des talents communiquant avec un backbone HCM.

Mais l'avenir est clairement au cloud et les scénarios "full cloud" vont envahir le marché.

Full Cloud HCM, Success-Factors et Cloud Payroll

La caractéristique décisive de l'architecture full-cloud réside dans la gestion des données de base dans SuccessFactors, dans le module Employee Central (EC).

EC remplace complètement l'administration du personnel et la gestion de l'organisation. Le coup de grâce pour PA20 et PA30, nos fidèles compagnons des 20 dernières années.

Ce qui est passionnant, c'est que SAP a réussi en un temps record à amener EC au même niveau que la gestion des données de base dans SAP HCM. Des champs locaux pour plus de 17 pays, une solution qui permet d'alimenter un système de paie rattaché avec toutes les données relatives aux salaires.

Le premier obstacle dans un projet "full cloud" est déjà évident : où fait-on la jonction entre EC et les systèmes de paie ?

Certains clients utilisent EC uniquement pour les données de base globales et toutes les données locales sont gérées dans les systèmes de paie, qui peuvent eux-mêmes être exploités on premise ou dans le cloud.

D'autres clients optent pour la "vraie" stratégie full-cloud et gèrent entièrement toutes les données dans EC, de sorte que les systèmes de paie ne servent plus qu'à produire les salaires mensuels.

Tant qu'EC ne comportera pas son propre moteur de paie, ce thème fera l'objet de discussions dans chaque projet Full Cloud et suscitera également des voix critiques qui se demanderont à quoi sert le Full Cloud si l'on doit encore rattacher un Payroll SAP "classique" derrière.

Nous considérons cela comme une phase de transition, faisant partie du processus de transformation, et si la paie est également obtenue à partir du cloud, les arguments critiques peuvent également être réfutés.

Dans le monde du "full cloud" pur, toutes les données relatives à la paie sont donc gérées dans EC et transférées de là vers un système de paie externe. Et là encore, il existe différentes options d'architecture.

En plus de la solution de paie en nuage hébergée par SAP (basée sur ERP 6.0), les systèmes SAP sur site déjà existants du client peuvent être connectés.

Il existe également des fournisseurs de BPO sur le marché qui peuvent mettre en place l'intégration des données de paie dans leurs systèmes. Il peut s'agir de systèmes de paie basés sur SAP, mais aussi sur des systèmes non-SAP. Il n'y a que l'embarras du choix et les processus de décision sont souvent longs.

Beam me up, Boomi

Reste à savoir comment les données d'EC sont transférées dans les systèmes de paie respectifs. SuccessFactors offre un grand nombre d'API qui peuvent être utilisées pour des scénarios d'intégration.

Outre les interfaces oData plus récentes, l'intégration de la paie standard était basée sur l'interface SFAPI basée sur SOAP. Toutes les données ne sont pas accessibles via les deux types d'interfaces, mais SAP n'a cessé d'étendre les interfaces oData, de sorte que l'on peut s'attendre à l'avenir à une couverture complète par les API oData.

Le middleware Boomi est actuellement disponible pour le transfert des données de facturation d'EC vers un système de paie SAP. SAP fournit à cet effet un contenu iFlow prédéfini qui effectue les conversions de données nécessaires.

Dans cette constellation, Boomi fait office de maître de réplication. Cela signifie que la réplication des données est déclenchée par Boomi. La première étape consiste à appeler l'API SuccessFactors, qui fournit les données modifiées des employés.

Une sélection des données modifiées depuis la dernière réplication est effectuée, de sorte qu'un fullload n'est jamais transmis. Après la conversion des données au sein de Boomi, un service web est appelé dans SAP et les données préparées lui sont transmises sous forme de fichier XML.

Le mappage spécifique au client des valeurs de champ peut être entièrement configuré dans SAP ; une grande partie est possible via des tables de Customizing.

Si cela ne suffit pas, le client dispose d'autres possibilités grâce à ses propres implémentations de BAdI. Le traitement s'effectue de manière séquentielle et est visible à tout moment dans le journal des applications.

Les éventuels messages d'erreur pendant le traitement sont signalés par SAP à EC via un processus Boomi séparé, où ils sont visibles dans le Data Replication Monitor.

Le gestionnaire du personnel a alors la possibilité de corriger les données erronées et de marquer à nouveau la personne pour une réplication. Les modifications de données traitées avec succès sont également communiquées à EC.

Les programmes et services nécessaires dans SAP sont livrés sous forme d'add-on. Les patches pour cet add-on suivent la stratégie de patches de la solution cloud.

Depuis quelque temps, le client peut choisir d'assurer l'intégration avec l'add-on ou d'appliquer l'intégration intégrée dans les dernières versions de HCM.

Un mash-up trompeur ?

Malheureusement, il n'est pas possible - à ce jour - de gérer dans EC toutes les données relatives à la paie. Cela concerne les infotypes spécifiques aux clients ou à certains pays.

Pour que l'utilisateur final ne remarque pas cette lacune et pour éviter que la gestion directe des données dans le système de paie ne soit malgré tout nécessaire, SAP a mis en place la technique du mash-up.

La gestion des données s'effectue ici via une application Webdynpro-Abap du système SAP, qui est intégrée directement dans EC sous forme d'iFrame. L'application de gestion des données de base du personnel basée sur le web, livrée pour la première fois avec HR Renewal, est utilisée à cet effet.

La connexion au système SAP se fait par SSO basé sur SAML2. Pour cela, chaque utilisateur RH autorisé à gérer les mash-ups doit disposer d'un utilisateur dans le système SAP. L'utilisateur n'a cependant pas connaissance du processus de connexion proprement dit.

Toutes les questions sont donc enfin réglées et la facturation peut commencer. Le décompte s'effectue directement dans le système de paie SAP, le bon vieux RPCalc vous salue. Mais ici aussi, l'innovation est de mise.

Jusqu'alors, il était souvent nécessaire d'accéder à l'interface utilisateur graphique SAP via VPN, mais aujourd'hui, grâce au nouveau Payroll Control Center, l'ensemble du traitement de la paie peut être entièrement basé sur le web.

Du point de vue de l'infrastructure déjà en place, l'intégration des mash-ups dans EC et la connexion de Boomi à un système SAP on-premise impliquent certaines transformations.

Si jusqu'à présent, il suffisait dans de nombreux cas de rendre le système SAP HCM accessible uniquement en interne ou par VPN, cela ne suffit plus dans le monde du cloud. L'accès depuis EC se fait en temps réel soit par l'utilisateur soit par Boomi.

Les interfaces de fichiers sont donc supprimées et ne sont pas proposées par SAP dans la version standard. L'accès se fait en ligne via HTTPS directement dans le système SAP. Les systèmes doivent donc être rendus accessibles depuis Internet.

Un dispatcher web SAP ou un autre reverse proxy déjà présent dans la DMZ garantit la sécurité nécessaire. Un login basé sur un certificat pour les services web ou une liste blanche IP peuvent encore renforcer la sécurité.

Pièges à éviter, choses à faire et à ne pas faire

Contrairement à l'ancienne stratégie de patchs SAP (Enhancement Packages annuels et HR Patches mensuels), la stratégie change dans le Cloud. Désormais, les corrections d'erreurs et les nouvelles fonctions arrivent sur le marché à un rythme trimestriel et sont aussitôt "imposées" à tous les clients.

Le client cloud n'a pas le choix d'avoir ou non la nouvelle version. Ce qui présente des avantages, mais aussi certains risques. En effet, ce n'est pas seulement la version SAP SuccessFactors qui est patchée, mais également le contenu Boomi et l'add-on SAP.

Si l'on souhaite profiter des nouvelles fonctions ou si l'on est confronté à une erreur de réplication, le patching de Boomi et de SAP (par le client) est indispensable. Tant que l'intégration dans SAP se fait via un add-on séparé, cela ne pose pas de problème majeur.

Mais si le client utilise l'intégration livrée via HR Packages, un patching des composants HR est nécessaire tous les trimestres, ce qui implique un travail d'implémentation et de test.

Un autre aspect de l'intégration concerne les utilisateurs nécessaires dans SAP. Comme mentionné ci-dessus, tous les utilisateurs de mash-up doivent disposer d'un utilisateur SAP. La plupart du temps, le nombre de ces utilisateurs est raisonnable et peut donc être géré sans stress.

Si, en revanche, le payslip généré dans SAP doit être mis à la disposition des collaborateurs via EC, tous les collaborateurs ont soudain besoin d'un utilisateur SAP (scénario de libre-service), et c'est au plus tard à ce moment-là que la double gestion des utilisateurs devient plus qu'ennuyeuse.

Entre-temps, SAP propose un programme de génération qui crée les utilisateurs SAP sur la base des matricules répliqués. Les utilisateurs sont alors nommés selon l'ID utilisateur EC (qui correspond à peu près au matricule), ce qui peut enfreindre les conventions d'appellation existantes.

De même, l'intégration dans une gestion centrale des utilisateurs n'est possible que dans une certaine mesure. SAP recommande de gérer les utilisateurs de SuccessFactors et de SAP via sa solution de gestion des identités.

Dans la pratique, ce n'est toutefois pas absolument nécessaire, pour autant que l'on puisse vivre avec les limites du rapport d'utilisateur ou renoncer à la génération automatique d'utilisateurs.

Lors de l'implémentation de EC, le modèle de données SAP sous-jacent doit être pris en compte dans tous les cas. Les clés, par exemple les catégories de collaborateurs ou autres, devraient être conçues de manière uniforme dans EC et SAP chaque fois que cela est possible, de sorte qu'un mappage ultérieur du contenu des champs ne soit que très peu nécessaire.

Cela permet également de s'assurer que la longueur maximale des champs dans SAP n'est pas dépassée. Les adaptations apportées aux champs pertinents pour la facturation au sein de EC entraînent souvent une adaptation dans le système de paie SAP.

Il faut en tenir compte dans le projet comme dans l'exploitation courante, de sorte que les deux domaines soient toujours synchronisés.

Si EC et un système de paiement SAP sont mis en place en même temps, le monde est relativement simple. Mais si un nouveau système EC doit être connecté via Boomi à un système de gestion des paiements SAP existant ou si un système EC existant doit être connecté à un nouveau système de gestion des paiements SAP, cela nécessite une analyse approfondie de tous les paramètres.

Les configurations incompatibles doivent être adaptées et il n'est souvent pas possible d'éviter ce que l'on appelle le fractionnement des données. Un split de données signifie qu'un enregistrement doit être divisé en deux à la fois dans SAP et dans EC à la date de référence, afin que seules les données à partir d'une certaine date soient répliquées. Il n'existe aujourd'hui aucun outil permettant de réaliser ces splits, ni dans SAP ni dans EC.

Il faut également être conscient que dans cette variante d'architecture, il faut en fait configurer deux systèmes de manière "redondante" : SAP-Payroll et EC. Ces configurations doubles augmentent également la charge de travail par rapport à une installation SAP HCM on premise.

Le futur ? Un regard dans la boule de cristal

Le remplacement de Boomi par Hana Cloud Integration (HCI) est prévu pour 2015. Ce qui a déjà été réalisé dans le scénario hybride doit maintenant être mis à la disposition des clients full-cloud.

Mais comme la HCI ne fait pas partie de la licence EC dans l'offre actuelle (contrairement à Boomi), les clients existants ne changeront probablement pas. Pour les nouveaux clients, la HCI pourrait être intéressante, car pour la réplication, le système SAP ne doit plus être accessible depuis Internet, mais le transfert de données est initié par un agent (programme sur un serveur chez le client) et le trafic n'a donc lieu que de manière sortante.

L'utilisation des mash-ups nécessite toutefois toujours l'ouverture de certaines URL vers l'extérieur.

Il convient de continuer à suivre l'évolution de l'intégration add-on versus standard RH. Comme mentionné ci-dessus, l'intégration directe dans le standard RH peut entraîner une augmentation de la charge de travail pour le client en raison de la modification des cycles de patch.

On attend avec impatience les nouvelles interfaces basées sur Fiori qui seront déployées à l'automne. SuccessFactors s'aligne ainsi sur le paradigme UX de SAP et se présentera à l'avenir encore plus comme une solution d'un seul tenant, même si derrière elle, une multitude de technologies et de systèmes différents sont encore à l'œuvre.

Et la question cruciale, dont nous attendons la réponse avec impatience de la part de SAP, est bien sûr l'avenir de SAP Payroll. Sera-t-elle un jour totalement intégrée dans EC ou même dans S/4 ? Le suspense reste entier et tous les regards et les oreilles sont tournés vers Walldorf...