Accueil > Big Data, Divers > Facteurs d’échec des Projets Big Data

Facteurs d’échec des Projets Big Data

écrit par René Lefebure

27 juin

Différentes études semblent montrer que le taux d’échec des Projets Big Data est proche de 50 % (selon certaines études le taux serait même de 60 %).

Faut-il s’étonner de ce taux élevé … personnellement je ne pense pas !

Au début c’est toujours comme ça !

Au lancement des projets CRM … le taux d’échec était de 70 % … et si on regarde aujourd’hui le taux d’équipement des entreprises en CRM, on peut légitiment se dire que ce ratio plus qu’alarmiste du début ne pouvait pas être interprété comme un motif de ne pas initier de projet d’équipement CRM pour les entreprises.

Une entreprise qui n’a pas su aller vers le CRM est une entreprise probablement disparue.

Dans la même tendance pessimiste, les projets ERP furent souvent décriés, et pourtant une entreprise sans ERP … aurait des problèmes pour monter son activité E commerce et dialoguer avec ses partenaires.

Un « buzz négatif » qui peut rapporter gros

Il me semble logique que « les mauvaises nouvelles » accompagnent la phase de lancement des projets.

Ce facteur est assez simple à comprendre … plus le discours s’oriente vers la difficulté (la probabilité de se tromper est importante) et plus le besoin de conseils (et donc de prestations) se développe dans les entreprises. Si je décide de me faire accompagner je « minimise » ce facteur de risque (enfin en principe, car il n’existe pas de Hit Parade chiffré des bons conseilleurs en projets Big Data).

Donc créer du « buzz négatif » crée des opportunités de Business pour les sociétés de conseil … en choix d’outils et/ou de technologie.

Si vous avez choisi de vous lancer dans un projet « Big Data », il existe quelques risques naturels que je vais chercher à vous illustrer … à vous de savoir les éviter.

« The Magical Box »

Ce facteur résulte des attentes parfois irréalistes des « décideurs » pour ce type de projet. Le cas le plus fréquent est lié à la « boulimie des datas », où les entreprises souhaitent « rapidement » ingérer des données semi ou non structurées, pour faire apparaître des innovations potentielles.

Bref les datas et le machine learning doivent être « The Magical Box » car il y a forcément dans les 80 % des données non structurées des moyens d’améliorer les processus actuels.

Malheureusement, comme dans les autres projets, les données « non structurées » nécessitent des phases plus longues que prévues pour les analyser et identifier des patterns utiles. On constate que ce n’est pas si facile de « fouiller » dans les données et que vouloir trouver vite des facteurs qui bouleversent le business modèle … c’est pas si simple.

La promesse de « l’émergence » n’est donc pas forcément tenue.

« David contre Goliath »

Alors pour éviter ce risque du « Magical Box », on retrouve dans les études, la recommandation de se définir un « bon Business Use Case ». Il s’agit de trouver le ou les bonnes applications pour se décider sur l’opportunité du Projet Big Data.

Dans cette configuration, les risques d’échecs sont aussi importants.

La tendance est celle du « bench mark » …on choisit un « business case » totalement maîtrisé … et on attend du projet Big Data soit des « baisses substantielles » de couts (projet data warehouse ou projet pilotage) , soit des gains de performances très importants (rapidité de traitement, up lift de modélisation). Souvent le bench mark consiste à prendre une application particulièrement bien maîtrisée dans l’entreprise et d’attendre que dans ces conditions « spartiate » le challenger écrase à plate couture la solution existante.

On peut dire que c’est rare que David écrase Goliath …

 « Principes d’incertitudes » »

Mais admettons que vous avez su trouver un projet innovant qui peut se traduire par des opportunités importantes de « nouveaux business », vous entrez dans la phase de « rationalisation brumeuse », la chère « incertitude de Heisenberg ».

Lorsque que vous avez évité tous les écueils précédents, réussi votre POC avec des nouveaux éléments et mis en évidence les possibilités de business modèles additionnels, alors vous entrez dans la « phase d’incertitudes ».

Le POC peut se traduire par une liste de recommandations qui remettent en cause les pratiques existantes (intégration de flux météo, de données de trafic, d’hyper personnalisation, renégociation de contrats avec des partenaires, etc.), et devant cette nouvelle « road map » l’entreprise redevient soudainement « frileuse ».

La première option est de dire que le POC a eu de la « chance », et donc de « relancer » une seconde étude pour confirmer ?

La seconde option est de lancer une analyse d’impacts pour chiffrer les conséquences du POC sur l’existant : refonte de l’architecture technique pour accélérer les boucles de collecte, d’analyse et de distribution par exemple) ou projet de réorganisation des métiers et des processus actuels (perçus comme obsolète).

Dans les deux cas, il faut donc relancer des investissements pour continuer à avancer. On attendait du POC un succès tellement évident qu’il ne poserait pas de questions complémentaires … mais le POC finit par poser une « nouvelle liste » de questions encore plus longues et à laquelle on n’a pas forcément toutes les réponses.

Vous venez de demander l’heure à Einstein, qui vous dit que maintenant ça dépend car tout est devenu relatif.

Mais admettons que vous acceptez de vivre avec un degré d’incertitudes et que vous choisissez d’avancer …

«  Parlez-vous SPARKS ? »

La première fois que j’ai entendu Sparks, ça m’a remémoré ce groupe des années 1970 avec les frères américains Ron et Russell Mael (« This Town Ain’t Big Enough for Both of Us »), mais ça voulait surtout dire que je ne connaissais pas grand-chose aux discours du cabinet conseil.

Mais le mot « Sparks » n’est malheureusement pas le « seul » nouveau mot dans le vocabulaire apporté par le « Big Data ». L’arrivée d’un projet « Big data » vous plonge dans un nouveau vocabulaire, et donc dans un risque de ne pas savoir tirer profit des « nouvelles technologies ». Si je prends mon domaine de compétences sur le Machine Learning, il est évident que l’apparition de « nouvelles techniques » de modélisation comme le « Deep Learning avec les kernels en SVM » nécessitent de maîtriser certaines bases pour pouvoir les dominer et donc les déployer.

Le manque de compétences internes dans la maîtrise de certaines technologies empêche l’acceptation, le succès rapide et probant des projets.

Pas facile d’accepter de repartir de zéros lorsque l’on a construit une expertise certaine (en base de données, en traitement des données, en maîtrise des flux, etc..). Plutôt que de régresser « en bafouillant du Sparks », on préfère rester sur ses univers de compétences.

Alors au final avoir 40 ou 50 % des projets « Big Data » qui fonctionnent, je trouve que c’est un taux très encourageant … d’ailleurs il me semble que les entreprises les « plus cotées » aujourd’hui sont des expertes du « Big data ».

 

Pas encore de commentaire

Faire un commentaire