Les conseils que vous connaissez déjà sont justes. Désignez un propriétaire. Commencez par un petit scope. Liez-le à un problème métier. Achetez un logiciel adapté.
Ce n'est pas là que les programmes s'effondrent. Ils s'effondrent dans les mécanismes qui les soutiennent : ce moment précis où une entrée du catalogue devient erronée et personne ne la corrige, la réunion où deux départements découvrent qu'ils ne parlent pas de la même chose quand ils disent « client », la facture qui arrive quand votre volume de données a triplé. Cet article traite de ces moments, car c'est là que la réussite ou l'échec d'une implémentation de gouvernance des données se décide réellement.
La Prédiction Qui Mérite d'Être Lue Attentivement
Gartner prévoit que d'ici 2027, 80 % des initiatives de gouvernance des données et analyses échoueront. Cette statistique est citée partout, généralement dépouillée de la partie qui compte vraiment. C'est une prévision, pas un résultat mesuré, et Gartner donne une cause précise : les programmes échouent parce qu'ils manquent d'une crise réelle ou artificiellement créée pour s'organiser autour.
Comprenez cela comme un diagnostic. Une gouvernance mise en place pour satisfaire un audit n'a aucune crise derrière elle, elle produit donc une politique que personne n'applique. Une gouvernance mise en place pour arrêter un problème qui coûte actuellement de l'argent à quelqu'un est utilisée, car quelqu'un la surveille.
Le chiffre souvent répété selon lequel les mauvaises données coûtent à une organisation 12,9 millions de dollars par an mérite la même prudence. C'est une estimation de 2020, toujours citée comme actuelle, sans méthodologie publiée derrière ce chiffre rond. Utilisez-le pour donner une direction, pas pour dimensionner un budget. Votre propre taux de doublons et vos heures de travail de correction sont une meilleure preuve qu'une moyenne vieille de cinq ans, et les rassembler est la première chose vraiment utile qu'un programme fait.
La Boucle d'Obsolescence Qui Tue les Catalogues
Voici l'échec que j'ai décrit en une ligne la dernière fois, montré en détail, parce que cette ligne cache tout le problème.
Un catalogue est un ensemble d'affirmations sur vos données : ce qu'un champ signifie, d'où il provient, qui en est propriétaire. Ces affirmations deviennent obsolètes dès que le système source change. Une nouvelle colonne apparaît. Une définition se décale. Un pipeline est redirigé. Pour rester exact, chacun de ces changements doit être reflété dans le catalogue.
Si ce reflet est manuel, quelqu'un doit remarquer le changement, ouvrir l'outil et modifier l'entrée. Ce travail entre en concurrence avec tout le reste sur leur liste, et il n'a pas de date limite. Il est donc reporté. Quelques entrées deviennent obsolètes. Les gens consultent une mauvaise entrée, perdent confiance et cessent de vérifier le catalogue. Une fois qu'ils arrêtent de vérifier, personne ne remarque l'entrée erronée suivante, et le décalage s'accélère. Au sixième mois, le catalogue décrit un système qui n'existe plus.
Un catalogue ne s'effondre pas d'un coup. Il s'effondre une entrée ignorée à la fois, et la première mauvaise entrée qu'un utilisateur découvre est celle qui lui apprend à cesser de lui faire confiance.
La solution est l'automatisation : moissonnage des métadonnées, détection des changements de schéma, entrées qui se mettent à jour d'elles-mêmes quand la source bouge. Cela coûte de l'argent. L'argent a besoin d'un sponsor. Et un sponsor n'apparaît que quand le programme est lié à une crise dont quelqu'un se soucie. C'est pourquoi la prédiction de Gartner et le catalogue obsolète sont le même problème avec deux visages. Pas de crise, pas de sponsor. Pas de sponsor, pas d'automatisation. Pas d'automatisation, maintenance manuelle. La maintenance manuelle s'interrompt dans le premier trimestre chargé.
Donc n'achetez pas un catalogue que vous maintiendrez à la main. Achetez la capacité à le maintenir à jour, ou gouvernez un périmètre plus petit que vous pouvez réellement maintenir exact.
Quand Deux Départements Possèdent Tous les Deux « Client »
Cette réunion décide si la gouvernance est réelle, et la plupart des déploiements ne la prévoient jamais.
Pour les ventes, c'est un compte, une entreprise qui vous achète, tandis que pour la finance, c'est une entité juridique qui paie les factures, ce qui peut être une maison mère couvrant trois comptes des ventes. Pour le marketing, c'est une personne, un contact nommé qui a ouvert un e-mail. Le même mot porte trois définitions à travers trois systèmes, et chacune est correcte dans le département qui l'utilise.
Le conflit se manifeste le jour où quelqu'un crée un rapport à travers les trois et les comptes clients ne correspondent pas. Ou une déduplication fusionne deux enregistrements qui n'ont jamais été la même chose, parce que la règle supposait une définition de « client » et les données en contenaient trois.
Un propriétaire ne résout pas cela en déclarant un vainqueur. Le mécanisme est plus étroit et plus utile. Le propriétaire force les définitions à être écrites, ce qui seul finit la moitié de la confusion, puisque les trois équipes ne savaient généralement pas qu'elles n'étaient pas d'accord. Ensuite, le propriétaire prend une décision structurelle : « client » est-il un concept avec un attribut de type, ou trois entités séparées liées par des relations, un compte qui appartient à une entité payante et contient des contacts ? Cette décision de modélisation est la gouvernance réelle. Tout ce qui suit, comme la déduplication, la génération de rapports et l'accès, en découle.
La gouvernance n'est pas le document de politique. C'est avoir une personne avec l'autorité de mettre fin à un argument qui reviendrait autrement chaque trimestre.
La raison de régler cela avant d'acheter un logiciel est que la réponse détermine ce que vous avez besoin que le logiciel fasse. Trois entités liées ont besoin d'un outil avec un modèle de données relationnel flexible. Un concept unique et plat en a besoin de beaucoup moins. Achetez d'abord, et vous pourriez acheter un outil qui ne peut pas représenter la structure sur laquelle votre propre entreprise fonctionne.
Dans le travail que nous avons vu sur les données de produits et de fournisseurs, le même motif s'affiche un niveau plus bas : un « fournisseur » en approvisionnement est un « vendeur » en finance et un « fabricant » sur l'enregistrement du produit, et les trois étaient maintenus dans des feuilles de calcul séparées qui ne concordaient silencieusement. Les consolider sur un modèle de données unique avec des relations définies est moins une tâche logicielle qu'une décision sur laquelle de ces trois vues est la source de vérité. L'outil n'applique la décision que quand elle est prise.
Lisez le Modèle Tarifaire, Pas la Liste des Fonctionnalités
Les listes de fonctionnalités convergent. Les modèles tarifaires sont là où se cache le coût à long terme, et ils vous punissent d'une manière précise : presque chaque modèle taxe la chose qui signifie que votre programme fonctionne.
La gouvernance réussit en couvrant plus de données, en connectant plus de systèmes et en obtenant que plus de personnes participent. Regardez ce que chaque axe tarifaire fait à ce succès.
- Par enregistrement.
Comme exemple travaillé, supposons qu'un outil coûte un tarif fixe par 10 000 enregistrements gérés, et vous commencez avec 40 000 enregistrements de produits. La facture est faible. La gouvernance fonctionne, vous intégrez donc les données clients et absorbez le catalogue d'une acquisition, et vous êtes maintenant à 400 000 enregistrements. Le coût est dix fois ce pour quoi vous vous êtes inscrit, et à ce moment vos flux de travail et intégrations reposent sur l'outil, donc partir est coûteux. - Par source ou connecteur.
Vous commencez à gouverner quatre systèmes. Le succès signifie étendre la gouvernance à l'ensemble du patrimoine, et deux ans plus tard vous payez pour vingt connecteurs. - Par siège.
Cela semble bon marché jusqu'à ce que vous vous souveniez que la gouvernance ne fonctionne que quand les responsables de chaque département peuvent agir. Plus le programme s'étend, plus vous achetez de sièges.
Chaque axe vous facture davantage précisément à mesure que vous réussissez. Le mouvement n'est pas de trouver un modèle sans coût. C'est de choisir l'axe que vous pouvez prévoir et contrôler. Si votre nombre d'enregistrements est volatil et votre liste de sources est stable, la tarification par source est plus sûre, et l'inverse est aussi vrai.
Sur le logiciel lui-même, le marché se divise en deux. Les grandes suites d'entreprise comme Collibra et Informatica gèrent le catalogage étendu et la traçabilité à travers des patrimoines complexes, avec la tarification et l'effectif qui vont avec. Pour les données principales comme les produits, fournisseurs et données de référence, les plateformes open-source sont un point d'entrée plus léger. AtroCore en est une, avec un modèle de données configurable, un accès basé sur les rôles et un historique des changements qui couvrent les mécanismes de gouvernance fondamentaux sans contrat d'entreprise ; elle se situe aux côtés d'options comme Apache Atlas et OpenMetadata, chacune plus performante pour un travail différent. Établissez une shortlist de deux ou trois et testez-les avec le test ci-dessous avant de vous engager sur un modèle tarifaire.
Ce Qu'Un Pilote Expose Que Démo Cache
Une démo du fournisseur s'exécute sur les données du fournisseur, et les données du fournisseur sont propres. C'est la raison entière pour laquelle la démo semble impeccable et vous dit presque rien.
Exécutez le pilote sur vos pires enregistrements à la place. Pour la déduplication, cela signifie alimenter l'outil avec votre vraie liste de clients ou fournisseurs, celle avec « Acme Inc », « Acme, Inc. » et « ACME INCORPORATED » comme trois lignes, plus les fautes de frappe, les codes pays manquants et cette entreprise qui s'échange légalement sous deux noms. Ensuite, étiquetez manuellement quelques centaines de ces lignes vous-même pour connaître la bonne réponse, et mesurez l'outil par rapport à elles.
Deux nombres sortent. Combien de vrais doublons elle a capturés, et combien d'enregistrements distincts elle a à tort fusionnés. Une fusion fausse est la dangereuse, car elle détruit les données en combinant deux clients qui n'ont jamais été les mêmes, et une démo propre ne la surfacera jamais. Ces deux chiffres vous indiquent si le moteur de correspondance fonctionne sur vos données. Rien de ce que le fournisseur vous montre ne le fera.
Faites la même chose pour tout ce qui compte le plus dans votre cas : un changement de schéma que le catalogue doit attraper, un flux d'approbation sous une charge réaliste, une règle d'accès avec un cas limite réel. Testez la chose qui cassera, pas celle qui démarre bien.
L'implémentation de la gouvernance des données se résume à une poignée de ces mécanismes. Gardez le catalogue exact, réglez les définitions avant de modéliser, tarifez pour la croissance que vous attendez, et testez le pilote sur vos données les plus sales. Obtenez cela juste, et les conseils génériques s'occupent d'eux-mêmes.