Pourquoi l'automatisation des flux de travail dans l'assurance échoue face aux exceptions

Le client d’un courtier ajoute dix voitures à une police de flotte. Neuf passent. La dixième est signalée comme volée et ne peut pas être assurée. L'automatisation qui devait traiter la demande n'a plus que deux mauvaises options : faire échouer tout le lot, ou en valider neuf et laisser la dixième dans la boîte de réception de quelqu’un sans aucune indication sur ce qui s’est mal passé.

La plupart des équipes d’assurance connaissent une variante de cette histoire. Le dossier sans anomalie passe sans problème, et tout ce qui s'écarte légèrement de la norme revient vers une personne qui dispose de moins de contexte qu'avant la mise en place de l'automatisation. McKinsey estime que plus de la moitié des activités actuelles de gestion des sinistres pourraient être automatisées d’ici 2030, tout en précisant que les sinistres complexes continueront de nécessiter un jugement humain. Le travail qui reste confié aux personnes est celui qui est sorti du cadre prévu, ce qui en fait précisément la partie pour laquelle il est le plus utile de concevoir les processus.

Le happy path est un choix délibéré

Les flux de travail sont généralement modélisés à partir de la cartographie des processus ou du formulaire. Une demande arrive, les documents sont reçus, les données sont vérifiées, le système est mis à jour et le client reçoit une réponse. Chaque étape suppose que la précédente s'est bien déroulée. C’est un point de départ logique, et cela décrit le processus idéal que l'équipe aimerait avoir.

Les chercheurs en process mining ont créé tout un domaine d'étude autour de cet écart. Leur manifeste propose d'étudier les processus réels par opposition aux processus théoriques, car ce que montrent les journaux d'événements correspond rarement au schéma. Dans un bureau d'assurance, cet écart ressemble à un numéro de compte manquant ou à une réponse qui répond à une autre question.

Cela explique aussi pourquoi tant de premiers projets d'automatisation déçoivent. EY a rapporté que 30 à 50 pour cent des projets initiaux d'automatisation robotisée des processus échouent, et l'une des erreurs récurrentes sur sa liste est de choisir des processus trop complexes pour l'outil. Dans l'assurance, la complexité se traduit généralement par des exceptions.

Lisanne Bainbridge a identifié le problème de fond dès 1983. Dans Ironies of automation, elle a démontré que lorsqu'une machine prend en charge le travail de routine, les personnes se retrouvent avec les tâches qui ne pouvaient pas être automatisées, tout en ayant moins d'occasions de s'y exercer. Automatisez la partie facile d'un flux de sinistres et la journée d'un gestionnaire se transforme en un défilé continu de cas difficiles, sans les dossiers de routine qui lui apportaient auparavant du contexte.

Où les dossiers quittent le chemin prévu

Les sorties de route sont prévisibles dès lors qu'on prend la peine de les consigner. La plupart trouvent leur origine chez le client ou dans le document, et très peu dans le système lui-même.

La première ligne est la plus courante, et c'est rarement la faute du client. Un courtier belge nous l'a décrit ainsi :

L'e-mail contenant deux demandes est plus difficile à repérer, et tout aussi fréquent. Un assureur avec lequel nous avons échangé estimait qu'environ 60 pour cent des e-mails clients qu'il souhaitait automatiser contenaient plus d'une demande. Un flux de travail qui attend une seule intention par message traite chacun de ces e-mails comme une exception.

Où va l'exception ensuite

Une exception est rarement difficile à résoudre. Le coût réside dans le passage de relais. Le dossier quitte le flux de travail sous la forme d'un e-mail ou d'une notification, atterrit dans une boîte de réception partagée, est transféré et ouvert par deux ou trois personnes avant que quiconque ne s'en charge. Le client attend, tout comme l'assureur ou le courtier de l'autre côté.

Le McKinsey Global Institute a estimé que les travailleurs du savoir consacrent environ 28 pour cent de leur semaine à gérer leurs e-mails. Dans un cabinet ou une compagnie d'assurance, une part importante de ces courriels est constituée d'exceptions qui reviennent, car chaque dossier qui sort du flux revient sous forme de message que quelqu'un doit lire et acheminer. L'animation ci-dessous montre cette différence à petite échelle. Basculez entre les deux paramètres pour voir où aboutissent les mêmes exceptions.

Mettre un chiffre dessus

Peu d'équipes savent ce que leur coûtent leurs exceptions, car ce temps est dispersé entre de nombreuses personnes et de multiples petites interruptions. Une estimation approximative suffit pour décider si le jeu en vaut la chandelle. Les valeurs par défaut ci-dessous illustrent le cas d'un bureau de taille moyenne : n'hésitez pas à les remplacer par vos propres chiffres.

Avec 400 dossiers par mois, dont un quart sort du flux et nécessite 35 minutes de traitement chacun, l'équipe passe environ 58 heures par mois sur les exceptions. Cela représente près d'un mi-temps. La majeure partie du temps est consacrée à retrouver le dossier et à relancer le client. La résolution en elle-même est généralement rapide.

Concevoir pour le dossier qui tourne mal

Un flux de travail capable de survivre aux exceptions est construit autour du dossier. Le dossier regroupe les messages, les documents, les données et le statut, de sorte qu'une exception devient un état du dossier avec un responsable et un historique. En pratique, quatre habitudes font toute la différence.

1. Terminez ce que vous pouvez, transmettez le reste avec du contexte. Neuf voitures sont ajoutées et confirmées au client. La dixième devient une tâche indiquant pourquoi elle a été bloquée.

2. Acceptez le dossier quelle que soit sa forme d'arrivée. Une réponse à un ancien fil ou une lettre numérisée est lue et rattachée au bon dossier, quel que soit son canal d'entrée.

3. Laissez le système signaler ses incertitudes. Si un numéro de contrat ne peut pas être mis en correspondance, le dossier le signale pour qu'une personne vérifie, évitant ainsi qu'un numéro mal lu ne se propage plus loin.

4. Indiquez clairement qui le dossier attend. Lorsque l'équipe peut voir d'un coup d'œil si la prochaine action lui incombe ou revient au client, les exceptions ne restent plus invisibles dans les zones d'ombre entre collaborateurs.

Les humains restent au cœur du processus. Ils se concentrent sur la partie où leur jugement fait la différence, avec tout le contexte nécessaire pour l'exercer.

Un compromis honnête

Concevoir pour les exceptions demande plus d'efforts au départ. Il faut déterminer à qui incombe chaque type d'exception et définir la solution de repli lorsque les données ne correspondent pas. Une automatisation limitée au cas idéal (« happy path ») est plus rapide à concevoir et bien plus séduisante en démonstration. Mais la différence se fait sentir quelques mois plus tard, lorsque le volume grandit et que les exceptions augmentent avec lui.

Un bon test consiste à prendre les exceptions du mois dernier et à déterminer où chacune d'elles a patienté, et pendant combien de temps. Si la réponse honnête est « dans la boîte de réception de quelqu’un », c'est là que réside votre prochain axe d'amélioration.

C'est pour cette raison que Penbox est articulé autour du dossier. Les automatisations de dossiers font avancer un dossier dès que ses données changent et consignent chaque étape dans la chronologie, une automatisation en échec peut être réessayée, et chaque dossier indique s'il est en attente de votre équipe ou du client. Email Intelligence et document intelligence lisent ce qui arrive et le rattachent au bon dossier, afin que les exceptions restent visibles et prêtes à être traitées.

Pour aller plus loin, découvrez pourquoi la réception des déclarations de sinistre est un problème de lecture, ce que les échanges d'e-mails à répétition coûtent à une équipe, ou comment le processus FNOL fonctionne pour les courtiers. Si vous découvrez tout juste cette approche, commencez par comprendre ce qu'est la gestion de dossiers.