Quiconque s’intéresse aux principes du Lean Management sait qu’il doit identifier les principaux « flux de valeur » de son organisation, à savoir l’ensemble séquentiel d’activités nécessaires pour créer et livrer au client une famille de produits et services ayant une valeur pour lui. Et pour chacun d’eux, il doit identifier la « voix du client », à savoir les attentes fondamentales du client pour cette famille de produits ou services.
En déclinant cela sur les Directions informatiques, quels sont les flux de valeurs types d’une DSI ? Même s’il appartient à chacun de définir une vision qui lui est propre de ses flux de valeurs, nous pensons que la plupart des DSI, quel que soit leur secteur, peuvent penser leur activité au travers des 4 flux suivants :
- Faire des études (préparer et imaginer les futurs possibles)
- Délivrer des nouvelles fonctionnalités logicielles
- Maintenir le système d’information en conditions opérationnelles
- Gérer le parc bureautique et matériel
Cette typologie n’a rien de fondamentalement originale mais a le mérite selon nous, de distinguer les services fondamentaux de la DSI en se plaçant du point de vue de ses clients.
1. Faire des études
Ce flux de valeur est peut-être le plus « original » dans le sens où de nombreux DSI peuvent penser les études comme la première étape du processus de développement. Or elles n’obéissent pas aux mêmes rythmes, ni aux mêmes impératifs que le projet. Ce ne sont d’ailleurs parfois pas les mêmes clients, l’étude se traitant au niveau stratégique, quand le projet se traite souvent à un niveau plus opérationnel. Les 2 écueils les plus fréquents sur les études sont :
- ne pas en faire. La DSI est un service technique qui se contente de lancer un projet dès qu’un responsable métier a une idéé
- pour caricaturer : « arrêter l’étude à la fin des spécifications détaillées », c’est-à-dire surinvestir dans cette phase.
La vraie valeur ajoutée de cette activité : étudier les possibles et donner une estimation macro des coûts, des gains attendus, et des conditions de faisabilité des projets afin de décider si l’investissement est opportun ou non. Pour viser l’excellence, ce flux de valeur suppose en amont qu’une partie de l’énergie de la DSI soit consacrée à la veille technologique, afin de prendre en compte les innovations du marché lors de la réalisation des études.
2. Délivrer les nouvelles fonctionnalités logicielles
Le client est généralement la Direction Métier à l’origine du projet (et qui souvent le finance). Ici, la valeur se mesure non seulement par le respect des délais et du budget, mais aussi par la mesure de l’appropriation par les utilisateurs et des gains générés. Notre expérience conduit à proposer quelques bonnes pratiques :
- Lotissez vos projets et vos évolutions en paquets de taille homogènes en termes de délais et de charges (quoi que vous en pensiez, c’est presque toujours possible)
- Utilisez le « First In, First Out » en ce sens ou le premier lot à avoir le go doit être le premier prêt pour la mise en production
- Gérez par les délais
- Versionnez vos mises en production pour mutualiser l’impact des changements sur la production et sur les utilisateurs
- Rendez les ressources travaillant sur le processus de delivery le plus polyvalentes possible (évitez les cols blancs / cols bleus)
- Ne négligez pas la conduite du changement auprès des utilisateurs
3. Maintenir le système d’information en conditions opérationnelles
Ici il s’agit de répondre aux mieux à la demande simple du client utilisateur : « je veux que ça marche ». Donc, si j’ai un problème ou une question, je veux une réponse rapide, et par ailleurs, je veux le moins d’incidents possibles. L’efficience passe ici par une capitalisation sur les problèmes les plus fréquemment rencontrés, afin de traiter le plus d’incidents possibles au premier niveau (help-desk, supervision). La question délicate à traiter est souvent la fluidification du processus entre ce premier niveau et les experts en niveau 2 ou 3. La mise en place d’une gestion des problèmes est également un facteur essentiel d’excellence.
4. Gérer le parc bureautique et matériel
Enfin, la fourniture des matériels aux utilisateurs peut parfois être isolée comme un flux spécifique dont les mécanismes sont proches de ceux d’une supply chain. Du point de vue du client, on peut toutefois aussi le fusionner pour l’analyse avec le 3e flux.
Bien sûr, sous ces flux, on retrouve des processus sous-jacents tels que décrits par ITIL ou d’autres référentiels. L’idée du Lean Management est de tirer la mise en place de ces processus par le besoin du client, plutôt que de les pousser par les contraintes des producteurs.
J’apprécie particulièrement le point de vue sur le premier flux, manière originale et à mon avis pertinente, de présenter cette chose que tant de DSI ne font pas : de la veille prospective, proactive.
En ce qui concerne le maintien en conditions opérationnelles, je suis toujours effaré pour ne pas dire scandalisé, de voir que tout le monde considère comme allant de soi qu’une application coûte, chaque année, entre 10 et 20% de son coût de construction.
Car, à la différence d’une voiture, point d’usure physique.
Qui trouverait normal de payer 100 EUR par an pour que sa TV continue à fonctionner ?
C’est pourquoi, sur ce troisième flux de valeur, je milite pour que, dès les études d’opportunité, les décideurs cadrent le coût de MCO, complet tant qu’à faire, d’un SI, et conçoivent ce dernier de manière à rester dans ce cadre de coûts. Quitte à en sortir en connaissance de cause.
En conséquence : les budgets de « run » sont prédictibles, et la fuite en avant cesse.
Ayant travaillé chez un constructeur automobile, les projets véhicule, dès les phases très amont, étaient ainsi cadrés. Tout écart de plus de 5% du coût du projet lors des phases de mise en oeuvre nécessitait une revue en COMEX.
à quel écart constaté en fait-on autant pour un projet SI ?
Je pense que c’est à ces conditions que cette professions arrivera à atteindre une bonne efficience, plutôt que de chercher de la main d’oeuvre à bas coûts en Asie ou en Afrique.
« Car, à la différence d’une voiture, point d’usure physique.
Qui trouverait normal de payer 100 EUR par an pour que sa TV continue à fonctionner ? »
Je me permets de rebondir sur cette affirmation. Certes une application ne connaît pas d’usure physique, mais elle connaît deux types d’imprévus, que je qualifierais « d’usure Métier » et « d’usure technique » :
– L’usure Métier se manifeste dans l’évolution des besoins métiers. Même en développant une application répondant parfaitement aux besoins à l’instant t, il ne faut pas oublier que le besoin peut évoluer à mesure de la vie de l’application. Un téléviseur ou une voiture ne sont pas évolutifs. Quand on n’en est plus content, on en change.
– L’usure Technique se manifeste de plusieurs manières. Il y a d’abord la correction des bugs présents lors de la 1e livraison, puis la correction des bugs issus des évolutions. Il peut également y avoir besoin d’adapter les infrastructures pour soutenir des évolutions de charge.
Alors bien entendu, en développant « proprement » dès le départ, et en anticipant d’éventuelles évolutions Métier pour faciliter les développements ultérieurs, on doit pouvoir limiter le budget de « run », mais celui ci connaît malgré tout plus d’incertitudes que dans d’autres domaines.
Maintenant nous sommes d’accord, certaines applications ont des coûts récurrents de run beaucoup trop élevés, souvent liés à un mauvais développement initial.