Le stress du DSI
Par Sabine Bohnké, fondatrice du cabinet Sapientis

mercredi 8 septembre 2010

Ou le DSI veut rendre le système d’information de son entreprise efficace et il ne le peut pas, ou il le peut mais ne le veut pas, ou il ne le peut ni ne le veux, ou il le veut et le peut. Dans le premier cas il est incompétent, dans le second, il est pervers, dans le troisième il est incompétent et pervers et dans le dernier cas, que ne le fait-il ?

En paraphrasant cette lointaine argutie théologique d’Epicure sur l’existence de Dieu et sa capacité à empêcher le mal, l’objectif n’est pas de jeter davantage le discrédit sur une profession difficile. A l’heure où la plupart des systèmes d’information d’entreprise ne sont certainement pas aussi efficaces que souhaité, les DSI de ces systèmes ne sont pas plus omniscients et omnipotents. Dès lors ils ne sont ni incompétents ni pervers, ils sont surtout … stressés.

Car un DSI capable et consciencieux, ou légitimement ambitieux, est voué au stress. Dans le premier cas, il veut bien faire et répondre au mieux aux besoins formulés, tout en ayant des infrastructures robustes, quitte pour cela à en consolider les fondations. Dans le second, il veut mieux faire ou faire autrement, poussé par l’ambition de laisser sa trace en construisant une valeur ajoutée ou de partager une vision. Il veut anticiper, être force d’évolution et avoir des structures évolutives.

Dans l’un ou l’autre cas, si la responsabilité du système d’information lui incombe seul, il n’a pas les moyens de ses ambitions.

Volonté et Contraintes

Quand on lui demande d’être réactif sur des besoins à court terme, en lui imposant des échéances contraintes et non discutables, il doit laisser de côté la construction du long terme. D’une part, il n’est pas certain de réussir si seules les contraintes de temps ont été considérées, d’autre part, il peut se retrouver à empiler des solutions spécifiques à satisfaction immédiate mais qui tôt ou tard auront un effet boomerang dû à des erreurs de conception, des difficultés d’intégration ou des redondances et des incohérences de processus, fonctions ou données.

Si a contrario il s’engage sur une vision à long terme avec la conception de schémas directeurs et de cadres d’infrastructures, cela peut l’entraîner sur une lourdeur d’approche et des cadres si directifs qu’ils annihilent l’objectif d’évolutivité recherché, par manque d’agilité. S’il veut toutefois bousculer les cadres, il peut également prendre le risque de ne pas construire sur les bonnes fondations.

Ajoutons à cela que dans la majorité des cas, il n’a pas les ressources en interne pour satisfaire aussi bien le court terme que le long terme.
Donc, le DSI capable est stressé, car sa volonté d’action et ses capacités en regard ne sont pas en phase. On lui demande de tenir un rôle avec des responsabilités qui ne dépendent pas de lui.

Seulement, ce stress n’est pas inéluctable, car il est généré par une mauvaise compréhension du rôle du DSI. Rien n’impose qu’il ait à porter seul la responsabilité des directions prises par le système d’information et les décisions d’évolutions. Les applications et les infrastructures d’un système d’information n’ont de légitimité qu’au regard de leur valeur à l’usage. Selon l’AFNOR, « la valeur d’un produit est une grandeur qui croît lorsque la satisfaction du besoin augmente et/ou que le coût du produit diminue ».

Pour augmenter la valeur du système d’information, il faut déjà connaître la couverture de ses fonctions existantes et leurs coûts. C’est à cette seule condition qu’on peut juger d’améliorations possibles.

Ainsi doit-on s’interroger sur chaque application en termes de couverture de besoins et de coûts: quelle valeur a-t-elle pour l’entreprise ? Est-ce une valeur purement utilitaire ? A-t-elle de l’importance pour les métiers tout en restant relativement standard ? Est-ce que cette application est directement liée au chiffre d’affaires, aux performances, à la productivité, à la capacité d’innovation ? Si elle est utilitaire, peut-on l’obtenir autrement en consommant moins de ressources, de temps et d’effort ?

Un manque de visibilité sur les bons paramètres de décisions

Or peu d’entreprises, grandes ou petites, effectuent un inventaire des applications de leurs systèmes d’information avec les paramètres utiles pour répondre à ces questions, c’est à dire la réelle visibilité sur la satisfaction des besoins et les coûts de fonctionnement complets.

Il y a plusieurs raisons à cela, nous en citerons ici quatre majeures.
- La première est qu’à force de réaliser des solutions temporaires, elles restent pour longtemps - car la suivante chasse toujours la possibilité d’avoir le temps d’améliorer la précédente - et peu à peu deviennent complexes à maintenir. Or les applications spécifiques ont une durée de vie supérieure (de cinq à dix fois) à la durée où un DSI reste en poste (en moyenne de 2 à 5 ans). Le taux de turnover des équipes et de leur responsable induit qu’au bout d’un certain temps, sans action préventive, la connaissance technique des applications va se perdre. Il deviendra de plus en plus difficile de comprendre leur fonctionnement et de les faire évoluer proprement, ce qui conduira à ne pas savoir justifier des coûts de maintenance ou comparer avec d’autres solutions.

- La seconde raison est que les services rendus par les applications doivent être tracés et évalués par les usagers de ces services. L’important n’est pas seulement de comprendre le prix à payer pour les avoir, mais ce que l’entreprise serait prête à payer compte tenu du service rendu. Pour citer Warren Buffet, « Le prix, c’est ce que l’on paie, la valeur, c’est ce que l’on reçoit. ». Il reste encore à impliquer davantage les utilisateurs en tant que clients décisionnaires et responsables. Aussi bien en amont, dans la description des indicateurs qui permettront d’évaluer l’atteinte des objectifs du service, qu’en aval, avec la mesure effective de l’apport réel du service via les indicateurs agréés avec toutes les parties prenantes.

- La troisième raison, ce sont les constructions au fil de l’eau ou en silos. Un client interne exprime son besoin, à un besoin correspond une application et à une application, une équipe dédiée. Ces constructions mènent à des architectures d’intégration compliquées avec des connexions à droite à gauche, sans infrastructure d’intégration qui faciliterait l’insertion de nouveaux services dans une architecture d’ensemble. Les interfaces sont vraisemblablement en mode point à point, asynchrone, et l’intégration de toute nouvelle application – éventuellement héritée du rachat ou de la fusion avec une autre structure – nécessite d’écrire une interface par échange de flux. En outre, les équipes ignorent les redondances puisqu’elles ne disposent pas de vision transverse des processus. Les fonctions se recouvrent et les données se dupliquent car il n’y a en général pas de recherche de mutualisation ou de réutilisation. La multiplication des applications implique souvent des opérations lourdes de dé-doublonnage de bases ou de fichier clients. Certains utilisateurs, pour manipuler plus rapidement les données dont ils ont besoin, en viennent à les gérer séparément dans des tableurs type Microsoft Excel qui n’apparaissent pas en tant qu’applications, ce qui fausse l’inventaire.

- La quatrième raison, c’est le manque de partage d’une vision commune du système d’information, en tant que patrimoine de l’entreprise. Ce qu’il fait actuellement, quel est son état d’obsolescence, à quoi il sert, comment il peut contribuer à la performance de l’entreprise, comment il peut l’aider à évoluer voire à innover. Le choix d’investir sur des projets nécessite de comprendre comment ils viennent compléter les applications existantes, selon les différents points de vue. Le ratio satisfaction du besoin sur coût ne peut se mesurer sans tenir compte de l’implication de toutes les parties prenantes dans la construction, le déploiement et l’usage du système et sans instaurer un lien permanent entre les enjeux de l’entreprise et l’évolution du système d’information.

Le DSI n’est ni omniscient, ni omnipotent

Si on considère que cela ressort de la responsabilité du DSI seul, ce dernier agirait comme un gestionnaire de patrimoine qui ne connaîtrait pas la valeur des actifs qu’il a en sa possession et les ferait évoluer indépendamment de l’environnement économique. La situation ne serait pas de tout repos. A contrario si on considère que le DSI n’est qu’un exécutant d’une stratégie sur laquelle il n’a pas voix au chapitre, cela conduit au développement d’applications sans logique de mutualisation ou de cohérence et sans prise en compte des contraintes de l’existant. Le DSI doit ensuite faire face seul aux difficultés à maintenir un ensemble cohérent qu’il ne peut améliorer qu’à condition de faire miroiter des réductions de coût, les seules sous sa responsabilité.

D’où un stress certain pour un DSI qui n’est ni omniscient, ni omnipotent. Il n’est pas omniscient car il ne connait pas tous les besoins à venir de l’entreprise, pas plus qu’il ne connait tous les facteurs exogènes (concurrence, changement de législation, …) qui devrait faire évoluer le système d’information. Sans dialogue concerté et approfondi avec les utilisateurs des services du système d’information existant, il ne mesure pas davantage ce qui est vraiment utilisé et n’a pas tous les moyens à sa disposition pour en quantifier la valeur. Cela supposerait qu’il connaisse tous les processus métiers de l’entreprise mieux que tous ceux qui les gèrent.

Le DSI n’est pas plus omnipotent au sens où il hérite d’un système d’information. Il ne peut décider brusquement de tout externaliser, de remplacer des applications par d’autres, d’en installer de nouvelles, sans avoir estimé le coût et la couverture de chaque application existante. Il ne peut agir efficacement qu’en connaissance de ses contraintes et des ses nécessités.

Pour éviter le stress et avoir un DSI efficace, la solution consiste à ne pas lui faire porter la responsabilité de l’évolution des systèmes d’information à lui seul. Pour cela, il faut que l’entreprise décide de mettre en place une gestion du portefeuille d’applications et une gestion du portefeuille projets avec des processus de décisions qui impliquent et responsabilisent toutes les parties prenantes.

La gestion du portefeuille d’applications (en exploitation) nécessite a minima une visibilité sur l’état des lieux du parc applicatif, et une réelle stratégie de maintenance incluant la maintenance préventive et la partie de maintenance perfective visant à l’amélioration de l’architecture du système, souvent simplement oubliées ou délaissées faute de temps et de budget.

La gestion du portefeuille projets (investissements) nécessite d’une part, d’analyser la valeur du service visé, d’autre part d’analyser comment chaque nouveau projet s’insère dans l’existant et en quoi il le fait évoluer en termes de couverture des besoins, de coûts, d’évolutivité, de cohérence. Notamment s’il y a possibilité de supprimer des applications obsolètes ou redondantes, ou de réutiliser des services existants.
Si ces deux portefeuilles sont bien gérés au niveau direction d’entreprise, et en transverse, le système d’information pourra augmenter sa valeur et le DSI diminuer son stress.

Le rôle du DSI n’est pas de chercher à tout savoir, ni même à savoir tout faire en interne, une fois ces portefeuilles mis en place. Ceux-ci lui permettront de mieux connaitre les enjeux, les contraintes et les usages. Dès lors, il pourra tenir un rôle qui dépendra cette fois de lui : comprendre les besoins, choisir et gérer au mieux la réponse, interne ou externe, tout en gardant cohérence à l’ensemble et en veillant à sa sécurité.