Articles Tagués ‘TCO’

All models are wrong, some are useful (Edward Deming)

You’ve probably seen many MIS cartographies. You know, those squares and rectangles imbricated, linked each other .. These diagrams contain a lot of information. They are most often maintained by dedicated teams and stored in a database, so that users can zoom in zones, areas, or districts. Users can find an application, its dependencies (but often, the map is not the territory ..) but who are those users? What benefit do they get from that?

As we all know «all models are wrong, some are useful». So what do we need a cartography for? We want to understand and discuss and take collective decisions. «We» stands for executive, managers and operationals.

Today executives don’t understand why we should reinvest in this «project» (note the typical misunderstanding between project and product; they tend to think that when the project is finished, the costs are over. It’s the opposite, once the project is finished, the life of the product begins, with continuous improvement .. or death), while operationals are unable to explain why they are so improductive, typically because of technical debt … Actually no one really understands each other world, and middle-managers try to take control on the debate with tons of cartography (ohh, look ! it would be so nice to merge these two application blocks, the titles say they do the same ..).

So we need a simple and comprehensive tool to better understand and discuss organizations IT assets – and liabilities, and take smarter decisions together: where to invest, on what, where to de-invest, etc.

OK, let’s get in : for each application in the system – we’ll call them product – we are going to measure 3 metrics : value, total cost of ownership (TCO) and technical debt. Then we’ll use a convention to display them as bubbles – rather than squares – to exhibit the fact that a system is not only a program, but a team of people as well. Team = Product.

While TCO can be measured quite precisely, we’ll see that we need to accept rough synthetic models for value and debt…


Value should be measured from the end-user standpoint. Hence the value of this system is not the amount of money it has costed, but rather the answer to the question «what would we do if we no longer had it ?». Here the temptation of complex multidimensional modeling is often strong, especially among engineers : «we should aggregate the loss of not being in the market for x days plus one third of the damage on the brand, estimated as customer loyalty divided by …». Stop!

There is no «true value» to measure here. There is just an approximate consensus, which has its own value : everyone agrees on the importante (or unimportance) of this product.

So discuss the question «what would we do if we no longer had it?» again and again. Discuss between IT and end-users, and executives. Argue, propose simple, unidimensional models. And at some point, someone will suggest a synthetic approach that best represents what should be understood by everyone.

By experience, these synthetic models fall in two categories, depending on the asset being «front-office» or rather «back-office» :

front-office assets, like a web store (Amazon, eBay, ..), are worth the revenues the company makes through them. Most of the time, if we don’t have them, this revenue will be lost. Value = revenues made through this chanel.

back-office assets are different. If we loose them, we can still talk to our customers and make revenues, we just have to manually do what we used to do with the help of computers (accounting, control, inventory, purchasing). Imagine a solution that would only require spreadsheets and basic workforce, you always can! (look back 30 years ago if you lack imagination). Value = total workforce cost per year, because spreadsheets and data space are nearly free nowadays.

Now you have one figure in € or $. If you add all the values of your sub-systems, front and back-office, it can be greater than your company revenues, which just shows that IT is very important in your company (eMerchant, banks, telcos ..).

As end-user value is the most important thing to see, we’ll use it as the main scale of our diagram, it will give the surface of each product, like :

Total Cost of Ownership (TCO)

Costs of a system are not only the project costs or the maintenance costs, but include all what we shouldn’t have to pay for if we didn’t have this system: hardware, software, production staff, support staff. In typical IT departments, production teams are separated from development teams. While it is often easy to track development costs at a product level, you’ll have to do some analytical accounting in the datacenter, where things are more mutualised. Start basic, asking the question at your production staff («OK, so roughly, this application takes 2 thirds of this Unix server, which is managed by those 2 people for half of their time?»), and checksum that the sum of all production costs equals the production total budget, including managers, licences, datacenter, energy ..

Now to remain visual and comprehensive, we’ll use a shade of gray to display costs as a fraction of value. The darker the shade, the lower the ratio TCO/value : dark assets cost more than what they are useful, light assets bring more value than what they cost. In the middle, grey assets are neutral, we could decide to «decomputerize», it would be the same for the company.

Technical debt, a liability

How could we simply approximate the last metric of our cartography? Remember the goal: discuss, get a consensus on what should be done. The best way is to ask people in the field (developers, production guys..) : «what do you think we should invest to go back to a normal state of productivity? (a state where you are happy to maintain the code, where you no longer suffer from reccurent incidents, etc.)». You may have to ask several times the question as often, people that have lived for long in a decayed environment tend to think that it is normal, so ask again, «how much to transform this code into Open-Source or Google-class code that you would be proud of. Then they will start to speak the truth and talk about their regular pains : technical obsolescence, lack of tests, data & code doublonning, code heterogeneity. Ask them the number of man-days required for a cleaning project, and valuate it in € or $.

We will then display this debt in €, as a fraction of the annual total cost, with a crust surrounding the asset. A crust visibly empeds an asset from developing, it is easily understandable by executives : bahhh big crust! ahhhh small crust! The thick crust on the right represents the equivalent of one year of costs of the asset (we should focus our entire energy for one year to clear it), a thin one, one tenth of the total cost (less than a month of the whole team to clean).

For products that are known to let their users very unsatisfied, it is a good idea to add the «end-user debt» as another contribution to the debt: how big a project that would produce all the features users have been complaining about for so long? I encourage you to be creative here : add it to the same crust or create another layer of crust with a different color…

Well, so where we go now? The cartography is not a goal in itself, it is a tool aimed at taking smarter decisions together, geeks, bosses and end-users. Imagine discussions with a result like this:

Or a discussion with your boss on something like this (more likely your situation …):

Now you must say, how to automatically build such a map? Just download this Excel tool I wrote, unzip the archive and start with the README. I distribute it under the GPL License so feel free to distribute and improve it.

Last, this cartography standard is evolving thanks to YOUR contributions. Help me. Comment. It should be improved, for instance by isolating variable costs from fixed costs at the production (datacenter amortization..), and probably many others learnt from experience.


« Tous les modèles sont faux, mais certains peuvent être utiles. »
Edward Deming

Cette nouvelle dialectique du but et des contraintes me perturbe au plus haut point. Pourquoi donc la division d’un but en sous-buts semble-t-elle échouer systématiquement ? Toute ma scolarité d’ingénieur, je l’ai placée sous le rationalisme de Descartes : tout problème peut se décomposer en sous-problèmes indépendants, toute cause produit des effets et il existe des causes premières, des lois immuables qui expliquent la réalité …Cette nouvelle confrontation avec un écosystème humain trop contingent me renvoie soudain des vagues de nostalgie. Je me trouve replongé dans l’univers mathématique de ma jeunesse, où tout était plus simple, plus beau, où je croyais qu’existait LA solution.

Peut-être ai-je besoin de me référer à un nouveau maître ? J’appelle Kasperski. Une fois arrivé dans mon bureau, l’énergumène ne juge pas utile de s’excuser de sa récente disparition. Je n’ose pas faire allusion à cet épisode, et compose le numéro de Secrotas.

– Jean-Louis Secrotas ? C’est Paul Boulier de la Générale.

– Bonjour Monsieur Boulier, comment allez-vous ?

– Très bien, merci, et vous-même. Je suis en compagnie d’un collaborateur, M. Kasperski, qui m’a aidé à répondre à vos questions.

– Excellent, à quelles réponses êtes-vous parvenus ?

– Le but de la DSI est de maximiser le débit de demandes mises en production, sous contrainte de coûts, de risques et d’intégration.

– Fantastique ! C’est extrêmement clair. Je ne dis pas cela pour vous être agréable. Utilisé comme leitmotiv auprès de vos collaborateurs, cela pourra effectivement guider chacune de leurs décisions.

– Merci Jean-Louis ! Je peux vous appeler Jean-Louis n’est-ce pas ? Cependant nous ne pouvons en rester là, un slogan ne suffit pas. Je fais quoi maintenant ?

– Avez-vous le sentiment que la DSI atteint son but tel que vous l’exprimez ?

– Non.

– Quelles sont les causes majeures qui l’en empêchent ?

– A cette question pour une fois j’ai tellement de réponses possibles que je ne sais laquelle choisir : peur de régressions sur ce qui marche déjà si on accélère les évolutions, circuit de décision d’investissement très long, vieillissement du patrimoine informatique, différences de productivité entre équipes …

– Avez-vous une carte du Système d’Information qui nous permette de visualiser les facteurs clés de succès pour atteindre votre but ?

– Bien sûr ! dis-je fièrement, en tentant de me connecter à l’Intranet « Cartographies du SI ».

– Contient-elle des informations qui permettent de mesurer la valeur pour le métier, le débit, le coût, ou la sécurité ?

– Euh … non, pas directement, c’est une cartographie. Mais elle contient un recensement exhaustif de nos systèmes et de leurs relations, c’est déjà bien utile.

– Pas vraiment pour ce qui nous concerne.

– J’ai aussi la carte de notre dernier schéma directeur … elle fait apparaître très distinctement les blocs fonctionnels, les référentiels de données …

– Un schéma directeur n’est qu’une carte virtuelle, Paul, un modèle qu’on aspire à faire émerger de la réalité, mais pas la réalité. On ne sait d’ailleurs pas à un instant t si la réalité projetée sera meilleure. Au fond, qui peut le savoir ?

– Mais qu’avez-vous en tête alors, Jean-Louis ?

– Je peux vous proposer un petit exercice qui devrait vous aider : dresser une nouvelle carte du SI qui apporte un niveau d’information utile pour atteindre le but tel que vous l’avez exprimé. Je vous envoie à l’instant la légende de cette carte par email.

Effectivement, trois messages surgissent sur mon ordinateur.
Secrotas commence son exposé :

« Je vous propose de mesurer trois métriques pour chaque application du Système d’Information.
La première est l’actif. J’entends par là la valeur qu’a le système du point de vue de ses utilisateurs. Cette métrique est rarement mesurée car on peut tergiverser des années sur ce que vaut un système : vaut-il la somme de ce qu’il a coûté, le coût de son arrêt pendant 3 jours, la perte d’une image de marque s’il tombe ? C’est du reste souvent pour cela que l’on ne mesure que les coûts. Pour mesurer l’actif, osez faire fi de l’abondante littérature engendrée par le thème du capital immatériel. Utilisez une méthode simple, fondée sur une seule question : « que ferions-nous sans ce système ? ». Les utilisateurs vous répondront alors soit qu’ils doivent sortir d’un marché – ce serait par exemple le cas pour un commerçant électronique qui perdrait son site Web – soit qu’ils doivent remplacer le système par des petites mains et de la bureautique – un système comptable pourra toujours être remplacé par un tableur et des dizaines d’opérateurs.

Au final vous obtiendrez un chiffre approximatif en euro. Cette valeur donnera la surface de nos applications, comme l’explique mon premier message :

La deuxième métrique est le coût total de l’application. J’insiste sur le total. Il s’agit d’évaluer l’économie annuelle que réaliserait la Générale si elle supprimait ce système. Cette économie prend sa source jusque dans les activités de construction et d’exploitation, souvent séparées dans des budgets différents – par exemple x euros d’études et de développement et y euros de machines, licences logiciels, heures d’astreinte, etc. Vous utiliserez une teinte allant du clair au foncé pour matérialiser ce coût en pourcentage de la valeur. Plus un actif est clair, plus son rapport valeur/coût est intéressant, plus un actif est sombre moins il est utile à l’entreprise ; et un actif gris coûte autant qu’il rapporte :

La troisième et dernière métrique est le passif de chaque système, c’est-à-dire la dépense qui serait nécessaire pour ramener l’application vers des normes de productivité cohérentes avec votre but. Là encore, descendez sur le terrain, et posez simplement la question « quel serait le niveau d’investissement nécessaire pour que cette application revienne à l’état de l’art de la productivité ? ». Vos collaborateurs pourront chercher à évaluer la dette technique accumulée avec le temps, dette à l’origine des coûts et des risques d’aujourd’hui : strates accumulées sans jamais nettoyer le fond, données en doublons, testabilité difficile, obsolescence technique. Ils réfléchiront alors à un projet de remaniement qui permette par exemple d’homogénéiser, de factoriser, d’ajouter des tests automatiques ou de mettre à jour la technologie. Pour finir, vous représenterez le coût ainsi évalué de ce projet en pourcentage du coût total calculé précédemment : 10% un contour fin, 100% une croute épaisse.

Paul, d’après vous à quoi ressemblerait la carte du Système d’Information selon cette légende ? » conclut-il.

Je réfléchis un moment. Il m’énerve avec ses bulles de savons et ses chiffres « à la louche », j’ai l’habitude des vrais chiffres moi ! J’essaie de rester calme. Je commence à lister les éléments qui me viennent à l’esprit : beaucoup d’applications dont les métiers pourraient difficilement se passer, bon rapport qualité-prix dans l’ensemble, passif limité grâce aux programmes d’urbanisation et de réécritures entrepris sous mon autorité, quelques moutons noirs le long de la route…

Je me lance dans un brouillon de dessin, mais déjà Secrotas prend congé poliment, et nous invite à le solliciter dès que nous aurons les premières esquisses.

Kasperski m’aide à formaliser mes intuitions. Nous les consignons dans une première carte.

Tout à coup, avant que je ne le lui suggère, il me demande de combien de temps il dispose pour mener un premier niveau d’enquête.

Je lui donne quinze jours et ma bénédiction…


Il est plus de 19h quand Kasperski entre dans mon bureau en brandissant des papiers avec une moue gênée.

Le quotidien qui m’a envahi ces dernières semaines m’a presque fait oublier la carte, et surtout mon ultimatum.

« Paul, j’ai rencontré plus de vingt équipes, interviewé en groupe les métiers et les informaticiens, et consolidé le résultat dans cette carte » dit-il en dépliant son ouvrage.

Et d’ajouter :
– C’est plus noir et crouté que prévu …

Il a réussi à me mettre immédiatement en colère. Je l’invective :

– Je dépense une part colossale du budget en contrôle qualité, en normes et procédures, en standards d’architecture, en composants mutualisés et vous me représentez le SI comme une sorte de décharge pleine de boules puantes, où la moitié des logiciels seraient pourris et devraient être remplacés !

Puis de m’excuser :

– Désolé Kasperski, vous n’y êtes pour rien. Les délais de livraison s’allongent, les clients n’ont pas ce à quoi ils s’attendent, et l’informatique coûte de plus en plus cher. Maintenant en plus, avec ce type de schéma, il m’est impossible de défendre son rapport qualité/prix ! Mais il reste un élément qui m’échappe : nos collaborateurs sont vaillants et compétents, ils ont tous des missions précises, qui participent d’une manière ou d’une autre à la réalisation du but, qu’ils soient développeurs, exploitants, acheteurs, architectes …

– On peut prendre l’hypothèse que chaque département fonctionne de manière optimisée, et que le grand horloger, vous en l’occurrence, n’êtes pas assez compétent pour coordonner le tout. Mais je ne pense pas que ce soit cela la bonne approche. La DSI n’est pas une horloge, ce serait plutôt un ensemble de cercles, vicieux ou vertueux, entrant en résonance les uns avec les autres : l’optimum de l’un peut nuire à l’optimum de l’ensemble.

– Hum. Appelons Secrotas, je veux son avis.

Bientôt sa voix résonne dans le haut-parleur :

– …. En effet, d’une manière générale produire de la valeur ajoutée nécessite de coordonner les efforts, de synchroniser les nombreuses ressources de l’entreprise : développement, marketing, vente, production, finance…Ce débit de valeur ajoutée se trouve à la merci du maillon le plus faible de la chaîne. Vous êtes d’accord avec moi Paul ?

– Oui. Mais pouvons-nous dérouler le raisonnement sur un exemple d’optimisation locale, celle des prix de revient par exemple.

– En voulant optimiser les coûts on néglige souvent l’importance de certaines ressources contraintes, qui pèsent sur l’ensemble de la chaîne en ce qu’elles en dictent le débit maximal. Par exemple, les achats décident de s’adresser à un fournisseur de roulements à billes moins cher mais livrant moins vite, avec comme résultat final d’assécher la contrainte, c’est-à-dire le poste d’assemblage du train avant, qui utilise ces roulements. La comptabilité analytique va saluer une diminution des prix de revient (et l’acheteur obtiendra sa prime), mais le débit de voitures aura diminué, ainsi que l’efficacité de l’entreprise au regard de son but. Sur ce poste goulet, il vaut mieux choisir un fournisseur plus cher mais plus fiable.

– Je sais. Lorsque nos achats font un but à part entière de la diminution du prix de revient des prestataires informatiques, ils peuvent s’opposer à l’objectif principal qui est de maximiser le débit de demandes mises en production… Comme disait un de mes amis CIO « If you pay peanuts, you get monkeys ».

– Cela peut même aller plus loin dans les effets pervers. Dans l’industrie, le pilotage par les prix de revient encourage à faire des stocks – or plus personne aujourd’hui ne souhaite faire des stocks, c’est-à-dire immobiliser du capital. En effet, quand les ventes vont mal, il convient de baisser l’activité pour s’aligner sur la demande. Mais alors, les coûts unitaires grimpent, puisqu’une grande partie de ces coûts n’est pas variable mais fixe : on ne supprime pas les gens ou les machines comme ça, même si on ne les utilise pas ! Pour préserver l’optimum local des « prix de revient », on va donc surproduire en période de sous-activité !

– J’imagine que tout cela a des raisons historiques. La méthode devait être pertinente au début du siècle, quand l’essentiel des coûts étaient variables, y compris le travail, payé à la pièce jusqu’au début du XXe siècle. Aujourd’hui, c’est souvent l’inverse, l’essentiel des coûts est fixe – les salaires sont payés à l’heure, pas à la pièce – mais la méthode de comptabilité analytique n’a pas évolué.

– Exactement, comme quoi il est temps d’évoluer !

J’enrage de n’avoir pas réfléchi davantage auparavant en ces termes, car tout m’apparaît de manière limpide à présent : non seulement il y a les achats qui diminuent les coûts unitaires de main d’œuvre au détriment de la qualité des logiciels produits, mais il y a aussi les représentants des utilisateurs qui tentent de « bien » cadrer la création de logiciel en accumulant les demandes métier dans des cahiers des charges qui – sous couvert d’exhaustivité – ne distinguent plus le nécessaire du superflu ; les architectes « simplifient » le SI en créant des guichets normatifs où s’empilent les demandes des projets ; les délais sont encore allongés, et au final voient le jour dans la douleur des monstres parfois adaptés mais toujours inadaptables…

Et tout ceci n’accorde pas une grande valeur au temps ! Alors que la maîtrise du temps est la vertu qui peut entraîner toutes les autres : les coûts bien sûr par effet mécanique, mais aussi la qualité, car pour livrer vite en toute sécurité il faut l’augmenter…
Et si on arrêtait la quête de systèmes adaptés à tout pour se consacrer à bâtir des systèmes adaptables !

Le téléphone sonne, interrompant mes pensées :

– Oui, j’écoute

– Ici Pichot de la Direction Commerciale. Vous êtes ailleurs ou en vacances Paul ?

– Pardon ?

– Vous avez dans votre boîte aux lettres un message que vous auriez peut-être dû lire avec attention …

Je me précipite sur mon ordinateur, Pichot est le Directeur Commercial et je ne l’ai jamais eu au téléphone pour autre chose que de gros soucis …

Effectivement un message dix fois transféré, répondu et re-transféré avec désormais une vingtaine de destinataires appartenant à quatre niveaux hiérarchiques vient de me parvenir :

From: Stéphane Pichot
Subject: Tr : Tr : Re : Alerte, bug sur le site Internet suite mise en production version 3.12Paul, faites quelque chose, vite.
> … vous vous foutez de ma gueule !!! On est en train d’offrir un voyage en
> Martinique à tous les mecs qui font un virement sur notre site bordel !!!
> …
>>… on a développé la nouvelle fonctionnalité de super pactole pour le
>> 100 000e virement …
>> … depuis qu’on a atteint les 100 000, chaque nouveau virement indique
>> « vous avez gagné le pactole », est-ce normal car il n’était pas spécifié
>> que l’on doive remettre le compteur à zéro ? …

Je tourne la tête pour regarder la nouvelle carte d’état major : la bulle « site Internet particulier » est noire, avec une énorme croute rouge. Je sens mon sang se glacer. D’après la carte, cela signifie que la dette technique est monstrueuse, donc que la correction prendra du temps, et que l’on a toute chance de déclencher d’autres bugs …

« Kasperski, je gère l’urgence ce soir et cette nuit. Pour le reste, on commence lundi. 8h dans mon bureau. Excellent week-end. »

-> Chapitre 3