Dilbert du 25/03/2011

Bien tenté petit scarabée!

Dilbert.com

Traduction approximative:

Boss: On peut tous apprendre de nos erreurs. Alors faisons la liste de tous nos échecs de l’année passée.

Dilbert: C’est une coïncidence si nos entretiens annuels sont la semaine prochaine?

Boss: Je serais entré dans la légende avec un truc pareil.

Catbert (DRH): Bien tenté.

Dilbert du 03/02/2011

Transposable au consulting sans aucun problème:

Dilbert.com

Traduction approximative:

Dilbert: Si nous construisons notre application sans aucun bug, nous ferons 10% de ROI.

Dilbert: Si nous salopons le travail, on pourra passer à 40% en vendant des upgrades et du service.

Dilbert : Mais ne vous inquiétez pas, nous n’avons pas le budget pour faire une application parfaite.

Boss: Je n’arrive pas à me souvenir si nous sommes radins ou malins.

4 liens rapides pour la semaine (2011-13)

C’est reparti!

  1. Si vous jouez ou avez joué à FarmVille, un très bon article de You Are Not So Smart sur le biais qui nous pousse à y retourner, encore et encore.
  2. Penelope Trunk sur pourquoi les employés problématiques ne sont jamais virés. Un point de vue intéressant.
  3. Les évangélistes du mouvement « Lean » à la défense de la notion flux tendu suite aux problèmes d’approvisionnement des compagnies ayant des fournisseurs au Japon. J’aime beaucoup leurs arguments.
  4. Un excellent article qui explique la comptabilité aux gens d’origine technique. Ça m’a ouvert les yeux, franchement c’est très très bien foutu.

______________________

<< Semaine PrécédenteSemaine Suivante >>

Les choses que l’on possède…

Hier, une amie me racontait une histoire étonnante qui s’est déroulée chez son client. Ce client est une entreprise française à portée internationale de plus de 5000 salariés.

C’est l’histoire d’une de ses collaboratrices, ayant plus de 10 ans d’ancienneté, qui s’est portée volontaire à un mouvement en interne auprès du département RH. Elle avait repéré une annonce sur l’intranet pour un poste en parfaite adéquation avec son plan de carrière et avait  facilement obtenu un entretien avec le responsable RH en charge du dossier.

L’entretien se déroule bien jusqu’au moment où le responsable demande un CV et une lettre de motivation à la collaboratrice. Celle-ci répond gentiment qu’elle ne voit pas l’intérêt de produire ces documents alors qu’elle appartient à l’entreprise depuis plus de 10 ans. Le recruteur ne change pas de position et continue d’exiger les pièces. La conversation s’envenime, le ton monte, jusqu’à ce que la collaboratrice quitte l’entretien et renonce au changement de poste.

Je trouve cela affligeant de la part du responsable RH.

Demander un CV à une personne qui est dans sa propre entreprise depuis 10 ans ? Le département RH ne connaît-il pas le parcours de cette collaboratrice ? Est-ce de la fainéantise pour ne pas aller ré-ouvrir les dossiers historiques ou est-ce un attachement déraisonnable à des processus mis en place pour recruter des inconnus ? Parce qu’il ne faut pas oublier que le CV et la lettre de motivation ne sont pas des fins en eux-mêmes, ce sont des documents utilisés dans le but de juger une personne avant de la rencontrer, pour décider si oui ou non on va la recevoir en entretien. Les exiger de la part d’une personne qui a plus d’une décennie d’ancienneté ? Affligeant.

C’est la raison pour laquelle je me méfie toujours des processus, des documents normés et des contrats. Ces créations artificielles, mises en place initialement pour garantir un résultat, ont une fâcheuse tendance à se substituer à l’objectif et à devenir le produit fini. Une documentation est rédigée pour aider l’utilisateur à prendre  en main l’outil, pas pour satisfaire la clause 25 alinéa 3b du contrat de prestation de service, sinon elle perd tout son sens.

Alors de temps en temps je prends le temps de m’écarter du clavier et de réfléchir à ce que je fais. Si je suis en train de réaliser quelque chose qui apporte de la valeur au moins à une personne, tout va bien. Si je rédige une documentation ou réalise une fonctionnalité qui ne servira qu’à satisfaire une clause dans un PDF, j’arrête et je passe à autre chose. Je ne sais pas vous, mais moi je n’ai déjà pas assez de temps pour faire des choses intéressantes, alors je ne vais pas en plus en perdre sur de l’inutile !

Ps : la citation du titre.

4 liens rapides pour la semaine (2011-10)

Désolé de la journée de retard mais j’étais en week-end :p

  1. Ben Horowitz sur comment recruter (ou ne pas recruter) quelqu’un dans la boîte d’un ami / d’une relation business. Beaucoup de bon sens.
  2. Un beau mythe fondateur d’entreprise: comment les managers se sont interposés contre une vague de licenciement dans le Pixar des années 85. Ça inspire.
  3. Par 37 Signals, une remise en place nécessaire sur ce qui se passe quand Yahoo rachète votre start-up.
  4. Enfin, un article écrit de la part de tous les hommes pour toutes les femmes, par un humoriste américain. C’est bien fait 🙂

__

<< Semaine PrécédenteSemaine Suivante >>

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 😉