Hygiène des données RevOps : le socle peu séduisant de l'orchestration

Personne n'est promu pour avoir dédupliqué des comptes. Il n'y a pas de démo phare pour une liste déroulante bien maîtrisée, ni de slide de conseil d'administration célébrant le fait que la plupart des opportunités ont enfin un horodatage d'entrée d'étape. L'hygiène des données, c'est de la plomberie. Invisible quand ça marche, coûteuse quand ça ne marche pas, et chroniquement sous-financée parce que sa valeur est défensive.

Mais chaque projet sur lequel un responsable RevOps a vraiment envie de travailler repose sur cette plomberie. Attribution, scoring, prévision, meilleure action suivante, l'orchestration elle-même. Faites tourner un bon modèle sur des données sales et vous obtenez des réponses fausses, précises et pleines d'assurance. Nous avons vu des équipes passer des mois sur un modèle de scoring pour découvrir ensuite qu'une grande partie de leurs comptes étaient des doublons, ce qui signifiait que le modèle avait appris, depuis le début, à partir d'historiques d'activité scindés. L'hygiène est la couche la moins glamour de l'architecture moderne de plateforme de revenus, et celle dont tout le reste dépend silencieusement.

Quatre façons dont les données se dégradent

Les données de revenu se dégradent de manières prévisibles, et chacune appelle une réparation différente, d'où l'intérêt de les nommer.

Duplication. « Acme », « Acme Inc » et « Acme Corporation » existent tous les trois parce que trois outils ont créé le compte indépendamment et que rien ne les réconcilie. Les décomptes de pipeline gonflent, l'historique d'activité se scinde en trois, et aucun enregistrement pris seul ne vous dit quoi que ce soit.

Incomplétude. Les champs dont vous avez besoin pour l'analyse sont vides. Si 30 % des opportunités n'ont pas de source de lead, l'attribution par source n'est pas incertaine à 30 %. Elle est inutilisable, parce que vous n'avez aucun moyen de savoir si les 30 % manquants ressemblent en quoi que ce soit aux 70 % que vous voyez.

Incohérence. Le même concept est encodé différemment dans chaque système. « Closed Won » ici, « Won » là, « 6 - Closed » dans le troisième. Chaque jointure entre ces systèmes fait tomber ou mal compter des lignes, et elle le fait silencieusement.

Obsolescence. Le champ était juste, un jour. Le champion est parti, le niveau a changé, et personne n'a mis à jour. Les données obsolètes sont les plus dangereuses des quatre parce qu'elles paraissent propres. Il y a bien une valeur dans le champ. Elle est simplement fausse.

La plupart des crises « nos chiffres ne correspondent pas » remontent à l'une de ces quatre causes. Déterminer laquelle représente la moitié du travail.

Les nettoyages ne tiennent pas

Le réflexe, quand l'instance est un chantier, est de planifier un nettoyage. Faire venir un consultant, bloquer un trimestre, construire une feuille de calcul de fusions. Cela fonctionne exactement le temps qu'il faut pour que de la nouvelle saleté arrive, ce qui prend généralement quelques semaines. On ne peut pas stocker de la propreté. On ne peut que la restaurer sans cesse.

Le vrai travail se situe donc aux points où les données entrent et circulent entre les systèmes.

Valider à l'écriture. Rejeter ou signaler les données mauvaises dès leur création, pas des mois plus tard. Champs obligatoires, contraintes de format et listes déroulantes imposées arrêtent la plupart des cas d'incomplétude et d'incohérence dès la porte d'entrée.

Résoudre les entités à l'ingestion. À mesure que les enregistrements circulent vers la couche de données partagée, faites-les correspondre à des entités canoniques immédiatement. Faire cela une fois, de manière centralisée, est bien plus simple que de le faire dans chaque outil, et c'est l'un des arguments les plus forts en faveur d'une couche de données partagée plutôt que des intégrations point à point. Sinon, chaque outil déduplique à sa façon et vous obtenez quatre opinions différentes sur le nombre de comptes que vous avez.

Surveiller en continu. Suivez la complétude, la duplication et la fraîcheur comme des métriques permanentes avec des alertes, de la même façon que vous surveilleriez la disponibilité d'un service. Un tableau de bord qui dit « 12 % des opportunités ouvertes n'ont pas d'étape suivante » transforme un problème invisible en un problème dont quelqu'un doit répondre.

Passer d'un nettoyage périodique à un système permanent est le changement le plus utile que la plupart des équipes RevOps puissent faire, et cela tient surtout à l'endroit où vit la logique d'hygiène, pas à sa sophistication.

Assez propre pour quoi

Des données parfaites sont un fantasme, et les poursuivre est en soi un mode d'échec. La question utile est de savoir si les données sont assez propres pour la décision qu'elles alimentent. Les standards doivent dépendre du consommateur.

La prévision exécutive a besoin d'une grande précision sur un ensemble restreint de champs (étape, montant, date de clôture) et peut tolérer du désordre ailleurs.

Le routage automatisé et l'écriture en retour ont besoin de cohérence avant tout, parce que les machines n'appliquent pas de jugement. Une valeur de liste déroulante mal casée casse la règle et personne ne le remarque jusqu'à ce qu'une affaire soit routée vers le mauvais commercial. La couche d'écriture en retour est impitoyable envers l'incohérence en amont, précisément pour cette raison.

L'attribution a besoin de complétude sur les points de contact et les identifiants, car les trous déforment tout le modèle. L'épine dorsale de l'attribution en dépend entièrement.

Écrire ces seuils noir sur blanc vous empêche de livrer des analyses que les données ne peuvent pas soutenir, et de peaufiner des champs qu'aucune décision ne lit jamais.

Par où commencer

Si vous êtes face à une instance en désordre, séquencez par effet de levier.

Instrumentez avant de nettoyer. Mettez en place des métriques de complétude et de duplication en premier, afin de pouvoir mesurer les progrès et montrer à quelqu'un ce que le travail a rapporté.

Réparez l'entrée avant le retard accumulé. Empêcher la nouvelle saleté d'entrer compte plus que nettoyer l'ancienne, parce qu'un arriéré nettoyé se re-salit si l'entrée reste ouverte.

Standardisez les listes déroulantes et les champs obligatoires entre systèmes, afin que le même concept ait le même encodage partout. C'est le gain le moins cher avec le bénéfice en aval le plus large.

Et donnez-lui un propriétaire. La qualité des données sans propriétaire n'a pas d'avenir. Une personne ou une équipe nommée, responsable des métriques d'hygiène, vaut plus que n'importe quel outil que vous pourriez acheter.

Rien de tout cela n'est techniquement difficile. C'est organisationnellement difficile, parce que cela entre en concurrence avec un travail visible et excitant pour capter l'attention. Les équipes qui restent propres sont celles qui rendent l'hygiène ennuyeuse et automatique plutôt qu'héroïque et périodique.

Points clés à retenir

• Les mauvaises données se déclinent en quatre saveurs : doublons, champs vides, encodages incohérents et valeurs obsolètes. Chacune appelle une réparation différente, donc diagnostiquez avant d'agir.
• Les nettoyages trimestriels ne tiennent pas. Placez la logique d'hygiène à l'écriture et à l'ingestion, et surveillez-la comme la disponibilité d'un service.
• Résolvez les entités une fois, au niveau de la couche partagée, plutôt que de laisser chaque outil dédupliquer à sa façon.
• « Propre » dépend du consommateur. La prévision veut de la précision, l'automatisation veut de la cohérence, l'attribution veut de la complétude.
• La partie difficile est organisationnelle. Instrumentez d'abord, fermez l'entrée, standardisez, et donnez-lui un propriétaire.

Les plateformes d'orchestration comme Revnewo ne valent que ce que valent les données canoniques sur lesquelles elles tournent. Avant d'investir dans des modèles plus sophistiqués, il vaut la peine de vérifier si le socle peut les porter.