En cinq étapes vers S/4 : Housekeep, Identify, Design, Transform, Operate

Faut-il le contourner, le laisser derrière soi et recommencer sur un terrain vierge ? Ou faut-il se contenter d'enlever des parties et de les emporter ? Et comment s'assurer, avec toutes ces alternatives, que la montagne ne s'effondrera pas pendant les travaux et qu'elle restera accessible ?

Les clients existants de SAP le savent : La migration vers S/4 et les projets de numérisation qui en découlent se déroulent au mieux lorsqu'ils ne démarrent la nouvelle génération de logiciels qu'avec les données et les documents les plus récents et nécessaires à leurs activités quotidiennes. Mais ils ne savent pas exactement comment se libérer du poids des données et des documents anciens.

Housekeep

Gérer les informations anciennes indépendamment du système : avec JiVS, une plateforme de gestion de l'information, la société suisse Data Migration Services propose la solution à ce problème. JiVS permet de gérer les données et les documents qui ne sont plus nécessaires sur le plan opérationnel, y compris leur logique commerciale, tout au long de leur cycle de vie : depuis leur reprise des systèmes productifs jusqu'à leur suppression définitive, en passant par leur conservation juridiquement sûre.

Plus de 1000 implémentations de JiVS dans le monde entier ont démontré que ce concept fonctionne. Les coûts d'exploitation de JiVS sont généralement inférieurs de 80% aux dépenses liées à la poursuite de l'exploitation des anciens systèmes. Le fait que les informations soient reprises telles quelles des anciens systèmes et classées de manière à garantir la sécurité de l'audit est reconnu par les auditeurs, ce qui garantit la sécurité juridique vis-à-vis des autorités financières.

De plus, en tant que plate-forme basée sur Java, JiVS est indépendante des systèmes sur lesquels elle fonctionne. Par conséquent, il n'y a pas de problème de remplacement du matériel, comme c'est le cas avec les anciens systèmes. En tant que système vivant, JiVS permet en outre des mises à jour régulières de la sécurité, ce qui limite durablement le risque de cyber-attaques et de cyber-espionnage. Une fois que les informations et la logique commerciale sous-jacente ont été transférées des anciens systèmes vers JiVS, il est possible de les désactiver complètement et de les éliminer.

Le housekeeping est ainsi en quelque sorte terminé. Les entreprises peuvent ainsi migrer vers S/4 uniquement la partie des données dont elles ont réellement besoin pour leurs activités quotidiennes, par exemple les commandes en cours.

L'expérience des projets JiVS menés jusqu'à présent nous apprend que des réductions de 50 pour cent à 80 pour cent du volume de données à migrer sont non seulement possibles, mais aussi réalistes ! Malgré le surcroît de travail nécessaire à l'analyse du stock de données et à la sélection des informations à migrer, le coût de la migration diminue en général de 50 pour cent, et parfois même davantage. Mais celui qui en est déjà à l'historisation et à la migration se trouve déjà au milieu du projet, c'est-à-dire quand tout est déjà planifié, budgétisé, analysé et décidé.Mais avant cette phase de mise en œuvre, il y a encore deux autres phases dans un projet de migration vers S/4 Hana : Identify et Design. Ces phases peuvent également être couvertes par JiVS.

Identifier

Avant de pouvoir réduire le volume de données à migrer, les clients SAP existants doivent d'abord déterminer s'ils ont besoin de données dans S/4 et, le cas échéant, de quelles données ils n'ont pas besoin. Pour ce faire, JiVS propose un outil d'analyse avec de nombreuses possibilités de paramétrage.

Par exemple, les informations enregistrées dans l'ancien système peuvent être sélectionnées en fonction des commandes datant de plus de six mois et qui ont donc généralement déjà été clôturées, ou en fonction des sociétés et des divisions qui n'existent plus. Bien entendu, cette analyse peut être affinée de manière itérative par d'autres critères de sélection de plus en plus pointus.

Même si la précision de l'analyse de potentiel n'est pas de 100 pour cent et que cette valeur n'est d'ailleurs pas visée dans la phase d'identification, les clients obtiennent une très bonne base de décision pour savoir si et dans quelle mesure le passage à S/4 et Hana à l'aide de JiVS en vaut la peine.

En raison du grand nombre de projets SAP menés à bien, JiVS connaît les structures de données des versions SAP les plus diverses, de la version 3.0 de R/3 jusqu'à la version 6.0 de SAP ERP/ECC. Il n'est donc plus nécessaire de développer les critères de sélection, mais seulement de les configurer.

Design

Une fois la décision prise, vient la phase de conception, c'est-à-dire la planification détaillée de la sélection des données et de la migration. Celle-ci n'a plus lieu dans l'ancien environnement, mais déjà sur JiVS. Les critères de sélection de la première phase sont encore une fois affinés et testés, de sorte que la coupe dans le stock de données puisse être effectuée automatiquement par le logiciel.

Mais la phase de conception présente d'autres avantages : elle permet non seulement de décider si le nombre d'objets de gestion dans S/4 ne peut pas être massivement réduit par des modifications de processus ou par le retour au standard SAP - des 180 maximum possibles à peut-être 40 ou 50.

En outre, c'est l'étape idéale du projet pour optimiser la qualité des données. Au fil des années, des enregistrements erronés, redondants et incomplets se sont accumulés dans les anciens systèmes. Ceux-ci peuvent désormais être nettoyés, éliminés et complétés au moyen de sources tierces telles que des répertoires d'adresses externes avant d'être transférés dans S/4. En effet, la numérisation requiert une qualité élevée des données. Enfin, des processus hautement automatisés sur la base de jeux de données erronés sont une contradiction dans les termes et conduisent à des décisions erronées ou lacunaires ainsi qu'à des opportunités de vente manquées.

Transform

À la fin de la phase deux, JiVS fournit des règles de filtrage précises et testées sous forme de liste XML. Les clients ont ainsi le choix d'utiliser l'outil propre à JiVS pour l'extraction, la transformation et le chargement (ETL) des données sélectionnées dans S/4 Hana ou des solutions de fournisseurs tiers, dont l'outil de conversion de SAP.

JiVS peut également transmettre le paquet de données complet au format XML à des outils ETL ou de transformation tiers. Si la conversion des données vers les nouvelles structures de données S/4-Hana est effectuée à l'aide de JiVS ETL, elles peuvent être directement importées dans le nouvel environnement de manière automatisée via le Migration Cockpit de SAP. Que les clients SAP existants reviennent ou non au standard SAP lors de la migration, les temps d'arrêt ne devraient plus dépasser la durée d'un week-end, même pour les très grands environnements SAP.

Operate

Une fois la migration effectuée, S/4 lancé avec succès et les anciens systèmes désactivés, la question se pose de savoir quel rôle JiVS doit jouer dans la phase d'exploitation (Operate). En effet, la plate-forme déploie tout son potentiel lorsque l'accès aux informations qui y sont stockées n'est pas occasionnel. Au contraire, JiVS permet d'éviter dès le départ, dans l'univers S/4 Hana, de nombreux problèmes typiques des environnements SAP existants.

Il s'agit par exemple de l'augmentation continue des besoins en ressources. Ainsi, les données et les documents qui ne sont plus utilisés dans les activités quotidiennes à partir d'un certain moment peuvent être régulièrement historisés au moyen de JiVS. S/4 reste ainsi durablement allégé, ce qui réduit d'autant les coûts d'exploitation au fil du temps. En outre, les informations contenues dans JiVS conservent une grande valeur, non seulement pour des raisons juridiques, mais aussi pour des raisons commerciales. Certes, le nombre d'accès aux informations non opérationnelles est inférieur à celui des informations opérationnelles, mais ce n'est qu'une question de fréquence et non d'utilité, bien au contraire :

Plus la durée des commandes et des projets est longue dans un secteur, plus les utilisateurs professionnels doivent régulièrement se référer à des informations remontant loin dans le temps. En outre, ils n'obtiennent une vue d'ensemble d'un client ou d'un processus que s'ils savent quelles informations existent globalement à ce sujet.

Pour ce faire, ils ne veulent pas passer d'un environnement à l'autre, car les ruptures de médias sont taboues à l'ère du cloud. C'est pourquoi Data Migration Services travaille de plus en plus à des intégrations, afin que JiVS ne joue pas seulement le rôle d'une archive à laquelle on n'accède qu'en cas de nécessité absolue, du point de vue des utilisateurs professionnels. Indépendamment de l'interface, qu'il s'agisse de SAP Fiori, S/4 ou C/4, les utilisateurs SAP doivent pouvoir consulter le stock d'informations correspondant à un cas de gestion. Ils doivent en outre avoir la possibilité de naviguer directement vers ces contenus à partir de l'interface SAP correspondante et de les ouvrir.

Outre ces intégrations frontales, d'autres intégrations back-end jouent un rôle important pour les services de migration de données. Pour que le transfert de données vers S/4 ou C/4, par exemple à partir de systèmes non SAP moins structurés, s'effectue de manière automatisée, il est nécessaire d'adapter dynamiquement les règles de mappage dans JiVS. Pour ce faire, les modifications apportées aux structures de données doivent être transmises automatiquement à la plateforme du fabricant suisse via une interface.

De plus, JiVS s'intègre parfaitement dans les stratégies de cloud et de big data des clients existants de SAP. En effet, la plateforme peut être implémentée aussi bien dans les centres de données des entreprises que sur toutes les plateformes cloud courantes telles qu'Amazon Web Services, Google Cloud Platform ou Microsoft Azure.

En outre, les informations conservées dans JiVS sont disponibles à tout moment pour des scénarios Big Data. Elles peuvent être consultées directement via la couche application de la plateforme, mais peuvent également être exportées en tant que jeu de données distinct, puis traitées dans les systèmes de big data.

Éditions JiVS S/4 et C/4

Les outils existants et les nouveaux développements prévus pour 2019 seront regroupés dans deux éditions spéciales de JiVS, l'une S/4 pour la migration ERP et l'autre C/4 pour la migration CRM. Les deux éditions seront optimisées à l'aide d'algorithmes d'intelligence artificielle et devraient être prêtes à être commercialisées d'ici l'automne 2019. Data Migration Services présentera les premières versions de démonstration des deux éditions d'abord au salon SAP Now les 3 et 4 avril à Bâle, puis au salon Sapphire du 7 au 9 mai à Orlando en Floride.

PDF (en anglais)