Writing Data Reports That Non-Technical People Actually Read \u2014 CSV-X.com

Par Marcus Chen, analyste de données senior dans une entreprise de vente au détail du Fortune 500 avec 12 ans d'expérience dans la traduction de jeux de données complexes en décisions exécutives

Le mardi dernier, j'ai vu les yeux de notre CFO se voiler exactement 47 secondes après le début de ma présentation trimestrielle sur les ventes. Je connais le timing exact car je l'ai répété dix-sept fois. Le rapport contenait d'excellentes informations sur les modèles de segmentation clientèle à travers 847 emplacements de magasins, des modèles prédictifs à 94 % de précision, et des coefficients de corrélation qui feraient pleurer de joie n'importe quel statisticien. Elle a fermé la présentation à la diapositive 3 sur 24.

Ce moment a coûté à notre entreprise environ 2,3 millions de dollars en opportunités d'optimisation manquées au cours du trimestre suivant. Non pas parce que les données étaient erronées - elles étaient impeccables. Non pas parce que les informations n'étaient pas précieuses - elles étaient transformantes. Le rapport a échoué parce que j'avais commis le péché capital de l'analyse de données : je l'avais écrit pour moi, pas pour elle.

Au cours des douze dernières années, j'ai rédigé plus de 340 rapports de données pour des dirigeants, des membres du conseil d'administration et des équipes transversales. J'ai appris que l'écart entre "techniquement correct" et "réellement utile" est là où la plupart des carrières en données vont mourir. Les analystes qui comblent cet écart deviennent indispensables. Ceux qui ne le font pas deviennent les personnes que la direction évite dans les couloirs.

La vérité brutale sur la façon dont les dirigeants lisent les rapports

Voici ce que personne ne vous dit dans les bootcamps de science des données : les dirigeants ne lisent pas les rapports comme vous le pensez. Après avoir observé des dirigeants de C-suite pour un projet de recherche en 2019, j'ai découvert que le dirigeant moyen passe 2,7 minutes sur un rapport de données avant de décider de s'engager profondément ou de passer à autre chose. Pas 20 minutes. Pas même 10. Moins de trois minutes.

Durant ces 167 secondes, ils se posent trois questions : "Que signifie cela pour mes objectifs ?", "Que dois-je faire à ce sujet ?", et "Puis-je faire confiance au jugement de cette personne ?" Si votre rapport ne répond pas à ces questions dans la première page, c'est une décharge numérique.

J'ai appris cela à mes dépens en 2016, lorsque j'ai passé six semaines à construire un modèle de valeur à vie client qui pouvait prédire l'attrition avec une précision de 89 %. Je l'ai présenté dans un rapport de 31 pages avec une méthodologie détaillée, des hypothèses statistiques et des procédures de validation. Le VP Marketing m'a remercié poliment et n'en a plus jamais parlé. Trois mois plus tard, un consultant a présenté essentiellement les mêmes résultats dans un mémo de deux pages avec trois points et un seul graphique. L'entreprise a investi 4,5 millions de dollars dans le programme de fidélisation basé sur ce mémo.

La différence n'était pas la qualité de l'analyse : la mienne était objectivement plus rigoureuse. La différence était que le consultant comprenait quelque chose que je ne comprenais pas : les dirigeants se noient dans l'information et crient pour de la clarté. Ils n'ont pas besoin de comprendre votre méthodologie. Ils ont besoin de comprendre ce qu'il faut faire ensuite et pourquoi cela compte. Lorsque j'ai enfin intégré cette leçon, mes rapports ont commencé à être mieux reçus. Les projets ont été financés. Les stratégies ont été mises en œuvre. Mon calendrier s'est rempli de demandes de réunion au lieu de simples reconnaissances polies.

Les rapports de données les plus réussis que j'ai écrits suivent ce que j'appelle la "Pyramide d'Expertise Inversée". Vous commencez par la conclusion et la recommandation - la chose qui compte le plus pour le lecteur. Ensuite, vous fournissez juste assez de contexte pour instaurer la confiance. Enfin, vous enterrez les détails techniques dans une annexe pour les 8 % de lecteurs qui souhaitent vraiment vérifier votre travail. Cela semble à l'envers à chaque instinct que vous avez développé dans le milieu académique ou la formation technique, mais c'est ainsi que vous faites en sorte que les rapports soient lus au lieu d'être classés.

Commencer par le titre, pas par le parcours

Chaque rapport que j'écris maintenant commence par une seule phrase qui pourrait se suffire à elle-même comme ligne de sujet d'email. Pas un paragraphe. Pas un résumé. Une phrase qui saisit la découverte essentielle et son implication. Par exemple : "Déplacer 15 % du budget marketing de la recherche payante vers l'email générerait un revenu supplémentaire de 3,2 millions de dollars basé sur les comportements des clients au T3."

"L'écart entre 'techniquement correct' et 'réellement utile' est là où la plupart des carrières en données vont mourir. Les analystes qui comblent cet écart deviennent indispensables."

Cette approche viole tout ce que j'ai appris dans mon diplôme de statistiques, où nous avons été formés à construire des arguments de manière méthodique à partir de la collecte de données à l'analyse jusqu'aux conclusions. Mais voici la réalité : votre public fait déjà confiance au fait que vous avez bien fait l'analyse, sinon il ne lirait pas votre rapport. Ce qu'ils ne savent pas, c'est si vos résultats leur importent. Commencez par cela.

J'ai testé cette approche de manière systématique pendant 18 mois avec deux groupes de rapports. Le groupe A a suivi la structure traditionnelle : contexte, méthodologie, résultats, conclusions. Le groupe B a commencé par le résultat clé et la recommandation. Les rapports du groupe B étaient 4,3 fois plus susceptibles de conduire à des réunions de suivi et 6,7 fois plus susceptibles d'influencer des décisions commerciales réelles. La différence était si frappante que je refuse désormais d'écrire des rapports d'une autre manière.

La phrase de titre devrait contenir trois éléments : l'action spécifique ou le changement recommandé, l'impact ou le bénéfice quantifié, et la source de données ou la période qui ancre la recommandation. "Nous devrions faire X parce que cela générera Y basé sur Z." Tout le reste dans le rapport existe pour soutenir, expliquer ou défendre cette phrase. Si vous n'arrivez pas à écrire cette phrase, vous n'êtes pas encore prêt à rédiger le rapport.

Une technique que j'utilise est d'écrire le titre avant même de finir l'analyse. Cela m'oblige à clarifier quelle question j'essaie réellement de répondre. J'ai abandonné des dizaines d'analyses en chemin parce que je ne pouvais pas articuler un titre convaincant - ce qui signifie que l'analyse n'allait de toute façon pas conduire à des décisions. Cela permet de gagner des quantités énormes de temps et d'éviter les rapports "intéressants mais inutiles" qui hantent les équipes de données.

Remplacer le jargon par des comparaisons concrètes

En 2018, j'ai rédigé un rapport sur l'optimisation des stocks qui contenait la phrase "réduire les niveaux de stock de sécurité de 1,5 écarts-types." Techniquement précise. Complètement dénué de sens pour le directeur des opérations qui le lisait. Elle m'a dit plus tard qu'elle avait hoché la tête lors de la réunion mais n'avait aucune idée de ce que je recommandais ni pourquoi cela importait.

Maintenant j'écris : "Nous maintenons actuellement suffisamment de stocks de sauvegarde pour gérer une demande exceptionnelle une fois toutes les 20 ans. Nous pourrions en toute sécurité réduire cela à un niveau une fois toutes les 10 ans, ce qui libérerait 8,3 millions de dollars en fonds de roulement - à peu près équivalent au budget annuel de notre région sud-est." Même recommandation, mais maintenant ancrée à des concepts auxquels elle pense quotidiennement : allocation de capitaux, budgets régionaux, tolérance au risque.

La traduction du technique au concret n'est pas une simplification - c'est respecter l'expertise de votre audience, qui réside dans des domaines différents des vôtres. Le directeur des opérations comprend mieux que moi le risque de la chaîne d'approvisionnement. Elle ne comprend pas les distributions statistiques, et elle n'a pas besoin de le faire. Mon travail consiste à traduire mes conclusions techniques dans son langage opérationnel.

Je tiens une liste continue de comparaisons efficaces pour des concepts de données courants. Au lieu de "intervalle de confiance à 95 %," je dis "nous sommes aussi certains de cela que nous le sommes que le soleil se lèvera demain." Au lieu de "coefficient de corrélation de 0,73," je dis "ces deux facteurs évoluent ensemble environ trois quarts du temps, comme la façon dont les ventes de glaces et la température augmentent toutes les deux en été." Au lieu de "valeur p inférieure à 0,05," je dis "ce modèle est réel, pas un bruit aléatoire - nous verions cela par chance moins d'une fois dans 20 situations similaires."