DataXstream OMS+

Migration de données SAP – Répondre aux questions importantes (Partie 1)

BlogSAP

Migration de données SAP – Répondre aux questions importantes (Partie 1)

C’est l’heure de la migration des données sur votre projet d’entreprise SAP. Que votre projet soit une implémentation, une acquisition ou une fusion, l’objectif est à peu près le même : l’acquisition entrante transparente de données de base et transactionnelles à partir d’une ou plusieurs sources de données externes tout en garantissant que cette activité a un impact minimal sur le reste de l’entreprise. C’est là que nous essayons de déplacer des années de données de base et transactionnelles négligées d’un système existant peu structuré et où tout est permis vers un système SAP très étroitement intégré et hautement structuré. Vous devez considérer la probabilité que le concept de gestion des données de référence n’ait pas encore été inventé lorsque le système existant ou source fournissant vos données a été mis en œuvre.

Quelle quantité de données déplacer ? Quelle quantité de données laisser derrière soi ? Que faut-il automatiser et que faut-il exécuter manuellement ? Comment orchestrer et exécuter avec élégance un basculement de migration de données d’un système à un autre ? Où et comment intégrer le plan de migration des données dans le plan global de mise en œuvre de l’entreprise ? Comment continuer à faire fonctionner l’entreprise pendant la phase de migration des données de mise en œuvre du projet d’entreprise ? Ces questions font toutes partie du plaisir de planifier !

Tests de migration de données

Les processus que nous avons pratiqués et que nous continuons de pratiquer régulièrement ne sont pas un problème, ne provoquent pas d’anxiété et n’augmentent pas la tension artérielle. Le rapport quotidien, la transaction personnalisée, l’interface qui s’exécute plusieurs centaines de fois par semaine – tout cela est désormais une seconde nature. Cela arrive et personne ne le remarque.

Mais revenons à la toute première fois que ces processus ont été mis en ligne. C’est précisément là que vous en êtes avec la migration des données. Pour la plupart, il s’agit d’un événement unique dans une vie. Il est donc important d’augmenter le niveau de confiance et de réduire les niveaux d’anxiété liés à cette activité. Ceci est réalisé par la pratique, la pratique, la pratique.

En règle générale, j’aime voir au moins trois cycles de test de migration de données exécutés dans un client de migration de données isolé. Cela permet plusieurs tentatives pour exercer et affiner le plan de migration des données ; collecter des statistiques de durée d’exécution nominale pour avoir une idée de la durée que pourrait prendre la migration des données ; identifier et corriger tout défaut d’objet du programme de migration de données ; identifier et corriger tout mappage de données et défauts de contenu ; et identifier et résoudre tout problème de configuration fonctionnelle. Chacune de ces tâches est effectuée dans le but d’améliorer considérablement le taux de retombées à chaque cycle de test de migration de données. Ces cycles de test de migration de données nous donnent également l’opportunité de mettre en pratique nos compétences d’extraction héritées, nos compétences d’analyse des retombées et nos compétences de nettoyage manuel des retombées.

Qualité des données sources

Chaque cycle de test de migration de données commence par l’extraction des données héritées ou sources. Une activité importante entre les cycles de test de migration de données est le nettoyage des données héritées ou sources. Le processus de migration des données découvrira très probablement de nombreux problèmes de données. Les données d’adresse des clients et des fournisseurs suffisent à elles seules à mettre à genoux votre logiciel de détermination de juridiction fiscale – ce code postal trop court, trop long ou tout simplement incorrect lorsqu’il est combiné avec la ville et l’État associés ; les différentes abréviations utilisées à la place du nom réel de la ville ; la ville et l’État saisis dans le même champ alors qu’ils auraient dû l’être dans des champs distincts ; etc. Si les données sources ne sont pas corrigées, vos cycles de test de migration de données commenceront à ressembler au film Groundhog Day.

L’approvisionnement et le nettoyage des données sources pourraient très bien s’avérer problématiques, en particulier dans un scénario d’acquisition ou de fusion où les fournisseurs font partie d’une organisation différente et ne sont pas incités à participer à votre projet. Si vous rencontrez ce scénario, vous devrez probablement engager le niveau de direction approprié de votre organisation pour avoir une discussion sérieuse avec le niveau de direction approprié de l’organisation fournisseur. Reconnaissez-le, gardez le contrôle et levez ce drapeau tôt. Ne restez pas assis pendant plusieurs jours à attendre que les données arrivent, car cela ne ferait que retarder votre projet.

Prise en charge de la migration des données pour d’autres tests

Dans n’importe quel scénario de projet d’entreprise, l’équipe de développement salivera à l’idée de tester ses personnalisations par rapport à vos données réelles dans la boîte du cycle de test de conversion. De même, l’équipe fonctionnelle s’efforcera d’utiliser vos données réelles pour tester des scénarios de configuration. Et l’équipe d’interface et l’équipe de l’entrepôt de données ne parviennent jamais à obtenir suffisamment de données pour jouer.

Pendant que vous travaillez dans le cadre de vos trois cycles de test de migration de données, dites simplement NON. Vous avez absolument besoin d’un environnement contrôlé pour les cycles de tests de migration de données, et ces autres équipes ne le respecteront pas. Ils ont un objectif et un objectif différents qui nécessitent de changer et de manipuler les degrés de liberté que vous devez maintenir constants.

Mais nous faisons tous partie de la même équipe et essayons de mener le projet à la ligne d’arrivée dans les délais prévus. Alors pour aider les autres membres de votre équipe, prévoyez des cycles de migration de données supplémentaires pour fournir ces données à ces équipes. C’est davantage une pratique de migration de données pour vous, et cela donne à tous les autres ce dont ils ont besoin.

Le monde parfait de la migration des données

Dans un monde parfait, pour chaque objet de données à convertir :

  1. Les spécifications fonctionnelles et les documents de cartographie sont bien rédigés et clairs.
  2. Un fichier de chargement de données est construit exactement en conformité avec les spécifications fonctionnelles et les documents de cartographie bien rédigés.
  3. Les objets ABAP de migration de données sont construits exactement comme spécifié par les spécifications fonctionnelles et les documents de mappage de données bien rédigés.
  4. Personne n’insiste pour que nous déplacions une cheville carrée dans un trou rond.

Dans un monde parfait, pour chaque ensemble de données à migrer :

  1. Les données du système existant ont été soigneusement nettoyées.
  2. The providers of the legacy data are genuinely interested in providing accurate data on time.
  3. Les fichiers de chargement résidant sur le serveur dans un système Unicode sont correctement codés en UTF-8.
  4. Un délimiteur autre que la virgule a été spécifié pour le fichier de chargement.

Dans un monde parfait, le client du cycle de test de migration de données :

  1. Est construit dans un boîtier qui n’est pas le boîtier de développement.
  2. Est configuré exactement comme le client sur lequel les objets ABAP de migration de données ont été créés et testés.
  3. N’est pas ouvert à la configuration, sauf si cela est prévu par sa conception.
  4. Is not part of a transport path. pour éviter que le cycle actuel de tests de conversion ne soit aveuglé par de nouvelles modifications de configuration.
  5. Est verrouillé afin que seules les tâches de migration et de validation des données puissent être effectuées.
  6. Est configuré pour gérer davantage de processus d’arrière-plan et de mise à jour et moins de processus de dialogue.
  7. Est construit dans une boîte qui dispose de suffisamment d’espace disque pour servir de référentiel pour les fichiers de chargement principaux et tous les fichiers de traitement intermédiaires nécessaires.

Dans un monde parfait, au niveau du projet :

  1. Il existe un plan global de basculement d’activité ou de mise en œuvre dans lequel vous pouvez assimiler votre plan de migration de données.
  2. Le plan de migration des données s’intègre parfaitement dans le plan global de basculement de l’entreprise.
  3. Une stratégie est en place pour mettre les données à jour entre le moment où le gel du basculement est appliqué et la date de mise en œuvre.

Restez à l’écoute!

Dans le monde réel, le plaisir ne fait que commencer. Ces scénarios mondiaux parfaits ne semblent jamais se produire. Mais restez à l’écoute ! Dans mon prochain article de blog de cette série, je discuterai des détails du plan de migration des données. Après cela, dans les articles suivants, j’examinerai certains scénarios du monde réel que j’ai rencontrés et discuterai de la façon dont je les ai gérés.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.