Une opération indispensable pour la migration

Tout Système d’Information fonctionne plus ou moins bien suite à des anomalies de logiciel, ou tout simplement parce que certains contrôles ne sont pas effectués lors de l’utilisation du système.

C’est particulièrement vrai sur les systèmes créés il y a quelques années, où certaines opérations étaient moins bien encadrées, comme par exemple la saisie de dates, qui pouvaient être rentrées sous des formats différents.

De ce fait, il existe nécessairement, dans le système source, des données qui ne sont pas correctes, ou pas fiables.

Par exemple, lorsque l’adresse d’un client est incomplète, tous les courriers lui étant adressés ne lui arrivent pas, ce qui entraîne :

un coût d’envoi inutile ;
du temps de traitement des retours NPAI (n’habite pas à l’adresse indiquée) ;
la rupture de la communication avec le client.

Les cas les plus courants concernent les informations sur les adresses, les numéros de téléphone, la civilité (M, Mme, Mlle) ou les RIB qui ne sont pas cohérentes ou non normalisées (une adresse postale française doit être structurée d’une façon très précise).

On constate également...

Les trois types de fiabilisation

Le chantier Fiabilisation des données reçoit de la part du chantier Migration des données des anomalies détectées sur la qualité des données du système source.

Son rôle est d’analyser ces anomalies et de décider quel va être le process mis en place pour corriger ces anomalies.

La fiabilisation peut être effectuée :

par saisie TP effectuée par l’utilisateur sur les données source ;
par passage de programme batch (ou requêtes) de mise en conformité de certaines données source ;
par règles de migration, définies lors de la spécification des règles.

Dans certains cas de figure, on peut également envisager de fiabiliser les données sur la cible après migration.

Mais il vaut mieux traiter les problèmes à la source.

1. Saisie transactionnelle

Il s’agit de mettre en place une action permettant de corriger sur le système source, des données obligatoirement à renseigner ou à structurer.

Prenons plusieurs exemples :

La civilité : lorsqu’elle n’est pas renseignée, il est possible de reprendre une transaction TP permettant de la renseigner, sur la base du prénom (quand ce n’est pas un prénom mixte).
L’adresse : certaines informations manquantes sont faciles à retrouver comme le code postal si l’on a la ville, ou le contraire.
Le numéro de téléphone : souvent...

À quel moment faut-il fiabiliser les données ?

La question se pose systématiquement lors des projets de migration, car :

Le système source possède toujours des données peu fiables.
Les projets de fiabilisation déjà étudiés n’ont jamais abouti, à cause du coût, des risques pris sur la base de production, ou par le caractère non prioritaire de l’opération.

Le premier élément de réponse est de privilégier la solution règle de migration.

Celle-ci permet de fiabiliser un maximum de données, avec la mise en place d’une table de transcodification et une modification (éventuelle) du logiciel source pour ne pas continuer à enregistrer la donnée de façon permissive.

Dans le cas où ce type de fiabilisation n’est pas possible (règle trop complexe), on envisagera la solution modification par saisie transactionnelle.

Cette solution a un coût certain et demande une logistique importante, mais elle n’implique pas de prise de risque.

Si l’opération est bien préparée, suffisamment à l’avance, il est même possible de suivre l’évolution des actions de fiabilisation, à l’occasion de chaque passage de la migration de données, et plus particulièrement lors des Bascules à Blanc.

À cette occasion...

Fiabilisation des adresses

Ce sujet est le plus fréquemment rencontré dans les opérations de fiabilisation.

Tous les Systèmes d’Information gèrent des adresses, que ce soit celles des clients, des fournisseurs, de divers prestataires, d’organismes d’État, de concurrents...

On constate que les erreurs sur les adresses sont courantes, engendrant des coûts postaux non négligeables.

Avant de trouver la bonne solution, la première chose à faire est d’effectuer une estimation la plus précise possible :

du volume d’adresses erronées ;
des coûts engendrés par ces erreurs ;
des conséquences au niveau commercial et marketing.

Cette analyse de la valeur permet d’orienter le choix, car chacune des solutions que l’on peut imaginer a un coût pour lequel il faut mesurer le retour sur investissement.

L’approche qui est proposée ici a été mise en place sur plusieurs projets et donne des résultats satisfaisants.

Elle présente un intérêt quand le volume d’adresses erronées est important.

Les principes de cette solution sont les suivants :

pas de mise à jour de la base de production avant la Bascule ;
application de la méthode « règle de migration » ;
utilisation d’un outil de fiabilisation d’adresses ;
création d’un outil sous Access pour stocker les bonnes adresses ;
mise en place d’une cellule pour corriger les adresses....