Lorsqu'un projet d'automatisation s'enlise ou produit des résultats peu fiables, la discussion porte généralement sur le fournisseur, la pile technologique ou la complexité du flux de travail. Rarement se tourne-t-elle vers ce qui en est le plus souvent réellement responsable : la qualité et la cohérence des données sur lesquelles le bot opère.
TrueFocus Automation, une entreprise d'automatisation RPA et IA basée à Dallas, spécialisée dans l'assurance titres et les opérations hypothécaires, en a fait directement l'expérience. Après avoir développé un bot pour le registre de titres propriétaire d'un client, l'automatisation a fonctionné… jusqu'à ce qu'elle ne fonctionne plus. Le processus semblait s'exécuter correctement. L'équipe du client n'a pas soulevé de préoccupations. Puis, une nouvelle équipe opérationnelle est arrivée et a commencé à demander pourquoi certains documents n'apparaissaient pas dans les recherches.
La réponse n'était pas un défaut du bot. C'était des décennies d'indexation incohérente des données.
Le problème caché dans les systèmes hérités
Les données historiques incohérentes constituent l'un des modes de défaillance les plus courants dans les projets d'automatisation impliquant des plateformes héritées, des bases de données propriétaires ou des systèmes d'enregistrement internes de longue date — et l'un des moins discutés.
Le client en question avait indexé manuellement des enregistrements de registre de titres pendant environ trente ans. Au fil du temps, la manière dont ces enregistrements étaient saisis avait évolué. Les conventions de nommage des documents n'étaient pas cohérentes et comportaient différentes références à un acte de propriété, comme DEED22W/1774, tandis que d'autres étaient indexés sous la forme 22/1774, D22-1774, D22W-1774. Lorsque TrueFocus a développé un bot effectuant des recherches par numéro de document, il ne retournait que les enregistrements indexés d'une certaine manière et manquait tout ce qui avait été saisi selon un schéma différent des années auparavant.
Sridhar Loganathan, COO de TrueFocus Automation, a décrit le schéma : « Les données qui se trouvent derrière ne sont pas cohérentes. Au cours de ces trente années, ils ont modifié la façon dont ils indexaient les documents. Lorsque nous avons développé un bot effectuant des recherches par numéro de document, seuls ces documents apparaissaient, pas les autres. »
Le bot faisait exactement ce pour quoi il avait été conçu. Les données sous-jacentes n'avaient jamais été cohérentes dès le départ.
Ce que la préparation des données signifie réellement avant d'automatiser
La préparation des données ne concerne pas le fait que vos données soient numériques. Il s'agit de savoir si vos données sont suffisamment cohérentes pour qu'un système basé sur des règles puisse les interroger de manière fiable. Un bot ne peut pas exercer de jugement. Si un document est indexé d'une façon en 2003 et d'une façon différente au fil des années, le bot en trouvera un et manquera l'autre, à chaque fois, à grande échelle.
Les questions à se poser avant de lancer tout projet d'automatisation incluent : Depuis combien de temps ces données se trouvent-elles dans ce système ? L'approche d'indexation a-t-elle évolué au fil du temps ? Différentes équipes ont-elles été responsables de la saisie des données à différents moments, et travaillaient-elles selon les mêmes normes ? Existe-t-il un processus validant la cohérence de l'ensemble des données ?
Ce ne sont pas des questions confortables, et les réponses sont souvent pires que prévu. Mais les faire émerger lors de la phase de découverte coûte bien moins cher que de les découvrir après six mois de développement.
TrueFocus traite désormais ce type d'examen des données comme une partie standard de son processus de découverte, en particulier pour les clients travaillant avec des plateformes propriétaires ou internes de longue date. La logique est simple : l'automatisation amplifie ce qui se trouve déjà dans vos données. Si les données sont incohérentes, l'automatisation met en évidence cette incohérence à grande vitesse et à grande échelle.
Le problème d'engagement client qui aggrave les choses
Le cas TrueFocus porte une seconde leçon. L'automatisation était en production depuis un certain temps avant que le problème de qualité des données ne se manifeste. L'équipe d'origine utilisant le système n'a pas signalé les documents manquants — qu'elle ne les ait pas remarqués, n'ait pas fait le lien entre les lacunes et l'automatisation, ou n'ait pas remonté le problème, le résultat était le même : le problème a grossi silencieusement.
Lorsqu'une nouvelle équipe est arrivée et a commencé à poser des questions, les lacunes sont devenues visibles. À ce stade, TrueFocus avait opéré sur la base d'hypothèses concernant les performances du système que le client n'avait jamais corrigées.
Loganathan a identifié la cause profonde directement : le client manquait d'un interlocuteur unique ayant une compréhension approfondie du fonctionnement de leur propre plateforme, et il n'existait aucune boucle de retour régulière entre les personnes utilisant les résultats et l'équipe gérant le système. L'équipe utilisait la solution sans jamais signaler qu'il manquait quoi que ce soit. Sans cette communication itérative, les problèmes se sont accumulés jusqu'à devenir coûteux à résoudre.
L'automatisation nécessite une supervision continue. Les bots doivent être surveillés, les exceptions examinées, et les personnes qui s'appuient sur les résultats doivent rester en contact régulier avec ceux qui gèrent le système.
À quoi ressemble un processus de découverte honnête
Pour les entreprises qui évaluent des fournisseurs d'automatisation, la volonté de faire émerger les problèmes avant le début d'un projet, plutôt qu'après la livraison, est l'une des choses les plus utiles qu'un fournisseur puisse offrir.
TrueFocus adopte la position selon laquelle identifier un problème de qualité des données dès la première semaine vaut mieux que de livrer une automatisation qui fonctionne de manière intermittente et érode la confiance dans la technologie. Cela implique des sessions d'observation où l'équipe réalisant le travail effectif parcourt le processus en direct. Cela signifie demander non seulement comment le flux de travail fonctionne aujourd'hui, mais comment il a évolué au fil du temps et si les données sous-jacentes reflètent ces changements de manière cohérente. Et cela implique d'être prêt à dire à un client potentiel que ses données ne sont pas prêtes, même lorsque ce n'est pas ce qu'il souhaite entendre.
Dans le cas qui a finalement mis fin à l'engagement de TrueFocus avec ce client, le co-fondateur Jimmy Lewis a pris la décision directement : « Si nous ne pouvons pas le faire, disons-le leur maintenant. Je ne veux pas faire traîner les choses. » Cette conversation est venue plus tard qu'elle n'aurait dû, mais le principe est solide. Un fournisseur prêt à vous dire qu'un projet n'est pas prêt est plus précieux que celui qui accepte le travail et livre quelque chose de peu fiable.
Jimmy Lewis est le co-fondateur de TrueFocus Automation, spécialiste de l'automatisation des flux de travail RPA et piloté par l'IA pour les secteurs de l'assurance titres, du crédit hypothécaire et de l'immobilier. TrueFocus a développé plus de 840 bots d'automatisation prenant en charge plus de 2 500 flux de travail et a restitué plus de 1,3 million d'heures de production à ses clients.
Cet article est basé sur des informations fournies par la source experte citée ci-dessus. Il est destiné à des fins d'information générale uniquement et ne constitue pas un conseil juridique, financier ou immobilier. Les lecteurs doivent effectuer leurs propres recherches et consulter des professionnels qualifiés avant de prendre toute décision immobilière ou financière.
