Pourquoi utiliser Data Sync Manager avant la migration vers S/4 ?

S/4 sera là tôt ou tard

Beaucoup de nos clients ont choisi Data Sync Manager (DSM) pour la réalisation d’un projet majeur. C'est souvent le cas lorsque le projet a mis en évidence dès le départ le risque que représentent pour le projet les anciens systèmes de test dont les données sont inexactes. Étant donné que de nombreuses organisations prévoient de migrer vers S/4, je voulais partager avec vous ce que DSM peut vous apporter avant, pendant et après la migration vers S/4, qui représente probablement le projet SAP le plus important dans votre horizon.

Avant : Rationalisation de l’infrastructure avant une migration à partir de l’existant

Beaucoup d’organisations possèdent une infrastructure SAP non productive étendue. Certains systèmes sont d’anciennes copies de production et d’autres sont des systèmes multi-mandants issus d’anciens projets achevés depuis longtemps. Au cours des 20 dernières années, le prix du stockage pour entreprise a baissé et la gestion s’est simplifiée. Par conséquent, les infrastructures SAP se sont vu attribuer de plus en plus d’espace. Sachant que S/4 arrive à grands pas, avec une technologie de base de données en mémoire bien plus coûteuse que sur disque, il est temps de se débarrasser des bagages superflus. Et en même temps de vous assurer de la présence de données de test de bonne qualité pour chaque phase du projet S/4, quelle que soit votre approche. Avec DSM, vous pouvez créer de nouveaux systèmes coquilles, les renseigner avec des mandants simplifiés contenant des données masquées et les utiliser pour remplacer les systèmes de test existants. Vous pouvez également utiliser la fonctionnalité de suppression de mandant de Client Sync pour supprimer les mandants redondants et ceux à réinitialiser avec des données de bonne qualité. Découvrez comment détecter les données de test SAP invisibles pour réduire les coûts.

Avant : Étapes de préparation S/4

Un certain nombre d’étapes peuvent être exécutées avant le début du projet S/4, comme l’intégration client-fournisseur. Cette étape, ainsi que d’autres facteurs, peut déclencher un nettoyage des données et du projet. La capacité de limiter les données sur demande au système de développement ou bac à sable permettrait de réduire fortement la durée de ces pré-projets fonctionnels et de mettre en valeur le travail à effectuer en production. Des données de test fiables selon vos besoins ; sélectionnez et copiez uniquement les données dont vous avez besoin. Découvrez comment fonctionne Object Sync .

Avant : Anonymisation des données sensibles

Plusieurs IS et sociétés de conseil de niche peuvent être impliquées dans votre projet S/4 et avoir besoin d’examiner vos systèmes non productifs pour fournir des recommandations, préparer des rapports d’analyse et définir le périmètre de projets potentiels. Ces organisations peuvent se connecter partout dans le monde et ont besoin de voir des données exactes MAIS pas des données personnelles réelles. Le nombre de violations de données qui font les gros titres augmente dans le monde : ne prenez pas le risque de laisser une personne télécharger une table de données sensibles à partir d’un système d’AQ et de la vendre au plus offrant. Data Secure vous donne un contrôle complet sur les données sensibles.

Pendant : Bac à sable

SAP recommande d’utiliser un bac à sable avant le commencement du projet. Pour en savoir plus sur ce qui se passe dans le bac à sable, cliquez ici. Plus le bac à sable est précis, mieux c’est, mais une copie complète des données de production signifie un équipement plus important et plus coûteux. Utilisez DSM pour créer un bac à sable simplifié et dédié pour le projet et envisagez le cloud, étant donné que la durée du projet de bac à sable n’est pas clairement définie et que l’activité doit être maintenue dans le même temps. Découvrez-en plus sur la façon dont Ballance Agri a utilisé DSM lors de la phase de bac à sable de S/4.

Pendant : Reconstruction d’un système non productif à partir d’un nouveau système de production

Pour toute personne utilisant une approche à partir de l’existant, je recommande de prendre en considération l’ampleur de l’écart entre la configuration, le paramétrage et le code dans le système de développement et la production. Au fil des ans, l’écart s’est accru avec l’abandon du code Z, la configuration transférée à l’AQ, puis l’annulation du projet voire même des add-ons tiers chargés en développement mais jamais désinstallés. Nos équipes de migration utilisent DSM pour reconstruire une infrastructure non productive à partir du système de production, dans le cadre de leur stratégie de migration vers le cloud. Cela pourrait également faire partie de votre approche de migration vers S/4.

La reconstruction du développement et de l’AQ à partir de la production à partir de la production signifie un départ plus propre de l'autre côté, avec un écart plus faible entre le développement et la production, minimisant ainsi les risques de défaillances. Certaines organisations l’ont même fait avec des copies complètes dans le cadre de leur migration, pour découvrir trop tard les coûts d’une telle opération. Vraisemblablement, la réduction du volume de codes spécifiques à restructurer en est un facteur déterminant. L’utilisation de DSM pour construire de nouveaux systèmes de test et de développement plus petits peut présenter le même avantage pour réduire l’écart entre le développement et la production, ainsi que le volume de code Z à restructurer, mais à une fraction du coût, étant donné qu’il est possible d’utiliser des équipements plus petits.

Pendant : Activation d’options cloud hybrides

Grâce à cette capacité de masquer les données en sortie, vous pouvez aussi envisager de conserver un environnement de production on-premise et de déplacer tous vos systèmes non productifs sur le cloud. Ce sont les systèmes qui bénéficient le plus de la souplesse des ressources du cloud. Démarrez les systèmes pendant les phases clés du projet ; et éteignez-les lorsque vous n’en avez plus besoin. Avec Object Sync et Client Sync qui maintiennent les données à jour, aucune donnée personnelle ou sensible ne quitte votre réseau.

Après : TDMS non pris en charge sur S/4

La réalisation de vos rêves S/4 ne marquera pas la fin du voyage. Les équipes fonctionnelles voudront faire de S/4 le cœur numérique de l’entreprise intelligente. Il est probable que de nombreux projets exploitant les possibilités de l’IA, du machine learning, etc. suivront, alors que votre entreprise cherche à trouver ou conserver un avantage concurrentiel. Tous ces projets auront besoin de données de test exactes et d’une infrastructure non productive agile. La solution TDMS tant critiquée, qui a conduit nombre de nos clients vers la solution DSM en premier lieu, ne prend pas en charge S/4, et au vu des changements que nous avons apportés à notre architecture au cours des quatre dernières années pour gérer les nouvelles technologies utilisées par S/4, il est difficile de voir comment elle le pourrait. DSM est utilisé sur S/4, est pris en charge par S/4 et est certifié sur S/4.

Après : Conservation des systèmes de test sur le même équipement tout au long de l’évolution de la production

À mesure que votre système SAP accélère de l’autre côté de la migration vers S/4, son volume augmente indubitablement. Les équipements devront évoluer, mais pas nécessairement votre infrastructure non productive. Avec une planification et une utilisation rigoureuses de DSM Client Sync, vous pouvez garder de plus petits structures de test à jour avec des sous-ensembles de production, ce qui signifie que le taux de croissance des systèmes de test est bien inférieur à celui de la production.

Intéressé par obtenir de l’aide pour la planification de votre migration vers S/4 ?

Notre rapport d’évaluation S/4 peut vous donner des renseignements de haute qualité sur les niveaux d’effort de chaque approche et vous alerter à l’avance sur les éventuels blocages qui pourraient survenir, notamment :

• Les éléments de contrôle de préparation SAP pertinents pour votre système

• Le nombre de clients/fournisseurs sans lien à BP

• Les bloqueurs techniques, tels que le système non-unicode

• Les domaines SAP utilisés par votre système qui ne sont plus pris en charge

• Le volume de code spécifiques

• Le tableau de bord interactif visuel du système pour encadrer les conversations internes

Demandez votre évaluation gratuite aujourd’hui. Vous pouvez également obtenir des mises à jour régulières en vous inscrivant à cette série de blogs ; ajoutez simplement votre adresse e-mail sous « Get Instant Updates ».