Si on voit bien la nécessité de passer par un « centre de services », à l’inverse, dans ce modèle, il faut être très prudent sur plusieurs aspects. Ainsi, réduire l’évaluation de la
performance informatique à la lecture des indicateurs d’un tableau de bord serait aussi dangereux que de se baser sur une satisfaction a priori
Le tableau de bord peut être « au vert », le service mauvais et les utilisateurs mécontents, si la définition des indicateurs n’a pas été faite en collaboration avec toutes les parties prenantes, et les mesures, significatives. La consolidation d’indicateurs est importante en ce sens.
Si la DSI mesure sa performance en termes de délais de temps de corrections des anomalies, elle n’aura pas une vision de l’impact utilisateurs. Une anomalie dite critique sur une application peu utilisée n’a pas le même poids que sur une application fréquemment utilisée, mais si cette application peu utilisée est elle-même critique, une seule anomalie sur une fonction essentielle peut induire des risques supérieurs que dans des cas fréquents d’utilisation, etc.
De même, si une anomalie est rapidement corrigée, cela ne signifie pas que la correction est de qualité. La pression des délais conduit souvent les techniciens de maintenance à effectuer des « copier coller » de code avec, en conséquence, des codes « obèses » de plus en plus difficiles à maintenir. Sans indicateurs de qualité, la rapidité de corrections peut être à double tranchant.
Il y a également un nécessaire devoir de marketing de la DSI, qui ne se réduit pas à une prestation tarifée « client-fournisseur » : celui d’être à l’écoute de ses clients pour leur proposer les bons services, et celui de les informer au mieux des services existants et d’en améliorer continuellement la qualité.
C’est une évolution vers l’anticipation des bons services qui ne peut se produire qu’à condition d’avoir des relations de confiance entre la direction générale, les directions métiers et la DSI.
Quant à la refacturation interne, elle doit privilégier des unités d’œuvres définies avec les métiers et adoptés par eux, et lisser autant que faire se peut les coûts des services transverses.
Pour exemple, il serait catastrophique de faire payer au premier projet métier le surcoût d’investissement initial d’une architecture SOA.
Il faut donc prévoir une logique d’abonnement, comme pour les offres Saas, où tous les clients bénéficient de la mutualisation, le modèle économique se basant sur le volume, plutôt qu’une facturation excessive aux premiers clients qui, de surcroît, ne bénéficieront pas tout de suite des bienfaits de la rationalisation d’une architecture, ces derniers portant sur la réutilisation ou l’intégration.
Dans le cas contraire, on s’expose à la mise en œuvre de solutions de contournement. Ainsi, un grand groupe international avait mis en place une structure interne type
« centre de services » pour le déploiement et l’utilisation d’un
EAI (Enterprise Architecture Integration) dans toutes les filiales du groupe.
Les filiales étant refacturées pour chaque application connectée à l’EAI sur la base d’indicateurs non métiers et sur une facturation supérieure à ce que leur aurait coûté une intégration point à point, ce dernier mode d’intégration s’est répandu, non officiellement mais rapidement, dans le groupe.
Chapitre 7 Les enjeux et défis de pilotage
"La liberté consiste à être gouverné par des lois et à savoir que les lois ne seront pas arbitraires".
Montesquieu Mot-clé du chapitre (balisage sémantique)
Mot-clé du chapitre (balisage sémantique) Mot-clé du chapitre (balisage sémantique)
Nous avons vu précédemment que le DSI entre « réduire les coûts et investir » disposait d’une marge de manœuvre étroite, et risquait de se retrouver coincé dans un engrenage figé, si la rationalisation des coûts ne permettait pas de réinvestir dans d’autres projets informatiques. En réalité, sa marge de manœuvre dépend de sa capacité à rendre le S.I. lisible, c'est-à-dire à expliciter et valoriser les services fournis, ou l’impact de ceux demandés.
Pour cela, il se trouve confronté à plusieurs défis, dont quatre principaux que nous détaillerons dans ce chapitre.
En premier, rendre le SI intelligible. La méconnaissance de ce que fait l’existant et comment, n’aide pas à optimiser les coûts récurrents. Cette méconnaissance est structurelle car elle est due à un système de construction des SI où la gestion des connaissances et les concepts d’urbanisation n’ont pas été suffisamment pris en compte. Le chapitre suivant détaillera davantage ce défi, mais force est de reconnaitre que sans visibilité sur son parc applicatif, les
contrats liés, les coûts dispersés, le DSI peut difficilement actionner les dispositifs de mutualisation, d’externalisation, de data centers ou de rationalisation des applicatifs et/ou des contrats fournisseurs.
En second, la maîtrise des coûts et du budget.
Les coûts informatiques sont rarement bien gérés, à la fois pour des raisons historiques et organisationnelles. Le DSI lui-même n’a pas forcément tous les coûts liés aux Systèmes d’information sous sa responsabilité directe, mais ce qui est plus gênant, c’est quand il n’en a pas non plus la visibilité globale, notamment pour les coûts afférant à la maîtrise d’ouvrage ou les coûts cachés de non productivité des utilisateurs, par exemple. Sans connaissance étayée des coûts des services, il est illusoire pour le DSI de vouloir gérer son budget comme celui d’un compte d’exploitation, ce qui est toutefois nécessaire pour inscrire la direction des Systèmes d’information comme une direction métier.
Il s’agit donc de connaitre les coûts, mais pour qu’ils aient un sens (sont-ils trop élevés ou non ? Faut-il les réduire ou au contraire investir ?) en tant que paramètres de décision du budget de la DSI, connaitre le « coût » d’un service ne suffit pas. Il faut également dans l’évaluation des services fournis, faire entrer la nature et le niveau de qualité des services ainsi que leur contribution à la valeur de l’entreprise, aussi bien immédiatement que dans le futur.
En troisième, optimiser la relation avec les autres directions L’implication des utilisateurs métiers dans la conception, la réalisation, l’évolution, le pilotage des systèmes d’information est un facteur clé de succès des services fournis et une condition indispensable pour pouvoir réellement les valoriser. Pour autant, cette implication ne se fait pas sans difficulté, faute du dialogue adéquat entre les parties prenantes au bon moment ou faute de prendre le temps de ce dialogue sous prétexte de coût ou de lourdeur immédiats, ce qui ne fait que reporter ces coûts en les multipliant à d’autres moments.
Certes, l’intervention d’une direction générale (DG) en sponsor des S.I., a contrario d’une DG indifférente, facilite le dialogue. Il reste toutefois à formaliser plus clairement les processus et les instances de décision, les rôles et les responsabilités des uns et des autres pour que la relation, bâtie sur la connaissance des engagements de chacun, se fasse sereinement.
En quatrième, gérer efficacement les ressources et moyens La gestion de projets informatique n’est pas une science exacte.
En partie en raison des trois défis précédents, car la méconnaissance de l’existant, le manque de sponsoring de la direction générale, l’insuffisance d’implication des utilisateurs aux
moments appropriés, notamment pour définir les objectifs et le périmètre métier, le non suivi des coûts globaux, sont autant de facteurs engendrant des dérapages en coûts et délais des projets. Il en résulte également beaucoup d’insatisfaction quant à la couverture fonctionnelle et la qualité des résultats obtenus.
Mieux gérer les projets informatiques est donc un défi d’amélioration en termes de moyens de la DSI, laquelle a également un potentiel d’amélioration dans la gestion de ses propres processus et ressources, humaines et matériels, qu’elle peut partiellement optimiser grâce à l’utilisation des meilleures pratiques, méthodes ou référentiels, de la profession.