Migration de données : quel est le vrai coût ?

Les raisons ayant conduit aux changements sont souvent clairement définies, mais la véritable estimation du prix du projet en lui-même est, quant à elle, fréquemment négligée au début du projet. En effet, le coût réel finit par être exprimé lors de la réunion du conseil d’administration lorsque vous devez expliquer pourquoi les coûts sont dépassés, les échéanciers ne sont pas respectés et les résultats promis ne sont pas atteints.

Le problème est que le nouveau système mis en place peut parfois être aussi peu performant que l’ancien système s’il utilise les mêmes données. Les meilleurs systèmes modernes s’accompagnent souvent d’une protection des données et de la capacité de forcer l’utilisateur à suivre des processus prédéfinis ainsi que divers contrôles au fur et à mesure que les données sont saisies dans le système en cours d’exécution. Ces contrôles peuvent être désactivés afin d’aider la migration, mettant ainsi le système en péril avant même d’avoir commencé à fonctionner.

Une fois que le système est infecté par des données de mausvaise qualité, le coût des réparations est estimé à 10 fois celui nécessaire pour empêcher les mauvaises données d’infiltrer votre système.

Ainsi, les divers coûts qui doivent être pris en considération lors de la migration des systèmes d’information de base sont :

• temps de développement / test / mise en œuvre de scripts de migration
• coût de la formation du personnel sur la façon d’utiliser le nouveau système
• les coûts associés à la gestion à la fois parallèle du nouveau et de l’actuel système
• réglage des processus et des rapports de la société vers le nouveau système

Un autre coût, rarement ajouté, mais qui devrait être pris en compte, est le coût potentiel de l’échec de la migration. Cela inclut également le coût réel de la migration livrée bien plus tard que prévu initialement.

Gartner estime que 31% des initiatives relatives aux données ont échoué l’année dernière en raison de mauvaises données. Par ailleurs, 24% ont subi une livraison tardive de leur projet en raison de problèmes liés aux données.

Pas un seul système ne peut prétendre travailler de manière efficace si les données sur lesquelles il fonctionne sont obsolètes, inexactes ou partiellement absentes. Considérez le coût de ne pas pleinement utiliser le nouveau système à son plein potentiel. Comment les fonctions jugées critiques par l’organisation parviennent-elles à fonctionner si l’information sous-jacente est inexacte ?

Faut-il simplement mettre la qualité des données à  l’ordre du jour des réunions sur l’état de la migration ? C’est un début ; il faut reconnaître que la qualité des données signifie beaucoup de choses différentes pour les différentes personnes au sein de l’organisation. Le directeur marketing, par exemple, aura une idée très différente de ce que « la qualité des données» signifie comparé à l’administrateur de base de données, et cela devrait être pris en compte lors des réunions hebdomadaires.

Bien que la qualité des données puisse être le plus grand risque dans une migration, cela peut aussi s’avérer être son plus grand atout. La migration est un moment opportun pour réfléchir sur la qualité des données et s’assurer que le nouveau système est alimenté par les données de la plus haute qualité.

Les outils de qualité de données peuvent automatiser l’analyse des données de migration et signaler des inexactitudes ainsi que des problèmes pouvant considérablement freiner la migration ou réduire l’efficacité du nouveau système. Outre les renseignements statistiques obtenus à partir de l’analyse des données, il faut également prendre en compte la possibilité d’être en mesure de s’assurer que toutes les données passent un filtre de qualité des données lors de la migration. Cela garantit que toutes les données migrées sont conformes aux normes établies par l’équipe de migration et que l’importation s’est faite correctement dans ce nouveau système.

Les défis déjà mentionnés sont exacerbés par le fait que la migration n’est souvent pas un exercice ponctuel. Comme les départements sont migrés tour à tour, l’ancien système et le nouveau système devront fonctionner en parallèle pendant un certain temps. Dans l’optique de limiter le risque, c’est bien sûr une bonne tactique ; mais l’exécution de deux ou plusieurs systèmes en parallèle signifie que notre migration peut potentiellement devenir la cible d’une attaque. Nous devons nous assurer que les systèmes sont synchronisés en dépit du fait que les données sont probablement accessibles, représentées et utilisées très différemment.

Ici, la qualité des données peut à nouveau nous aider. Grâce aux outils de qualité de données les plus à jour du marché, il est possible de savoir quelle est l’information qui est stockée, où et sous quel format, et il est également possible de savoir que Pierre et Paul représentent la même entité dans notre nouveau et ancien système de base. Comme les données changent dans le nouveau système, il peut être nécessaire de mettre à jour l’ancien système afin de refléter ceci. De la même façon, comme les départements utilisant encore les anciens systèmes ajoutent des informations nouvelles ou modifient des éléments existants, ces changements doivent être reflétés dans le nouveau système. Ce style de migration est également connu comme la migration continue synchronisée et il réduit considérablement l’effort global de migration et le risque associé.

Si vous êtes encore à vous demander si oui ou non cet effort en vaut vraiment la peine, pensez aux bénéfices de réduire de 50% les risques d’échec de votre implémentation. Les migrations sont, certes, coûteuses, mais ne laissez pas ces coûts avoir raison de vous.