Santé / Assurance · Automatisation & RPA
Automatiser trois processus de back-office et en refuser deux autres
Cinq processus candidats à l'automatisation, chronométrés sur le terrain. Trois passaient le seuil de retour sur investissement, deux non. Nous avons documenté pourquoi et n'avons développé que les trois.
- Secteur
- Santé / Assurance
- Taille
- 600 salariés
- Service
- Automatisation & RPA
- Modèle
- Étude puis forfaits
- Durée
- Étude 2 semaines, 3 robots en 11 semaines
Contexte
Le back-office ressaisissait manuellement des données entre l'outil de gestion des adhérents, un extranet partenaire et un tableur de contrôle. La direction avait un budget d'automatisation et une liste de cinq processus fournie par les équipes métier.
Le problème
- Ressaisies manuelles entre trois systèmes sans interface
- Estimations de charge fournies par les équipes, jamais mesurées
- Aucune API disponible sur l'extranet partenaire
- Précédente tentative d'automatisation abandonnée après six mois
Ce que nous avons fait
- Observation et chronométrage des cinq processus réellement exécutés, pendant deux semaines
- Écart constaté entre temps déclaré et temps réel allant de -40 % à +25 % selon le processus
- Calcul de ROI sur trois ans, maintenance incluse, processus par processus
- Deux processus écartés : fréquence trop faible pour l'un, règles de gestion changeant chaque trimestre pour l'autre
- Trois robots UiPath développés avec file d'exceptions et alerte nominative
- Quatre semaines de tourne en double avant bascule sur chaque robot
- Procédure de reprise manuelle écrite et testée pour chaque processus
Résultats
- 3 / 5
- processus retenus
- 1 840 h
- rendues par an
- 9 mois
- de retour sur investissement
- 99,2 %
- de taux de succès à 6 mois
Ce qu'il en reste
Les heures récupérées ont été réaffectées au traitement des dossiers complexes, pas à une réduction d'effectif — c'était une condition posée par la direction dès le départ. Les deux processus écartés ont fait l'objet d'une note expliquant pourquoi, que le client a réutilisée pour arbitrer d'autres demandes en interne.
« Le livrable le plus utile de l'étude, c'est la partie qui explique pourquoi deux processus ne devaient pas être automatisés. On s'en sert encore. »
Technologies
- UiPath
- Power Automate
- SQL Server
- REST API