Une entreprise réutilise certaines informations en permanence. Une même identité produit, un fournisseur approuvé, un client ou une gamme de tailles peuvent servir à de nombreuses commandes. D'autres informations n'existent que parce qu'une commande, une réception, un contrôle, une expédition ou une facture a eu lieu. Mélanger ces deux catégories crée des erreurs évitables.
Dans cette leçon, les données de référence désignent des informations relativement stables, maintenues de façon contrôlée et réutilisées dans plusieurs transactions. Les données de transaction sont créées par un événement commercial précis. « Stable » ne veut pas dire « immuable ». Cela veut dire que la valeur change par une modification approuvée, et non parce qu'une ancienne commande a été recopiée. L'objectif pratique est simple : réutiliser ce qui doit l'être et créer un enregistrement distinct et traçable pour chaque nouvelle transaction.
Vous devez connaître : les règles des leçons 1.1 et 1.2 : chaque champ important a un responsable et une source approuvée, et l'équipe maintient une seule version courante approuvée.
À la fin de cette leçon, vous pourrez :
Non couvert ici : conception de base de données, configuration logicielle, modèles techniques de données ou produit ERP/PLM particulier. Nous restons sur la règle métier.
| Terme | Signification |
|---|---|
| Responsable de la donnée | Le rôle chargé de confirmer qu'une donnée métier précise est actuelle et correcte. |
| Source approuvée | Le document, l'approbation ou l'enregistrement maîtrisé qui prouve la valeur en vigueur. |
| Source de référence | L'enregistrement courant reconnu comme faisant autorité pour une donnée. |
| Donnée dérivée | Une valeur calculée à partir d'autres entrées approuvées. |
| Transmission de données | Le moment où l'information passe à une autre personne ou un autre service. |
| Utilisateur en aval | Une personne ou une équipe qui dépend d'une donnée précédente pour travailler correctement. |
Ces termes restent valables que le champ soit réutilisable ou propre à une seule transaction.
Si un produit possède une identité et une construction approuvées, chacun ne doit pas ressaisir de mémoire une nouvelle identité dans chaque commande. Si un fournisseur a une raison sociale et des paramètres de paiement approuvés, chaque acheteur ne doit pas entretenir sa propre variante du nom. Les informations réutilisées ont besoin d'un responsable et d'une source maîtrisée.
Une transaction est différente. Sa quantité, sa date demandée, sa répartition couleur/taille, sa réception, son résultat de contrôle, son étape d'expédition et sa facture appartiennent à cet événement. La transaction peut reprendre des champs de référence approuvés pour donner le contexte, mais elle doit conserver son propre historique. Si la référence change plus tard, les anciennes transactions ne doivent pas être réécrites silencieusement.
| Ce qui peut varier | Traitement habituel | Pourquoi c'est important |
|---|---|---|
| Identité produit et spécification approuvée | Maintenir le code style, la construction, la gamme de tailles et la matière standard comme références contrôlées. | Plusieurs commandes peuvent utiliser la même définition sans la ressaisir. |
| Identité client et fournisseur | Maintenir raison sociale, adresse, rôles de contact et paramètres convenus dans un enregistrement unique. | Une petite différence de nom peut créer un doublon involontaire. |
| Engagement de commande | Enregistrer quantité, date demandée, couleurs/tailles et conditions propres à cette commande. | La commande suivante peut légitimement être différente. |
| Événement d'exécution | Enregistrer réception, avancement, contrôle, expédition ou facture au moment où l'événement se produit. | Ces faits ont une date et doivent garder leur propre historique. |
| Réassort Make to Stock | Réutiliser les références produit et site, mais créer chaque réassort, mouvement ou vente comme transaction séparée. | Une prévision permanente ne transforme pas tous les réassorts en un seul événement. |
Cedar & Co. est une entreprise Make to Stock domestique avec 12 magasins. L'équipe planifie à partir d'une prévision permanente. Omar ne veut pas que chaque magasin ou acheteur reconstruise la description produit à chaque réassort. L'identité du style, la gamme de tailles et la spécification courante sont des références réutilisables. Elles ont besoin d'un responsable et d'une source maîtrisée.
Un réassort n'est pourtant pas une donnée de référence. Chacun a sa quantité, sa date demandée et son statut. Un transfert entre magasins est un autre événement. Une réception en stock en est un autre. Une vente en est encore un autre. Tous peuvent pointer vers le même produit, mais doivent rester des transactions distinctes afin que Cedar & Co. puisse savoir ce qui s'est réellement passé, où et quand.
La même règle vaut en usine, bureau d'achat, filature/tissage ou distribution : maîtriser l'identité de l'objet et séparer l'historique de chaque événement.
Le calculNous utilisons deux transactions fixes de l'académie uniquement comme comparaison, pas comme commandes de Cedar & Co. Order A comprend 15 000 T-shirts à 3,20 USD par pièce. Order B jeans comprend 3 000 jeans à 9,80 USD par pièce.
Les deux transactions sont valides, mais leurs quantités, prix unitaires et valeurs totales diffèrent. C'est pourquoi une quantité ou une valeur de commande ne doit pas être stockée comme attribut permanent du produit. Un style peut garder une identité stable alors que chaque commande porte sa propre quantité approuvée. La fiche produit dit ce qu'est l'article ; la transaction dit ce qui s'est passé commercialement cette fois-ci.
Inscrivez ensuite la réponse dans la fiche de responsabilité. Marquez les champs réutilisables, leur responsable et leur source. Marquez séparément les champs propres à la transaction. Lors d'une nouvelle commande, ne reprenez que les valeurs de référence approuvées et créez ou reconfirmez toutes les valeurs propres au nouvel événement.
Le piègeUne référence peut changer. Une spécification produit peut recevoir une révision approuvée. Une adresse fournisseur peut évoluer. Un paramètre client peut être corrigé. Le contrôle ne vient pas d'un gel éternel du champ ; il vient d'une modification volontaire par le responsable et d'une nouvelle version qui devient la source approuvée pour l'avenir.
L'erreur inverse est plus dangereuse : copier la commande précédente et laisser sa quantité, sa date, son prix ou son statut servir de vérité initiale à la suivante. Cela économise quelques secondes de saisie mais peut coûter des heures d'enquête. Réutilisez les références approuvées ; reconfirmez les champs transactionnels.
Pensez aux informations de référence comme au carnet d'adresses et à la bibliothèque de produits de l'entreprise. Vous voulez une description fiable d'un produit, d'un client, d'un fournisseur ou d'un site, réutilisable à chaque besoin. Les données de transaction sont plutôt le journal de ce qui s'est réellement passé : cette commande, cette réception, ce contrôle, cette expédition, cette facture.
La bibliothèque peut être mise à jour après une modification approuvée. Le journal doit continuer à montrer ce qui était vrai au moment de l'événement. Une nouvelle commande peut pointer vers la même fiche produit, mais elle possède sa propre quantité, sa propre date et ses propres faits commerciaux. Cette séparation empêche une ancienne commande de devenir la règle cachée de la suivante.
L'équipe d'Omar chez Cedar & Co. prépare un nouveau réassort pour un style existant. La fiche produit courante approuvée contient déjà l'identité du style et sa spécification. Un membre de l'équipe ouvre la dernière ligne de réassort et propose de la copier entièrement pour aller plus vite. Cette ligne contient aussi la quantité précédente, la date demandée et les instructions commerciales du réassort précédent.
Quelles informations peuvent être reprises et lesquelles doivent être créées ou reconfirmées avant de libérer le nouveau réassort ? Décidez avant d'ouvrir la réponse.
Reprendre uniquement les références courantes approuvées. Créer ou reconfirmer chaque champ propre à la transaction.
1. Utiliser l'identité produit et la spécification courante depuis leur source maîtrisée, pas simplement depuis l'ancienne ligne. 2. Créer ou reconfirmer la nouvelle quantité, la date demandée, la destination et toute instruction commerciale propre à ce réassort. 3. Donner au nouveau réassort sa propre identité de transaction et son propre historique de statut. 4. Garder l'ancien réassort inchangé comme historique ; ne pas l'écraser pour créer le nouveau. 5. Si un champ de référence a changé depuis le dernier réassort, utiliser la nouvelle valeur approuvée pour le nouvel événement tout en conservant l'historique ancien.
Cette décision n'interdit pas le copier-coller. Elle impose de savoir ce qui est copié. Un modèle contrôlé peut faire gagner du temps, mais aucun champ d'une ancienne transaction ne doit survivre dans une nouvelle uniquement parce que personne ne l'a remarqué.
Le problème peut devenir une mauvaise quantité, une mauvaise date, une mauvaise destination, un client en double ou une spécification périmée. Il coûte aussi du temps : comparaison de lignes, recherche d'e-mails, annulation de mouvements de stock, correction de documents et explication des écarts entre rapports.
Les exemples approuvés montrent l'échelle de deux transactions distinctes. Order A représente 48 000 USD de FOB total ; Order B jeans représente 29 400 USD. Ce sont deux dossiers commerciaux distincts, pas des valeurs permanentes à inscrire dans une fiche produit. Garder la frontière claire coûte moins cher que réparer une nouvelle commande construite sur les faits de l'ancienne.
Ouvrez le classeur T17-C01 sur la responsabilité et la qualité des données. Pour chaque champ, indiquez le responsable, la source approuvée et s'il s'agit d'une référence réutilisable ou d'une information propre à une transaction. Pour les références, notez comment les révisions sont approuvées. Pour les transactions, notez quel événement crée la valeur et quels utilisateurs en aval en dépendent.
Avant une nouvelle commande ou un nouveau réassort, reprenez uniquement les références courantes approuvées. Effacez ou reconfirmez chaque champ transactionnel.
[Télécharger le classeur](../../templates/T17-C01-data-ownership-data-quality.xlsx)
1. Quel champ est le plus probablement une information de référence réutilisable ?
2. Que faire quand une référence approuvée change après la fin d'une ancienne transaction ?
3. Pourquoi copier la ligne de la commande précédente peut-il être risqué ?
| FR | EN | AR | TR | Signification |
|---|---|---|---|---|
| Responsable de la donnée | Data owner | مسؤول البيانات | Veri sorumlusu | Le rôle chargé de confirmer qu'une donnée métier précise est actuelle et correcte. |
| Source approuvée | Approved source | المصدر المعتمد | Onaylı kaynak | Le document, l'approbation ou l'enregistrement maîtrisé qui prouve la valeur en vigueur. |
| Source de référence | Source of truth | المرجع المعتمد | Ana referans | L'enregistrement courant reconnu comme faisant autorité pour une donnée. |
| Donnée dérivée | Derived data | بيانات مشتقة | Türetilmiş veri | Une valeur calculée à partir d'autres entrées approuvées. |
| Transmission de données | Data hand-off | تسليم البيانات | Veri devri | Le moment où l'information passe à une personne ou un service qui en a besoin. |
| Utilisateur en aval | Downstream user | مستخدم لاحق للبيانات | Sonraki kullanıcı | Une personne ou équipe qui dépend d'une donnée précédente pour travailler correctement. |
La prochaine leçon montre comment vérifier que les données sont complètes, valides, cohérentes et disponibles au bon moment avant de les transmettre. Retour à la carte du cours