Si vous donnez un poisson à un pauvre, il mangera un jour; mais si vous lui apprenez à pêcher, il mangera tous les jours.
Lao-Tseu
Aujourd’hui je voudrais parler avec vous d’un sujet qui semble préoccuper de nombreuses sociétés – la valorisation des données grâce à l’analytique.
Pourquoi analytique ? Nous avons déjà vu que que les systèmes analytiques sont liés à de nombreux sujets, tel que la gouvernance des données, l’intégration, la data quality, le MDM et d’autres (https://ithealth.io/pourquoi-bi-a-la-main-dans-le-sac-des-projets/). Il est donc intéressant que nous pouvons prouver le ROI de nombreux efforts en utilisant un seul argument, n’est pas ?
« Mais nous avons déjà un système analytique » – diriez vous – « un précieux, cher système BI à la base de Cognos, Microstrategy, Business Objects, etc. » (soulignez/ajoutez votre option).
Je sais. Vous avez aussi un entrepôt de données et probablement une équipe BI, mais aussi une équipe de Data Scientists (peu importe comment vous les appelez).
Le problème n’est pas là. Vous ne pouvez pas valoriser les données de l’ensemble de votre société via un système de reporting géré par une seule équipe. Pour montrer la valeur de données et de vos efforts, vous allez devoir sortir de l’impasse dans laquelle vous vous êtes mis. Je vous préviens : un Data Lake à base d’Hadoop ne vous aidera pas. Commençons autrement : initialement, que veulent vraiment vos utilisateurs ?
C’est vrai, l’IT peut avoir raison. En revanche, cela va en contradiction avec le principe YAGNI (You aren’t gonna need it). Dit autrement, le besoin n’est pas toujours prouvé à long terme. Ainsi, n’essayez pas de résoudre un problème avant de l’avoir eu.
Pour l’instant, vous n’avez rien à faire de plus que copier la base pour réaliser des rapports – l’utilisateur n’en sera que plus content. Il n’a pas encore besoin d’un système plus complexe ! En fait, vous devriez pouvoir boucler le besoin d’utilisateur en 1-2 semaines. Si vous ne le faites pas, pourquoi l’utilisateur croirait un instant à vos propositions futures ?
Voici l’une des solutions :
Dans notre cas de figure, si je dois garder un seul mot pour décrire le processus, ce sera « immédiat ». On ne vous demande pas une gestion d’environnements, on ne vous demande pas non plus une disponibilité de 99,99%. On demande simplement d’avoir la possibilité. Servez votre utilisateur avec une solution simple qu’il/elle pourra manipuler sans votre aide. C’est l’étape #1.
Dans la réalité. Une société technologique utilise un outil d’analyse ad-hoc directement sur la base de suivi de production. Le métier n’a pas seulement l’accès au reporting mais il a la possibilité de créer et de modifier les analyses à tout moment.
L’erreur que vous pouvez faire maintenant c’est de bloquer l’utilisateur avec les spécifications et vos réflexions de haut niveau qu’il/elle ne comprendra pas. Laissez l’utilisateur faire et aidez-le à faire !
Que va-t-il se passer ensuite ? Les utilisateurs vont découvrir la nouvelle possibilité – analyse de données « instantanée » (s’ils n’ont pas de visibilité – vous pouvez la donner, par exemple, j’ai vu des consultants faire des analyses sans spécification ni demande juste pour démontrer la capacité de la nouvelle offre).
Maintenant c’est le moment de faire des flux… très simples. Il faut juste copier les données même s’il est vrai que techniquement le câblage peut prendre du temps. De ce fait, soit vous utilisez un système de Change Data Capture soit un ETL avec des capacités pour développer rapidement les flux de copie de données. La contrainte de cette migration sera acceptée par le métier puisque c’est le métier lui-même qui l’a demandé !
Dans la réalité. Une société – leader dans le secteur des mutuelles – propose aux métiers l’accès à des outils analytiques mais également à une base analytique segmentée, dont l’un des segments est une vision « centralisée » des données. Les autres segments peuvent être configurés par le métier suivant ses besoins.
Il ne faut pas avoir peur – votre équipe BI cherchera toujours à fournir des rapports « jolis » ou des rapports « complexes ». L’effet donné est que le métier va analyser plus et autrement. C’est l’étape #2.
Dans la réalité. Une société – leader du marché d’assurance – a donné l’accès à son outil de reporting ad-hoc à tout le personnel qui a besoin d’accomplir des analyses. Dès lors, le nombre d’utilisateurs ne cesse de croitre. Pour cela, le besoin est couvert par un cluster de plusieurs serveurs.
Que va-t-il se passer par la suite ? Bien sûr, le métier aura besoin de croiser les données cross-système, mais à ce niveau, le besoin ne sera pas le même. Vu votre performance précédente, vous pouvez expliquer que la définition de données dans un système n’est pas le même que dans un autre et que ce genre de demande nécessite une investigation plus profonde. La pédagogie devrait fonctionner. Mais, encore une fois, vous n’avez aucune obligation de sauter directement dans la solution type DWH dit « complet ».
Vos utilisateurs sont plus avancés ? Ils/elles demandent plus de fonctionnalités, le métier parle de besoin de Data Governance et Data Quality, MDM et BPM ? C’est l’étape #3. Avec une maturité des métiers issue des étapes 1 et 2, vous pouvez désormais construire sereinement le SI du futur tout en étant adoubé par vos utilisateurs.
Dans la réalité. La mise en place d’une offre de reporting ad-hoc dans un groupe international a ouvert très rapidement plusieurs besoins d’amélioration de la qualité de données.
Continuez, ne décevez pas le métier. On va vous écouter de plus en plus. N’oubliez pas de délivrer vite ce que le métier attend et surtout, laissez l’analyse entre les mains de vos utilisateurs.
Conclusions
Quelles sont les conclusions et de quoi avez-vous besoin ?
- Vous devez accepter que le reporting peut être fait par les utilisateurs « en prod ». Si non, ne livrez vous pas des documents via Share Point « en dev » puis « en recette » ? Il n’y a pas de raison valable à ce qu’un rapport ne soit pas encore considéré comme n’importe quel autre document que les utilisateurs puissent créer eux-mêmes.
- Vous devez proposer un outil facile à utiliser. Vous le savez, en plus de Microsoft Word il existe aussi LaTeX, Adobe Illustrator, etc. Dit autrement, il existe des outils « démocratiques » et des outils « professionnels ». Vos utilisateurs ont besoin d’un outil « démocratique » pour « se débrouiller ». Cela s’applique à Word, mais aussi à l’outil d’analyse de données. Ainsi, en avoir 2 outils pour des usages différentes ne pose pas de problème.
- Des spécifications pour choisir un outil d’analyse ? Je vous le déconseille. Proposez plutôt aux métiers de venir essayer 2-3 outils du marché (Tableau, Spotfire, PowerBI, faites votre liste) puis organisez les votes. Important de rappeler à cette étape que l’outil n’est pas pour vous – c’est pour les utilisateurs finaux. Posez-vous la question : est ce si grave que les Data Scientists utilisent Tableau et le métier – Spotfire ? Relativisez et ne mettez pas tout de suite des barrières.
- Si vous avez choisi un outil avec le métier et que finalement celui-ci ne convient pas – changez-le tout de suite. La majorité des vendeurs annualise le paiement donc la perte restera raisonnable.
- Débrouillez-vous pour avoir une base de données analytique qui pourra garantir la bonne performance une fois le besoin exprimé. Non, MySQL et Oracle ne sont pas les bases analytiques per se.
- Vous devez proposer le service dont vos utilisateurs ont besoin maintenant, mais faites-le avec perfection.
Bonne santé à vous et à vos données !