Le bon sens est-il soluble dans la Business Intelligence ?

Pour prendre une bonne décision, il faut disposer de données propres, précises et validées. Ok. Bien sûr. Nous sommes tous d'accord.Mais est-ce suffisant ? Il n'est peut-être pas inutile de savoir aussi lire et trier les données avant de pouvoir en extraire la substantifique moelle. Une petite pointe de bon sens ne sera pas superflue...

La mise en place de la structure de collecte des données et d'alimentation du système décisionnel est une phase essentielle du projet. Longue et coûteuse, c'est aussi la plus ingrate.
Au cours d'un projet BI un poil conséquent, l'équipe de développement achevait de bâtir une première tranche de la structure d'alimentation, fournissant des données *propres* et donc *utilisables* au système global d'aide à la décision. Le coût et la durée de l'opération, conséquents comme il se doit, suggérèrent quelques réflexions de techno-fiction.

Un développeur pensa à haute voix : *Avec des données aussi nickel, je crois de plus en plus que, finalement, un jour viendra où l'on pourra automatiser la prise de décision !*
Je ne sais pas pour vous, mais pour moi, l'association des mots « décision » et « automatiser » me titille toujours un brin l'épiderme.
Il précisa alors, afin de modérer un tant soit peu son propos : *Bon OK, je ne parle pas des décisions stratégiques, mais en tout cas pour les décisions opérationnelles, cela me semble évident. *
Sans vouloir engager une longue polémique sur le sujet, je me permis un simple bémol en ajoutant que la décision dite opérationnelle n'était pas toujours une évidence. Elle comporte toujours une part de risques qu'un système automatique ne saurait évaluer.
« Les seuls cas à risques limités sont les décisions dont la solution est déjà comprise dans l'énoncé, du type: si A faites 1 si B faites 2... Il suffit alors de lire les données pour être assuré de prendre la bonne décision. D'ailleurs dans ce cas, parler de décision est un abus de langage. De toutes façons, en entreprise, le nombre de décisions de ce type (procédurales par exemple) se réduit comme une peau de chagrin. »

Après réflexion, je me rends compte que même dans ce dernier cas, la décision n'est pas aussi évidente que cela. Il s'agit en effet d'extraire l'information décisive de la masse de données délivrées. Pas toujours si simple.

Pour vous donner une idée de la difficulté, je vous propose un retour sur les bancs de la communale avec un petit problème de train qui arrive à l'heure...
Voici l'énoncé :

Problème : Un train de marchandises, composé d'une motrice et de 14 wagons chargés, part de Marseille à 8h35 pour rejoindre la gare de Villeneuve Saint-Georges, plate-forme de triage. Il s'arrête en gare d'Aix-en-Provence durant 5 minutes pour laisser la voie libre à un express puis, il s'arrête de nouveau à Lyon Perrache durant 15 minutes pour changer de conducteur. Il roule cependant à une moyenne de 75 km/h et le trajet total dure 7h30. Une mouche modifiée génétiquement a un comportement particulièrement curieux. Elle part de Villeneuve-Saint-Georges (gare d'arrivée) à la même heure de départ que le train, soit 8 h 35. Elle vole à 200km/h de moyenne et se dirige directement vers le train. Chaque fois qu'elle rencontre le train elle retourne sans délai à son point de départ pour revenir de nouveau vers le train qui bien sûr entre temps a progressé. Elle répète son manège inlassablement jusqu'à ce que le train arrive à destination. Ses allers-retours sont de plus en plus courts et en conséquence plus fréquents. Son parcours peut être représenté graphiquement comme un signal amorti peu à peu.
Question : Quelle distance (arrondie au km) la mouche a-t-elle parcourue ?

L'information est propre, nette, précise. Pourtant la quantité de détails constitue un bruit ambiant qui perturbe le décideur. L'information essentielle lui échappe. Pas toujours si facile d'en extraire la substantifique moelle. Toute la difficulté du problème ci-dessus réside d'ailleurs dans ce bruit confus et cette multiplication de détails qui masquent l'information essentielle.
Les rapports périodiques produits par les entreprises ont aussi fortement tendance à noyer l'information sous une quantité de détails. Combien de tableaux de bord sont encore bâtis en partant du principe : « Cette donnée est-elle utile ? Bon je ne sais pas, mais je l'ajoute quand même, ça pourra toujours servir, on ne sait jamais... » ?
Bien entendu, il y a vraisemblablement une information essentielle cachée dans toutes ces données, mais comment la détecter, comment l'extraire et l'interpréter ?
Alors comment s'en sortir ? Avec un peu de bon sens. Aussi bien au moment de la composition du rapport ou du tableau de bord qu'au moment de sa lecture et de son interprétation.
C'est d'ailleurs la solution du problème ci-dessus (du niveau école primaire une fois les informations essentielles identifiées...).

Mais, pssst... Entre-nous, poussons un peu plus avant le raisonnement...
Dans quelques cas, pas si rares d'ailleurs, la bonne décision n'est-elle pas plutôt une question de bon sens que de disponibilité de l'information ?
Je me souviens ainsi d'une anecdote que l'on prête à Antoine Riboud, le père du fils.
Lors de la chute du mur, les entrepreneurs français avaient dépêché des experts dans les pays de l'ex bloc communiste afin d'identifier le potentiel de croissance et l'opportunité de s'implanter. La mutation venant tout juste de démarrer, les rapports, camemberts et autres barres-graphes étaient bien en mal d'indiquer une tendance précise. Les entrepreneurs, perplexes, jugèrent prudent d'attendre. Pourtant Antoine Riboud avait décidé d'implanter tout de même une usine. Entrepreneur de renom, que pouvait-il avoir vu dans ces chiffres plutôt plats ? Quelle information essentielle avait échappé aux autres ?
Il répondit : *Tous ces chiffres et prévisions, je ne sais pas trop. Ce que je sais, c'est que dans tous les cas, il faudra bien qu'ils mangent.*

Finalement la Business Intelligence peut-elle vivre sans le Bon Sens ?
Promis, la prochaine fois, je vous soumets un problème de robinets.

  Recommandez cet article