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 😉

C’est parti!

Plus tôt je vous décrivais rapidement mon métier. C’est une description très artificielle, de celle que l’on fait quand on se présente en entretien chez un client pour gagner une mission.

Je vais quand même prendre le temps d’aller plus loin, de préciser ce qu’est le job de consultant, puisque c’est autour de ces activités que va se structurer ce blog, son contenu.

Pour moi dans ce job il existe 5 grandes facettes :

A – le développeur : celui qui exécute

C’est la partie du job dans laquelle on réalise, on fabrique, on produit…  Pour moi un bon consultant sait réaliser, même si ce n’est pas sa tasse de thé, même s’il ne le fait plus ou que très rarement. S’il ne sait pas faire, s’il n’a jamais fait, à mon sens il ne pourra pas assumer les rôles que je décris après. C’est donc manifestement pour moi la partie la plus importante, sans laquelle rien ne se passe.

  • Un projet sans développeur ne se réalise pas !

B – le designer : celui qui imagine

Avant de pouvoir faire, il faut concevoir ce qu’on va faire. Il faut entendre le besoin client (dans ma salle de bain il me faut une serviette qui absorbe mieux !), comprendre les intentions réelles sous-jacentes (quand je me lave les cheveux, ma serviette ne les sèche pas vraiment bien !), et imaginer une solution qui résoudra le problème et non les symptômes (un sèche-cheveux par exemple, à comparer au besoin initial…).

  • Un projet sans designer se réalise mal – qualité foireuse, périmètre non couvert.

C – le chef de projet : celui qui facilite

Attention à la vision franco-française du chef de projet qui le positionne comme un petit chef ! Un chef de projet, c’est le chef d’un projet. Un projet, ce sont des powerpoints, des docs, des deadlines, un bout de code, et 3 serveurs. Les êtres humains qui travaillent sur le projet ne sont pas le projet. Donc un chef de projet n’est pas un chef de gens, pas un manager. Le vrai job d’un chef de projet est de rendre possible et faciliter au maximum les contributions des gens qui participent au projet. Il élimine la résistance à la contribution, mais il ne dirige rien ! Je n’invente rien ici hein, confère Scott Berkun ou Joël Splosky.

  • Un projet sans chef de projet est en retard, hors budget, ou ne se réalise pas.

D – le testeur : celui qui garantit

On ne peut pas faire de la qualité sans prévoir une phase de tests soutenus des livrables. C’est un métier à part entière, que je trouve vraiment trop sous-représenté dans le monde du décisionnel. Je n’ai pas encore vu de SSII ou boîte de conseil qui disposait d’une petite équipe de testeurs, transverse, bien équipée, pour aller sur chaque forfait valider ce qui était livré. Pourtant le coût peut tout à fait être intégré à la prestation et la valeur ajoutée est immédiate!

  • Un projet sans testeur c’est un projet où les consultants sont en fuite dès le PV de recette signé, attention quand vous irez voir sous les tapis…

E – le service après vente : celui qui accompagne

Cette partie tout le monde l’oublie tellement souvent que moi-même j’ai faillit pour cet article! Fabriquer c’est beau, mais livrer proprement, accompagner les utilisateurs, remonter les anomalies, faire accepter le produit, c’est 90% de ce que le client va percevoir. C’est bien plus que 3 slides poliment vendus comme de la conduite du changement. C’est s’engager sur le long terme, et en faire la preuve. Rien ne sert de se battre pour signer de nouveaux clients quand les anciens sont tellement contents qu’ils continuent à vouloir signer avec vous!

  • Pas de service après vente, pas de relations à long terme avec le client

Ce découpage des rôles n’est pas nouveau, encore une fois je n’invente rien: il n’y a qu’à voir toutes les grilles d’évaluation des consultants lors des entretiens annuels.  Et évidemment ce découpage ne s’applique pas qu’au décisionnel.

Les 4 premières facettes sont 4 professions classiques de l’IT. Si le consultant décisionnel est au milieu de tout ça, c’est parce qu’en général il travaille en parallèle sur des petits projets (1 à 6 mois) dans des petites équipes (2/3 personnes). Dans ce genre de conditions, tout le monde doit être ouvert et capable d’assumer un peu tous les rôles. La cinquième facette, c’est moins une profession qu’une attitude un peu trop rare à mon sens.

(MàJ : 30/08/2010 – sp)