Il y a une journée mondiale de la protection des données et c’est aujourd’hui, lundi 28 janvier 2019.
C’est le Conseil de l’Europe qui a, le premier et dès 2007, proclamé une journée européenne de la protection des données à caractère personnel.
Dernièrement, et au-delà de GDPR (oui je fais le pari qu’il n’y a plus besoin de dire ce que c’est), l’actualité nous a montré à quel point les données personnelles étaient un enjeu énorme et qu’il y avait encore une longue route à parcourir. La liste des « évènements » liés aux données personnelles ne cesse de s’allonger : Amende Google, Facebook et Cambridge Analytica, vol des données d’élus Allemands, piratage « Collection #1 »… et ce ne sont que les plus emblématiques (il y en a de multiples rien qu’avec Facebook).
Au-delà du fait de mettre en place des responsabilités, des procédures et des outils pour se conformer à GDPR, il me semble important de mettre en avant quelques éléments-clés :
La finalité de GDPR c’est de protéger les individus : oui, il ne s’agit pas juste de protéger des données et de mettre en place des procédures,
GDPR ne peut être vue comme une simple approche de protection et de sécurité : le cycle de vie des données personnelles concerne quasiment tous les acteurs des organisations,
On parle beaucoup des « clients » lorsqu’il s’agit de GDPR : n’oublions pas que les « collaborateurs » d’une organisation sont également à traiter avec, a minima, la même sensibilité,
C’est la « finalité » des traitements sur les données personnelles qui permet de justifier ces traitements : cela milite pour une approche orientée « usages » pour avoir la bonne maille d’étude.
Dès lors, c’est au sein de la culture même de chaque organisation qu’il faut intégrer la protection des données personnelles et, plus largement, la valeur des données. D’un côté, nous avons la culture d’une organisation qui peut se caractériser par ses valeurs partagées, ses croyances et convictions, ses pratiques, ses comportements. De l’autre, nous avons une Culture Data qu’il devient de plus en plus nécessaire de partager le plus largement possible.
Il faut donc diffuser une Culture Data à tous les étages des organisations : C’est cela qui va permettre de prendre la mesure, à l’échelle de l’organisation, de la protection des données personnelles mais aussi de la valeur des données (qualité, disponibilité…). Mais il faut faire cela en s’insérant dans la culture en place, pour venir l’étendre et l’enrichir, et pour s’assurer que cela est fait de façon durable. En effet, penser qu’il suffirait de mettre en place un plan « Culture Data pour tous » générique et sans personnalisation est probablement voué à l’échec.
Et comme il ne faut pas rester sur un « échec », espérons que cette journée de protection des données personnelles permettra de faire avancer la Culture Data à tous les étages de la société.
Data scientist, data analyst, data cruncher,… ces dernières années, le nombre d’intitulés de postes relatifs au traitement, et plus particulièrement à l’analyse, de données a explosé. On constate également la popularité croissante des compétences inhérentes à ces postes via divers tops ‘in-demand skills’, publiés annuellement sur LinkedIn. Ces postes ont tous une compétence requise en commun, l’analyse de données, aujourd’hui jugée primordiale dans le monde professionnel par le cabinet Gartner, jusqu’à l’élever au rang de norme.
Mais ne sommes-nous pas déjà entrés dans une nouvelle époque, durant laquelle les composantes basiques de ces compétences vont peu à peu migrer dans le ‘savoir commun’ et devenir des pré-requis pour un scope plus large de métiers ? Ne sommes-nous pas entrés dans l’ère de la ‘data democratization’ ?
Pourquoi une explosion de de la demande relative à ces compétences ?
A l’heure où plus de la moitié de l’Humanité a quotidiennement accès à Internet et où 90% des données disponibles ont été créées dans les deux dernières années, toute entreprise collecte et stocke une quantité importante de ces données. De formats et types variés, ces dernières sont également transversalement issues de la totalité des métiers de l’organisation. Les capacités de traitement (stockage et puissance de calcul, ‘asservis’ à la loi de Moore depuis des décennies) ont elles aussi explosé, passant d’un statut de facteur limitant à celui de non-sujet.
Traditionnellement, ces données étaient propriétés de la DSI. Certes, les décisions des BU métiers et du top management s’appuyaient déjà sur ces données. On ne pouvait toutefois pas se passer d’un intermédiaire pour leur consultation et traitement, augmentant les risques de non compréhension de la donnée ainsi que les temps de traitement des demandes. Aujourd’hui, de plus en plus d’organisations transversalisent leur entité ‘data’, afin de rapprocher les données des métiers, porteurs de la connaissance de la donnée, et des usages, délivreurs de valeur.
Car il est évident que, bien qu’elle soit complexe à déterminer précisément et instantanément, la donnée a une valeur évidente qu’il convient d’exploiter. Pour cela, une capacité d’analyse, plus ou moins poussée, est nécessaire à tous les niveaux de l’entreprise, au plus proche de la donnée et ce pour ne pas en perdre la signification.
Mais il existe encore des freins à cette démocratisation. En entreprise, le nouvel analyste peut se heurter à une mauvaise compréhension de la donnée. Même si la tendance est au partage et à la “transversalisation”, les données sont encore parfois stockées et gérées en silo, rendant difficile l’accès et la transparence de la signification métier de cette donnée.
Mais multiplier les analystes peut aussi représenter un risque de multiplier les analyses…identiques. Aussi, un sujet apparaît lorsque la donnée est rendue accessible plus largement : celui de la protection des données personnelles, récemment encadré par la nouvelle réglementation GDPR. En effet, la finalité d’un traitement de données doit aujourd’hui être systématiquement précisée, tout comme la population de personnes accédant aux données en question. Cette dernière doit par ailleurs être réduite au strict minimum et justifiable.
Cette data democratization est donc porteuse, dans le monde de l’entreprise, d’un message supplémentaire : une gouvernance bien établie agrémentée d’une communication efficace sont nécessaires et catalyseront la démocratisation.
Et concrètement, analyser des données ?
Avant toute chose…
Il existe une règle d’or dans le monde de l’analyse de données et elle s’appliquera également aux nouveaux analystes issus de la data democratization. Cette règle, éprouvée et vérifiée, stipule qu’en moyenne 80% du temps effectif d’un analyste sera consommé par la collecte, le nettoyage l’organisation et la consolidation des données, ne laissant que les 20% restants pour les analyser et en tirer de la valeur. Il faut donc que les nouveaux analystes prennent conscience de cette contrainte et aient une base de connaissances sur les réflexes de vérification à avoir lors de la réception d’une nouvelle source de données.
Visualiser
On peut définir la visualisation de données (ou dataviz) comme une exploration visuelle et interactive de données et leur représentation graphique, indépendamment de leur volumétrie, nature (structurées ou non) ou origine. La visualisation aide à percevoir des choses non évidentes en premier lieu, répondant à deux enjeux majeurs du monde de l’entreprise : la prise de décision et la communication.
Mais attention, un graphique mal utilisé peut faire passer un message erroné, laisser percevoir une tendance peu fiable ou maquiller une réalité. C’est donc pour cela qu’il convient de donner à tous une base méthodologique permettant d’exploiter la puissance de la dataviz tout en évitant les écueils.
La force de la visualisation réside en l’aperçu instantané qu’elle permet d’avoir sur une large quantité de données, pour peu que son créateur ait fait le bon choix de représentation. Plusieurs paramètres sont à considérer lorsque l’on souhaite choisir une visualisation : quel phénomène je souhaite mettre en évidence ? de combien de variables ai-je affaire ? ma représentation doit-elle être continue ou discrète ? …
Ci-dessous, une cheatsheet sous forme de visualisation, avec pour thème : “Quel type de graphe pour quel usage ?”
Avec quels outils, pour commencer ?
Une des raisons d’occurrence de cette ‘data democratization’ est l’émergence de technologies facilitatrices, permettant à un plus grand nombre d’interagir avec les données, à l’aide de frameworks de code ou d’interfaces graphiques accueillantes pour une expérience guidée et visuelle :
Logiciels de ‘data federation’ et dataviz : des interfaces graphiques simples, guidant la manipulation de l’import des données de formats et de sources différentes jusqu’à leur visualisation, intégration dans des dashboards et publication de rapports. On peut citer les solutions leaders du marché : Tableau Software, QlikView, Microsoft Power BI,…
Solutions “all included” et plateformes : dans une unique application, la possibilité est donnée de mener des analyses automatiques jusqu’à de la modélisation complexe, le tout sans avoir à toucher (ou peu) une ligne de code (exemples de solutions : IBM Watson Analytics, Dataiku, Saagie,…)
Frameworks et librairies : s’adressant à un public plus averti, il s’agit là de fonctions et méthodes prêtes à être ré-utilisées et adressant des problématiques et utilisation bien particulières (exemples : librairies NumPy et Pandas en Python pour faciliter la manipulation de données, librairie D3js en JavaScript pour la dataviz, …)
Mais il est toutefois un outil encore très majoritairement utilisé pour des cas simples de reporting, visualisation, agrégation et modélisation simple. Il s’agit du tableur on-ne-peut-plus-classique : Excel et l’ensemble de sa cour d’alternatives (GSheets, LibreOffice Calc,…). Et il est évident que l’on ne peut pas parler de démocratisation sans citer cet outil.
L’utilisation du tableur est aujourd’hui un pré-requis pour un grand nombre de métiers, dont certains sans aucun rapport à l’informatique. Aussi, le niveau de compétence en la matière n’a fait que s’élever d’années en années et c’est une tendance qu’il convient d’accompagner. De son côté, Microsoft ne cesse d’enrichir les fonctionnalités et, paradoxalement, de simplifier l’utilisation de son outil, en ajoutant des suggestions basées sur une analyse intelligente des contenus.
Notre conviction
Bien que nous n’ayons aujourd’hui pas le recul pour l’affirmer, on peut avoir bon espoir que cette démocratisation révolutionne la prise de décision en entreprise, en permettant aux employés à tous les niveaux de l’organisation d’avoir accès à des données et d’en tirer conclusions, plans d’action et projections.
Et nous pouvons espérer que cette démocratisation ne se cantonne pas au périmètre de l’entreprise traditionnelle : quid du travailleur indépendant, du petit commerçant ou du restaurateur ? Il est évident que ces individus également, dans l’exercice de leur activité, génèrent ou reçoivent des données qu’ils pourraient exploiter et valoriser (optimisation des stocks, analyses de résultats,…). Pour ces professionnels, un minimum de compétence internalisée mènerait à des économies en prestations et en temps passé, mais également à un éventuel ROI issu de l’analyse et de l’exploitation de leurs données.
Forts de ces constats, nous nous sommes aujourd’hui forgé la conviction suivante :
Le 27 novembre, à l’hôtel Peninsula, plus de 50 participants de tous les secteurs d’activité ont assisté à notre événement « Maîtriser et Augmenter la valeur des données ».
Cette table ronde était l’occasion de faire un 360° sur les usages faisant des données un actif majeur pour les organisations. Rythmée par les témoignages exceptionnels de Lydia Bertelle de Paris La Défense, Laurent Drouin de la RATP, Isaac Look de Malakoff Médéric et l’artiste Filipe Vilas-Boas, nos intervenants ont pris le temps de, partager leur vision, présenter leurs cas d’usage et détailler les leviers et les freins afin de structurer une approche pragmatique pour augmenter la valeur des données.
4 temps forts ont rythmés cette matinée:
Le regard Artistique et Numérique porté par Filipe Vilas-Boas, un artiste citoyen qui a installé un Casino permettant à tout un chacun de réfléchir et comprendre l’impact des données sur nos vies.
Les choix et investissements de Malakoff Médéric en temps et en ressources sur le sujet de la Gouvernance des Données porté par Isaac Look
Les Usages comme les vecteurs de la valeur de données, éclairés par des exemples de la RATP, portée par Laurent Drouin
L’approche choisie par Paris La Défense et Lydia Bertelle pour augmenter la valeur des données illustrant la feuille de route, le fonctionnement, les difficultés et les résultats concrets atteints.
Rhapsodies Conseil a pu, à cette occasion, présenter et remettre aux participants un exemplaire de son Livre-Blanc « Augmentez la valeur de vos données ! » détaillant sa méthodologie de mesure et d’identification des actions permettant d’augmenter la valeur des données.
Revivez les moments forts de l’évènement sur nos médias:
Vidéo
Podcast
Photos
Accueil de l’Hôtel Peninsula
Introduction de la Table Ronde
Casino Las Datas
Evénement DATA – Témoignage Isaac Look de Malakoff Médéric
Tout comme une dette financière choisie intelligemment peut être synonyme de succès financier, toutes les dettes techniques ne sont pas nécessairement handicapantes pour l’entreprise, et peuvent aussi être un levier de croissance rapide. Cela se vérifie tout particulièrement lorsqu’on ajoute un nouveau système pour prendre des parts de marché : la dépense présente pour répondre au « time-to-market » est faite dans l’espoir d’un gain futur.
Attention cependant, tout comme les dettes financières non maîtrisées, les dettes techniques peuvent devenir un « poids mort » pour l’entreprise. En cas de difficultés trop importantes, elles accaparent les équipes et engendrent une évolution défavorable du rapport Run / Projet. Cela est synonyme de baisse dans la capacité à livrer de nouvelles fonctionnalités, mais aussi souvent de démobilisation des équipes, voire de turn over. Dans les cas extrêmes, par exemple pour les entreprises avec des ressources limitées, cela peut devenir léthal si la direction n’est pas vigilante à cet indicateur Run/Projet.
C’est pourquoi dans ce premier article, nous avons identifié 3 types de dettes IT et 3 parades pour les traiter :
Dette technique opportuniste et plan de remédiation
Un concepteur sait, en général, qu’il y a deux façons de créer une fonctionnalité : la bonne ou la rapide. La manière rapide n’est pas nécessairement la mauvaise, car elle consiste à ne pas faire de sur-qualité. Cependant, l’économie peut très bien avoir été faite au détriment de la scalabilité : la bonne idée d’un jour se révèle être un choix non pérenne. Bien souvent le concepteur est contraint de faire ainsi pour réduire le time-to-market.
Ce choix est parfaitement acceptable, mais il faut l’accompagner d’un plan de remédiation, pour assurer la pérennité du nouveau système une fois que celui-ci en sera en production. Dans le cas contraire, les dettes techniques vont s’accumuler petit à petit, ce qui entraînera inexorablement la baisse de la qualité de service pour les utilisateurs, la frustration des équipes en charge de la maintenance applicative et l’accroissement des coûts d’exploitation du fait des incohérences techniques et fonctionnelles à corriger continuellement.
Ce type de dette doit donc être tracé, pour permettre des actions de remédiation. En parallèle, un sponsor / product owner doit être tenu responsable de l’évolution de la dette technique sur son périmètre, et donc être objectivé sur ce sujet. La cohérence n’est pas un artifice.
Dette technique liée à l’innovation et pilotage des exigences
Dans le monde de l’IT, de nouveaux patterns et technologies apparaissent sans cesse. Il en va de même pour les usages.
Un choix de conception, à un moment donné, peut être remis en cause soit par une évolution des usages métiers, soit par l’apparition d’une nouvelle technologie entraînant une obsolescence fonctionnelle.
Ce type de dette finit toujours par apparaître qu’on le veuille ou non. Il est donc important de sensibiliser le sponsor / product owner à la nécessité de suivre la satisfaction des exigences sur son périmètre, afin de déclencher des actions de remédiation le cas échéant.
Dette technique « endémique » et vastes chantiers de modernisation
Ce type de dette est relatif aux vieux systèmes, sur lesquels ont été empilées au fur-et-à mesure des demandes d’évolution de nouveaux traitements complexes, sous forme de « verrues », jusqu’à créer une complexité telle que les systèmes deviennent impossibles à maintenir / faire évoluer, sans parler du turn over, entraînant inexorablement une amnésie informatique.
Dans le cas de fonctionnalités critiques pour le métier, cela constitue un risque opérationnel pour l’entreprise.
Ce type de dette doit être évité autant que possible, et faire l’objet de vastes chantiers de modernisation. Souvent, cela implique un remplacement pur et simple du système par un nouveau, plus adapté, et surtout mieux conçu.
Il existe aussi d’autres types de dettes, notamment celles créées inconsciemment …
Dans tous les cas, un système de classification des dettes techniques va permettre de les identifier et de sensibiliser les donneurs d’ordre, et leur proposer des plans de résolution adaptés :
Plan de remédiation pour favoriser la scalabilité et la pérennité au fil de l’eau
Pilotage des exigences pour accompagner l’évolution technologique
Vastes chantiers pour faire face à la dette « endémique »
Le sujet vous intéresse ? Restez à l’écoute, dans un prochain article, nous discuterons des différents impacts de la dette technique sur l’entreprise, et pourquoi cela n’est pas qu’une question « d’informaticiens ».
Dette technique : 3 types, et 3 approches pour la maîtriser
Avec l’arrivée récente de différentes réglementations impactant les données (RGPD, Bâle III, Bâle IV, BCBS 239), il est devenu primordial de connaître son patrimoine de données afin de pouvoir identifier et appliquer les bonnes politiques de gouvernance de la donnée (qualité, sécurité, accessibilité). Il faut que les entreprises voient cette contrainte comme une opportunité qui leur permettra à terme de faciliter leurs différents projets de transformation et de mieux valoriser leurs données.
Quel Data Scientist ou Responsable de Traitementmétier ne s’est pas interrogé sur la source d’une donnée à utiliser pour son cas d’usage ? Comment connaître son origine et son cycle de vie et s’assurer de sa qualité ? Comment savoir, au sein d’une entreprise, qui est le Data Owner sur une donnée en particulier ? Ou trouver le glossaire des termes métier associés à cette donnée ? Comment montrer à un RSSI, un DPO ou un Régulateur que les mesures de sécurité liées à une réglementation ont été associées à une donnée et mises en œuvre ?
C’est là où une solution de Data Catalog (ou catalogue de données) devient essentielle et peut vous aider à répondre à ces différentes questions. Celui-ci deviendra la base d’information centrale, un peu comme une bibliothèque, qui vous permettra de rechercher, trouver et connaître les bonnes sources de données pour vos cas d’usages Big Data ou vos traitements métiers. Ceci permet de regrouper les données au sein d’un même référentiel, de collecter, d’enrichir et de partager toutes les métadonnées associées.
Figure 1 – Exemple de métadonnées
Mais comment faire pour s’y retrouver ? Les différentes offres du marché se vantent toutes de pouvoir gérer et maîtriser votre patrimoine de données, générant, ainsi, de la valeur. Il faudra d’abord définir le périmètre de la gouvernance de données à mettre en œuvre et recueillir les exigences fonctionnelles et techniques. Ce qui suit vous aidera ensuite à comprendre ce que pourra couvrir une solution « Data Catalog ».
La fonctionnalité de base est déjà de pouvoir récupérer automatiquement les métadonnées techniques, c’est-à-dire les informations décrivant vos données d’un point de vue infrastructure (fichier, base de données, table, colonne, etc). Les éléments différenciant pour le choix de la solution vont dépendre de votre écosystème et des connecteurs nécessaires. Est-ce que vos données sont structurées, non structurées ou sont-elles sous format document ? Est-ce que vos données sont contenues dans des bases de données SQL ou noSQL ? Quel socle technologique Big Data utilisez-vous ? Avez-vous des données dans des Cloud Public ? Comment transporter ou partager vos données ? Via des traitements spécifiques, un ETL, un ESB ou via une API Gateway ?
Ces métadonnées décrivant vos données techniques comme un dictionnaire devraient être reliées à une donnée logique et une donnée métier qui sera elle-même à l’aide d’un glossaire métier.
Figure 2 – Architecture de Donnée
Un cadre de gouvernance des données avec une organisation, des acteurs, des processus et des livrables documentaires doit aussi pouvoir être décrit et déployé via un métamodèle opérationnel .
Ce métamodèle implémenté dans l’outil devra permettre de gérer des rôles et des organisations afin de pouvoir définir des responsabilités pour appliquer cette gouvernance de données. Celle-ci ne pouvant être mise en œuvre que si la donnée a d’abord été classifiée et que des politiques de gouvernance liées à un référentiel d’entreprise ou demandé par un Régulateur ont été identifiées et reliées à cette donnée métier. Tout ceci n’étant possible que si l’outil permet de gérer un modèle opérationnel de gouvernance des données personnalisables.
Parmi les autres fonctionnalités attendues pour cet outil il y a également la capacité de générer des états de Data Lineage.
Figure 3 – Exemple de Data Lineage
Cette fonctionnalité est majeure et permettra de traduire visuellement la vision 360° de vos données. Ceci vous habilitera par exemple à réaliser des analyses d’impact en cas de changement sur un système aval vous fournissant la donnée. Ces états peuvent vous aider également à analyser l’écart entre deux KPIs ou de répondre à une exigence réglementaire demandant de documenter de bout en bout comment tel indicateur aura été généré. L’outil vous permettra aussi d’avoir une vision sur la qualité de ces données via par exemple du data profiling ou des indicateurs. Ceci permettra de faire gagner du temps à vos Data Scientist pour sélectionner l’algorithme le plus approprié ou motivera votre Data Steward à sélectionner le jeu de données le plus approprié pour votre cas d’usage ou traitement métier.
Figure 4 – Exemple de Data profiling
Enfin pour terminer, cet outil devra être accessible via une application web, fournir un moteur de recherche et proposer un référentiel de cas d’usages avec les sources de données associés. Ceci activera le partage de la connaissance de ce patrimoine au travers de votre organisation et l’identification des sources de données critiques à vos traitements métiers. A terme, ce patrimoine permettra plus facilement aux métiers de générer de la valeur pour votre entreprise tout en maitrisant les règles de sécurité et accessibilité de cette donnée.
Voilà pourquoi le Data Management ne peut plus se faire via un tableau Excel et qu’un catalogue de donnée devient essentiel.
Ma série d’articles sur l’Architecture et l’agilité en arrive à son 5ème chapitre. J’ai fait beaucoup de recherches, échangé avec des agilistes et des confrères Architectes. Mais avais-je vraiment pris le temps d’intégrer l’agilité dans mon mode de fonctionnement ? Pris le temps d’en discuter et d’y travailler avec mes équipes ? Et qu’a fait notre cabinet de conseil pendant ce temps-là ? Voici mon retour (d’expérience) sur ce qui s’est passé dans mon écosystème dernièrement.
Avoir dans notre cabinet une équipe dédiée à la Transformation Agile est vraiment un atout dont je n’avais pas encore mesuré toute la portée. L’évolution se fait doucement mais sûrement et en profondeur. Que ce soit par des formations, des conseils ou des exemples, elle se fait sentir à tous les niveaux du cabinet. Nous sommes en train de trouver notre voie et c’est bien là le secret !
Former les managers
En tant que consultant d’abord puis manager, je suis des formations régulièrement. Depuis plus de 15 ans ces formations portent sur mon expertise, l’Architecture, mais aussi sur le métier de consultant et de manager d’équipe.
Notre équipe de Transformation Agile propose une formation au Management 3.0. Comment refuser une telle opportunité ? Prendre 2 jours de réflexion sur ma pratique de management qui n’avait pas évolué depuis quelques années. Avoir les bonnes pratiques et de nouvelles techniques autour du management à intégrer dans mon fonctionnement et celui de mon équipe.
Je pensais bien que le changement était en marche, mais là, j’ai vraiment réalisé le retard que j’avais pris. Nous sommes donc en train de changer notre fonctionnement interne, nos modes de réunions, de travail etc. L’équipe en parlera surement plus en détail dans un prochain article.
Je ressemble à ça maintenant, j’ai bien changé, non ?
La formation pour tous, mais laquelle ?
En parallèle, la réflexion m’avait mené aussi sur la formation des consultants vers l’agilité et les changements que cela implique. Quelle formation ? Pour quel but ? Pour commencer, 2 formations fondamentales tiennent la corde. Elles correspondent aux 2 rôles principaux des projets agiles aujourd’hui : le Scrum Master et le Product Owner.
Les 2 formations sont pour partie les mêmes. Les bases de l’agilité y sont présentées. La suite diffère selon le rôle que l’on est amené à jouer. Est-ce que vous allez travailler en tant que responsable du produit ou en tant qu’animateur du projet ?
Le Product Owner se focalise sur la valeur, les finances, la stratégie, et est connecté avec les différents intervenants et clients autour du projet.
Le Scrum Master est un facilitateur de l’atteinte des résultats, un leader non autoritaire qui connecte les gens et les aide à tirer le meilleur d’eux-mêmes dans la constitution de l’équipe. Il est là pour catalyser les résultats.
Pour le métier d’Architecte, les 2 aspects semblent importants. Dans ce cas, pourquoi choisir ?
Nous avons alors pris le parti de former certains architectes en Scrum Master et d’autres en Product Owner. L’avenir nous dira si nous devons compléter par la suite la formation des uns ou des autres.
L’essentiel est de se lancer.
Nous ferons au fur et à mesure des projets et des missions, les constats et les retours d’expérience des uns et des autres sur l’utilité et la spécificité de chacune des formations (par exemple, sous le format des rétrospectives présentées dans SCRUM !)
La détection des faux positifs
Maintenant que nous sommes formés à l’agilité, que nous en connaissons les principes, le 1er changement qui nous vient à l’esprit est de détecter tous les projets qui se prétendent Agile (le terme étant très galvaudé en ce moment) et qui ne le sont pas. Et surtout de pouvoir dire en quoi ils ne sont pas agiles.
Un projet qui conserve un découpage de ses travaux en lots. Un projet sans autonomie. Autant de projets avec lesquels nous travaillons, qui se prétendent agiles, voire sont convaincus de l’être.
Nombreux sont les exemples que nous voyons dans les entreprises au quotidien.
Un des principaux défauts, que j’avais souligné dans un article précédent, est qu’il est très difficile pour un projet d’être vraiment Agile si les managers ne le sont pas et ne font pas évoluer leur posture.
Même s’il est toujours aussi difficile de travailler avec ces projets, au moins nous pouvons échanger avec eux, les aider aussi et peut être trouver des axes d’amélioration ?
Et au niveau du cabinet, le LAB !
En parallèle, notre cabinet a initié une pratique de Lab : dispositif de créativité, de co-construction et d’intelligence collective aussi bien orienté vers l’interne que vers l’externe. Les initiatives sont venues, les projets ont commencé, les premiers résultats arrivent. La dynamique est en place et le mode de fonctionnement se rode.
Il y aura des réussites, des échecs, mais surtout plein de belles histoires.
Mais le plus important dans tout ça, ce n’est pas le Lab, c’est bien le symbole. Dans notre cabinet, comment trouver une place dédiée pour le Lab où nous puissions travailler avec les bons outils ? Le seul endroit qui s’y prêtait était déjà occupé. Et pas par n’importe qui, pensez donc : le président et ses 2 DG Adjoints. Ce sont eux-mêmes qui ont proposé de laisser leur bureau pour le Lab.
Si ça, ce n’est pas un changement visible !
Fini la V1, vive le MVP !
Dans l’ancien mode de fonctionnement d’un projet, nous annoncions toujours la mise à disposition d’une V1, complète et exhaustive. Elle prenait du temps et consommait des ressources. Pour un résultat rarement satisfaisant.
Avec l’agilité, nous faisons des MVP (Minimum Viable Product). Un produit suffisamment complet du 1er coup pour qu’un client y trouve de l’intérêt (juste les bonnes fonctionnalités). Pas avec toutes les fonctionnalités bien sûr mais plus qu’une V1 bancale. Une approche qui oblige à se focaliser sur l’essentiel.
Nous essayons de démocratiser cette approche pour tous nos projets, y compris pour nos projets en interne.
Et cela fonctionne mieux. Les MVP sont mieux acceptés, consomment moins de ressource, apportent plus de retours d’expérience.
Est-ce que ça change vraiment ?
Oui ça change. Surtout la perspective avec laquelle on aborde les sujets.
La mise en pratique se fait avec un plus grand partage de toutes les informations. La transparence est primordiale.
Les échecs sont permis. On apprend à marcher en tombant. Il faut essayer. Les nouveaux modes de fonctionnement ne marchent pas du 1er coup ? Quoi de plus normal. Apprendre de nos erreurs et continuer à avancer.
La confiance était déjà de mise dans notre cabinet mais le management agile va encore plus loin.
Ne plus imposer mais fournir les informations pour que chaque niveau puisse décider de son mode de fonctionnement, de ses actions et de ses buts.
Rome ne s’est pas faite un jour, mais les changements sont visibles et je pense maintenant que personne ne pourrai / ne voudrai retourner en arrière.
Aller très loin ou aller trop loin ?
Dans la formation Management 3.0 certains aspects bouleversent complètement nos modes de fonctionnement. « Ne pas promettre de récompense », « Récompenser des comportements pas des résultats » sont des exemples de préconisations de cette formation. Ces règles visent à valoriser le collectif plutôt que l’individu / l’individualisme.
Quel changement quand on est habitué à avoir des objectifs fixés en début d’année et d’être jugé, et récompensé, sur la base de l’atteinte ou non de ces résultats.
Imaginer des commerciaux qui ne soient plus récompensés sur l’atteinte de leurs résultats mais sur leur comportement ! Impensable de nos jours dans la plupart des entreprises. Et pourtant, on sent bien la justesse des arguments de ces nouvelles techniques de récompense.
Certaines habitudes auront la vie plus dure que d’autres, et le trajet sera d’autant plus long.
Conclusion
C’est une révolte, sire ? Non, juste une belle évolution ! En faire moins (exit les V1 fastidieuses) mais mieux (les MVP).
Le principal est que cela soit le fait d’une volonté commune et que les dirigeants (un fort niveau de sponsoring est indispensable) comme les collaborateurs y adhèrent. Nous avons tous à y gagner et à grandir dans ces nouveaux modes de fonctionnement.
Nous avons les techniques, des formations sont à disposition et des vidéos pour nous guider.
A nous de jouer !
Chapitre(s) suivant(s) ?
Je ne vais plus annoncer de suite, car cela évolue / change tellement vite ! Mais ne vous inquiétez pas, vous ne serez pas déçus.
