Processus de données / 07
Deux systèmes. Des règles claires pour un même enregistrement.
Un client est modifié dans le CRM et aussi dans l’ERP. Quelle version fait autorité ? Nous construisons la synchronisation autour des responsabilités métier et des identités stables afin que les transferts réguliers ne créent pas de conflits silencieux.
La situation initiale
Bidirectionnel ne signifie pas que chaque champ circule dans les deux sens.
Le CRM gère les interlocuteurs, l’ERP l’adresse de facturation et les conditions de paiement. Les deux systèmes enregistrent le même client avec leur propre identifiant. Une règle générale donnant priorité à l’horodatage le plus récent peut remplacer une adresse ERP validée par un contenu CRM plus ancien.
Nous examinons chaque champ et chaque processus séparément. Les identifiants stables, marqueurs de modification et informations de suppression sont essentiels. Sans accès fiable aux deltas, un rapprochement complet maîtrisé est souvent plus réaliste qu’un fonctionnement supposé en temps réel.
Ce que DataSource prend en charge
Détecter les changements. Résoudre les conflits.
Identité
Associer les identifiants locaux et détecter les doublons métier. Définir une procédure pour les enregistrements créés, fusionnés et supprimés.
Directions
Définir le système de référence pour chaque champ. Marquer les changements par leur version ou leur origine lorsque les systèmes le permettent, afin de limiter les boucles de synchronisation.
Rapprochement
Traiter les deltas, enregistrer les progrès confirmés et prévoir des comparaisons régulières comme contrôle correctif. Résoudre les conflits avec l’équipe responsable.
Kunde 004218
ERP → CRM: billingAddress, paymentTerms
CRM → ERP: contactName, contactPhone
Version passt → definierte Felder aktualisieren
Version weicht ab → erneut lesen / Konflikt klären
Datensatz gelöscht → vereinbarte Löschregel anwendenScénario technique / Exemple illustratif
Une modification d’adresse est propagée de manière ciblée.
Scénario d’état illustratif. L’ERP gère l’adresse de facturation, le CRM le contact. Un conflit de version est signalé au lieu d’écraser aveuglément l’ensemble de la fiche client.
Données d’exemple et règles proposées. Les interfaces et règles métier concrètes seront examinées pour votre projet.
Gestion des erreurs, sécurité et exploitation
Conflits, suppressions et progression.
Suppressions
L’absence dans une réponse incomplète ne constitue pas une notification de suppression. Des tombstones, un archivage ou un inventaire complet confirmé doivent préciser sa signification.
Interruptions
Reprendre après une panne depuis le dernier état confirmé. Si les données de modification ont expiré, effectuer un nouveau rapprochement selon une procédure définie.
Actualité des données
Convenir des fenêtres de traitement et des délais acceptables. Le temps réel ne constitue pas un engagement fiable sans source adaptée, capacité cible et responsabilité d’exploitation.
Questions métier
Les détails qui comptent avant la mise en œuvre.
Delta · Rapprochement · Responsabilité par champ · Conflits · Suppressions
Peut-on modifier le même champ dans les deux systèmes ?
Oui, mais il faut une règle de résolution des conflits ou un processus de validation. Une règle d’horodatage n’est pertinente que si son effet métier et la référence temporelle sont adaptés.
Les webhooks empêchent-ils toutes les mises à jour manquantes ?
Non. Les événements peuvent arriver plusieurs fois, en retard ou dans un ordre différent. Selon le fournisseur, un rapprochement complémentaire est utile.
Comment traiter les doublons ?
Clarifier d’abord les règles d’identification et la qualité des données existantes. Les associations incertaines doivent être vérifiées avant toute fusion automatique.
Pour la clarification technique
Partir de votre processus concret.
Décrivez les systèmes, objets de données, exemples d’identifiants, directions souhaitées et délais acceptables. Les exemples de conflits et de suppressions sont particulièrement utiles.
Le premier échange clarifie les accès disponibles, la responsabilité des données et un premier flux limité. Nous convenons ensuite du périmètre, des responsabilités et des conditions.
Des exemples anonymisés suffisent pour commencer. Merci de ne pas envoyer de mots de passe, tokens ou données personnelles de production dans la première demande.
Problématiques associées
La prochaine connexion dans son contexte.
Interfaces ERP et CRM
Les équipes commerciales et comptables traitent le même client avec des missions différentes. DataSource connecte les interfaces prises en charge et clarifie quelles données sont transférées, et quand, entre prospect, client et compte débiteur.
Synchroniser les commandes & les statuts
La boutique signale le paiement, l’ERP n’a pas encore de commande et le service d’expédition dispose déjà d’un numéro de suivi. Nous relions ces étapes avec des états définis, des références de commande uniques et une reprise planifiée.
Traiter les webhooks de manière fiable
Un événement arrive et doit déclencher une action dans le système suivant. Livraisons multiples, retards ou panne de l’API cible en font un processus d’exploitation. Nous le développons avec des événements explicites et des effets vérifiables.