Auteur : David PERRET Publication : 01/11/2015 Toute société utilisatrice de logiciel de gestion est inéluctablement confrontée à des migrations de données. Ces migrations représentent des risques et un budget important. La migration des données d un progiciel vers un autre nécessite de maîtriser les étapes à mettre en œuvre pour la réalisation d un tel projet. Le risque n est pas tant d échouer à migrer un système de gestion que de consacrer plus de temps et de budget que ce qui est réellement nécessaire au projet. *** Pourquoi migrer un logiciel de gestion? *** L activité des sociétés est largement tributaire des systèmes d information. Et les logiciels utilisés pour la gestion des positions financières jouent un rôle déterminant. Des facteurs récurrents génèrent des besoins d investissements permanents liés à cette dépendance aux systèmes d information : L évolution des métiers et la recherche de gains de productivité générateurs de nouveaux besoins ; Les avancées technologiques et leurs incidences directes sur la maintenance des parcs informatiques et des logiciels associés ; La transformation de l environnement réglementaire incitatrice à la normalisation et à l industrialisation des processus ; Les changements de comportement des consommateurs incitent les sociétés à investir pour maintenir et accroitre leur compétitivité face aux concurrents. Ne pas faire évoluer ses systèmes d informations présente un risque de perte de compétitivité pour une société vis-à-vis de sa concurrence. Et tout changement présente des risques. De plus, lorsque les logiciels de production sont manipulés par des utilisateurs, le risque opérationnel lié au changement de système est d autant plus important. Aussi, la migration de logiciel est un sujet incontournable pour l activité de la société et est un projet à risques. Cette analyse cherche à mettre en exergue les risques liés à la migration de logiciel, ses enjeux et sa mise en œuvre. T o u s d r o i t s r é s e r v é s, r e p r o d u c t i o n e t d i f f u s i o n i n t e r d i t e s P a g e 1 5
Les enjeux d une migration de données entre deux systèmes de gestion Car il n est pas dans l intérêt d un éditeur de communiquer ses modèles de données ou son code source, le changement d un progiciel à un autre peut s avérer complexe. Bien que la «matière première» traitée par deux logiciels puisse être la même, chaque logiciel «traduit à sa façon» les caractéristiques qui constituent une chaîne d information et la manière dont elles seront traitées. Ainsi, lors d une migration de logiciel, il faudra concilier des modèles différents, propres à chaque progiciel : pour le stockage des données ; pour la définition des processus et des fonctionnalités qui composent un logiciel. Les impacts en matière de risques Il existe des facteurs de risques propres aux logiciels dans un projet de migration : Les risques qui concernent les opérations en stock comme celles à venir et qui résident dans les processus et les fonctionnalités du nouveau logiciel. Les processus et fonctionnalités du nouveau logiciel doivent être conformes aux besoins des utilisateurs et permettre la continuité de la gestion des stocks en production ; Les risques liés au transfert des données en stock sont de deux natures, risque de perte de données et risque de dégradation de la qualité des données transmises ; La bascule de l activité d un logiciel à un autre est déterminante car la production ne doit pas être affectée par le changement de logiciel. Tout risque de rupture dans la chaîne de traitement de l information doit être évité. Par ailleurs, d autres facteurs de risques liés à la gestion du projet peuvent mettre en cause sa réussite en matière de durée et de coût. Ces principaux facteurs sont : La mauvaise prise en compte des environnements techniques et métiers du logiciel à migrer, notamment l ensemble des échanges depuis ou vers d autres systèmes ; Un périmètre de données et de fonctionnalités à migrer mal défini ou modifié au cours du projet ; L environnement et notamment d autres projets peuvent impacter le projet de migration pendant sa durée ; Un mauvais accompagnement des utilisateurs peut engendrer l échec du projet, si le nouveau logiciel est parfaitement opérationnel mais qu il n est pas maîtrisé par les utilisateurs. T o u s d r o i t s r é s e r v é s, r e p r o d u c t i o n e t d i f f u s i o n i n t e r d i t e s P a g e 2 5
*** Les étapes de mise en œuvre du projet *** Les enjeux d une migration de logiciel sont importants et le travail préparatoire est déterminant pour la réussite de ce type de projet. L analyse des écarts fonctionnels Pour que la migration d un système à un autre soit possible, une analyse des écarts fonctionnels entre progiciels est nécessaire afin de traiter le stock de données et d effectuer une mise en qualité de celui-ci. En effet, dans le cas d un progiciel permettant de gérer des opérations financières, on ne trouve pas deux progiciels fonctionnant de la même manière bien qu ils répondent à des règles de marchés identiques. Donc, le stock des données existantes est impacté par le mode de fonctionnement du nouveau progiciel et des écarts de fonctionnement peuvent exister avec l ancien progiciel. La mise à niveau des fonctionnalités du nouveau progiciel La «mise à niveau» des fonctionnalités du nouveau progiciel est essentielle pour permettre de répondre aux besoins de fonctionnement exprimés par les utilisateurs. Cela concerne autant : La gestion de nouvelles données entrantes ; La poursuite de la gestion des données en stock Car il faut que nouvelles et anciennes données coexistent dans un cadre homogène sans différenciation de traitement par les utilisateurs. La mise en qualité du stock de données Au fil du temps, une dégradation de la qualité des données dans les logiciels de gestion est souvent constatée. Il y a deux principales causes à cela : Il est généralement plus facile pour un utilisateur de forcer la valeur d une donnée calculée par un logiciel plutôt que de chercher la cause d un mauvais calcul et de la corriger ; Dans d autres cas, le logiciel n est pas capable de faire un calcul et la donnée est directement renseignée dans le logiciel. Dès lors, plus un logiciel de gestion est utilisé depuis longtemps et plus il risque de présenter des données «customisées». Pour garantir le bon fonctionnement du logiciel cible, il est important de mettre en qualité le stock des données migrées afin de permettre au logiciel cible de fonctionner correctement et pour limiter le nombre de données «customisées» présentes et à venir. T o u s d r o i t s r é s e r v é s, r e p r o d u c t i o n e t d i f f u s i o n i n t e r d i t e s P a g e 3 5
Le mapping et la complétude des données Deux choses sont à faire pour transférer de manière équivalente des données entre deux progiciels : Définir une correspondance entre les modèles de données des systèmes concernés ; Etablir une correspondance de valeurs entre les données de référence. Pour le premier point, la connaissance des modèles de données de chaque système est un atout qui permettra d optimiser le temps nécessaire à l analyse. Le deuxième point est lié à la diversité des systèmes de gestion. Dès lors que des standards de marché sont définis, chaque progiciel se les réapproprie pour définir ses données de référence, «static data». Ainsi, entre deux progiciels définis pour une même activité, des données de référence seront définies avec des valeurs, ou identifiants, différents bien que correspondant à une même définition. Une correspondance entre ces différentes valeurs sera préalablement nécessaire au transfert des données de l ancien système vers le nouveau. De même, une complétude du référentiel du système cible par rapport aux besoins des données à migrer du système source est souvent nécessaire. La profondeur et l alimentation du référentiel Définir la profondeur des valeurs des données, «dynamic data», du référentiel est un enjeu de plus pour la réussite d une migration de système. Par exemple, dans un système de gestion, la profondeur des calendriers de jours fériés servant à calculer la date d échéance d un flux financier doit être conforme aux besoins des opérations nouvelles comme des plus anciennes. Les historiques de valeurs des données du référentiel dont la valeur change doivent être mis à jour dans le système cible en fonction des besoins du stock migré. Mais pour que le stock puisse vivre, il faut également que chaque historique de valeurs se rapportant à une donnée du référentiel soit mis à jour à chaque fois que cela est nécessaire. La phase de tests De tous ces paramètres à vérifier et à mettre en œuvre, il en résulte une phase de tests importante. Les tests réalisés au niveau unitaire, seront également être conduits dans un environnement global au travers de scénarios prédéfinis et avec des cas représentatifs couvrant les besoins finaux. Les tests doivent être réalisés avec les utilisateurs qui garantissent le bon fonctionnement du système cible conformément aux besoins exprimés. Cela comprend les tests : T o u s d r o i t s r é s e r v é s, r e p r o d u c t i o n e t d i f f u s i o n i n t e r d i t e s P a g e 4 5
Des fonctionnalités du système cible ; De la qualité des données du stock dans le nouveau système ; Du bon fonctionnement des échanges entre le système cible et les systèmes amonts et avals ; De la qualité des flux entrants et sortants du système en cible. La qualité des tests et des environnements utilisés pour leur exécution sont déterminants pour l interprétation des résultats et la qualité de la mise en production à venir. La bascule L action du changement de progiciel, la bascule de l ancien système vers le nouveau, est cruciale. Cette étape intervient en fin de projet, lorsque : Les phases de tests des fonctionnalités du nouveau système et de son implémentation dans l environnement technique ont abouti à un «GO» ; Les données à migrer, leur qualité et leur prise en charge dans le système cible ont également été testées et approuvées ; La méthodologie de bascule a été définie de manière précise. Si la bascule n est pas réalisée convenablement, elle peut contraindre : Au report de la bascule ; Au maintien de l ancien système. Dans tous les cas, une telle éventualité s avèrera coûteuse pour l entreprise. Validation des données Une fois basculées, les données sont l objet d une dernière vérification. Cette étape permet de concrétiser le travail précédemment réalisé. Elle se conclut par la validation de la migration des données et correspond à l achèvement du projet. En cas de non validation des données migrées, la réussite du projet est remise en cause. Réussite du projet Le processus de mise en production est déterminant pour l appréciation globale de la réussite du projet. Il implique l organisation d une équipe «projet» constituée d équipes «fonctionnelles» et d équipes «techniques», d une gestion adéquate des tests fonctionnels, de non régression et de performance. Par ailleurs, l équipe «projet» a un rôle à jouer pour assister les utilisateurs et l équipe de maintenance dans la gestion des configurations, des incidents et de la conduite du changement. T o u s d r o i t s r é s e r v é s, r e p r o d u c t i o n e t d i f f u s i o n i n t e r d i t e s P a g e 5 5