La DSI, comme tout fournisseur de services, prend des risques à ne pas formaliser clairement sa relation client-fournisseur avec les autres directions de l’entreprise, quitte à établir des contrats de service, en précisant les attendus clients, l’engagement de niveau de services, voire des modes de refacturation en interne.
Car sinon, ce n’est pas seulement la DSI, mais toute l’entreprise qui subiront les conséquences de la non formalisation dont :
Manque de visibilité des services rendus par la DSI,
Niveaux d’engagement de services mal formalisés d’où réduction de coûts nuisibles à la qualité,
Abandon ou dérapage de projets coûteux,
Gestion du court terme de la demande fonctionnelle, pas d’évolution des systèmes existants jusqu’à ce que l’évolution soit une nécessité coûteuse impliquant des investissements dans l’urgence,
Désalignement progressif du Système d’information avec les enjeux d’entreprise.
Comment ça marche ?
La contractualisation des services
Si la DSI est perçue comme un fournisseur de services dans bon nombre d’entreprises, la relation « client-prestataire de services » est rarement formalisée dans un contrat.
Pour autant ce dernier a pour objet de clarifier les conditions opérationnelles de la fourniture de service. Ainsi pour une application en exploitation, le contrat décrit le niveau de fonctionnement et de support auxquels le prestataire fournisseur du service s’engage vis-à-vis de l’utilisateur. Lequel reconnaîtra dans ce contrat explicitement connaitre le cadre d’exploitation de l’application et les limites du service fourni.
Ce contrat a pour mérite de ramener les « coûts » de l’informatique a un référentiel de mesure qui permette de les qualifier en fonction du niveau de service rendu et non de manière intrinsèque, comme dans un ratio de type coût de l’exploitation rapporté au poste de travail qui ‘na pas de sens. Une application qui doit fonctionner 24h/24, 7j/7, n’a pas les mêmes contraintes de disponibilité que les autres, et son coût de développement ET de fonctionnement en est tributaire.
Ainsi les niveaux de services formalisés dans le contrat peuvent prendre en compte les plages horaires du support, les performances attendus, le niveau d’assistance fonctionnelle à l’utilisation, les temps de correction en cas d’anomalies et selon leur nature, temps de rétablissement du service en cas de panne, les sauvegardes, les fonctionnements en mode dégradé, etc. Tous sont autant de paramètres qui influent sur les coûts.
Le contrat formalise également les indicateurs qui vont permettre de suivre l’engagement de services, et les modalités de revues de ces engagements.
Ce sont des pratiques courantes en infogérance qui peuvent être reportées sur l’exploitation et la production interne. Le terme anglo-saxon qui s’est répandu pour désigner ses engagements de niveaux de service est SLA (Service Level Engagment).
Si le client n’a pas à s’engager sur le coût des investissements pour un projet, s’il n’est pas tenu de contribuer au coût de fonctionnement des services qu’il utilise, s’il n’a pas à clarifier dans ses demandes d’évolution ou de changement le gain attendu, et justifier de ses enjeux, le champ des demandes peut être infini.
La DSI ne sera pas en mesure de faire le tri, ne disposant pas des critères qui pourraient le lui permettre, et répondra de manière réactive en fonction des pressions exercées, pas en fonction des axes de développement stratégiques pour l’entreprise.
On verra les coûts de la DSI, pas les profits, d’autant qu’ils seront difficiles à obtenir dans ces conditions.
En effet, les applications développées ne seront pas alignées sur les véritables enjeux consolidés au niveau de l’entreprise, puisque réalisées au coup par coup des pressions souvent accompagnées de délais irréalistes par méconnaissance des contraintes de réalisation.
Quant aux applications existantes patrimoniales comment évaluer leur valeur et les risques liés à leur obsolescence (donc a fortiori les éventuels efforts à faire pour remédier à ces risques) si on a peu ou prou d’idée de ce qu’il coûterait à l’entreprise « à faire sans » ?
L’enquête Sapientis déjà évoquée le montre ici également, il y a un potentiel d’évolution extrêmement important dans le fonctionnement des organisations sur ce point.
MoyenPilotageAmélioration.png Légendes figurant dans l’image
Figure 7-6.
Moyens de pilotage estimés à améliorer
Source observatoire « Modernisation des SI et maturité des entreprises » Copyright Sapientis
Sans l’implication des métiers commanditaires dans la définition de ce qui est attendu d’un projet d’investissement, il a une forte probabilité d’être voué à un échec onéreux et nous y reviendrons dans les chapitres suivants. Mais l’implication ne suffit pas, encore faut-il que le commanditaire s’engage à porter tout ou partie de l’investissement du projet, et le coût de fonctionnement du service ensuite, au prorata de son utilisation (s’il est le seul utilisateur la « facture » globale lui incombe).
A partir de là, il sera plus prudent dans ses demandes et s’interrogera sur les indicateurs de réussite du projet demandé. Car aucun client n’est naturellement prêt à payer pour le fonctionnement d’un service dont il n’arrive pas à mesurer les gains à son niveau, sauf à être dans l’obligation légale de le faire. A quoi verra-t-on le changement par rapport à l’existant ? Comment mesurera-t-on le succès du changement ? Comment illustrer concrètement le changement ?
Le rôle de la DSI n’est pas de répondre à ces questionnements, c’est le rôle du commanditaire du projet de se les poser avant le lancement en prenant bien soin, comme nous l’avons évoqué précédemment, de s’entourer du conseil pertinent pour trouver les réponses et de définir à leur suite les bons indicateurs métiers qui pourront être suivis opérationnellement par la suite.
Si les utilisateurs des services rendus par l’informatique ne sont pas responsabilisés en amont de leur développement, il y a fort à parier que la DSI devra les solliciter ensuite, avec peu de succès, pour retrouver la lisibilité du service rendu, comme le montre cette autre figure extraite de l’enquête Sapientis.
Implicationutilisateurs.png Légendes figurant dans l’image
Figure 7-7.
Implication des utilisateurs dans les indicateurs métiers Source observatoire « Modernisation des SI et maturité des
entreprises » Copyright Sapientis
La refacturation des coûts de fonctionnement par la DSI à ses clients, en fonction de leur utilisation des services, ou tout autre moyen de corréler les coûts à l’usage et aux gains, c'est-à-dire de valoriser les services, aura au moins un effet vertueux. Les utilisateurs seront plus enclins à ne réclamer que le niveau de qualité dont ils ont réellement besoin. Ce qui limitera drastiquement des fausses contraintes de disponibilité 24h/24, par exemple, en raison des surcoûts induits ou, à contrario, obligera à définir les niveaux de criticité pour chaque application et le niveau de maintenance préventive.
De plus, mettre cette valorisation sous la responsabilité des métiers, induira également un bilan du projet sur la base
d’indicateurs vérifiables définis en amont. On pourra vérifier les prévisions de rentabilité du projet et progressivement construire un référentiel pour juger de la crédibilité des estimations de gains liées aux demandes, au regard des coûts et résultats réels. Sinon, les estimations resteront déclaratives et sans engagement, laissant les projets risquer les échecs et la DSI en porter le poids.