Transfert de données entre deux systèmes : intégration ou manuel ?

Définissez d'abord les informations et la transaction à déplacer

Un enregistrement de vente peut être saisi d'abord dans le système client, puis dans l'application comptable. Une autre équipe pourrait déplacer la liste des fournisseurs d'un fichier Excel vers l'écran d'achat. Dans les deux cas, le problème n’est pas seulement la copie. Il faut savoir quel champ a quelle signification, quand le dossier est finalisé et où la correction sera effectuée. Une connexion établie avant que ces informations ne soient clarifiées peut transporter des données erronées plus rapidement. La première étape consiste à écrire le processus actuel à travers quelques exemples réels. Par exemple, le numéro de commande est-il disponible dans les deux systèmes ? Ou la correspondance est-elle effectuée en fonction du nom et de la date ?

Spécifiez la source de données séparément. Si l'adresse du client est mise à jour dans une application mais reste ancienne dans une autre, la version à utiliser doit être claire. Chaque champ doit avoir une source principale et valide, quelle que soit la méthode de transfert. Un bon début consiste à écrire côte à côte dans un tableau le nom du champ, le format, l’obligation, le champ cible et la règle de contrôle. De cette façon, les différences entre les systèmes deviennent visibles et tout le monde utilise la même cartographie.

Quand le transfert manuel est-il raisonnable ?

Si le travail est effectué rarement, que le nombre d'enregistrements est faible et que chaque enregistrement doit être interprété, un transfert manuel peut être raisonnable. Automatiser immédiatement un processus qui est encore en évolution peut impliquer de réexécuter encore et encore les règles changeantes dans le logiciel. Cependant, le travail manuel doit aussi avoir un certain ordre. L'enregistrement transféré doit être marqué, une deuxième saisie doit être empêchée et le résultat doit être vérifié. Si la devise ou la date d'un montant copié est incorrecte, les totaux égaux des deux écrans ne suffiront pas à détecter l'erreur.

Ne comptez pas seulement le temps de frappe pour estimer le coût du travail manuel. Préparer le dossier, compléter les champs manquants, trouver l'erreur et la corriger font également partie du travail. L’enregistrement des étapes du processus et des exceptions pendant une semaine fournit des données concrètes pour la prise de décision. Ce record ne garantit pas un taux d’épargne précis ; Il montre quelle étape est répétée et laquelle nécessite une évaluation humaine. La limite appropriée pour l’automatisation se résume souvent à cette distinction.

Le transfert groupé via fichier peut être une solution intermédiaire

Si le système source propose l'export et le système cible propose l'import, un traitement par lots via CSV ou Excel peut être suffisant. Cette méthode ne nécessite pas de connexion constante entre les deux applications. D'autre part, l'ordre des colonnes, le format de date, le séparateur décimal, l'encodage des caractères et le comportement de l'espace libre doivent être vérifiés. Une correspondance qui fonctionne dans le fichier exemple peut ne pas produire le même résultat dans un fichier provenant d'un autre pays. Les codes de produits comportant des zéros non significatifs peuvent également être interprétés comme des chiffres et peuvent changer.

Choisissez un petit échantillon représentatif pour essayer le transfert de fichiers. Les nouveaux enregistrements, les enregistrements mis à jour, les champs manquants et les enregistrements en double doivent être inclus dans le même test. Les lignes acceptées et rejetées apparaîtront séparément dans le rapport d'importation. La correction et la soumission à nouveau de la ligne ayant échoué ne doivent pas recréer les lignes réussies. pour ce besoin saisie de données en masse L'approche peut être examinée ; La méthode doit là encore être choisie dans les limites permises par l'application utilisée.

Dans quelles conditions l’intégration directe a-t-elle du sens ?

Si les travaux sont répétés fréquemment et que les deux parties disposent d'interfaces de connexion prises en charge, une intégration peut être envisagée. Avoir une API seule ne suffit pas. L'autorisation d'accès, les limites d'utilisation, la signification des champs, l'ordre de mise à jour et les réponses aux erreurs doivent être connus. Il convient également de déterminer dès le début si la connexion sera uniquement en lecture ou en écriture. Au lieu d'accorder une autorisation trop large, le champ d'application le plus restreint pour mener à bien l'action concernée est sélectionné. Avant de travailler avec des données de production, une vérification est effectuée dans un environnement de test approprié.

Le sens de transmission doit être clair. Dans une connexion unidirectionnelle, le système source transmet la modification à la cible. Dans une connexion bidirectionnelle, il est possible que le même enregistrement soit modifié des deux côtés. Dans un tel cas, il n’est pas toujours juste que le dernier à écrire gagne. La règle de conflit, la date de modification et les champs nécessitant une approbation humaine doivent être définis. La suppression nécessite également une décision particulière : supprimer l'enregistrement de l'autre côté, le désactiver ou simplement supprimer le lien aura des conséquences différentes. La suppression automatique ne doit pas devenir le comportement par défaut.

Réinventez la gestion des erreurs et des replays

La même demande peut être renvoyée lorsque la connexion est perdue. Le système doit être capable de comprendre qu'il s'agit d'une répétition de la transaction précédente et non d'un nouvel enregistrement. Cela nécessite un identifiant d'enregistrement et un statut de transfert inchangés. Les transactions réussies, les transactions en attente et les erreurs nécessitant une intervention humaine sont séparées. La notification ne doit pas simplement indiquer qu’il y a une erreur ; Il doit indiquer quels enregistrements peuvent être affectés, s'il est possible de réessayer en toute sécurité et l'étape suivante. Les journaux ne doivent pas se transformer en une pile de mots de passe et de données personnelles.

Prenez la décision avec un petit pilote

Sélectionnez d'abord un seul groupe de données et une action limitée. Le critère de réussite du projet pilote devrait être la correspondance correcte des champs, la prévention de la récurrence et le suivi des erreurs plutôt que le nombre de transmissions. Comparez les résultats avec les enregistrements sources ; Essayez également le chemin du retour. Les méthodes peuvent être comparées lorsque le propriétaire du processus, le propriétaire de la connexion et le responsable sont clairs. Options commerciales et d'automatisation Déterminer le périmètre via permet de clarifier la limite du problème avant de changer les pratiques existantes.

Questions fréquentes

Une API est-elle requise pour chaque transfert de données ?

Non. Les petits travaux peu fréquents peuvent être effectués manuellement, les travaux appropriés peuvent être effectués via un fichier. La décision concernant l'API est prise en fonction de la fréquence de récurrence, de l'accès pris en charge et de la gestion des erreurs.

Que se passe-t-il si le même enregistrement change des deux côtés ?

Des règles de collision sont requises pour la transmission bidirectionnelle. Les zones qui seront alimentées par quel système et les changements qui nécessiteront l'approbation humaine sont déterminés à l'avance.

Comment réaliser le premier test ?

Un ensemble de données restreint et représentatif est sélectionné. Des enregistrements nouveaux, mis à jour, manquants et en double sont tentés ; Les résultats sont comparés à la source.