23 Avr 2008 |
|
Parmi les utilisateurs d'informatique en entreprise, certains ont l'impression d'être moins bien servis que d'autres... Et c'est parfois le cas. La qualité de service d'une DSI dépend notamment de son expérience avec telle ou telle direction métier. La DSI a une meilleure connaissance de ses utilisateurs dès lors qu'elle a déjà réalisé plusieurs projets avec eux. Au cours de cette expérience, la direction informatique s'imprègne du métier et de ses besoins, de ses priorités, de ses automatismes, de son workflow, de sa culture. Les DSI sont de plus en plus rompues à cet exercice et deviennent parfois assez efficace dans la phase d'apprentissage. On trouve, au sein des DSI à différents niveaux, de plus en plus de gens dont le job est d'être à l'écoute des besoins des métiers : •- - les informaticiens sont parfois d'anciens consultants, habitués à changer d'environnement et en particulier à travailler avec de nouveaux métiers •- - les business analysts étudient finement les besoins et traduisent pour les développeurs •- - les Delivery Managers, plus rares, assurent la direction de projets en même temps que la relation avec utilisateurs (sorte de relation client au sein de la DSI) •- - le Directeur informatique lui-même est peut-être un ancien du métier, plutôt qu'un informaticien En revanche, le métier a souvent du mal à comprendre qu'il doit lui aussi faire des efforts et que la réussite d'un projet dépend aussi de lui. Un métier qui n'a pas vraiment travaillé avec la DSI ne prend pas toujours au sérieux la valeur ajoutée potentielle des directions informatiques. Le métier doit passer une suite de paliers successifs. Les premiers rapports avec la DSI n'incitent pas à l'engouement quand le métier aborde l'informatique d'entreprise avec l'œil du bricoleur domestique. De plus en plus de gens ont déjà installé chez eux un ordinateur, des logiciels ou une connexion à Internet: sans être informaticiens, ils s'en sont bien sortis. Aussi sont-ils parfois agacés de la qualité de service dans leur environnement professionnel: qu'il s'agisse de la qualité des réponses du support informatique sur des applications bureautiques supposées connues ou une question a priori anodine sur la synchronisation d'un PDA fourni par leur employeur... Si le métier demande à la DSI un service qui sort de l'ordinaire, elle a tout à coup l'impression de faire l'objet d'un interrogatoire et le ton monte « Je ne comprends pas, nos concurrents utilisent tous ce logiciel, c'est indispensable pour nous! » Si le métier franchit une étape supplémentaire et lance un projet, le mythe de l'informatique plug & play s'effondre définitivement. D'une part, le métier va passer beaucoup plus de temps que prévu sur le projet. Après tout, il a exprimé ce qu'il voulait. Maintenant ce qu'il attend c'est juste une date de livraison. Il reçoit une proposition très détaillée qui ne donne pas envie à lire. Quand finalement il trouve le temps et le courage de la lire, il se rend compte qu'elle comporte plein de questions et qu'il va encore falloir y passer du temps. La DSI propose plusieurs options, mais aucune n'est complètement satisfaisante en termes de contenu, de délai ou de coûts. Quand le projet est livré, enfin, le métier constate que certaines choses posent problème. La réponse de la DSI est inlassablement la même : « vous ne nous avez jamais spécifié ce point dans vos besoins ». Pour le métier, l'outil livré est inexploitable en l'état : il faudrait procéder à des ajustements. De son côté, la DSI fait le point sur le temps passé, les ressources consommées, les messages contradictoires des utilisateurs. Elle se demande si, au lieu de dépenser l'argent de l'entreprise sur des projets aussi mal définis, il ne vaudrait pas mieux tout arrêter. L'arbitrage monte en haut lieu. Finalement, on décide de continuer le projet avec une enveloppe budgétaire complémentaire, l'utilisateur s'engage à communiquer un besoin stable, la DSI s'engage à réaliser le besoin, on nomme un nouveau directeur de projet accepté par l'une et l'autre partie qui rapportera à la direction générale. Et pour la pochaine fois, on nomme décide de renforcer la fonction "maîtrise d'ouvrage" sur les projets. Fort de cette expérience, la DSI et le métier se sont dotés d'un « traducteur » : quelqu'un qui fera l'interface entre les utilisateurs de l'outil, qui consacreront peu de temps au projet, et les développeurs qui produiront les solutions techniques. La question est à présent de savoir de qui va dépendre cette maîtrise d'ouvrage. Trois solutions sont possibles : •- 1. La maîtrise d'ouvrage est rattachée au métier. L'avantage est l'intégration, la proximité avec le métier. L'inconvénient est que le métier n'est pas toujours en mesure de gérer cette maîtrise d'ouvrage ou que cette maîtrise d'ouvrage ait par ailleurs des fonctions opérationnelles et il y a fort à parier qu'elle devienne un goulot d'étranglement sur les projets. •- 2. La maîtrise d'ouvrage est rattachée à la DSI : elle est entièrement dédiée aux projets. Elle est mutualisée sur plusieurs métiers. Le problème est que tel ou tel métier se plaint de son manque de disponibilité ou de son manque de connaissance du contexte. •- 3. Il existe une direction maîtrise d'ouvrage indépendante, on trouve cette organisation parfois dans le milieu bancaire. L'avantage est qu'elle est professionnelle, rompue aux relations avec les métiers et aux projets. L'inconvénient majeur est que sa position, entre le marteau et l'enclume, est difficilement tenable politiquement sur la durée. D'une part en tant que traducteur (l'adage dit « traduire, c'est trahir »), entre celui qui a le besoin et celui qui livre la solution, sa valeur ajoutée n'est pas toujours perceptible, au contraire elle sera accusé d'être à la source de tous les malentendus. Par ailleurs elle complique l'innovation technologique : la DSI a perdu son lien direct avec les utilisateurs et ne sait pas dans quelles mesures une innovation technologique sur le marché peut apporter de la plus value à l'entreprise. L'entreprise peut rapidement se faire distancer par ses concurrents sur ce plan. |