Closing the SAP Data Gap: A CIO’s Guide to Clear, Connected Data 

L'erreur la plus courante

Historiquement, les organisations construisaient des processus personnalisés directement à l'intérieur de leur ERP de base. À l'époque de l'ECC, c'était essentiellement la seule option possible. Avec S/4HANA, un modèle différent est disponible, qui s'articule autour du concept de noyau propre, mais de nombreuses organisations continuent de s'en tenir aux anciens modèles.

Le problème se manifeste de deux manières. Soit les personnalisations sont encore réalisées directement dans le cœur de l'ERP, soit elles sont construites dans un système complètement indépendant qui n'a pas de véritable connectivité avec SAP. Dans les deux cas, le résultat est le même : les équipes passent beaucoup de temps à gérer l'intégration et à faire fonctionner ensemble des processus déconnectés.

Ce que signifie le "clean core" en réalité

On parle beaucoup du clean core en ce moment, mais ce qu'il signifie en pratique est simple. Les personnalisations ne doivent pas être intégrées au cœur de l'ERP. Elles ralentissent les choses, alourdissent les systèmes et, plus visiblement, rendent les cycles de mise à niveau longs et pénibles. Plus la personnalisation est présente dans le cœur du système, plus la mise à niveau nécessite de travail.

L'approche recommandée par SAP consiste à intégrer ces personnalisations dans la BTP (Business Technology Platform). Tous les éléments de la SAP Business Suite, y compris S/4HANA et Business Data Cloud, reposent sur BTP. Elle permet l'intégration, le développement d'applications personnalisées et sans code au sein de l'écosystème SAP, ainsi que des connexions standard entre les systèmes.

L'avantage pratique est considérable. Lorsque vous développez dans BTP plutôt que dans le noyau, une mise à niveau S/4 ne touche pas du tout à ces processus. Vous réduisez la dette technique au sein de votre ERP central, vous simplifiez les cycles de mise à niveau et vous évitez les gels qui empêchent les utilisateurs de se servir eux-mêmes pendant qu'une mise à niveau est en cours. Il y a aussi un aspect licence : si les utilisateurs accèdent à S/4 uniquement parce qu'un flux de travail personnalisé y est hébergé, le transfert de ce flux de travail vers BTP supprime entièrement le besoin de ces sièges.

Un exemple concret : Le portail fournisseur xi.Orion

Improving a créé un portail appelé xi.Orion pour soutenir les relations avec les vendeurs et les fournisseurs. Le scénario auquel il répond est courant : les équipes en contact avec les clients reçoivent un flux constant de questions de la part des fournisseurs sur le statut du paiement des factures, les demandes d'achat et les bons de commande. Il s'agit d'une interaction à fort volume et à faible valeur ajoutée qui consomme une grande partie de la bande passante interne.

xi.Orion a été développé au sein de BTP, en suivant l'approche "clean core". Les fournisseurs peuvent utiliser le libre-service, charger une demande d'achat (PR) ou un bon de commande (PO), utiliser Joule, l'IA de SAP, pour demander le statut d'approbation de la PR ou du PO, et vérifier quand les factures sont prêtes à être payées. Lorsqu'un fournisseur soumet une demande d'achat directement via le portail, il lance un processus d'approbation sans que les utilisateurs externes ne touchent au cœur de l'ERP. Cela crée également un environnement plus sûr puisque les fournisseurs n'ont pas accès au système interne lui-même.

Les allers-retours par courrier électronique sont remplacés. La charge de travail des équipes internes est réduite. Et rien de tout cela n'a nécessité de personnaliser S/4HANA.

Où s'inscrivent Fabric, Databricks et Snowflake ?

Même les ateliers SAP ne fonctionnent pas en mode mur à mur avec SAP. SAP l'a reconnu et l'écosystème s'est considérablement ouvert. Business Data Cloud comprend désormais des connecteurs standard vers des systèmes non SAP pour les données opérationnelles, avec un accès direct à Databricks, Snowflake et Microsoft Fabric. Une approche de copie zéro delta pour Fabric devrait être disponible au cours du second semestre de cette année.

Pour le DSI, cela se traduit par une grande flexibilité. Vous pouvez conserver votre investissement SAP intact, préserver la couche sémantique et les relations entre les données de base qui se trouvent dans SAP, tout en joignant ces informations aux données opérationnelles provenant de l'extérieur du réseau SAP. Cette combinaison de données SAP riches et centrées sur l'entreprise avec des données opérationnelles externes a toujours été difficile à réaliser. Les outils actuels la rendent beaucoup plus accessible.

Que faire en cas de migration intermédiaire ?

Pour les entreprises en cours de migration vers S/4HANA, deux points méritent d'être abordés avant que la migration ne soit trop avancée.

Le premier est le clean core. Cela peut sembler être une question à traiter plus tard, mais il est souvent plus rentable de déplacer les processus personnalisés vers BTP pendant la migration plutôt qu'après. L'identification précoce des processus les plus lourds et la planification de leur transfert hors du noyau avant la mise en service constituent une meilleure utilisation du moment.

Le deuxième point concerne les données et l'analyse, qui ont tendance à être traitées après coup dans les migrations d'ERP. Les organisations passent à la phase opérationnelle et découvrent ensuite que leurs utilisateurs n'ont pas de rapports ou de stratégie de reporting définie. Définir le programme de données et d'analyse en amont, avant la mise en service, permet aux utilisateurs de disposer des rapports dont ils ont besoin dès le premier jour.

À quoi ressemblent dix-huit mois de progrès ?

Avec une feuille de route claire, une organisation qui aurait dix-huit mois de travail aurait S/4HANA en place avec des services BTP gérant l'intégration, remplaçant les anciens middleware tels que PI/PO. La philosophie "Clean Core" serait mise en pratique, les processus personnalisés étant transférés vers les applications BTP. Business Data Cloud connecterait les données opérationnelles d'un entrepôt de données ou d'un lac de données aux données SAP, avec SAP Analytics Cloud pour les rapports et les prévisions.

Il en résulte des rapports en libre-service dans l'ensemble de l'organisation, une planification et des prévisions plus automatisées, ainsi qu'un cœur de métier nettement plus propre. L'objectif est de boucler la boucle : des données propres à l'entrée, de l'intelligence à la sortie, et rien de cassé au milieu.

Prêt à commencer ?

Improving aide les DSI à naviguer dans la modernisation de SAP, à adopter des pratiques de noyau propre et à construire un paysage de données connecté qui prend en charge à la fois les opérations et l'analyse. Que vous soyez à mi-parcours de la migration ou que vous envisagiez la suite, parlons de ce qu'il faut faire pour commencer.