S/4 On-Prem et SAP FSM : deux systèmes, un seul objectif

Comment la SAP Business Technology Platform (BTP), en tant que couche d'intégration, peut-elle relier S/4 On-Prem et SAP FSM et permettre un processus de service de bout en bout ?

S/4 Hana Service et SAP Field Service Management remplissent des fonctions différentes dans le processus de service. Le premier est axé sur la gestion des processus de gestion d'entreprise, tandis que SAP Field Service Management est conçu pour la gestion opérationnelle du service sur le terrain.

Cette répartition claire des tâches présente certes des avantages pour chaque rôle au sein du processus de service, mais en l'absence d'intégration, les informations doivent être harmonisées ou mises à jour manuellement entre les différents systèmes. Il en résulte, d’une part, des pertes d’efficacité organisationnelles dues aux ruptures de support et, d’autre part, une charge administrative accrue, alors que l’objectif des deux composants est justement d’éliminer au mieux ces charges.

Double saisie des données

Le défi réside toutefois très rarement dans les performances fonctionnelles de chaque système, mais plutôt dans leur interopérabilité.

Bien que SAP S/4 Hana et SAP Field Service Management soient tous deux des produits du même éditeur, ils reposent sur des modèles de données différents. Dans le système ERP, de nombreux objets de gestion sont étroitement liés les uns aux autres. Un ordre de service contient par exemple des références à des partenaires commerciaux, des articles, des objets techniques et des structures organisationnelles. Ces relations reflètent des liens commerciaux complexes. SAP Field Service Management utilise en revanche un modèle de données davantage axé sur les processus opérationnels de service. Les objets tels que les appels de service ou les activités sont structurés de manière plus compacte et s’orientent vers la planification des interventions sur le terrain.

En l'absence d'une intégration technique appropriée, les informations doivent donc être transférées manuellement d'un système à l'autre. Les problèmes typiques liés à cette situation sont la nécessité d’une double gestion des données de base telles que les clients ou les adresses, un manque de transparence quant à l’état actuel d’une intervention de service, ainsi que des ruptures de flux qui peuvent survenir entre la planification, le service extérieur et la facturation.

Couche d'intégration BTP

Dans de nombreuses organisations, ces lacunes sont comblées par des processus manuels. Les techniciens de maintenance documentent les informations séparément, tandis que les gestionnaires doivent regrouper les données provenant de plusieurs systèmes. Cela augmente considérablement la charge administrative et réduit considérablement l’avantage initial. Pour relever ces défis, une couche d’intégration entre les systèmes est nécessaire. Dans l’environnement SAP, ce rôle est assumé par la SAP Business Technology Platform (BTP). La BTP fournit une plateforme cloud qui relie différents systèmes entre eux. Pour les scénarios d’intégration, on utilise l’Integration Suite au sein de cette plateforme. Elle fait office de middleware entre les applications connectées.

Plateforme et couche d'intégration

Cette couche d'intégration a pour rôle d'orchestrer les flux de données entre les systèmes. Les informations provenant de S/4 Hana sont converties dans un format adapté, puis transmises à SAP Field Service Management. Les retours d'information provenant du service extérieur peuvent ensuite être retransmis de manière structurée au système ERP.

Pour simplifier, l'architecture peut être représentée en trois niveaux : Cette structure permet d'établir un couplage lâche entre les systèmes. Il est ainsi possible d'apporter des modifications à un système sans avoir à adapter l'ensemble de l'architecture d'intégration.

Orchestration avec Integration Suite

Au sein de la SAP Business Technology Platform, l'Integration Suite se charge de la mise en œuvre opérationnelle de l'intégration des systèmes. La logique d'intégration est modélisée dans ce que l'on appelle des flux d'intégration (iFlows). Ces iFlows définissent la manière dont les messages sont reçus, transformés, puis transmis aux systèmes cibles.

Un flux d'intégration type comprend plusieurs étapes. Tout d'abord, la plateforme reçoit un message provenant du système ERP. Les données qu'il contient sont ensuite analysées et transposées dans la structure du système cible. Enfin, le transfert vers l'interface correspondante du système cible a lieu. La couche d'intégration remplit alors plusieurs tâches techniques : la transformation de différents formats de données, par exemple XML ou JSON, le mappage entre les modèles de données des systèmes, ainsi que la gestion des flux de communication entre les applications.

Il en résulte une couche de traduction technique entre les systèmes. Celle-ci garantit que les informations, identiques sur le fond, sont correctement transférées malgré des structures de données différentes.

Une structure correcte ne suffit pas

La mise en place technique correcte de l’intégration ne constitue qu’une partie de la solution. Une structure organisationnelle clairement définie dans le système SAP S/4 HANA est tout aussi déterminante. Ce n’est que lorsque les entités organisationnelles et les responsabilités sont gérées de manière cohérente que les filtres pour le transfert de données peuvent être configurés correctement.Ces filtres déterminent quels objets du système ERP sont transférés vers SAP Field Service Management. Il s’agit par exemple des partenaires commerciaux, des objets techniques ou des ordres de service. Si les structures organisationnelles ne sont pas modélisées de manière cohérente, le nombre d’enregistrements répliqués sera soit trop élevé, soit trop faible.

Cadre de réplication des données

Dans SAP S/4 Hana, le cadre de réplication des données constitue la base de ces transferts automatisés. Il détermine quelles données sont transférées dans un premier temps, puis synchronisées en continu. Une configuration rigoureuse de ce cadre contribue de manière significative à la stabilité de l'intégration.

Si cette base n'est pas correctement configurée, les synchronisations automatiques ne fonctionnent souvent que de manière très limitée. Dans ce cas, les processus de réplication doivent être lancés manuellement afin que les données puissent être maintenues à jour entre les systèmes. (Source : Inwerken)