Investir dans l'Automatisation des Processus Métier : Par Où Commencer

La situation à laquelle les entreprises sont confrontées aujourd'hui

Les coûts de main-d'œuvre augmentent et le recrutement devient plus difficile. Pourtant, le volume de travail à traiter n'a pas diminué. De nombreuses entreprises tentent de combler cet écart par l'automatisation, mais lorsqu'il est temps de commencer, elles se heurtent à la question de par où commencer.

Le problème n'est pas un manque de choses à automatiser. C'est qu'il y en a trop. Même les entreprises disposant d'un système complet de gestion des ressources d'entreprise passent une part substantielle de leur temps de travail réel en dehors du système. Extraire un bon de commande d'un e-mail et le retaper dans le système, copier un numéro de suivi depuis le site d'un fournisseur logistique dans un modèle client, réconcilier manuellement plusieurs feuilles de calcul à chaque clôture de période — ce sont des cas typiques.

Individuellement, ces tâches semblent triviales. C'est pourquoi elles figurent rarement sur une liste d'amélioration. Mais si une personne passe 90 minutes par jour sur ce type de travail, une organisation de 20 personnes perd environ 7 500 heures par an. C'est la charge de travail de 3,5 employés à temps plein.

La perte la plus importante n'est pas le temps mais les erreurs et les retards. La transcription manuelle produit toujours des fautes de frappe, et le traitement s'arrête chaque fois que la personne responsable est absente. Comme ce coût n'est enregistré dans aucun livre, au moment où il se manifeste, il a déjà pris la forme d'une plainte client ou d'un délai manqué.

Pourquoi les projets d'automatisation ne répondent pas aux attentes

Lorsqu'une initiative d'automatisation échoue, la cause réside généralement non pas dans la technologie mais dans la sélection des candidats. Trois schémas se répètent.

Premièrement, le processus choisi était dominé par des exceptions. Si plus de la moitié des cas nécessitent un traitement d'exception, l'automatisation ne réduit pas le travail ; elle crée une nouvelle tâche de vérification de l'exactitude du résultat automatisé. Du point de vue de l'opérateur, la charge de travail a augmenté.

Deuxièmement, les données d'entrée n'étaient pas structurées. Les bons de commande dont le format varie selon le fournisseur, ou les feuilles de calcul dont l'ordre des colonnes change à chaque fois, nécessitent une normalisation du format avant toute automatisation. Sauter cette étape et la logique de traitement des exceptions continue simplement de croître.

Troisièmement, il n'y avait pas de référence pour mesurer l'effet. Si le temps de traitement n'est pas enregistré avant le déploiement, il ne reste après que l'impression que les choses "semblent plus rapides". Lorsque le retour sur investissement ne peut pas être démontré, le budget pour la prochaine initiative n'est pas sécurisé non plus.

Ces trois questions peuvent être résolues avant le début des travaux. C'est pourquoi un diagnostic est nécessaire.

Distinguer d'abord les deux types d'automatisation

Avant de commencer le diagnostic, diviser l'automatisation en deux types simplifie le jugement.

L'automatisation basée sur des règles prend en charge le travail dont les conditions et le traitement sont clairement définis. Des tâches telles que "lorsqu'un bon de commande arrive, lire les lignes et les enregistrer dans le système" ou "chaque matin, envoyer une liste d'articles dont le stock est tombé en dessous du seuil". Le résultat est toujours le même, la vérification est simple, et le coût de construction est relativement bas.

L'automatisation basée sur le jugement traite le travail où l'entrée varie à chaque fois et où il n'y a pas de réponse unique correcte. Classer des demandes en libre format, extraire uniquement les champs requis de documents à mises en page incohérentes, ou répondre à des questions clients en prose relèvent tous de cette catégorie. Son champ d'application est beaucoup plus large, mais elle doit être conçue en supposant qu'elle peut se tromper.

Les deux types sont vérifiés différemment. Pour l'automatisation basée sur des règles, il suffit de vérifier si elle a fait exactement ce qui était spécifié, tandis que l'automatisation basée sur le jugement nécessite que la tolérance à l'erreur et le point d'intervention humaine soient définis à l'avance. Gérer les deux selon la même norme sans faire cette distinction entraînera invariablement des problèmes pour la seconde.

Un cadre de diagnostic en quatre étapes

Étape 1 — Établir un inventaire des tâches

Listez les tâches répétitives dans chaque département et enregistrez trois choses pour chacune.

• Volume mensuel
• Temps par cas
• Nombre de personnes qui s'en occupent

L'objectif de cette étape n'est pas la précision mais une liste comparable. Tenter de mesurer à la minute et l'enquête elle-même ne finira jamais. Demandez à la personne effectuant le travail combien de minutes cela prend environ et notez la réponse. Affiner la marge d'erreur sera suffisant plus tard, une fois les candidats réduits.

En pratique, une organisation de 20 à 30 personnes produit une liste de 40 à 60 éléments. L'acte de compiler la liste est déjà utile en soi. Des tâches répétitives que même le responsable de département ne connaissait pas apparaissent souvent à ce stade.

Une précaution lors de l'enquête. Ne demandez pas aux gens ce qu'ils aimeraient automatiser. Formulé ainsi, vous obtiendrez le travail qu'ils détestent le plus, et non le travail le mieux adapté à l'automatisation. Leur demander de décrire ce qu'ils ont fait hier dans l'ordre chronologique est plus précis.

Étape 2 — Évaluer l'adéquation à l'automatisation

Évaluez chaque tâche selon quatre axes.

Ne conserver comme candidats de première sélection que les tâches évaluées comme "suitable" sur les quatre axes. Si un axe est "unsuitable", classifiez la tâche comme celle dont la condition préalable doit être résolue avant l'automatisation. Lorsque la structure de l'entrée est inappropriée, par exemple, il ne s'agit pas d'une initiative d'automatisation mais d'une initiative de standardisation de format.

Il existe une méthode simple pour juger de la clarté des règles. Demandez à la personne effectuant le travail si elle pourrait transmettre la tâche à un nouvel arrivant en utilisant uniquement la documentation. Un travail qui ne peut pas être transmis sur papier ne peut pas non plus être confié à une machine.

Une évaluation inappropriée de la structure de l'entrée n'est pas un motif immédiat d'abandon, car c'est un domaine que l'automatisation basée sur le jugement, comme distingué ci-dessus, peut couvrir. Dans ce cas, cependant, l'objectif de précision et la procédure de révision doivent être conçus en parallèle, donc prévoyez une période de préparation plus longue que pour une initiative basée sur des règles.

Étape 3 — Calculez la période de retour sur investissement

Prenez des mesures précises uniquement pour les candidats de première sélection, puis calculez la période de retour sur investissement.

Annual savings = monthly volume × 12 × time saved per case × hourly labour cost
Payback period (months) = build cost ÷ ((annual savings − annual running cost) ÷ 12)

Trois points nécessitent de l'attention.

Fixez le coût horaire de la main-d'œuvre sur une base entièrement chargée, et non sur le salaire. En incluant l'assurance légale, les dispositions de licenciement et l'espace de bureau, cela représente généralement 1,3 à 1,5 fois le salaire. Fixez ce chiffre au salaire seul et les économies sont sous-estimées, entraînant le rejet d'initiatives réellement solides.

Le temps économisé par cas n'est pas de 100%. Même après l'automatisation, du temps est consacré à la vérification des résultats, à la gestion des exceptions et à la surveillance du système. Pour une estimation prudente, comptez 70 % du temps de traitement existant comme étant l'économie.

Prenez toujours en compte le coût de fonctionnement annuel. Les coûts des serveurs, les frais d'API externes et les contrats de maintenance appartiennent ici. Une période de retour sur investissement calculée sans cet élément est plus courte que la réalité.

Un exemple concret

Substituer des chiffres rend le jugement clair. Ce qui suit est un exemple hypothétique destiné à illustrer la méthode de calcul ; les valeurs réelles varieront selon les circonstances de chaque entreprise.

Supposons la tâche de transférer les commandes d'achat reçues par e-mail de la part des fournisseurs dans un système interne.

Time saved per case is 12 minutes × 70% = 8.4 minutes, that is, 0.14 hours.

Annual savings    = 400 × 12 × 0.14 × 25,000 = 16,800,000 KRW
Annual net effect = 16,800,000 − 2,400,000 = 14,400,000 KRW
Payback period    = 18,000,000 ÷ (14,400,000 ÷ 12) = 15 months

A payback period of 15 months falls short of the "within six months for a first initiative" criterion set out below. In that case there are three options: find another task with a higher volume, narrow the build scope to lower the cost, or defer the initiative.

Apply the same calculation to a task running at 1,200 cases a month and the annual saving becomes 50,400,000 KRW, with the payback period dropping below five months. Volume dominates the payback period — that is the essential lesson of this calculation. Work that is short per case but occurs often generally comes before work that takes longer per case.

Stage 4 — Decide the order of execution

Sort by shortest payback period, but do not choose the first initiative on payback period alone. The first initiative has two conditions.

• A payback period within six months
• Work whose failure would not halt the core business

The second condition matters. If the first automation causes problems in a critical process, automation as an undertaking loses credibility inside the organisation. Conversely, a first success secures the budget and the cooperation of the business side for what follows. The first initiative is rightly chosen for certainty rather than scale.

Candidates that surface first, by industry

The tasks that come forward as first-round candidates are largely predictable by industry. Use the following as a reference list when building the inventory.

Manufacturing and distribution — collecting and entering purchase orders by supplier, alerts for stock below threshold, generating shipping instructions, collecting tracking numbers from logistics providers and notifying customers, multi-spreadsheet reconciliation at period close.

Services and B2B — issuing quotations, tracking contract status and expiry alerts, issuing recurring invoices, classifying enquiry types and assigning owners, summarising consultation histories.

E-commerce — order status change notifications, classifying returns and exchanges, synchronising product information across channels, collecting and classifying reviews, back-in-stock alerts.

Common to all — verifying attendance and expense documentation, provisioning accounts for new joiners, compiling periodic reports, synchronising data between external systems.

This list is only a starting point. Recognise as genuine candidates only those that pass the Stage 2 assessment, because exception rates and format structure differ from company to company even for the same task.

Checks before deployment

Once you have decided to proceed, confirm that the following five things are in place.

Have you measured the baseline. Processing time, case volume and error counts before deployment must be recorded. Begin measuring after deployment and there is nothing to compare against.

Is there a designed path for handing exceptions to a person. Cases the automation cannot handle will certainly arise. When they do, they must pass to a person rather than fail silently. Without this path, missed cases are discovered days later.

Do you have a means of noticing that the automation has stopped. When a person stops doing something, it is visible. Automation stops quietly. At minimum, put in place monitoring sufficient to raise an alert when throughput deviates from the norm.

Is maintenance responsibility defined for when the target system changes. The interfaces and APIs of integrated systems change without notice. Who fixes them, and by when, must be set out in the contract or in internal policy.

Have you checked personal data and regulatory requirements. If the process being automated handles customer or employee information, there are items to settle before work begins.

• Where personally identifiable information is stored during processing, and for how long it is retained
• If data is transmitted to an external service, in which country that data is stored
• Whether a processing record is retained so that activity can be traced after the fact
• Whether access rights are separated by role

Where an external artificial intelligence service is used in particular, always verify in the contract terms whether the data you submit is used to train that service. Enter customer information without checking this clause and an automation that works perfectly well in technical terms becomes a compliance breach. Retaining a step in which a person reviews the automated output is necessary for the same reason.

Build it yourself, or use what already exists

Once the target is settled, the implementation approach must be chosen. The deciding question is whether the work in question is a source of competitive advantage.

If handling the work differently from competitors is itself a strength of the company, building to fit is the better course. Conversely, if every company handles the work the same way, using something already proven is faster and cheaper. Building attendance tracking or electronic approval from scratch is, in most cases, waste.

When evaluating off-the-shelf products, however, check three things.

Can our processes be adapted to the product. Off-the-shelf products are built on the assumption of a standard procedure. Where current practice diverges sharply from that assumption, resistance to changing the process costs more than modifying the product.

Can the data be extracted. This is needed when migrating to something else later or connecting to internal systems. Confirm the data export function and the integration method before signing.

Who is accountable when it stops. For work that depends on an external service, an outage at that service is an outage in your operations. Obtain the response times and remedies in the event of an outage in writing.

Common objections and how to handle them

Automation initiatives are blocked more often by the organisation than by the technology. Anticipating the objections makes them easier to answer.

"There is nothing wrong with the way we do it now." Usually true. The problem arises not now but when volume grows. Answer this objection by presenting the breaking point rather than present-day inconvenience. Calculating and showing the maximum volume the current headcount can process is more persuasive.

"Does this mean my job disappears." This is the strongest objection and must be answered directly. Explain that the target is the simple, repetitive work the person already disliked, and decide in advance where the freed-up time will go before telling them. Without an answer ready, you will not secure cooperation even at the survey stage.

"There are too many exceptions for this to work." From the business side, this claim is usually accurate. Do not argue; count the exception rate for real. That is precisely the purpose of the Stage 2 assessment. If the count shows many exceptions, removing the task from the candidate list is the correct outcome.

"We tried this before and it failed." Establish the specific cause of the failure. In most cases it is one of the three patterns set out above. Demonstrate, with evidence, that the same mistake will not be repeated.

The first 90 days after deployment

Go-live is not the end but the start of verification. Confirm the following over the first 90 days.

First two weeks — parallel operation. Run the automation alongside the existing method and compare the results. The discrepancies found in this period reveal the true exception rate. Switch over directly without a parallel period and incorrect processing will be discovered weeks later.

First month — categorise the exceptions. Classify the cases passed to a person by type. Where a particular type recurs, it is not an exception but a missing rule. Incorporating it into the rules widens the scope of automatic processing.

Three months — compare against the baseline. Measure processing time, case volume and error counts again and compare them with the figures recorded before deployment. This comparison is the budgetary basis for the next initiative.

If the effect fell short of expectations, record that too. Knowing the conditions under which automation does not perform as hoped is the most valuable information available when choosing the next initiative.

Summary

Automation succeeds or fails on candidate selection rather than tool choice.

• Turn repetitive tasks into a list so that they can be compared.
• Distinguish rule-based automation from judgement-based automation and verify each differently.
• Keep as candidates only work with clear rules, structured input and few exceptions.
• Calculate the payback period conservatively, reflecting fully loaded labour cost and running cost. Volume dominates the outcome more than time per case.
• Choose the first initiative for certainty, not scale.
• Confirm the scope of personal data processing and the location of data storage before work begins.

Above all, measure the baseline before you begin. An improvement that is not measured cannot be proven, and an improvement that is not proven receives no further budget.