Bataille d’experts – le retour : Savoir trancher un sujet technique lorsqu’on est DSI

Dans un précédent article je vous donnais quelques conseils pour fournir les bons arguments à son DSI afin qu’il tranche sur des sujets techniques. J’inverse les rôles aujourd’hui, pour m’adresser à nos CIO, nos CTO, ou encore nos DSI / RSI, en somme à nos patrons de l’informatique.

Et là le conseil va être beaucoup plus simple : si vous en êtes à trancher des sujets techniques, c’est que vous avez raté le coche dans votre organisation. Vous avez un background technique ? C’est une très bonne chose. Mais si vous êtes le chef il faut bien se dire que ce n’est pas grâce à votre compétence technique, soyons honnêtes. Ne croyez donc pas que votre avis vaut mieux que celui de vos troupes, sur le terrain, qui elles développent encore plus de 6 heures par jour.

Un DSI n’est pas nommé pour répondre lui même au débat technique. Il est nommé pour constituer une équipe de confiance, capable de le faire pour lui. Le job d’un exécutif c’est plein de choses passionnantes, mais ça n’inclut pas de prendre des décisions opérationnelles.

Donc si un sujet technique est escaladé jusqu’à vous (quel ETL utiliser pour le prochain projet, quelle modélisation choisir pour son datawarehouse…), sachez reconnaître le problème organisationnel sous-jacent, et réagir en fonction.

Pour ça, voici les grandes étapes à suivre :

  • D’abord, constituez-vous un état-major d’experts en qui vous avez confiance. Qu’ils soient internes (c’est mieux) ou externes, identifiez des individus qui savent vous dire non, qui savent vous dire quand vos décisions sont mauvaises, quelle que soit leur place dans la hiérarchie. N’hésitez d’ailleurs pas à tester la capacité à la franchise de cet état-major de temps en temps : demandez des avis externes, croisez le retour de plusieurs personnes, posez des questions théoriques douloureuses dont vous savez les réponses, auditez le résultat de vos audits… Car en effet, la confiance n’exclut pas le contrôle.
  • Une fois ces référents identifiés, appuyez-vous sur eux pour vous conseiller dans la décision. Non pas pour vous expliquer le sujet technique, mais plutôt pour vous clarifier les intérêts et conflits d’intérêts de chacun, et comprendre pourquoi votre organisation n’a pas su répondre au problème. Vous n’êtes pas là pour trancher le choix de l’éditeur de l’ETL, vous êtes là pour comprendre pourquoi votre architecte décisionnel n’a pas réussi à faire appliquer ses recommandations.
  • Enfin, n’ayez pas peur de prendre et d’assumer des décisions qui ne font pas de compromis. Si un sujet escalade jusqu’à vous, il sera forcément chargé émotionnellement et votre décision fera obligatoirement des malheureux. N’essayez donc pas de satisfaire tout le monde, vous n’arriverez qu’à des demi-mesures qui feront trainer la situation dans le temps. Mieux vaut une vraie tristesse, qu’une fausse joie (dixit les experts). Soit les recommandations de votre architecte sont mauvaises, alors il vous faudra l’accompagner dans la mise à jour de sa compétence ; soit l’équipe projet est trop arrogante pour reconnaître la sagesse de l’architecte, et un effort de management doit être fait pour remettre les choses à plat.

Le résultat c’est que vous ne choisissez pas à la place de vos équipes, vous corrigez votre organisation pour qu’elle réponde elle-même à la question, et aux prochaines du même acabit.

Si sur le papier ça a l’air simple, il est clair que dans la vie de tous les jours c’est plus complexe. On a tous une tendance à vouloir jouer les superhéros, à sauter dans l’action et sauver les situations. Une caractéristique d’ailleurs encore plus présente chez les individus ayant réussi à se hisser dans les fonctions exécutives. Mais il faut savoir déléguer les décisions au bon niveau de responsabilité (le terrain), et respecter ces décisions. Pour un collaborateur, il n’y a rien de pire qu’un désaveu de la part de sa hiérarchie, surtout si de son point de vue il faisait le nécessaire pour protéger l’entreprise. Il est également important d’éviter le micro-management, car intervenir sur toutes les décisions c’est encourager vos équipes à vous masquer les problèmes afin de conserver leur autonomie.

Enfin, et je conclue peut-être avec le message le plus important de cet article : en cas de problème ne blâmez pas une personne, blâmez plutôt les processus et/ou l’organisation. Cette règle est à la base du Lean IT, dont un des piliers est le respect de la personne. Elle est essentielle au bon fonctionnement du groupe. Au-delà de la considération à avoir pour son prochain, c’est également un excellent coup de pouce à la transparence, puisque l’apparition d’un défaut dans l’organisation sera l’occasion d’améliorer les conditions de travail des équipes.

Mon SSD m’a tuer :(

Catastrophe! Le morceau de technologie du futur que je vous vantais dans un précédant article m’a lâché!

Plus de détection au boot ni dans le BIOS. Heureusement que j’avais conservé mon disque système précédant en l’état, j’ai pu redémarrer sur Windows XP en moins de 2 minutes (ça c’est du plan de reprise d’activité :))

Après recherche sur le forum de support d’OCZ, j’ai découvert qu’il existe des incompatibilités notoires entre les cartes mères Dell (surtout les anciennes) et les SSD dernières générations. Si seulement je l’avais su avant…

En terme de données j’ai juste perdu mes téléchargements iTunes, le reste étant stocké sur des disques en dehors du système.

Passé ma colère initiale, j’avoue que je prend la chose plutôt bien. J’ai attendu trop longtemps avant de mettre à jour ma machine, c’est de ma faute si je me retrouve avec des incompatibilités descendantes. Le seul truc qui me gonfle c’est la gestion du SAV du disque. Mais même pour ça je gère: je me rassure en me disant que vu que je ne ré-utilise pas le disque immédiatement je n’aurai pas à gérer mon impatience.

Ce qui est bien c’est que je peux tirer de cette expérience quelques leçons intéressantes pour mon métier:

  1. Pour ses applications critiques, il faut savoir éviter le bleeding-edge
  2. Pour l’ensemble de ses applications, il faut savoir se mettre à jour régulièrement afin d’éviter les ruptures technologiques
  3. Lors des évolutions, il faut tester, maquetter, prototyper, pour se protéger des incompatibilités masquées
  4. Maintenir et tester son plan de reprise d’activité et ses sauvegardes n’est pas une option
  5. Disperser ses données sur plusieurs supports évite de tout perdre en cas de crise
  6. Disposer d’un mode de fonctionnement dégradé en cas de crise permet de mieux gérer son stress et donc optimise la recherche de solutions

On les connaît déjà tous ces points, ou bien c’est du bon sens, mais est-ce que c’est appliqué sur les projets ou applications sur lesquels vous bossez en ce moment? C’est ça la vraie question!

Ps : Oui il y’a une faute dans le titre, c’est une private joke pour les gens nés avant 1995!

Mise à jour 11/05/2011 : L’épilogue SSD.

Modèle d’organisation de la DSI, ce qu’il ne faut pas faire.

Hier j’ai eu une discussion intéressante avec un client qui fait partie des CO (Chief Officers, CEO, CTO, CIO, CFO …) d’un grand groupe international.

Nous parlions de l’organisation de la DSI (Direction des Services Informatiques) et de comment le modèle de fonctionnement en société de prestation interne avait sur le moyen terme détruit l’implication des équipes informatiques dans son entreprise.

Ce n’est pas la première fois que j’entends ou je vis ce genre de situation, je vous avais d’ailleurs déjà passé cet article qui à mon sens résume très bien la problématique. Je vous rapporte ses principaux arguments ci-dessous :

  • Quand la DSI est conduite comme un business, avec des clients (internes) et des contrats (les spécifications), son objectif n’est plus de faire progresser l’entreprise. Pour le management l’objectif devient la minimisation des budgets, pour les équipes de répondre aux cahiers des charges en minimisant les efforts.
  • Dans ce mode de fonctionnement disparaissent les synergies, la collaboration entre les équipes et l’objectif commun de faire progresser l’entreprise… tout ce qui permet de créer un groupe de travail efficace en somme.
  • Quand la DSI fonctionne comme une société indépendante, le reste de l’entreprise la traitera comme un fournisseur. Or les décideurs métiers n’ont en général que très peu confiance en leurs fournisseurs. Difficile de créer de la valeur dans ces conditions.
  • Et que dire des fonctions informatiques transverses comme la qualité, l’architecture ou la sécurité, qui deviennent des verrues qu’aucun client ne veut inclure dans son budget ? Qui donc payera pour ça ? Le premier à développer un nouveau projet ? Tu parles d’une incentive à ne pas faire évoluer ses plateformes. On comprend mieux pourquoi nos outils de travail ont plus de 6 ans.
  • Une fois entrée dans ce mode, la plupart des réunions entre les métiers et les équipes de la DSI deviennent des réunions d’arbitrage, pour décider qui a le moins tord entre des métiers qui ont rédigé des spécifications les plus vagues possibles pour ne pas risquer d’oublier quelque chose, et des techniques qui se sont mis des œillères et ont codé bêtement, sans chercher à comprendre le besoin pour minimiser le temps d’implémentation.

Et là on peut prendre un peu de recul et se rappeler que tout ce beau monde travaille dans la même entreprise. C’est déprimant non ?

Quelles sont les solutions quand on en arrive là ? Personnellement j’en vois 2 :

  • Aller jusqu’au bout du mouvement et externaliser complètement sa DSI. Ainsi la DSI pourra être mise en concurrence avec d’autres prestataires, et pourra à son tour prendre d’autres clients. Ce n’est pas la solution que je retiendrai car à mon sens c’est mettre en danger une fonction « régalienne » de l’entreprise, mais au moins les incentives seront alignées correctement et les collaborateurs pourront travailler efficacement.
  • Faire machine arrière et réintégrer la DSI dans l’entreprise : abolir la notion de client interne et mettre à la poubelle toute la gestion du budget par facturation interne. L’objectif devient alors de visualiser la DSI non plus comme un centre de coût mais comme une boite à outils permettant au métier de mieux remplir ses fonctions.

Elle est bien jolie cette deuxième solution mais comment faire pour la mettre en œuvre quand la DSI est mal organisée, les collaborateurs sont déprimés, le turnover explose, les compétences fuient le bâtiment plus vite que les RH ne savent les trouver, et qu’en prime les métiers détestent la DSI parce que les projets informatiques ne finissent jamais bien ?

Je n’ai pas de recette miracle, chaque DSI répondra différemment à une réorganisation, mais il y a des pistes à suivre, certaines risquées et d’autres moins. Etant donné que l’objectif de la démarche est de changer la manière dont la DSI se perçoit et est perçue, le mieux est de commencer par les domaines où elle est en contact avec le reste de l’entreprise : en premier lieu dans les projets et dans la vie de tous les jours.

La première des pistes, celle qui concerne les projets, c’est évidemment l’Agilité. Il n’y a qu’à aller voir les valeurs de l’Agilité pour voir le lien immédiat avec ce que je raconte ici. Les méthodes de gestion de projet Agile sont à mon sens un des premiers outils à mettre en œuvre pour réussir cette transition. De plus c’est une piste facile à suivre puisqu’elle n’engage qu’un projet et une équipe à la fois. Je ne vais pas détailler ce point maintenant, c’est plus qu’un article à part entière et je le ferai certainement dans les semaines qui viennent si le sujet vous intéresse, je vous laisse consulter ma série d’article dessus: 1, 2, 3. Juste une petite remarque sur le sujet: attention à ne pas tomber dans le culte du cargo qui consisterait à appliquer une énième méthode en en oubliant l’esprit.

La seconde piste, concernant la vie de tous les jours, pourrait concerner la hotline. Pourquoi ne pas remplacer le modèle actuel de call center anonyme, qui marche si bien pour la gestion de la relation client (c’est de l’ironie, évidemment), par ce qui se fait de mieux en social en ce moment : un stack overflow interne ? Dans un call center tout est procéduré, caché dans des applications mal standardisées, sans aucune transparence ni cycle d’amélioration, avec des tonnes de redondances, des acteurs dénués de toute individualité et de tout chemin de progression. Au contraire dans un outil comme stack overflow, chaque hotliner a un profil, une réputation, des domaines d’expertises, les résolutions se font en plein jour, les utilisateurs contribuent au système, les mêmes questions ne sont pas reposées 50 fois par jours… En somme c’est tout l’inverse !
Plutôt que de mettre en place des workflows compliqués qui ne marchent jamais vraiment, il suffit d’utiliser les tags et de mettre en place des abonnements mails. Sur ce genre de plateforme, les rouages redeviennent des gens et retrouvent la fierté de leur travail. Et si c’est le réseau qui plante et que le site est injoignable ? Un mini call center à la Zappos fait très bien l’affaire ! Pour tout dire j’ai hâte de voir ce genre de solution déployée dans une entreprise!

Une remarque en passant : n’imaginez pas mettre en place une variabilisation de la rémunération des hotliners en fonction des statistiques de réponse sur la plateforme, sinon tout le système s’écroulerait

J’aimerais conclure en rappelant qu’au-delà de ces deux premières pistes, le seul vrai porteur de ce changement de mentalité est le directeur des services informatiques (ou équivalent). Sans une volonté sans faille de sa part à faire changer les choses, tous les efforts seront voués à l’échec. Mais si vous avez cette motivation et que vous lisez ce blog, rien ne pourra vous arrêter 😉