Lors d’un précédent billet, je m’insurgeais contre cette vision simpliste et contre-productive des approches d’achat centrées sur la réduction du taux de journée.

Le prix de l’incompétence

Ne nous leurrons pas, à métier constant, plus le taux moyen est bas, plus vous aurez des services de piètre qualité. Il n’y a pas de magie. De plus, cela coûte cher dans la durée, pour plusieurs raisons :

• directement, la productivité sera moindre avec des ressources moins efficaces. “ If you pay peanuts, you get monkeys ! ”
• indirectement, votre organisation supportera des coûts additionnels liés à la gestion des manques de compétence.
• dans la durée, car un défaut de qualité a souvent des répercussions sur les coûts de maintenance et la dette, comme par exemple avec la tour de Pise…
• par le risque, car il est probable de ne pas atteindre les objectifs fixés si vous n’avez pas les bons profils.

Les leviers de réduction des coûts

Comme je l’exposais dans mon billet précédent, il existe trois façons de réduire une facture de prestations de services, et le raisonnement s’applique de manière plus large qu’un projet soit sous-traité ou non :

• En faire moins en réduisant les ressources, et mieux vaut cibler un excès de profils expérimentés que l’inverse.
• Automatiser un maximum de tâches. Il existe des outils pour automatiser certaines tâches de développement. CodeFluent Entities permet de réduire le volume de code manuel à écrire d’au minimum 50%.
• Négocier ! Cela permet d’optimiser l’équation, à partir du moment où la dynamique avec le fournisseur reste gagnante pour celui-ci et que vous lui proposez quelque chose en échange.

Or, la réalité de bien des situations de terrain est que beaucoup de sociétés sont pilotées par des approches purement financières des achats, sans aucun moyen d’estimer réellement la valeur de ce qui est produit au niveau des équipes de développement. C’est alors qu’on retrouve des personnes démunies qui essayent d’appliquer le 3^e levier dans des proportions souvent largement irréalistes.

Une approche pour chiffrer les coûts et la valeur

Plutôt que de se contenter de critiquer ces raisonnements et leurs impacts néfastes, essayons de proposer une manière différente de raisonner.

En réalité, les services achat ne sont pas dupes, mais ils doivent afficher des chiffres pour justifier leur rôle, et ils n’ont souvent que peu de critères mesurables, hormis le taux journalier, pour justifier leurs choix.

C’est donc d’abord le travail du responsable de se forger une conviction sur la valeur produite pour chaque ressource en tenant compte de la dynamique d’équipe.

Des hypothèses d’impact de la réduction

Pour une raison stratégique quelconque, on me demande de réduire les coûts de mon équipe. Voici 3 scénarios que je présenterais suivant l’option retenue. L’impact estimé ici reflète assez bien mes convictions sur ce qui se passe dans la réalité lorsque l’on retient ses options.

Les chiffres que j’avance sont étayés par un modèle détaillé avec des hypothèses issues de l’expérience que je publierai dans un prochain billet.

Scénario 1 : réduction par approche achat “ classique ”

Tout d’abord, nous pouvons choisir de simplement tirer les prix vers le bas sans réellement retravailler la restructuration de l’équipe. Les coûts diminueront donc mécaniquement avec la baisse des taux.

Ce scénario produira un effet de “ Juniorisation ” car les ressources vont dériver rapidement vers des profils moins qualifiés. La productivité va se réduire fortement et il existe même un point de rupture ou plus rien ne fonctionnera.

En restant optimiste, pour 15% de coûts économisés on aura en réalité une perte en valeur de 30% par la chute de l’efficacité.

Scénario 2 : réduction du périmètre ciblée sur les profils les moins productifs

Cette approche “ de bon sens ” de réduction de l’ambition est heureusement appliquée, mais elle est parfois limitée à la simple réduction de périmètre.

Un contexte imposé de réduction de coûts donne l’opportunité de forcer l’évaluation de l’équipe, et il y a fort à parier qu’avec un management approprié, on puisse gagner en productivité tout en réduisant la taille de l’équipe. Cela traduit une réalité observée sur le terrain. Il est établi qu’une petite équipe de développement est plus efficace qu’une grande, et adapter la taille de l’équipe et le délai de production d’un projet aux enjeux économiques réels et à la valeur de sortie globale est crucial en développement.

En ciblant sa réduction de périmètre et de ressource, on pourra atteindre 20% de coûts économisés et augmenter l’efficacité tout en ne réduisantla valeur que de 15%.

Si certains grands projets obligent à avoir de grandes équipes, alors il faut intégrer ces facteurs en amont, et travailler autant que faire se peut au découpage.

Scénario 3 : réduction ciblée combinée à des outils de productivité

Il est paradoxal qu’un métier tel que le développement soit, finalement, très peu outillé et que les personnes en charge de budgets informatiques ou d’achats, ne se posent pas plus la question des outils.

Avec une représentation fonctionnelle adéquate et des outils adaptés, on peut automatiser la production d’une part significative de code technique répétitif, avec un gain en maintenance directement corrélé. En plus, le gain sera plus important pour le support de nouvelles technologies, qui sera assuré en partie par les outils.

Avec une focalisation sur les profils efficaces et motivés, on parvient finalement à produire la même valeur tout en diminuant les coûts globaux de 35%.

Je publierai prochainement les hypothèses et tableaux détaillés qui m’ont permis d’obtenir ces chiffres dans les 3 scénarios.

Mais il y a fort à parier que la décision sera évidente pour un décideur de bon sens soucieux de ses intérêts financiers et à qui on présentera le graphique de synthèse :

 

D’autant plus qu’il pourra mesurer la valeur ajoutée apportée au passage avec des économies substantielles et durables, sans démotiver les équipes en place.