Notre métier
Slow Business Intelligence, alias Décisionnel Raisonné
Slow Business Intelligence!
A la manière de la « slow food » ou bien du « slow management« , voici que Steve Bennett (voir son blog et son twitter) lance le concept « slow » appliqué au décisionnel : Slow BI.
Slow BI, ça veut dire faire du décisionnel intelligemment, posément. Le faire bien.
Plus qu’un terme marketing, qu’un billet d’humeur, c’est une méthode et une vision de travail qui nous est proposée.
Slow BI, on pourrait traduire cela en « Décisionnel Raisonné« , même si le terme est loin d’être parfaitement adéquat.
Mais alors, qu’est ce que ça veut dire ?
Dans cet article, je vais reprendre l’argumentation de Steve Bennett en l’agrémentant de mes avis, commentaires et points de vue.
Le logo Slow Food
Steve Bennett nous raconte l’histoire de John Franklin qui, dans une bataille navale, a su tuer son ennemi en ne cédant pas à la panique ni à l’action frénétique mais en restant calme, posé, en ne paniquant pas. (Récit tiré du livre « The Discovery of Slowness« ).
Pour prendre la bonne décision, effectuer la bonne action, il a pris le temps de rassembler les éléments, de les étudier, de voir leur tendance puis, et seulement après réflexion, il a agit.
On retrouve là un comportement décisionnel sain, non ?
Cela peut prêter à rire, mais c’est avec cette anecdote que Bennett commence par répudier les comportements temps-réel que de nombreux destinataires des tableaux de bord que nous réalisons en décisionnel croient être le Graal.
Attention, il faut faire ici une précision importante : lorsque nous parlons de temps réel, nous parlons bien de vouloir mettre à jour des indicateurs dans des délais très courts, très rapprochés. Ce n’est pas la même chose que le décisionnel opérationnel !
La notion de temps réel est un peu fourre-tout, celle d’opérationnel est une vraie branche du décisionnel, dont la direction des métiers opérationnel a la charge.
Afin de préciser son argumentaire, Steve Bennett cite les trois types de latences listées par Richard Hackathorn :
- La latence de données : c’est le temps nécessaire à la récupération, au traitement et stockage des données (en gros, l’ETL)
- La latence d’analyse : le temps pris pour comprendre et analyser les données avec de pouvoir les utiliser comme sources d’actions
- La latence d’action : c’est le temps utilisé pour pour réagir à l’information reçue et prendre des actions
Pour la latence de données, il s’agit surtout d’un problème technique (puissance de l’ETL, optimisation des flux, …). Concernant la latence d’action, c’est surtout coté entreprise que cela ce joue (processus internes, …).
Concentrons nous donc sur la latence d’analyse.
Tout l’objectif d’un processus décisionnel est de faire une analyse correcte, avec les bonnes données. Mais alors, le temps réel ne va pas servir à grand chose ? Plus d’informations, plus vite, ce n’est pas forcément utile !
Steve Bennett nous rappelle que l’important, c’est le contexte. Pour prendre des décisions, il faut savoir les replacer dans l’ambiance, l’environnement. Et avec trop de données trop vite, il devient fastidieux voir impossible de prendre ce recul. Ou bien il va falloir l’expliquer au décideur, à chaque fois (et il y aurait là perte de temps).
Durant ma formation, j’ai appris qu’une des choses importante en décisionnel était la confiance dans les chiffres. Le décideur doit savoir à quoi il a affaire. Et cette confiance prend du temps à se construire !
Or, avec des chiffres trop volatiles, le décideur peut croire de « mauvais » faits ou bien perdre cette confiance (phénomène du « Non mais c’est n’importe quoi, ça change tout le temps ! » : le décideur abandonne ou, de lui même, ne regarde que moins régulièrement).
Bref, il faut lisser et prendre le temps, sans quoi de mauvaises décisions, sans recul ni données pertinentes, seront prises.
Il faut réfléchir...
On le voit bien, la course au « temps réel » (différent de l’opérationnel, je le reprécise), n’est pas forcément la voie à suivre ou doit tout au moins être menée avec prudence.
Récapitulons donc ce qu’est le « slow BI » :
- Délivrer des chiffres bruts peut faire des dégâts et mener à de mauvaises décisions
- Il faut prendre le temps de lisser les chiffres et prendre en compte le contexte
- Il ne faut surtout pas négliger l’analyse de l’usage à venir des chiffres par les décideurs
- Améliorer la qualité d’analyse doit être l’objectif : à ce niveau, plus de données plus vite ne peut qu’induire en erreur
Finalement, le Décisionnel Raisonné, le Slow BI, c’est de prendre le temps d’analyser le Business, sous tous les angles et en toutes circonstances !
Steve Bennett pense d’ailleurs que c’est n’est qu’ainsi que seront posées les bases pour faire proprement du « Fast BI« .
Un concept attirant et parlant… mais pas évident à vendre !
Que pensez vous de ce concept ?
Personnellement, je me sens plutôt en accord avec tout cela : c’est finalement un « nom » sur une méthode de travail (qui est parfois mise à mal actuellement)
Cependant, cette vision n’est pas forcément évidente à « vendre ». Il faut bien comprendre que « slow » ne veux pas dire en faire moins, ou plus lentement. Ce n’est pas pour bosser moins : c’est pour faire mieux et ne pas faire inutile.
C’est faire du décisionnel, du vrai.
Il faut donc bien se faire comprendre de ses interlocuteurs.
Mais il me semble que c’est un concept « porteur » : des gens calmes, posés et sûrs d’eux ont tendances à « vendre plus » et inspirent confiance. Ils sont en général plus écoutés et plus suivis à long terme.
C’est aussi un message de qualité qui sera forcément reconnu à terme.
Je ne vois donc que des avantages à cette dénomination !
Et vous ?
MAJ 31/08/2009 : Steve Bennet, sur son blog, propose une méthodologie, nommée BIG, pour atteindre en pratique les objectifs proposés dans la notion de Slow BI.
Tags: Discussion
13 commentaires pour “Slow Business Intelligence, alias Décisionnel Raisonné”
Poster un commentaire
Il est clair qu’à l’heure où on veut toujours aller plus vite au lieu de bien prendre le temps de réfléchir, on passe plus de temps et d’efforts à réparer les dégâts d’une politique de course en avant tête baissée qu’à véritablement avancer…
Bien vu Thomas!
Fanny t’en parlera également mais c’est également le cas en web analytics où tous les éditeurs te vantent le mérite du « temps réel » alors que:
1- les données arrivent par vague et ont donc besoin d’une synchro/réconciliation/déduplication
2- de plus en plus, les données WA sont croisées avec des sources externes/complémentaires qui doivent – elles aussi – être mises à plat avant d’être assimilées.
3- la nature « vivante » du Web rend l’exercice plus compliquée en WA puisque quand bien même on analyserait/identifierait une opportunité d’optimisation, le temps de faire un changement ferait louper une fenêtre de tir. On comparerait alors des oranges et des mandarines. Même couleur et même forme, mais pas la même taille ni la même saveur… d’où l’intérêt de TESTER avant la mise en production 😉
Amicalement,
Julien Coquet
Association Web Analytics France
En effet, comme le précise Julien le web est un univers en constante évolution ce qui fait que si à un instant T les résultats sont très positifs, ce ne sera pas forcément le cas à l’instant T+ 20 minutes.
si vous prennez le site de la RATP par exemple celui-ci enregistre des pics essentiellement lorsqu’il y a des problèmes sur les lignes les plus fréquentées ce qui fausses totalement le traffic lorsque vous regarder celui-ci à la minute près.
Ce qu’il faut dans ces cas-là c’est regarder et suivre la tendance générale, sur une période assez large.
Si le décideur ne fait que regarder le nombre de visiteurs uniques toutes les 5 minutes (en utilisant cette fameuse touche F5) et prend la décision de virer ou non son web master en fonction du résultat, alors il n’a pas compris qu’un plan de taggage prend 1 mois à mettre en place, 15 jours pour voir des résultats intéressants…
Mais cela se retrouve aussi dans le domaine des ventes (c’est le cas notamment en ce moment avec les soldes) où les grands magasins étudient les achats des visiteurs et font des promotions en live en direct. Qui n’a jamais entendu le monsieur de chez Leclerc pour ne pas le citer vous dire « qu’en ce moment et ce pour encore seulement 30 minutes le jambon blanc était en promo à -40% » ?
Cela est de l’incitation à l’achat en direct.
Pour moi le temps réel n’a qu’un seul intérêt : la gestion des stocks. Car la c’est indispensable pour savoir ce que vous pouvez vendre et à quel prix (en fonction notamment de ce que vous coûte votre stocke, de vos prochain réapprovisionnement…).
Les décideurs qui en dehors de ce domaine vous réclame du temps réel sont sûrement des décideurs qui ont peur de manquer d’information, de ne pas savoir interprêter l’information, ou pire d’avoir l’information trop tard.
Mais à ce moment là c’est aux éditeurs de logiciels, aux consultants et aux chefs de projets décisionnels de se remettre en cause car une étape du projet n’a pas fonctionnée : l’accompagnement client, l’implication du client dans le projet, le choix de l’outil, le choix des indicateurs…
Merci à tous pour vos commentaires !
@François : Effectivement ! Et c’est souvent nous, les consultants/intégrateurs, qui passons un temps fou pour réparer tout cela. Plutôt énervant et souvent peu stimulant… Il faut vraiment expliquer l’intérêt d’une démarche « slow » au décideurs et leur montrer que prendre un peu plus de temps au début va surtout leur permettre d’en gagner après !
@Julien : Merci pour ce lien avec le WebA ! En effet, c’est technique du « slow » peut s’appliquer à de très très nombreux domaines : tous ceux qui nécessitent un processus d’analyse à un moment ou un autre (encore plus dans nos métiers de gestion/traitement/analyse de données car la latence d’analyse est au milieu du processus global !).
@Fanny : Les exemples sont très parlants. Le mode « reporting-F5 » est en effet souvent recherché alors même qu’il n’a que très peu d’intérêt ! Excepté, comme tu le précises, dans la gestion de stocks : mais on est alors dans une démarche de décisionnel « opérationnel », qui nécessite plutôt des processus figés que des phases d’analyses complexes. Pas faux également concernant la responsabilité « a posteriori » des CdP, consultants & Co, mais je pense surtout que la responsabilité est « a priori », c’est à dire en amont du projet, au moment de la vente, de la définition du périmètre et des spécifications fonctionnelles. Avant de « vendre » un projet au client, il faut que toutes les parties soient conscientes de sa portée et de ses limites : dire « après » que le temps réel est inutile, ne sera pas utilisé correctement et/ou que l’analyse du business n’a pas été suffisante dessert tout le monde, il faut le dire/prévenir « avant ». Cela à un coût que le client doit être prêt à supporter et il doit être conscient et responsable des limites s’il ne choisit pas cette voie.
@Tous : La technique « Slow BI » ou décisionnel raisonné semble donc s’appliquer à bien des métiers : au moins à ceux ayant une part importante d’analyse. Dès que cette part est non négligeable (différent de l’opérationnel), la méthode « slow » doit être mise en avant par les consultants/intégrateurs. Reste à faire comprendre son intérêt (à moyen-long terme) aux clients !
En fait l’ article soulève un point important que l’on oublie souvent : quelles sont les actions qui pourront être prises grâce aux données fournies par la BI ? Une fois la réponse à cette question obtenue on peut alors définir la fréquence de rafraichissement de l’information. Inutile d’afficher les ventes France d’une chaine de magasin raffrachies toutes les minutes si dans le meilleure des cas, la moindre action correctrice ne pourra pas être prise en moins d’une semaine de délai.
En fait, la slow BI, c’est juste la bonne BI, c’est juste bien faire un projet BI en se posant (et surtout en posant aux utilisateurs) les bonnes questions.
Je rejoins complètement l’analyse d’Alexis : il faut prendre le temps d’identifier et de comprendre les besoins avant de se lancer dans la réalisation technique. Elémentaire !
J’ai pourtant l’impression que bien souvent les responsables informatique cherchent à anticiper (à tord ou à raison?) les besoins sans prendre le temps de consulter les utilisateurs, ci bien que le décisionnel se transforme en fourre-tout!
On parle donc de temps réel : c’est vrai que c’est beau, que le défit technique proposé est intéressant, etc. Mais il est clair que le temps réel n’intéresse pas toutes les directions fonctionnelles de l’entreprise.
Au bout du compte le décisionnel perd de sa crédibilité puisque comme le décrit François, on passe son temps à rafistoler l’existant développé dans la précipitation.
Petit ajout : Steve Bennet, sur son blog, commence une série de posts proposant une méthodologie, nommée BIG, pour atteindre en pratique les objectifs proposés dans la notion de Slow BI.
C’est ici.
De nouveau un article en relation avec le concept de Slow BI : http://analytics.typepad.com/oz-analytics/2011/06/big-business-intelligence.html
Je suis globalement en accord avec l’article : en gros il faut réfléchir pour faire de l’analyse de données. Ca parait le minimum.
Concernant le temps réel, en dehors du terme marketing, et de BI opérationnelle, je pense que cela peut avoir un avantage pour fluidifier des chargements de données en travaillant en continu plutôt qu’en plage batch. Mais c’est purement technique, pas pour des problèmatiques d’analyse. Et il y a des contraintes à prendre en compte, comme la cohérence des données, en particulier lorsqu’il y a plusieurs sources de données à utiliser. Il faut respecter la consistance globale de ce qu’on manipule.
@Seb :
Merci pour ce commentaire. Comme le disait Alexis dans un commentaire précédent : « la slow BI, c’est juste la bonne BI, c’est juste bien faire un projet BI en se posant (et surtout en posant aux utilisateurs) les bonnes questions ». C’est en effet le minimum 🙂
Pour le temps réel, il peut quand même avoir des intérêts opérationnels voir d’analyses : prendre une décision rapide sur le trajet d’un camion, décider de charges serveurs, .. les possibilités sont nombreuses. L’intérêt technique évoqué est juste aussi, je n’y avais pas pensé. Merci.
Le point de la cohérence des données est en effet capital : il faut s’assurer que toutes les sources sont aux même niveaux de traitement. Mais dans le cas d’un temps réel ou de BI opérationnelle, on peut justement accepter plusieurs biais : soit d’avoir moins de données (peu de sources) soit accepter une certaines marge d’erreur. L’essentiel est que l’utilisateur en soit averti !
On retrouve dans l’article les points clé de n’importe quel job, la confiance dans les infos, la compréhension partagée des données… Et j’en passe.
Depuis 2 mois je suis sur des projets BI en « trash Dev ». Et on se fait pourrir pour des retard.
Donc ça fait du bien de relire de temps en temps ce billet.
Histoire de se rappeler que je ne suis pas forcement lent, pas organisé ou pas compétent.
@SylvainD :
Merci pour ces remarques.
Le projet parfait n’existe pas mais il est important de sensibiliser le client et toute l’équipe à l’importance des bonnes pratiques, leur montrer que c’est l’intérêt de tous.
Bon courage pour vos projets « trash dev » 🙂
Un concept intéressant mais pas très évident à commercialisé en effet.