Loading...Dans un précédent article, nous avons présenté le concept de coût total de possession (connu sous le sigle TCO, pour Total Cost of Ownership) des produits digitaux et expliqué en quoi il s’agissait d’un facteur essentiel dans la prise de décision du CTO. Nous allons ici approfondir la notion de coût total de possession et examiner comment et pourquoi les CTO en ont une approche différente. Nous verrons également en quoi l’implication d’un DSI peut avoir un impact et comment vous pouvez vous préparer au TCO (tout en étant conscient des coûts cachés).
TCO et typologie des CTO
Le coût total de possession implique la responsabilité du CTO. Mais la manière dont les CTO abordent cette question peut différer selon le type de CTO.
- Le CTO « grand penseur », qui prépare de nouveaux axes opérationnels ou travaille sur de nouveaux modèles commerciaux, aura besoin d’estimations de TCO de haut niveau.
- Le CTO « gestionnaire des infrastructures », qui essaie de promouvoir les technologies dans les différentes business units et entités, appuiera son processus de prise de décision sur les estimations de TCO établies sur 3 ans avec un niveau important de détail.
- Le CTO « visionnaire », qui gère la technologie en expert du produit et/ou du développement, généralement un cofondateur, aura tendance à ignorer le TCO au profit d’une Vision.
- Le CTO « centré sur les technologies tournées vers l’extérieur » se saisira rapidement du concept de TCO qui deviendra un argument commercial intéressant ou une part essentielle de sa mission de conseil.
Dans tous les cas et quel que soit le type de CTO en place, le TCO reste important. Si les décisions d’un CTO sont généralement excellentes, le TCO ne viendra que les conforter davantage.
CTO, DSI et TCO
Parfois, le CTO se partage l’espace technologique de l’entreprise avec le DSI. Dans ce cas, le principal défi est de s’assurer que l’entreprise ne dispose pas de deux architectures concurrentes (loi de Conway inversée). S’ils sont au même niveau hiérarchique, cela pourrait entraîner la coexistence de définitions différentes du TCO.
Il ne devrait toutefois y avoir qu’une seule et unique définition du TCO. Les informations relatives au TCO doivent être identiques et accessibles à tous les dirigeants. Le CTO et le DSI doivent veiller à ce qu’il n’y ait qu’une seule architecture de système d’information. Cependant, même si le TCO semble être un très bon outil pour calibrer les attentes entre CTO et DSI, je ne me souviens pas avoir jamais vu la mise en œuvre totalement satisfaisante d’une telle organisation.
L’autre scénario possible serait que le CTO rende des comptes au DSI. Peu importe qu’on la juge bonne ou mauvaise, cette approche impliquerait en tout cas le transfert de la responsabilité du TCO au DSI. Cela pourrait être une bonne chose en ce sens que les DSI sont formés et coutumiers des analyses coût-avantage. Élargir le savoir du DSI au TCO ne devrait pas être un problème.
Appréhender le TCO
| Le TCO est | Le TCO n’est pas |
|---|---|
| Un exercice qui doit améliorer la prise de décision à long terme (poser les bonnes questions au bon moment) | Le seul ingrédient nécessaire à une bonne prise de décision |
| Un accélérateur de prise de décision | Un processus long et lent (n’a pas à l’être) |
| Une responsabilité placée sous la direction du CTO (pour les initiatives technologiques) | Une responsabilité collective (pour l’équipe technologique, le CTO reste responsable) |
| Une estimation requise également au cours de la due diligence | Uniquement utile aux investisseurs |
| Une prévision | Un engagement |
| Une prévision revue régulièrement | Une estimation réalisée au début d’un projet/d’une initiative ou mise à jour avant les audits |
Un ensemble d’informations contenant :
|
Une question de :
|
| Intégré systématiquement à la discipline de l’architecture de la solution | Un savoir mystique réservé à quelques élus |
L’occasion de bien faire les choses, car il est impossible d’évaluer le TCO sans :
|
Un simple processus informatif |
Se préparer au TCO
| Le TCO requiert | Le TCO ne requiert pas |
|---|---|
| Une expertise spécifique (planification, incrémentation, analyse coût-avantage, connaissance IT 360°) pour commencer à le tester | Que des managers (au contraire, plus il y a d’acteurs, mieux c’est) |
| De la bienveillance et des critiques constructives | Une expérience en analyse coût-avantage (même si cela peut aider) |
| Un effectif raisonnable (plus d’une personne) | L’implication de tous (3 à 5 contributeurs suffisent en général) |
| Un cadre exploitable (équation du TCO + checklist de questions) | D’importantes préparations initiales (juste ce qu’il faut, juste à temps) |
| Un facilitateur (les Scrum Masters peuvent en général s’en charger) | La bénédiction du CTO (le CTO doit s’assurer que ces estimations correspondent toujours aux moyens de l’entreprise, peut attirer l’attention sur l’estimation, mais ne doit en rien changer les réponses des experts) |
| Une conversation | Un outil sophistiqué spécialisé |
| Un minimum de formation et de mentorat auprès des équipes (pour bien faire les choses dès le début) | Une formation formelle ou une certification spécifique pour commencer les estimations |
| Des équipes qui comprennent la proposition de valeur des estimations de TCO | Le simple remplissage d’un document type avec des données |
| Des révisions régulières (dans le cadre d’une gouvernance fonctionnelle) | Une préparation avant les audits (si une préparation est nécessaire pour les audits, les estimations de TCO ne fonctionnent peut-être pas très bien) |
| De l’observation (plus nous mettons à jour nos estimations, plus nous apprenons) | Des documents et des présentations (il vaut mieux automatiser le reporting) |
| Un leadership en matière de FinOps | Une approche coercitive de la conduite d’équipes |
Révéler les coûts cachés
La plupart des responsables technologiques ont du mal à indiquer de quels systèmes, sous-systèmes et flux de données disposent l’entreprise. La complexité est telle qu’on peut facilement perdre le contrôle. Des choix doivent être effectués concernant la structure des coûts.
Voici un exemple : selon la consommation de tarification de votre API Gateway publique, vous réallouez les coûts de cette infrastructure aux applications, filiales, partenaires ou entreprises des clients. Ceci requiert une intendance continue.
Plus d’options budgétaires
Voici un autre exemple : si au cours des phases de financement, votre entreprise a été contrainte de maintenir l’EBITDA dans une fourchette spécifique, le fait de comprendre les structures de coûts et la manière dont elles seront finalement amorties deviendra un atout pour le CTO que vous êtes.
FinOps
Nous devons admettre que la complexité existante appelle à l’émergence d’une nouvelle discipline : le FinOps. La réalité du FinOps nourrit les estimations de TCO et la pratique du TCO accroît la sensibilisation au FinOps dans l’entreprise. Le Maturity Model du FinOps doit s’enrichir des bonnes pratiques du TCO pour un FinOps totalement aligné.
Catégorie de coûts
Selon le contexte (acheter vs développer), il peut être difficile de savoir comment entrer les coûts dans les bonnes colonnes. Surtout quand on parle de DevSecOps ou quand on acquiert des solutions SaaS au lieu d’en développer. Ce qui prime avant tout, c’est de voir les coûts. Ensuite, quelles que soient les règles qui assignent les coûts aux colonnes, elles doivent être explicites et constantes (n’en changez pas d’une évaluation de TCO à l’autre).
Coûts pour quantifier l’impact des risques
Meilleur vous deviendrez en analyse de risques, plus vous aurez envie de voir leurs coûts afférents apparaître dans le TCO. Nous pouvons citer la « dette technique » ou les « dépendances technologiques externes » en guise d’exemples pertinents.
L’accent sur l’architecture
Une architecture de solution bien conçue doit inclure le TCO. Ce point est d’autant plus important pour les CTO que certains se considèrent encore comme les architectes en chef. Peu importe par qui le travail est effectué, c’est au CTO qu’incombe la responsabilité de l’architecture.
Si, de manière générale, l’analyse des coûts n’a pas toujours été une préoccupation explicite en matière d’architecture, le budget figure toutefois dans le corpus de connaissance de l’architecture de la solution. Au fil du temps, nous avons assisté au passage de la méthode ATAM (analyse des choix d’architecture) à la méthode CBAM (analyse coût-avantage), sans parler du mouvement FinOps. Toutes ces évolutions montrent que l’analyse des coûts est aujourd’hui omniprésente dans l’architecture.
Compte-rendu de décisions d’architecture (ADR), gouvernance et dépenses réelles
Nous avons déjà évoqué la due diligence. La due diligence est un audit. Les auditeurs chevronnés examinent l’Architecture Decision Record (ADR), s’intéressent au TCO et à la manière dont ces estimations ont évolué au fil du temps en s’appuyant sur les progrès et dépenses réels.
Optimiser le résultat, pas le rendement
Faire des estimations de TCO dissuade l’organisation de se précipiter dans de nouvelles initiatives. Tout le monde veut de nouvelles fonctionnalités, de nouvelles technologies, de nouvelles organisations, etc., mais le plus difficile est d’optimiser l’existant, de le faire fonctionner et de le mettre en relation avec des indicateurs commerciaux (EBITDA, échelle de revenus, diversification industrielle, montée en gamme, CLV).
Dans mon équipe produits, nous notons les initiatives de roadmap en tenant compte de facteurs comme les objectifs de croissance, les problèmes opérationnels, la baisse des risques de sécurité, la résolution de la dette technique, etc. Plus l’initiative est récente, plus le score est bas. Plus le TCO est vaste, plus le score diminue. Plus le score est élevé, plus il prend de l’importance dans les priorités trimestrielles. Nous n’avons pas touché une seule fois à l’algorithme du score en deux ans !
Utilisez les estimations de TCO lors de votre propre processus d’achat
Il devrait être désormais évident que vous pouvez utiliser les estimations de TCO au cours de votre processus d’achat pour mieux comparer les offres.
La pression sur les coûts génère un type d’innovation différent
Imaginez une époque où l’on publiait des études pour convaincre les responsables technologiques de virtualiser. Mais l’amélioration n’est pas venue des responsables. L’industrie tout entière s’est améliorée à cause de la pression des coûts : c’est le fait du TCO. La pression sur les coûts a conduit le secteur à la virtualisation. Nous sommes plus écoresponsables qu’avant dans le domaine informatique.
Sans TCO, pas de legs du CTO
Lors d’un meetup organisé à Paris à propos du leadership des CTO, j’ai parlé du monde des affaires comme d’un jeu sans fin. Nous ne devons pas nous voir éternellement aux postes que nous occupons actuellement. L’entreprise continuera la partie et nous prendrons un autre chemin. Que laissons-nous derrière nous ? Que trouvera le prochain CTO en arrivant ? Ce nouveau venu dira-t-il : « Ouah ! Voilà une base sur laquelle je vais pouvoir m’appuyer pour continuer à construire » ou pensera-t-il plutôt : « Il va falloir tout reprendre à zéro ! » ?
Bien entendu, des estimations de TCO ne suffisent pas à laisser un héritage dont le CTO peut être fier, mais elles sont un réel bond en avant dans une stratégie commerciale et technique holistique.
***
Si vous voulez perfectionner vos compétences de CTO ou souhaitez évaluer l’adéquation d’un candidat au poste de CTO, découvrez-en plus sur l’évaluation de CTO pour le Growth et l’évaluation de CTO pour le recrutement que vous propose Pentalog.
À l’origine, cet article a été publié sur le blog CTO Craft, le partenaire de Pentalog pour la formation des CTO.
