RPA : calculer le retour sur investissement avant de développer, pas après

La question posée à un prestataire RPA est presque toujours « combien coûte l'automatisation de ce processus ». La bonne question est « ce processus mérite-t-il d'être automatisé », et elle se répond avant de chiffrer le développement.

Chronométrer, pas demander

Les estimations de temps fournies par les équipes sont systématiquement fausses, dans les deux sens. Nous avons mesuré des écarts allant de moins quarante à plus vingt-cinq pour cent sur les mêmes processus.

Elles surestiment quand le processus est pénible : la personne se souvient des cas difficiles. Elles sous-estiment quand il est routinier : personne ne compte les interruptions, les reprises et les vérifications.

La seule méthode fiable est l'observation directe : s'asseoir à côté de la personne, chronométrer plusieurs exécutions réelles, et mesurer aussi la fréquence réelle sur douze mois glissants — pas la fréquence théorique.

La formule complète

Le gain annuel se calcule simplement :

Gain = (temps unitaire × fréquence annuelle × coût horaire chargé) × taux d'automatisation réel

Le dernier facteur est celui qu'on oublie. Un robot traite rarement cent pour cent des cas : il traite les cas nominaux et renvoie les exceptions à un humain. Un taux réaliste se situe entre soixante-dix et quatre-vingt-quinze pour cent selon la variabilité du processus.

Le coût, lui, comporte trois postes :

• Le développement, une fois.
• Les licences, chaque année, souvent sous-estimées.
• La maintenance, chaque année : c'est le poste que les projets RPA ignorent le plus. Un robot casse à chaque changement d'écran de l'application cible. Comptez entre quinze et vingt-cinq pour cent du coût de développement par an.

Le seuil de décision

Notre règle : si le retour sur investissement dépasse dix-huit mois en incluant la maintenance sur trois ans, nous recommandons de ne pas automatiser.

Les processus qui échouent le plus souvent à ce test :

• Ceux exécutés moins de deux fois par mois. Le gain absolu est trop faible.
• Ceux dont les règles changent chaque trimestre. Le coût de maintenance dépasse le gain.
• Ceux qui traitent des cas trop variables. Le taux d'automatisation réel tombe sous cinquante pour cent et l'humain doit tout vérifier de toute façon.

Documenter le refus

Quand un processus ne passe pas, écrivez pourquoi. Ce document a une valeur réelle pour le client : il lui sert à arbitrer les demandes internes suivantes sans refaire l'étude.

C'est aussi le meilleur test de la relation avec votre prestataire. Un prestataire qui n'a jamais recommandé de ne pas automatiser un processus n'a probablement jamais fait le calcul.

Le piège du gain théorique

Un gain de mille huit cents heures par an ne devient une économie que si ces heures sont réaffectées ou supprimées. Si elles sont simplement rendues à des personnes qui restent au même poste avec la même charge nominale, le gain existe en qualité de vie mais pas en compte de résultat.

Ce n'est pas un argument contre l'automatisation : c'est un argument pour dire honnêtement, dès le départ, quel type de gain est visé. Les projets qui promettent une économie budgétaire et livrent un confort de travail sont ceux qui laissent le plus mauvais souvenir.