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 ;)

9 réflexions au sujet de « Modèle d’organisation de la DSI, ce qu’il ne faut pas faire. »

  1. Et pourquoi pas une hotline de haute qualité, je me rappel un grand débat sur les point fort d’une entreprise qui avait mis en place une hotline d’expert avec un gros suivi client… une autre piste…

    je ne dis pas non plus : ce qui est visible, doit etre beau !
    Mais à la place de l’utilisateur j’atend 3 chose de la DSI
    – les applications qui fonctionnent
    – Une hot-line de qualité
    – Des conseils !

    pour moi c’est bien ce dernier point qui est preceque innexistant !

  2. Je suis fondamentalement d’accord avec la conclusion. Le bon fonctionnement d’une équipe, d’une service, d’une BU ou d’une entreprise est avant tout une histoire d’hommes (et de femmes évidemment).

    Je suis plutôt en règle général pour une séparation des responsabilités (services) dans l’entreprise et par extension à la refacturation interne des fonctions support (je suis moi même directeur dans une SSII et travailler sans budget est une utopie).
    Pour palier l’effet de bord que tu expliques dans cet article, il est important que la DSI ait bonne presse et collabore étroitement dans les projets.
    Là où je bossais avant, nous avions des chefs de produit qui avait un rôle transverse dans l’entreprise. Nous avions mis en place des binômes entre le CDP (au sens projet informatique) et de chef produit et cette complicité centrée autour du « produit » permet de se focaliser sur un objectif commum. Les informaticiens expliquant leurs problématiques techniques aux chefs de produit et les chefs de produit expliquant les enjeux légaux, marketing, commerciaux, etc.
    Comprendre l’autre et trouver des solutions ensemble a bien fonctionné. En revanche, il faut bien comprendre que l’important est le talent des CDP (technique/produit) à faire la liaison et ne pas s’arquebouter sur son petit monde. C’est une question de philosophie d’entreprise, qui doit être portée par les « patrons ».

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s