Quand le nombre d'opérations croît plus vite que le chiffre d'affaires, chaque volume supplémentaire exige un recrutement de plus. Voyons quelle part du travail prennent les processus, les robots et l'assistant — et laquelle ils ne prendront jamais.
couches d'automatisation du back-office
processus et robots en fonctionnement
ligne de code pour lancer un processus
Le volume croît linéairement ; le travail de back-office plus vite, car chaque opération traîne une file d'exceptions.
Un versement au-dessus du plafond, un remboursement sur une opération contestée, l'ouverture d'un marchand : chacun demande une chaîne d'accords, et cette chaîne vit dans les courriels.
Exporter depuis le portail du prestataire, déposer dans un dossier, charger dans la comptabilité. Un travail où l'humain sert de câble de liaison.
Où est l'argent de cette opération, pourquoi ce refus, comment émettre un remboursement. La réponse est dans le système, mais la trouver est rarement plus rapide que de demander à un collègue.
À tâches différentes, outils différents. Les confondre coûte cher : un robot ne remplace pas un processus, un assistant ne remplace pas un robot.
Validations, escalades et délais se décrivent par un schéma : qui valide, ce qui se passe au-dessus d'un plafond, où part la tâche si personne ne répond en un jour. C'est le système qui exécute le schéma, pas la mémoire d'un collaborateur.
Là où la contrepartie n'a pas d'API, le robot fait ce que faisait l'humain : il se connecte au portail, prend l'export, dépose le fichier à sa place. Selon un calendrier, et sans oublier.
Il répond aux questions sur les données de votre organisation : statut d'une opération, motif de refus, historique des modifications. Il n'économise pas l'opération mais les minutes de recherche — qui font une heure par jour.
L'automatisation du back-office se vend d'ordinaire comme un outil unique, et c'est sa principale faiblesse. Un robot lancé sur un processus de validation devient une construction fragile : changez l'ordre des accords et il casse. Un processus censé remplacer le transfert de fichiers bute sur l'absence d'API chez la contrepartie. Le bon partage est simple : le processus décrit les décisions, le robot exécute les actions, l'assistant répond aux questions.
La deuxième différence tient à l'auteur de l'automatisation. Un déploiement classique demande un prestataire et un projet de plusieurs mois, après quoi le moindre changement redemande le prestataire. Ici, le processus se construit dans l'espace opérateur par la personne qui y travaille : celle qui sait le mieux où le temps se perd. Le coût d'un changement tombe à une demi-heure, et l'automatisation cesse de vieillir.
Et une limite honnête. L'automatisation ne prendra ni l'analyse d'une opération contestée, ni la négociation des commissions avec le prestataire, ni la décision de verser ou non de l'argent à un bénéficiaire douteux. C'est précisément cela, le travail de back-office. L'intérêt des trois couches est que vos équipes s'y consacrent au lieu de recopier des lignes entre deux fenêtres.
Trois assistants de configuration. L'opérateur les parcourt seul, sans développement.
Étapes, rôles, conditions de passage, délais et escalades. Le processus démarre sur un événement d'opération ou manuellement.
Scénario, calendrier, identifiants et comportement en cas d'échec : réessayer, différer ou passer la main à un humain.
Le périmètre de données accessible, les rôles utilisateurs et les limites : ce à quoi il répond et ce qu'il transmet.
Commencez par le processus, pas par le robot : tant que l'ordre des validations n'est pas décrit, le robot automatisera le désordre et coûtera plus cher que le travail manuel.
Inscrivez-vous et construisez vous-même le premier processus : le schéma tourne sans développement. Les robots et l'assistant viennent ensuite.
Commencer