Investing in Process Automation: Where to Start
A four-step diagnostic procedure to select automation projects based on data rather than intuition. It includes an assessment grid for suitability, a calculation formula for return on investment, sector-specific application examples, and points to check before launch, including personal data and regulatory requirements.
The situation businesses face today
Labor costs are rising, and recruitment has become challenging. However, the workload continues to increase. Many companies are looking to bridge this gap through automation but hesitate when it comes to the question: 'Where to start?'
The issue is not the lack of candidates for automation, but rather their abundance. Even in companies with an integrated resource management system, a significant portion of actual working time is consumed outside the system. Extracting a purchase order from an email to re-enter it into the system, copying a tracking number from a carrier's website to paste into a client's form, and manually reconciling multiple spreadsheets at each closing are common examples.
Taken individually, these tasks may seem insignificant. They rarely make it onto the improvement project list. Yet, if an employee spends 90 minutes a day on these tasks, an organization of 20 people loses about 7,500 hours a year. This equates to the workload of 3.5 full-time positions.
The greatest loss is not time, but errors and delays. Human transcription inevitably leads to typos, and processing halts whenever the responsible person is absent. This cost is not recorded in any accounting books, only becoming apparent when it manifests as a customer complaint or a delay in closing.
Why Automation Projects Fall Short of Expectations
When automation fails, the cause is often not technical but rather the scope selection. Three patterns tend to repeat.
First, the chosen process was dominated by exceptions. If more than half of the cases involve exception management, automation does not reduce the workload; it creates a new task of verifying whether the result of the automated processing is correct. From the employee's perspective, the workload has increased.
Second, the input data was not standardized. Purchase orders with varying formats depending on the client, spreadsheet files with changing column orders require standardization of formats prior to any automation. Skipping this step only multiplies the rules for exception management indefinitely.
Third, there was no reference to measure the effect. If the time required before deployment was not recorded, only an impression remains: 'it seems faster.' Without proof of return on investment, the budget for the next project will not be secured.
All three issues can be assessed before launch. This is why a diagnostic is necessary.
First, Distinguish Between Two Types of Automation
Before entering the diagnostic phase, categorizing automation into two types simplifies the analysis.
Rule-based automation handles tasks where the conditions and processing methods are clearly established: 'when a purchase order arrives, read the lines and record them in the system,' 'every morning, send the list of items whose stock is below the threshold.' The result is always the same, verification is straightforward, and implementation costs are relatively low.
Judgment-based automation deals with cases where the input varies each time and there is no single answer. Classifying free-format requests, extracting only certain elements from disparate document formats, and responding with sentences to customer inquiries fall into this category. The scope covered is much broader, but the design must assume that an error is possible.
The two types are not verified in the same way. For rule-based automation, it is sufficient to check if the execution was exactly as specified; for judgment-based automation, it is necessary to predefine the acceptable margin of error and the point of human intervention. Managing both under a single criterion inevitably leads to difficulties with the latter.
A Four-Step Diagnostic Framework
Step 1 — Inventory of Tasks
List the repetitive tasks department by department and note three elements for each.
- Number of cases per month
- Time required per case
- Number of people assigned to processing
The goal of this step is not accuracy but to create a comparable list. Trying to measure to the exact minute prevents the survey from being completed. Ask employees how long it approximately takes and note the response as is. There will be time to refine once candidates are narrowed down in the following steps.
Experience shows that in an organization of 20 to 30 people, this list contains 40 to 60 entries. The very act of compiling it is already useful: repetitive tasks that department heads themselves were unaware of often emerge at this stage.
One precaution is necessary during the survey. Do not ask employees what they would like to automate. Phrased this way, the question brings up the most disliked task, not the easiest to automate. It is more accurate to ask them to recount what they did the previous day, in chronological order.
Step 2 — Assess Suitability for Automation
Evaluate each task along four axes.
| Evaluation Axis | Suitable | Unsuitable |
|---|---|---|
| Clarity of Rules | The decision criterion can be written out clearly | Depends on the experience and intuition of the employee |
| Normalization of inputs | Fixed format and fields | Different form each time |
| Exception rate | Less than 10% | More than 30% |
| System accessibility | Stable API or interface available | Interface constantly modified |
Only retain 'suitable' tasks across the four axes as top candidates. Whenever an axis is 'unsuitable', classify the task among those whose condition must first be resolved before any automation. For instance, if the normalization of inputs is unsuitable, it is not an automation project but a format normalization project.
There is a simple method to assess the clarity of the rules: ask the employee if they could pass this task to a newcomer using only the documentation. What cannot be conveyed through a document cannot be conveyed to a machine either.
An unsuitable normalization of inputs does not necessitate immediate abandonment, as this is an area that can be addressed by automation requiring judgment as mentioned earlier. However, in this case, the goal of accuracy and the control procedure must be designed together: therefore, plan for a longer preparation time than for a rule-based project.
Step 3 — Calculate the payback period
Only conduct precise measurement for top candidates, then calculate the payback period.
Économies annuelles = cas par mois × 12 × temps économisé par cas × coût horaire de main-d'œuvre
Délai de retour (mois) = coût de mise en œuvre ÷ ((économies annuelles − coûts d'exploitation annuels) ÷ 12)
Three points require caution.
For the hourly labor cost, consider the total cost, not just the salary. Including social contributions, severance pay, and office space, it typically represents 1.3 to 1.5 times the salary. Limiting it to the salary underestimates the savings and excludes justified projects.
The time saved per case is not 100%. After automation, verifying results, managing exceptions, and system control still consume time. To remain cautious, calculate savings based on 70% of the initially required time.
Be sure to include annual operating costs. Server costs, external API fees, and maintenance contracts are part of this. A calculated payback period without this item appears shorter than reality.
Example calculation
Substituting values makes judgment clearer. The following is a hypothetical example intended to illustrate the calculation method; actual values vary according to the specific conditions of each company.
Prenons la tâche consistant à reporter dans le système interne les bons de commande reçus des clients par courriel.
| Élément | Valeur |
|---|---|
| Number of cases per month | 400 cas |
| Time required per case | 12 minutes |
| Taux d'économie après automatisation | 70 % |
| Coût salarial complet horaire | 25 000 KRW |
| Coût de mise en œuvre | 18 000 000 KRW |
| Coûts d'exploitation annuels | 2 400 000 KRW |
Le temps économisé par cas s'établit à 12 minutes × 70 % = 8,4 minutes, soit 0,14 heure.
Économies annuelles = 400 × 12 × 0,14 × 25 000 = 16 800 000 KRW
Effet net annuel = 16 800 000 − 2 400 000 = 14 400 000 KRW
Délai de retour = 18 000 000 ÷ (14 400 000 ÷ 12) = 15 mois
Un délai de retour de 15 mois n'atteint pas le critère indiqué plus haut, « moins de six mois pour le premier chantier ». Trois options s'offrent alors : chercher une autre tâche au volume plus élevé, réduire le périmètre de mise en œuvre pour en abaisser le coût, ou reporter ce chantier au second plan.
Appliqué à une tâche de 1 200 cas par mois, le même calcul porte les économies annuelles à 50 400 000 KRW et ramène le délai de retour sous les 5 mois. Le volume de cas gouverne le délai de retour : c'est le point essentiel de ce calcul. Une tâche brève mais fréquente passe généralement avant une tâche plus longue à l'unité.
Étape 4 — Déterminer l'ordre de lancement
Classez les chantiers par délai de retour croissant, mais ne choisissez pas le premier d'entre eux sur le seul délai de retour. Le premier chantier obéit à deux conditions.
- Délai de retour inférieur à six mois
- Une tâche dont l'échec n'interrompt pas l'activité principale
La seconde condition est déterminante. Si la première automatisation provoque un incident sur un processus essentiel, c'est la démarche d'automatisation elle-même qui perd sa crédibilité dans l'organisation. À l'inverse, un premier succès sécurise le budget et la coopération des métiers pour les chantiers suivants. Le premier chantier se choisit sur la fiabilité plutôt que sur l'ampleur.
Les candidats qui ressortent en premier selon le secteur
Selon le secteur, les tâches qui remontent comme candidats de premier rang sont généralement les mêmes. Utilisez cette liste comme référence au moment d'établir votre inventaire.
Industrie et distribution — collecte et saisie des bons de commande par client, alerte sur les stocks passés sous le seuil, génération des ordres d'expédition, collecte des numéros de suivi auprès des transporteurs et notification aux clients, rapprochement de feuilles multiples lors de la clôture mensuelle.
Services et B2B — émission de devis, suivi de l'état des contrats et alertes d'échéance, émission des factures récurrentes, classement des demandes par type et affectation à un interlocuteur, synthèse de l'historique des échanges.
Commerce électronique — notification des changements de statut de commande, classement des demandes de retour et d'échange, synchronisation multicanal des informations produit, collecte et classement des avis, alertes de réapprovisionnement.
Transverse — contrôle des pièces justificatives de temps de présence et de frais, création des comptes des nouveaux arrivants, consolidation des rapports périodiques, synchronisation des données entre systèmes externes.
Cette liste n'est qu'un point de départ. Ne retenez comme candidats réels que ceux qui ont franchi l'évaluation de l'étape 2, car pour une même tâche le taux d'exceptions et la normalisation des formats diffèrent d'une entreprise à l'autre.
Points à vérifier avant le déploiement
Une fois le lancement décidé, assurez-vous que les cinq points suivants sont prêts.
Avez-vous mesuré la référence ? Le temps requis, le nombre de cas traités et le nombre d'erreurs avant le déploiement doivent être consignés. Commencer à mesurer après le déploiement prive de tout point de comparaison.
Le chemin de renvoi des exceptions vers un opérateur est-il conçu ? Des cas que l'automatisation ne saura pas traiter surviendront nécessairement. Ils doivent alors être transmis à la personne en charge, et non échouer silencieusement. Faute de ce chemin, les cas omis ne sont découverts que plusieurs jours plus tard.
Disposez-vous d'un moyen de vous apercevoir que l'automatisation s'est arrêtée ? Lorsqu'une personne cesse de faire son travail, cela se voit. Une automatisation, elle, s'arrête en silence. Une surveillance minimale, du niveau d'une alerte déclenchée lorsque le nombre de cas traités s'écarte de l'ordinaire, doit être en place.
La responsabilité de la maintenance en cas d'évolution du système cible est-elle définie ? Les interfaces et les API des systèmes connectés changent sans préavis. Qui corrige, et dans quel délai, doit être fixé par contrat ou par une règle interne.
Avez-vous vérifié les exigences relatives aux données à caractère personnel et à la réglementation ? Si la tâche visée manipule des informations clients ou des informations relatives aux salariés, certains points doivent être clarifiés avant le lancement.
- Où les données à caractère personnel (PII) sont-elles stockées au cours du traitement et pendant combien de temps sont-elles conservées
- Si des données sont transmises à un service externe, dans quel pays elles sont stockées
- Si un historique de traitement subsiste et permet une traçabilité a posteriori
- Si les droits d'accès sont différenciés selon les personnes
En particulier, lorsque vous recourez à un service d'intelligence artificielle externe, vérifiez impérativement dans les conditions contractuelles si les données saisies sont utilisées pour l'entraînement de ce service. Introduire des informations clients sans avoir contrôlé cette clause transforme une automatisation techniquement satisfaisante en manquement réglementaire. Conserver une étape de vérification humaine des résultats de l'automatisation relève de la même logique.
Développer soi-même ou utiliser l'existant
Une fois le périmètre arrêté, il faut choisir le mode de réalisation. Le critère de décision est de savoir si cette tâche est une source d'avantage concurrentiel.
Si la manière de traiter la tâche, différente de celle des concurrents, constitue précisément la force de l'entreprise, mieux vaut développer sur mesure. À l'inverse, si toutes les entreprises la traitent de la même façon, utiliser une solution déjà éprouvée est plus rapide et moins coûteux. Développer de zéro la gestion des temps de présence ou l'approbation électronique relève, dans la plupart des cas, du gaspillage.
Lors de l'examen d'un produit sur étagère, vérifiez néanmoins trois éléments.
Pouvons-nous aligner nos processus sur le produit ? Les produits sur étagère sont conçus en supposant des procédures standard. Si les pratiques actuelles s'en écartent fortement, la résistance à faire évoluer les processus coûte plus cher que la modification du produit.
Pouvons-nous extraire les données ? Cela sera nécessaire pour migrer plus tard vers autre chose ou pour raccorder le produit au système interne. Vérifiez avant contrat les fonctions d'export et les modalités d'intégration.
Qui est responsable en cas d'arrêt ? Pour une tâche qui dépend d'un service externe, une panne de ce service équivaut à une interruption de notre activité. Faites confirmer par écrit les délais d'intervention et les conditions de compensation en cas d'incident.
Objections fréquentes et façon de les traiter
Les chantiers d'automatisation butent plus souvent sur l'organisation que sur la technique. Connaître à l'avance les objections attendues facilite la réponse.
« La façon de faire actuelle ne pose pas de problème. » C'est généralement exact. Le problème ne se situe pas dans le présent mais dans l'augmentation des volumes. Face à cette objection, présentez non pas la gêne actuelle mais le point de rupture. Calculer et montrer le nombre maximal de cas traitables avec l'effectif actuel est plus convaincant.
« Mon poste ne va-t-il pas disparaître ? » C'est l'objection la plus forte, et elle appelle une réponse frontale. Il faut établir puis exposer d'emblée que la tâche visée est un travail répétitif simple que le collaborateur n'appréciait pas, et préciser à quoi le temps ainsi libéré sera consacré. Sans cette réponse préparée, la coopération fait défaut dès la phase d'enquête.
« Il y a bien trop d'exceptions pour que cela fonctionne. » Cette remarque des métiers est le plus souvent exacte. Ne la contredisez pas : comptez réellement le taux d'exceptions. C'est précisément l'objet de l'évaluation de l'étape 2. Si le comptage confirme un taux élevé, il est juste de retirer cette tâche de la liste des candidats.
« Nous avons déjà essayé et cela a échoué. » Faites préciser les causes de l'échec. Il s'agit dans la plupart des cas de l'un des trois schémas exposés plus haut. Il faut démontrer, éléments à l'appui, que la même erreur ne sera pas répétée.
Les 90 jours qui suivent le déploiement
La mise en service n'est pas la fin, mais le début de la vérification. Contrôlez les points suivants pendant les 90 premiers jours.
Les deux premières semaines — exploitation en parallèle. Faites fonctionner l'automatisation et la méthode existante conjointement, et confrontez les résultats. Les écarts relevés pendant cette période révèlent le taux réel d'exceptions. Basculer directement sans parallèle conduit à découvrir des traitements erronés plusieurs semaines plus tard.
Le premier mois — classement des types d'exceptions. Classez par type les cas renvoyés à un opérateur. Si un type revient de façon répétée, il ne s'agit pas d'une exception mais d'une règle manquante. L'inscrire dans les règles élargit le champ du traitement automatique.
Trois mois — comparaison avec la référence. Mesurez de nouveau le temps requis, le nombre de cas traités et le nombre d'erreurs consignés avant le déploiement, puis comparez. Ce tableau comparatif fonde le budget du chantier suivant.
Si l'effet est resté en deçà des prévisions, consignez également ce fait. Savoir dans quelles conditions une automatisation ne produit pas les résultats attendus constitue l'information la plus précieuse pour choisir le chantier suivant.
Synthèse
Le succès d'une automatisation se joue moins sur le choix de l'outil que sur le choix du périmètre.
- Dressez la liste des tâches répétitives afin de les rendre comparables.
- Distinguez l'automatisation à base de règles de l'automatisation nécessitant un jugement et adoptez des modes de vérification différents.
- Ne conservez comme candidates que les tâches aux règles claires, aux entrées normalisées et aux exceptions peu nombreuses.
- Calculez le délai de retour de façon prudente, en intégrant le coût salarial complet et les coûts d'exploitation. Le nombre de cas pèse davantage sur le résultat que le temps unitaire.
- Choisissez le premier chantier sur la fiabilité et non sur l'ampleur.
- Vérifiez avant le lancement le périmètre de traitement des données à caractère personnel et le lieu de stockage des données.
Et surtout, mesurez la référence avant de commencer. Une amélioration non mesurée ne peut être prouvée, et une amélioration non prouvée n'obtient pas le budget suivant.