Cuando un proyecto de automatización se estanca o produce resultados poco fiables, la conversación suele girar en torno al proveedor, la pila tecnológica o la complejidad del flujo de trabajo. Rara vez se dirige hacia lo que con más frecuencia es realmente el responsable: la calidad y la consistencia de los datos contra los que opera el bot.
TrueFocus Automation, una empresa de automatización RPA e IA con sede en Dallas especializada en seguros de títulos y operaciones hipotecarias, se encontró con esto directamente. Tras construir un bot para la planta de títulos propietaria de un cliente, la automatización funcionó hasta que dejó de hacerlo. El proceso parecía ejecutarse correctamente. El equipo del cliente no planteó ninguna preocupación. Luego, llegó un nuevo equipo de operaciones y comenzó a preguntar por qué ciertos documentos no aparecían en las búsquedas.
La respuesta no era un fallo en el bot. Eran décadas de indexación de datos inconsistente.
El problema oculto dentro de los sistemas heredados
Los datos históricos inconsistentes son uno de los modos de fallo más comunes en los proyectos de automatización que involucran plataformas heredadas, bases de datos propietarias o sistemas de registros internos de larga duración, y uno de los menos discutidos.
El cliente en cuestión había estado indexando manualmente los registros de la planta de títulos durante aproximadamente treinta años. A lo largo de ese tiempo, la forma en que se ingresaban esos registros había cambiado. Las convenciones de nomenclatura de documentos no eran consistentes y tenían diferentes referencias a una escritura, como DEED22W/1774, mientras que otros estaban indexados como 22/1774, D22-1774, D22W-1774. Cuando TrueFocus construyó un bot que buscaba por número de documento, solo devolvía los registros indexados de una determinada manera y omitía todo lo ingresado bajo un esquema diferente años antes.
Sridhar Loganathan, COO de TrueFocus Automation, describió el patrón: "Los datos detrás de esto no son consistentes. A lo largo de esos treinta años, cambiaron la forma en que indexaban los documentos. Cuando construimos un bot que buscaba usando el número de documento, solo aparecían esos documentos, no los demás."
El bot hacía exactamente lo que fue construido para hacer. Los datos subyacentes nunca habían sido consistentes desde un principio.
Lo que realmente significa la preparación de los datos antes de automatizar
La preparación de los datos no se trata de si sus datos son digitales. Se trata de si sus datos son suficientemente consistentes para que un sistema basado en reglas pueda consultarlos de manera fiable. Un bot no puede tomar decisiones discrecionales. Si un documento está indexado de una manera en 2003 y de una manera diferente a lo largo de los años, el bot encontrará uno y perderá el otro, siempre, a escala.
Las preguntas que vale la pena hacer antes de que comience cualquier proyecto de automatización incluyen: ¿Cuánto tiempo llevan estos datos en este sistema? ¿Ha cambiado el enfoque de indexación con el tiempo? ¿Eran diferentes equipos los responsables de la entrada de datos en diferentes momentos, y trabajaban con los mismos estándares? ¿Existe algún proceso que valide la consistencia en todo el conjunto de datos?
Estas no son preguntas cómodas, y las respuestas suelen ser peores de lo esperado. Pero sacarlas a la luz durante el proceso de descubrimiento cuesta mucho menos que descubrirlas después de seis meses de desarrollo.
TrueFocus trata ahora este tipo de revisión de datos como una parte estándar de su proceso de descubrimiento, especialmente para los clientes que trabajan con plataformas internas propietarias o de larga duración. La lógica es sencilla: la automatización amplifica lo que ya existe en sus datos. Si los datos son inconsistentes, la automatización saca a la luz esa inconsistencia a velocidad y volumen.
El problema de la participación del cliente que lo empeora
El caso de TrueFocus lleva una segunda lección. La automatización estaba activa y funcionando durante algún tiempo antes de que el problema de calidad de los datos saliera a la superficie. El equipo original que utilizaba el sistema no informó sobre los documentos faltantes, ya fuera porque no lo notaron, no conectaron las lagunas con la automatización o no lo escalaron; el resultado fue el mismo: el problema creció en silencio.
Cuando llegó un nuevo equipo y comenzó a hacer preguntas, las lagunas se hicieron visibles. Para entonces, TrueFocus había estado operando bajo suposiciones sobre el rendimiento del sistema que el cliente nunca había corregido.
Loganathan identificó la causa raíz directamente: al cliente le faltaba un único punto de contacto con un profundo conocimiento de cómo funcionaba su propia plataforma, y no había un ciclo de retroalimentación regular entre las personas que usaban los resultados y el equipo que gestionaba el sistema. El equipo estaba usando la solución pero nunca informaba de que faltaba algo. Sin esa comunicación iterativa, los problemas se acumularon hasta que se volvieron costosos de solucionar.
La automatización requiere supervisión continua. Los bots deben ser monitorizados, las excepciones revisadas, y las personas que dependen de los resultados deben mantenerse en contacto regular con quien gestione el sistema.
Cómo es un proceso de descubrimiento honesto
Para las empresas que evalúan proveedores de automatización, la disposición a sacar a la luz los problemas antes de que comience un proyecto, en lugar de después de la entrega, es una de las cosas más útiles que un proveedor puede ofrecer.
TrueFocus adopta la posición de que identificar un problema de calidad de datos en la primera semana es mejor que entregar una automatización que funcione de manera intermitente y erosione la confianza en la tecnología. Eso significa sesiones de observación en las que el equipo que realiza el trabajo real recorre el proceso en vivo. Significa preguntar no solo cómo funciona el flujo de trabajo hoy, sino cómo ha cambiado con el tiempo y si los datos subyacentes reflejan esos cambios de manera consistente. Y significa estar dispuesto a decirle a un cliente potencial que sus datos no están listos, incluso cuando eso no es lo que quieren escuchar.
En el caso que finalmente terminó con el compromiso de TrueFocus con este cliente, el cofundador Jimmy Lewis tomó la decisión directamente: "Si no podemos hacerlo, digámosles ahora. No quiero alargar esto." Esa conversación llegó más tarde de lo que debería, pero el principio es sólido. Un proveedor dispuesto a decirte que un proyecto no está listo es más valioso que uno que toma el trabajo y entrega algo poco fiable.
Jimmy Lewis es el cofundador de TrueFocus Automation, especialista en automatización de flujos de trabajo impulsada por RPA e IA para los sectores de seguros de títulos, hipotecas e inmobiliario. TrueFocus ha desarrollado más de 840 bots de automatización que soportan más de 2.500 flujos de trabajo y ha devuelto más de 1,3 millones de horas de producción a sus clientes.
Este artículo está basado en información proporcionada por la fuente experta citada anteriormente. Tiene únicamente fines informativos generales y no constituye asesoramiento legal, financiero ni inmobiliario. Los lectores deben realizar su propia investigación y consultar a profesionales cualificados antes de tomar cualquier decisión inmobiliaria o financiera.
