Mauvaise(s) synergie(s), projets au long cours, perte de sens et de motivation… Il semblerait que les équipes IT et Métiers ont du mal à s’accorder sur le concept d’innovation. Mettre en place des briques technologiques ne serait donc pas la condition sine qua none au succès des projets Big Data. Pour que ces projets conduisent les organisations sur le chemin du succès, il est temps que l’IT et les Métiers trouvent un espace de jeu afin d’expérimenter ensemble la co-construction.
Notre expert Nicolas Roux, Directeur Innovation Novencia Group, revient sur les principales raisons de l’échec de la majorité des projets Big Data. Mais aussi, sur les méthodes à mettre en place pour créer des synergies. Entretien.
Selon un analyste de Gartner, 70% des projets Hadoop échouent en raison d’un manque de compétences et d’attentes trop élevées des organisations. Donc près des 3/4 des projets big data Hadoop sont voués à l’échec ?
Il y a deux raisons majeures à l’échec des projets big data.
Lorsqu’on évoque l’échec de 3/4 des projets big data, on confond souvent ces échecs avec les mauvais retours d’expérience sur les datalake. En rassemblant les données dans une énorme base, en faisant travailler un data scientist, les entreprises ont cru mettre en œuvre des projets Big Data. Depuis 2012, le buzz autour du Big data et l’injonction à l’innovation, ont poussé les entreprises à réduire le concept d’innovation à l’installation de briques technologiques par la DSI. Jusqu’en 2015, la vision des Big Data était donc trop technophile. Une DSI pouvait monter des projets avec de gros budgets sans avoir réfléchi à la gouvernance des données. Je compare souvent cette démarche en citant l’exemple de Renault qui s’est amusée à fabriquer un Renault espace en mettant un moteur de formule 1. Résultat, la firme au losange disposait d’un véhicule ultra performant dont la réalité économique s’est limitée au buzz. On est dans la même configuration pour le big data. En interne, les DSI ont mis en place des technologies trop complexes et les Métiers ont été incapables de les exploiter. C’est de cette décorrélation qu’est né ce premier constat d’échec.
Le deuxième échec concerne la démarche innovation.
Traditionnellement comment était-elle abordée ? Une entreprise lambda se disait experte sur le marché d’un type de produits. Elle investissait en R&D (Recherche et développement) et du coup, naturellement, elle avait le rôle de créateur d’innovation. Aujourd’hui, la tendance c’est de dire j’ai compris que mon produit n’est qu’une brique et je dois faire en sorte qu’il corresponde à des usages. La tendance est donc au « customer centric » qui prend en compte les besoins clients dès le départ du projet.
En ce sens, dans l’innovation digitale, on construit un produit vivant. Tous les 6 mois, tous les mois, voire tous les jours dans certains cas. Le produit doit être amélioré, doit offrir de nouvelles fonctionnalités. Le dialogue de sourds entre IT et métiers résulte du manque de démarche et de méthodologie générales qui doit être véhiculée par une approche innovation.
L’innovation, ça marche comment ?
« La première étape est d’essayer de détecter de nouveaux cas d’usage pour créer de nouveaux services. Une fois les usages détectés, on crée un écosystème. C’est-à-dire, un terreau capable de faire émerger des pistes ou des idées pour répondre aux enjeux client. Au sein de cet écosystème, on retrouve des collaborateurs Métiers interne mais aussi des prestataires externes. Mais aussi, une méthodologie, une démarche agile et de l’UX Design. En travaillant l’expérience utilisateur, on crée un MVP (minimum viable product) en un minimum de temps pour qu’on puisse le tester rapidement. Ce n’est qu’au cas où certains services fonctionnent que j’itère ! En somme, dans la conception d’un nouveau produit, dans une démarche d’innovation tout le monde doit comprendre que le produit est un être vivant »
Comment identifie t-on un dialogue de sourds ?
Comment on identifie rapidement un dialogue de sourd ? Dès qu’on arrive chez un client et qu’on s’aperçoit, d’une part que, la DSI a investi des sommes énormes sur son SI pour pouvoir mettre en place des briques technos type big data. Et d’autre part, que les Métiers ne comprennent pas la valeur ajoutée et le temps perdu à monter un tel projet. C’est une situation coutumière des grands groupes. On la retrouve plus rarement au sein des nouvelles directions digitales.
Autre cas de figure. Un produit a été fabriqué dans une démarche d’innovation. Sauf que le bât blesse quand la DSI s’aperçoit qu’elle n’a pas été consultée et qu’elle met son veto au moment d’industrialiser. En effet, elle estime que le produit ne correspond en rien à l’architecture cible, ni aux contraintes sécuritaires. Donc, on se retrouve avec un produit construit qui ne correspond à aucune règles internes du SI.
Comment amorcer le dialogue ?
En somme, il manque un espace de jeu entre la DSI et le Métier pour qu’ils expérimentent ensemble. Les DSI traditionnelles doivent comprendre qu’elles ne prennent pas de risques si elles apprennent à fonctionner autrement. A contrario, au sein des start-ups industrialisées comme Vente Privée par exemple, ces problématiques n’existent pas. En effet, elles ont une vraie culture du digital et de l’innovation. Elles se sont développées sur ce modèle de co-construction dès le départ.
Réussir un projet Big data c’est donc une question de mentalités ?
Au niveau des organisations, certains de nos clients sont dans une dynamique transverse et agile, et ont donc atteint un bon niveau de maturité par rapport à ces problématiques. A contrario, certains de nos clients n’ont pas d’approche disprutive par rapport à leur marché.
Concernant l’IT, il faut prendre en compte qu’à l’origine, la DSI est le garant d’un SI fiable. C’est-à-dire, sécuritaire, qui doit offrir un SLA (Service Level Agreement) de plus de 99%, et assurer la maintenance en cas de panne. Son rôle est de faire des choix techniques. Et ainsi, garantir la gestion d’un ensemble d’applicatifs qui va permettre à la société de fonctionner au quotidien. Sauf que, c’est antinomique avec les approches d’innovation car, dans une démarche d’innovation on utilise des technologies très récentes et non usitées. Ainsi, il est fréquent qu’un DSI refuse de mettre en en place certaines technologies car les éditeurs sont inconnus.
Enfin, coté Métiers, ils s’épuisent et se découragent car chaque projet fait l’objet d’un développement long qui s’étale de 6 mois à un an. Or, dans une démarche d’innovation, un cycle de test ne doit pas dépasser les 4 mois. Au delà, le terme d’innovation est galvaudé.
Donc oui, changer les mentalités, vivre avec son temps, prendre des risques sur de nouvelles technologies, tester, industrialiser tout en préservant la sécurité du système informatique permettrait de mener au succès un projet Big data.
L’Innovation n’est donc pas qu’une question de temps ?
Quand on veut innover, on prend en considération plusieurs facteurs. L’organisation des équipes, les méthodologies et les outils à mettre en œuvre . Quand on veut que ça fonctionne bien on se monte une « feature team » c’est à dire une équipe pluridisciplinaire, de taille réduite, qui va travailler sous un mode collaboratif.
Dans ces équipes, on retrouve des développeurs ultra expérimentés. Ces artisans du code sont appelés des craftsmans. Ils sont capables de mener un projet de A à Z tout en appliquant de très bonnes pratiques. L’applicatif peut ensuite évoluer facilement grâce à des test produit tous les 4 mois. Aujourd’hui, on n’a plus besoin d’une équipe de 20 personnes pour réaliser un produit car les craftsmans savent utiliser les bons outils comme la livraison continue par exemple. Grâce à cette méthodologie, on peut réduire les coûts et envisager l’industrialisation au fur et à mesure des succès rencontrés.
La data est-elle la passerelle pour améliorer le dialogue ?
Aujourd’hui la data est un moteur de l’innovation. A partir de son exploitation, on va pouvoir répondre aux problématiques d’un client et de ses usages. L’enjeu, c’est réussir de mettre dans la même pièce IT et Métier pour qu’il discute ensemble d’une bonne exploitation de cette data.
Auparavant, on faisait le choix d’une base de données qui devait répondre à 90% des cas d’usages. Aujourd’hui, tout est différent car avec des feature team, on peut gérer 10 projets différents avec 10 équipes différentes. Si ça se trouve dans ces 10 projets, il y aura des briques technos communes à l’ensemble des 10 projets et des briques spécifiques communes à seulement 2 projets. Le dialogue est donc extrêmement important car si tout le monde travaille sur le customer centric la matière première c’est la data. C’est donc le point commun entre l’IT et les Métiers.
Dans des entreprises comme Facebook, on innove par le code, le Métier a une idée, l’IT développe un bout de code.
Doit-on former les collaborateurs ?
Les collaborateurs doivent être formés et coachés sur les méthodologies et les outils. Aujourd’hui, on parle beaucoup de coach agile car les entreprises ont besoin de personnes qui sont à la pointe des nouvelles technologies. La veille technologique et sectorielle doit être très forte. Il est nécessaire que le niveau d’acculturation des collaborateurs soit forte. En somme, les collaborateurs doivent être formés sur comment on passe de l’idée à l’applicatif.
Quels sont les avantages que les équipes IT & Métiers peuvent tirer d’une co-construction ?
L’enjeu encore une fois c’est les feature team. Mais un autre enjeu c’est aussi de décloisonner les équipes et d’impliquer les IT sur la conception de produit. Une équipe pluridisciplinaire est selon moi, un facteur de succès.
Concrètement, un projet big data est souvent lié à un projet innovation. C’est pourquoi j’ai insisté sur le concept d’innovation. Le but ultime, c’est l’expérience utilisateur. C’est comment faire que son organisation soit plus performante, que les collaborateurs soient impliqués. Mais également, comment faire en sorte que les technologies facilitent le quotidien des collaborateurs sans passer nécessairement par de la formation au logiciel. Aujourd’hui, il faut inverser ce qu’on connait dans l’entreprise. Il faut concevoir des logiciels qui collent aux besoins en interne. C’est-à-dire, des nouveaux produits qui correspondent aux utilisateurs et non l’inverse.
Pour encourager le dialogue peut-on évoquer le facteur de réduction de coût ?
L’enjeu pour moi n’est pas là. L’enjeu est d’être disruptif et de véritablement se transformer digitalement.
Chez novencia, quelle est votre approche ?
Notre approche c’est de proposer une start-up interne. On n’est pas là pour tout transformer, on est là pour montrer l’exemple. En faisant de l’évangélisation par l’exemple, on co-construit avec le client. Notre objectif est de partir d’un use case. A partir de là, on explique au client comment aller, comment communiquer autour du projet et obtenir l’adhésion de l’ensemble des collaborateurs. Mais y compris ceux qui ne font pas partie du projet. On crée de la curiosité dans l’entreprise. Et on emporte avec nous toutes les équipes qui attendent du coup, les améliorations.
Novencia vous accompagne !
