Le 4ème temps de l’USI 2012 était placé sur le thème « rêver ». Nous reprenons avec une heure de philo par André Compte-Sponville, le moment philosophique de la conférence. Très sympa. J’ai ensuite enchainé avec Y.Morieux puis une présentation d’une scientifique du MIT sur l’interface Homme-Machine, avant de terminer avec Philippe Stark, dont je n’aurai pas grand chose à dire.
Yves Morieux, Blackberry Hill, effet Domino
S’il y a un bonhomme qu’un Boss doit voir une fois, c’est Yves Morieux. Au lieu d’acheter un livre de Management à la Fnac ce week-end, le DSI de base devrait lire et écouter Yves Morieux, Senior Partner au BCG. Bon, le Geek que je suis était content de venir voir l’édition 2012 de sa présentation. En effet, en 2010 si vous recherchez dans les vieux numéros du Touilleur Express, vous pourrez trouver cet article qui a été vu 1300 fois sur le blog : Let I.T Be.
Globalement cette présentation était assez proche de ce que j’avais vu en 2010. Le speaker est vraiment excellent, et je ne regrette pas d’avoir ré-écouté une partie du message de 2010. Le BCG analyse et accompagne la stratégie des grandes entreprises, en prenant en compte les grandes tendances qui affectent la société. Aujourd’hui, le monde des grandes entreprises souffre. Yves Morieux exhorte les informaticiens, plus particulièrement l’IT à avoir du courage, une capacité à improviser et à s’adapter pour réparer les dégâts. Nous sommes entrain de vivre une catastrophe organisationnelle. Il y a un moment de vérité à vivre, appuyé par le fait que la productivité stagne dans le monde de l’entreprise, que les gens souffrent parfois et que les clients ne sont pas heureux.
Il y a quelques années, la productivité augmentait régulièrement. Aujourd’hui c’est terminé. Nous n’augmentons que de 1% par an. Le danger de ne pas avoir une meilleur productivité, c’est que notre niveau de vie ne s’améliore pas. Dans les années 50-70 avec une forte augmentation de la productivité nous pouvions alors doubler le niveau de vie en une génération. Le souci c’est aujourd’hui : avec une productivité qui stagne il faudra 3 générations pour doubler le niveau de vie. Bref on risque de devoir vivre à crédit pour mieux vivre. Si notre niveau de vie n’augmente pas, nous serons obligé de nous endetter. Or avec la crise actuelle, ce sera de plus en plus difficile. Le BCG s’est donc intéressé dans le monde de l’entreprise aux endroits où la productivité disparait.
La deuxieme chose c’est le bonheur au travail et le désengagement des équipes. Il y a des employés heureux, des employés malheureux et surtout des employés qui luttent activement contre les intérêts de leur entreprise.
Le désengagement actif c’est lutter activement contre les intérets de son entreprise. Lorsque l’on est activement désengagé c’est que l’on souffre. Toute la question c’est pourquoi cette chute de l’engagement. La cause commune c’est les dégats causées par l’organisation moderne. Et quel role l’IT peut-elle y jouer ?
Le coeur du problème pour beaucoup d’entreprises c’est entre autre l’application à la lettre du « Strategic Alignment » proposé par Michael Porter, professeur de stratégie d’entreprise à Harvard.
Wikipedia http://fr.wikipedia.org/wiki/Michael_Porter
L’un des principaux apports théoriques de Porter consiste en une modélisation de l’environnement concurrentiel de l’entreprise sous la forme de cinq facteurs, dits forces de Porter, qui influent sur le partage des profits au sein d’une industrie :
- l’intensité de la rivalité entre les concurrents ;
- le pouvoir de négociation des clients ;
- le pouvoir de négociation des fournisseurs ;
- la menace d’entrants potentiels sur le marché ;
- la menace des produits de substitution ;
La stratégie des entreprises dans les années 90 a été d’aligner l’IT à partir des facteurs clés du succès. Cela fonctionnait en 90 lorsque le monde était simple. Il suffisait de mieux négocier avec un client pour augmenter sa marge. Il suffisait d’essayer de garder un monopole sur le marché pour exister. Il suffisait de réduire les coûts pour améliorer encore la marge… Bref le « …il suffisait… » a fait beaucoup de dégâts. Aujourd’hui c’est terminé.
Si vous vous battez sur le coût uniquement, c’est une route courte et sans issue. Aujourd’hui une entreprise n’a plus l’alternative entre le coût et la qualité. Si par exemple un fabricant d’automobile vous vend une voiture uniquement sur le coût en oubliant la qualité, cela ne fonctionne plus. L’entreprise ne peut pas choisir entre couts et qualités. Et ce qui est intéressant, c’est que ceci est vrai aussi pour l’IT.
Lorsqu’Yves Morieux explique cela, j’ai une pensé émue pour ces projets informatiques envoyés en Inde, lorsque l’IT était devenu sale et chère en France. Oh j’en ai des histoires de cowboy du code et d’indiens de Mumbai, et des plantages faramineux. La qualité était catastrophique et les coûts de gestion aussi. Comment peut-on imaginer qu’un projet fait à 3000 km de ses utilisateurs se passe bien ? Il y a bien les grosses SSII qui s’en servent pour réduire les coûts. Mais quid de la qualité ?
Yves Morieux continue ensuite en revenant sur ce qui se passe dans la tête d’un « manager » en 2012. Et j’espère que les Boss qui n’écoutaient pas à ce moment-là, trop occupés à exciter le petit bouton de leur BlackBerry vont bien lire ce qui suit. Nous répondons à la complexité par la confusion. Les managers passent 30% de leur temps en réunion et 40% en reporting. Finalement le « manager » n’est vraiment dans son rôle que 30% du temps. En fait, il devrait porter 3 titres sur sa carte de visite : « va en réunion/contente son boss/manage vraiment ».
Les managers ne s’occupent que de 30% de leur temps à réellement manager. Ce qui syphone la productivité c’est le labyrinthe de cette organisation. Le sens au travail est de moins en moins évident. Lorsque l’on passe son temps à le perdre en réunion, il est logique que le salarié se désengage activement pour ne pas péter un cable. Ce n’est pas les psy qu’il faut envoyer dans les organisations. Mais l’IT. Oui.
A chaque problème ou à chaque nouveau projet, nous créons de la complexité. Structures, processus, coordination, évaluation, incitation, score card, indicateur, KPI. Dans l’exemple de la construction d’un véhicule, l’application d’un système à la Michael Porter entraine une complexité et un modèle matriciel, qui entraine une dilution de la responsabilité de la personne. Pour résoudre un problème, Yves Morieux reparle du concept de l’ombre du futur. Plutot que de donner un bonus au développeur pour qu’il écrive correctement son code, faites-lui faire une mise en prod ou une journée avec le client final. Vous verrez que cela donne de meilleurs résultats et redonne du sens au développeur. Essayez de trouver un système qui ne récompense pas, mais qui fait prendre conscience du pouvoir de vos équipes. Et arrêtez de vous la péter avec votre BlackBerry (ça c’est de moi).
Un thème ensuite me rappelle mon ancienne vie de salarié dans un gros (j’ai pas dis grand, j’ai dis gros) groupe de la finance. L’histoire du développeur qui devient manager.
Yves Morieux reprend ensuite sur le thème du développeur qui devient manager. Dans l’IT il faut remettre en cause l’alignement stratégique. La séquence linéaire où le développeur devient manager est catastrophique. Aujourd’hui lorsqu’il y a un nouveau sujet, l’entreprise crée immédiatement un chef de projet. Mais à quoi sert-il ? Malheureusement un chef de projet ne sert qu’à coordonner. D’ailleurs il passe son temps à coordonner et à faire avancer « son » projet. Or la clé c’est plutôt de faire coopérer les équipes techniques, marketings, produits, support, etc. Vous IT : remettez en cause les roles de coordinations et pensez à la coopération. Dans votre organisation, comment faire le meme métier en mettant plus de collaboration ?
Dans la Banque, nous avions le Back et le Front. Bon, les deux ne se coordonnaient pas. Alors nous avons inventé le Middle-OFfice. Et bam, maintenant nous avons 3 problèmes au lieu de 2 problèmes. D’un autre côté, cette séparation est aussi indispensable pour des raisons réglementaires.
Il montre ensuite ce mail d’un manager daté de 19h50 qui convoque une équipe de 34 personnes dont 12 optionnels avec un ordre du jour pour le lendemain 15h. La salle rigole assez fort, enfin sauf les Boss qui continuent à résoudre des gros problèmes avec leur BlackBerry.
Mince c’est dingue, le manager à 19h50 qui balance une méga-réunion avec 2 fois la taille d’une PME. En plus, il met 12 personnes comme « invité optionnel ».
Tu fais quoi toi lorsque tu es marqué comme optionnel dans cette invitation ? Si tu viens c’était que tu n’avais rien d’autre à faire. Si tu ne viens pas, tu vas peut-être louper un truc croustillant. La réunion c’est le cancer de certaines entreprises. Supprimez les salles de plus de 8 places.
Allez supprimez aussi les BlackBerry car y’en a… enfin bon.
D’ailleurs à propos de ce BlackBerry, Yves Morieux en parle très bien.
Cet outil rend les gens stupides. Ils ne se parlent plus, mais ils se convoquent. On ne décide de rien aujourd’hui, tant que la réunion pour décider si on décide n’est pas faite. Ok ? Allez je t’envoie une invit’ avec mon blaque-béri.
Il y a quelques années, pour avoir un manager vous passiez par le filtre de son secrétaire. Et peut-etre que grâce a ce système finalement, les entreprises n’avaient pas besoin de 20 salles de réunion, et que finalement les gens prenaient des décisions. Aujourd’hui nous sommes bêtes, avilisés par des petits appareils, engagés en répondant à un email le soir, mais en perdant 2 heures en pleine journée dans une réunion dont on a rien à faire.
Soyez acteur et refusez cela. Il est temps de faire prendre conscience que le nombre de structures, de hiérarchies, le nombre de métriques, le nombre d’étapes pour approuver une décision sont autant de symptômes que l’entreprise est malade. A quand l’indicateur de « pourritude » d’une entreprise ? Tiens nous on est à 34. Mais avec la création de ce nouveau département transversal on devrait passer la barre des 50.
Si le concours « Best Place To Work » est bien, je propose l’indice carbonite de l’entreprise la plus compliquée, en se basant sur l’analyse de l’organigramme et les chiffres tirés des bilans financiers. Essayons de trouver une correlation entre le budget Black Berry et l’ambiance dans une grande entreprise du CAC40. A quand l’application « parachute » sur son iphone, utilisable si on décide de sauter par la fenêtre ?
Yves Morieux se livre ensuite à une simulation pour démontrer l’absurdité du système. Prenons le cas d’une entreprise qui entre 1950 et 2012 a suivi à la lettre les principes de Michael P. A chaque problème, elle créé une structure. Imaginons qu’elle créé 6 structures, qui doivent se coordonner. Cela donne (6n(6n-1))/2 soit 36 fois plus de soucis pour qu’elles fonctionnent correctement. 
Bref nos entreprises sont devenues obèses de la complexité et souffrent de sur-coordination. Il faut remplacer cela par de la collaboration. Le tout est d’améliorer la coopération.
Pour terminer, voici quelques outils et principes que nous pouvons mettre en oeuvre pour améliorer les entreprises. Yves Morieux présente ce qu’il appelle les « Smart rules for cooperation »
Améliorer la connaissance des autres, renforcer les intégrateurs, faire prendre conscience de l’ombre du futur. Augmentez le pouvoir de chacun pour qu’il puisse agir. Donnezun objectif collectif. Supprimez les monopoles internes, renforcez la coopération. Remplacez les bonus par des malus si les équipes ne coopèrent pas.
L’IT ne doit pas etre un business partner mais doit challenger la façon dont le métier de l’entreprise est mis en oeuvre et de refuser les les pieges de l’alignement stratégique.
Conclusion
En conclusion j’ai appris ce que je savais déjà : certaines organisations souffrent de complexité, d’absence de coopération. Les managers sont restreints à un rôle de coordination, avec peu de moyens. Les développeurs n’ont pas accès aux clients, aux équipes marketing ou aux personnes de l’exploitation. L’entreprise est une pieuvre géante, et elle ne veut pas que ses équipes coopèrent. Le souci c’est que ceci n’est pas compatible avec 2012. Ce n’est pas compatible avec des outils de communications transverses comme les emails par exemple. Les échanges entre les équipes s’effectuent par email, puis par réunion, mais toujours selon un canal qui consomme beaucoup trop d’énergies.
Ce que je pense là-dessus, c’est que nous nous sommes plantés. Nous avons voulu créer des entreprises où les départements sont isolés les uns des autres. Par exemple un développeur ne fera pas de mise en production ou une rencontre avec un utilisateur. Il sera obligé de passer par son chef de projet, qui lui, aura le difficile rôle d’essayer de coordonner. Or la clé que livre Yves Morieux, c’est de coopérer. Au lieu d’interdire un développeur d’une équipe A, de poser une question à un gars d’une équipe B, nous devrions virer le manager qui a créé cette règle.
Le développeur n’est pas un ouvrier (avec cependant tout le respect que je porte à un ouvrier) mais en général une personne assez éduquée pour avoir un Bac+5. Un développeur en général est aussi diplômé que le petit Boss qui a passé cette heure à bidouiller son Black Berry.
Et un développeur comme moi n’a pas à demander « la permission d’aller discuter avec Robert ». Non.
La clé pour peut-être moins souffrir et plus s’amuser serait de revenir à des petites équipes autonomes et indépendantes. J’imagine une équipe avec 30 personnes maximum. Dans ces équipes nous pourrions mélanger le responsable produit, la chargée de qualité, le web designer, le développeur, le gars du marketing, le commercial et le gars de l’exploitation. Et supprimer du coup les différents départements. Nous pourrions aussi supprimer des Boss. Bref, faire comme dans une startup.
J’espère maintenant que dans 2 ans, Yves Morieux viendra nous raconter des histoires de succès et de changements.
0 no like
Je pense que Google a du se pencher sur les pbs mentionnés par Yves Morieux.
Ils ont du s’apercevoir que différentes personnes embauchées avaient des profils « réunionite » différents. Comme je l’ai écrit dans un commentaire d’un autre billet du TE: « le soin de leur processus de recrutement (incluant plusieurs entretiens techniques intensifs) montre que, pour Google, les développeurs ne sont pas des ressources interchangeables. Car comme je l’ai écrit pour un autre commentaire http://www.touilleur-express.fr/2011/09/01/quel-type-de-developpeur-etes-vous/ « Mon idée, c’est que Google a compris qu’un très bon développeur coutait 2 à 3 plus cher que le prix de base, mais qu’il était 5 fois plus productif : la différence entre les 2 ratios est tout benef pour Google. En fait, la différence entre ces 2 ratios (et donc, l’avantage pour Google) est encore supérieur : on est ici dans une évaluation linéaire, mais en matière de travail en équipe, le cout des échanges se fait en n^2 et donc, l’avantage compétitif que tire Google de son processus d’embauche est aussi en n^2″. Et un autre avantage d’avoir des développeurs de bon, voire de haut-niveau, pour Google est d’avoir une hiérarchie sans doute plus faible, car ce type de développeurs sont de ceux qui s’auto-organisent plus facilement. »
Si l’on ajoute à cela que Google tend (semble-t-il) à privilégier la formation de petites équipes, et l’auto-management, avec une organisation managériale plane, et aussi le fait que Google incube, en son sein, ses propres jeunes pousses, il me semble qu’ils s’organisent pour palier aux pbs mentionnés par Yves Morieux, en mixant les forces des petites et des grandes structures.
Reste que cela n’est pas synonyme de succès: Google Wave a bien échoué.
A propos de Google Wave, la vue d’un employé Google ayant participé à ce projet: http://rethrick.com/#mmm
Même Google peut sombrer dans la réunionite, avec de grandes équipes dont les membres ne sont pas toujours coopératifs…
« Fast-forward six months and Google was in a lavish, new office with Walkabout fully underway and around 35 strong. The trouble, I am sure, began a lot earlier but this is when I started to really feel it. First, there was the dreaded endless meeting–they lasted for hours with very little being decided. Then, you started having to push people to provide APIs or code changes that you desperately needed for your feature but that they had little to no interest in beyond the academic.
My style is to ask politely and then when I realize nothing is going to be done, to do it myself. This is a prized hacker ethic, but it does NOT work in large teams. There is simply too much system complexity for this to scale as a solution. Instead of shaving one Yak, you’re shaving the entire Yak pen at the Zoo, and pretty soon traveling to Tibet to shave foreign Yaks you’ve never seen before and whose barbering you know little about. »