Quand on intègre le service informatique d’une grosse et vénérable compagnie industrielle, on vous fait rapidement comprendre que le cœur de métier, la valeur de l’entreprise réside dans la manufacture et la vente de son produit phare, pas dans son SI. Fair enough.
Cependant, cet état de fait devient problématique lorsque cette même société décide d’opérer une transformation digitale de son activité. Car une transformation digitale coûte cher, en temps comme en ressources. Elle peut s’avérer risquée à de nombreux égards (mauvaise identification des besoins, mauvaise qualification des solutions, changements hasardeux et précipités, manque de connaissances et compétences etc) et, mal maîtrisée ou prise trop tard, peut même faire pâtir le produit final (voir le cas d’école Jaeger, qui illustre pourquoi cette transformation est nécessaire, mais on peut également citer Kodak, Nokia et même dans une certaine mesure Boeing et Microsoft).
Jaeger, un style aussi désuet que leur stratégie digitale
Dès lors, il devient compliqué de cacher son dédain (spirituel mais surtout financier) envers l’IT en invoquant la priorité au produit final. Car si, dans les industries traditionnelles, l’informatique n’intervient pas (ou peu) dans la réalisation de ce dernier, elle en est en revanche le premier support, du bureau d’étude à la livraison. On ne peut donc plus décemment renier aux services informatiques leurs besoins grandissant d’investissement et décorréler la valeur du service qu’ils apportent de celle du produit qu’ils servent. Tout est lié.
« Oui mais… Je tiens à mon argent. Je veux le faire prospérer. J’ai l’habitude de calculer le coût de mon produit. Après tout, il ne s’agit que de la somme de ses matières premières, des coûts humains, énergétiques, d’outillage et de R&D. Je sais aussi calculer et appliquer un coefficient à ce coût pour en dériver ma marge minimale pour que mon entreprise florisse. Je sais à quoi m’attendre. Ça fait 30 ans que la formule ne change pas. Qu’en est-il d’un service (stricto sensu) informatique ? »
Mais seulement si vous pouvez me prouver que ça en vaut le coup !
Car si nous vivons maintenant dans une société d’innovation et de startups, que l’on valorise à perte sur parfois pas beaucoup plus que quelques slides, le financier industriel a besoin de preuves concrètes pour être rassuré et justifier ses investissements. Il veut des chiffres. Il veut pouvoir projeter un rendement et une marge sur courts, moyens et longs termes. Il veut un retour sur investissement.
Si mon ton parait moqueur ou méprisant, croyez bien qu’il n’en est rien. Dans un monde capitaliste, une société existe pour prospérer et gagner de l’argent, pour son bien comme celui de ses employés. Et quand l’on constate les travers et débordements de certaines startups (voir la débâcle Theranos ou celle bien plus amusante mais pas moins scandaleuse de Juicero), on se dit qu’il y a un intérêt certain à savoir où l’on met ses sous. Oui mais voilà…
Qui n’a jamais rêvé d’un presse-fruit (et je suis indulgent) à 400$ ?
L’exercice se prête très bien à des processus éprouvés et des produits industriels dont l’évolution est maîtrisée (car lente). En revanche, il est très difficile de l’appliquer à des produits innovants qui se renouvellent constamment et de plus en plus rapidement, tant les technologies et les compétences changent. Ajoutez à cela un focus très fort sur le besoin utilisateur, mouvant et absolument contre-intuitif pour un développeur, et vous obtenez la formule parfaite pour complexifier à l’infini un calcul de ROI.
Mais là où le calcul d’un ROI devient particulièrement compliqué, c’est dans une transformation digitale et, plus précisément, dans une transformation DevOps. Pourquoi me direz-vous ?
- Si vous lisez ces mots, il y a des chances que vous ayez conscience des difficultés derrière le déploiement de tels changements, tant ils sont transverses et profonds. Ils nécessitent souvent la refonte complète des organisations, le déploiement de nouveaux outils et process allant même jusqu’à la remise en cause des modèles financiers. S’il est assez aisé de calculer un retour sur investissement à l’échelle d’un produit et de ses composantes (humaines, fonctionnelles et matérielles), il est bien plus difficile de l’opérer sur l’ensemble des produits d’une structure. Car chaque produit est unique, a des besoins spécifiques, des individualités et une culture d’équipe particulières, des habitudes différentes… Il n’est donc pas possible de faire un calcul à l’échelle d’une organisation globale tant les paramètres sont multiples, dans leurs nombres comme leurs dimensions, et intriqués de la perspective du produit final. Si je déploie un nouvel outil de gestion du backlog sur l’équipe de développement des badges de cantine, quel sera l’impact sur le prix de ma voiture/avion/produit d’alimentation ? Bonne chance…
- La transition DevOps est notoirement coûteuse à mettre en place. Et ses effets ne se voient qu’au fil du temps, la maîtrise progressive des outils amenant l’accélération, la qualité et finalement les économies attendues. Un peu comme ce qu’on observe d’ailleurs avec le passage à Agile (nous en reparlerons dans un prochain article). Ainsi, si DevOps est promesse de retours sur investissement, ces derniers ne se dessinent que sur le long terme. Ils sont, de plus, durs à estimer sans un travail très consciencieux de définition des priorités et des objectifs, tant le champ opérationnel de DevOps est potentiellement large.
Facile… Laissez faire les pro
Cette complexité représente un grand challenge dans notre travail. Car être un agent du changement, c’est savoir l’adapter au besoin des gens et les en convaincre. C’est abattre la résistance au changement. Et cette dernière n’hésite pas à se jeter sur n’importe quel argument pour justifier du statu quo.
Et le ROI en est un particulièrement difficile à surmonter. L’absence de retour sur investissement à court et moyen terme, le travail en amont réclamé pour identifier les priorités et les objectifs, la somme et les exigences demandées pour le mettre en place, la difficulté de faire des projections réalistes à long terme… Autant d’arguments derrière lesquels se cacher pour ne pas avoir à changer. L’argent restant le nerf de la guerre, il s’agit souvent de LA carte à abattre pour dérailler toute volonté de transition DevOps.
Alors que faire ? Car, encore une fois, une exigence de ROI en soi n’est pas injustifiée. Face à une entité qui attend de telles informations pour déclencher sa transformation, quelle réponse apporter ?
- Puisque DevOps ne délivre sa toute-puissance qu’au fil des itérations, faites un POC. Commencez petit sur un seul et unique petit produit, où les besoins et attentes sont bien plus maîtrisables, où les implications sont moindres. Vous pourrez alors effectuer un calcul réaliste du retour sur investissement espéré et prouver par l’exemple
- Appuyez-vous sur l’expérience de l’industrie digitale. Il existe de nombreux exemples d’implémentations réussies de DevOps. Alliez ces exemples à votre rhétorique pour convaincre par les faits, pas par les promesses
- Faites des approximations grossières, cédez au ballpark estimate. Ça fonctionne !
Encore une fois, il n’est pas question de dévaloriser la notion de ROI. Bien au contraire. Lorsqu’une organisation DevOps commence à tourner, ses effets sont tellement visibles et positifs qu’il y a tout intérêt à mettre en place des indicateurs de performance afin d’en dériver les gains (pour mieux les réinvestir dans la qualité, l’innovation ou un babyfoot). Seulement, cela ne pourra se faire que dans le temps. Pas initialement.
Face à des exigences de ROI, il n’y a pas de solution miracle. Chaque personne, chaque situation est différente et apporte son lot de questionnements. Il faut faire preuve d’astuce afin de contourner ce problème qui, bien trop souvent, paralyse des prises d’initiative et sert de bouclier anti-changement plus que de réelle préoccupation. Sur ce, je vous laisse, faut que j’aille expliquer à quelqu’un qu’utiliser Ansible pour déployer 2 changements par an n’est peut-être pas l’action la plus optimisée de l’année.
Mais tu vas changer oui ?!