Ce que vaut vraiment une automatisation quand les choses tournent mal

La plupart des projets d’automatisation sont validés sur une phrase : « Cette tâche prend cinq minutes, nous la faisons des centaines de fois par mois, nous gagnons donc de nombreuses heures. » La phrase est vraie et incomplète. Elle ne compte que les exécutions qui se passent bien.

Toute automatisation produit aussi du travail qui n’existait pas avant :

• Les exceptions. Des entrées que les règles n’avaient pas prévues : une pièce jointe illisible, une référence d’article inconnue, un client qui écrit « comme la dernière fois ».
• La reprise. Trouver ce que l’automatisation a fait de l’exception, corriger l’enregistrement et prévenir la personne qui a reçu le mauvais résultat.
• Le contrôle. Quelqu’un regarde le journal ou un échantillon de résultats, parce que personne ne fait confiance à un processus que l’on ne regarde jamais.
• La maintenance. Un fournisseur change un format de fichier, un système connecté est mis à jour, une clé d’accès expire.

Pour calculer la vraie valeur d’une automatisation, portez ces quatre postes sur la même feuille que le gain, dans la même unité. Les minutes par mois conviennent bien.

Les chiffres ci-dessous sont illustratifs. Ils décrivent une entreprise inventée qui reçoit des commandes par e-mail et les saisit dans son système de commandes. Remplacez-les par les vôtres avant de décider quoi que ce soit.

• La tâche est effectuée 360 fois par mois.
• À la main, elle prend 5 minutes. L’exécution automatisée ne demande aucun temps humain.
• 5 % des exécutions rencontrent une exception : 360 × 0,05 = 18 exécutions par mois.
• Chaque exception coûte 40 minutes : la remarquer, trouver ce qui s’est passé, corriger l’enregistrement, saisir la commande à la main et prévenir le client.
• Une personne passe 15 minutes par jour ouvré sur le journal et sur un petit échantillon. Avec 20 jours ouvrés, cela fait 300 minutes par mois.
• La maintenance représente en moyenne 2 heures par mois.
• La réalisation prend 44 heures, y compris le temps de vos propres équipes pour expliquer le processus et tester.

Le projet a été vendu pour 30 heures par mois. Il en apporte 11, un peu plus du tiers du chiffre brut. Le seuil de rentabilité se déduit du chiffre net, pas du brut : 44 heures de réalisation divisées par 11 heures par mois, cela fait 4 mois. Calculé avec les 30 heures brutes, il aurait semblé atteint en six semaines.

Le graphique présente les mêmes chiffres illustratifs côte à côte.

Dans cet exemple, les exceptions coûtent plus que le contrôle et la maintenance réunis, et c’est typique. Deux données méritent le plus d’attention.

Le contrôle et la maintenance coûtent 420 minutes quoi qu’il arrive, ce qui laisse 1 800 – 420 = 1 380 minutes à dépenser en exceptions. À 40 minutes chacune, cela fait 34,5 exceptions par mois, soit environ 9,6 % des 360 exécutions. Au-delà de cette part, l’automatisation coûte du temps. À 10 % exactement, le compte est de 36 × 40 = 1 440 minutes pour les exceptions, 1 860 minutes de coût au total, et une perte nette de 60 minutes par mois.

L’écart entre une part d’exceptions de 5 % et une de 10 % est assez faible pour passer inaperçu dans une démonstration faite avec vingt exemples triés sur le volet. Mesurez cette part sur au moins un mois réel d’entrées avant de construire.

L’essentiel des 40 minutes n’est pas la correction elle-même. C’est le temps qui passe avant que quelqu’un s’en aperçoive, puis le travail d’enquête. Si l’automatisation s’arrête devant une entrée douteuse et la confie à une personne en indiquant la raison, l’exception pourrait ne coûter que 15 minutes : 18 × 15 = 270 minutes. Le coût total tombe à 690 minutes, le gain net monte à 1 110 minutes, soit 18,5 heures par mois, et le seuil de rentabilité est atteint après 44 ÷ 18,5, soit environ 2,4 mois.

Voilà pourquoi une gestion claire des erreurs dans une automatisation des processus vaut plus qu’une étape automatisée de plus. Il en va de même pour les intégrations entre systèmes : un transfert en échec qui se signale lui-même coûte peu, un échec silencieux coûte cher.

Le calcul vous dit si une étape est rentable. Il ne vous dit pas quelle liberté laisser à l’automatisation. Cela dépend de la fréquence à laquelle l’étape échoue, de ce que coûte une erreur et de la possibilité de l’annuler.

La validation n’est pas gratuite non plus. Si une personne a besoin d’une minute pour valider chacune des 360 commandes, cela fait 360 minutes par mois, plus que les 300 minutes de contrôle de routine de l’exemple. La validation est rentable là où elle évite des exceptions coûteuses : appliquez-la donc aux cas douteux et laissez passer les cas clairs. Une automatisation qui sait quand elle n’est pas sûre rend ce partage possible.