No es Oro todo Proceso que Reluce
Autor: Txema Fernández | Client Success Manager | RPA Technologies
Madrid, 23 de mayo de 2024 – Hay una frase sabía que dice “Lo peor de cometer errores, es no aprender de ellos” y si ese aprendizaje lo compartes para que otros no caigan en los mismos errores, o parecidos, se entiende que además de ser mejor persona, hacemos una comunidad mucho más preparada y fuerte.
Con este objetivo voy a compartir con todos vosotros uno de los errores que en los últimos años siempre me viene a la cabeza cuando pienso en «cagadas» que he cometido y que podrían haber sido fácilmente corregibles. Si esto sirve para que alguno que esté leyendo el artículo evite caer en la misma equivocación, daré por bien empleado el tiempo en redactarlo y en compartir con vosotros algo que normalmente no estamos acostumbrados.
Es cierto, que en nuestra cultura no está bien visto exponer al público los fracasos y desaciertos que uno comete. En cambio, en la cultura anglosajona éstos son considerados como una gran oportunidad, y la mejor forma de progresar y ser mejores. Ellos, al igual que yo, piensan que es imposible llegar al éxito sin haber fracasado en algún momento. Por este motivo, comparto con vosotros esta experiencia y os invito a que, si queréis, compartáis las vuestras.
Pues empecemos por poneros en contexto. Dentro del proyecto de transformación que quería llevar la empresa se decidió “practicar” con procesos que se hicieran internamente, y así evitar el riesgo de involucrar a un cliente. En primera instancia, se solicitó a las áreas internas que nos proveyesen de casos de uso donde tuvieran necesidad de eficiencia.
Todos los departamentos internos nos mandaron sus procesos candidatos a ser automatizados. Muchos de ellos estaban destinados a morir. Les pedimos que en esas candidaturas nos incluyesen la periodicidad y el volumen de registros que se hacían. Muchos eran procesos que se ejecutaban una sola vez al mes o semanalmente. En esas circunstancias era complicado conseguir el retorno de la inversión.
Cada vez que recibíamos los candidatos para automatizar de cada departamento, manteníamos una reunión con cada uno de ellos para que nos contarán un poquito de cada uno de los procesos. En la reunión con Recursos Humanos les preguntamos directamente por un proceso que tenía decenas de miles de casos al año, la gestión de partes de bajas médicos.
El proceso era relativamente sencillo. Se escaneaba el parte de baja que mandaba el empleado, y después se subía al ERP los datos necesarios que contenía el parte, junto con el propio documento justificante. Además, este proyecto iba a necesitar de la utilización una herramienta de captura y procesamiento de datos para automatizar la extracción y validación de información de los documentos.
Antes de hacer nada, como estábamos acostumbrados, hicimos un «business case» rápido. Para ello además de la volumetría necesitábamos el TMO o tiempo medio de la operación, es decir, lo que se tardaba en leer y extraer los datos del parte y en introducir la información en Meta4, el sistema donde se administraban los recursos humanos de la empresa. Había una excepción en esta parte, en el caso de las renovaciones, no se requería introducir los datos dentro.
Los resultados eran muy esperanzadores. Calculamos que en la lectura y extracción se dedicaban 3 minutos de media y en la parte de grabación en Meta4, otros 2 minutos. No fueron estimaciones muy altas. Teniendo en cuenta que en la parte de grabación pusimos un factor corrector del 50%, según nuestros cálculos, se dedicaban al mes casi 400 horas a la gestión de partes de bajas médicos. Esto llevado a FTE (Full Time Employee), con una productividad del 80%, conseguíamos un ahorro de algo más de 3 FTEs anualmente.
Otro de los retos que nos encontramos en este proyecto era la entrada de los datos. El soporte de todas estas operaciones era en papel. Los trabajadores enviaban a la empresa el papel que les había dado el médico o la mutua. Veíamos que para obtener el ahorro completo era necesario digitalizar este proceso. A pesar de que se mantuviera la entrega del papel, propusimos que el trabajador adelantara vía formulario web con el móvil el parte de baja.
Utilizando la tecnología de ABBYY que permitía la lectura y captura desde el móvil, propusimos que el trabajador recibiera un enlace y directamente hiciera una foto a través de esta herramienta. La solución reconocía la plantilla de parte – existen diferencias entre las 17 comunidades autónomas y también entre las mutuas – y señalaba los campos que iba a extraer de cada documento.
La bondad de esto es que la captura del dato se hacía en tiempo real y esto permitía que los datos extraídos fueran confirmados y verificados para el usuario. De esta manera habíamos eliminado el escaneo y almacenaje de los documentos a través de la fotocopiadora de la empresa.
Todo eran bondades para modernizar el proceso y a la vez hacerlo automático con un bajo porcentaje de casos fallidos que tuvieran que ser revisados por algún técnico del departamento de Recursos Humanos.
Ahora llegaba el momento de calcular los esfuerzos. Teníamos una variedad finita de tipos documentales. 17 variantes de los Servicios Públicos de Salud, 3 variantes del Instituto Nacional de la Seguridad Social, y 20 variantes por Mutua de Trabajo. Se determinó, con el asesoramiento del fabricante, realizar 3 plantillas y 30 variantes, que son pequeñas variantes de esas plantillas. A eso había que añadir el coste de desarrollar el robot de grabación de datos en Meta 3 junto con el desarrollo del scripting para la captura móvil.
A esos esfuerzos había que añadirle los costes de licenciamiento del software RPA y de la solución de ABBYY. En este último caso se decidió por la solución Cloud con una volumetría de 100.000 documentos. Por la parte de la licencia Robot se estimó la necesidad de tener una licencia totalmente dedicada al proceso, ya que los partes podían llegar en cualquier momento.
A modo de resumen, los costes del proyecto el primer año, suponían 45% del ahorro bruto que se alcanzaría. En el segundo año y siguientes, los costes sólo supondrían el 32% de ese ahorro de FTEs. Todo tenía sentido y estábamos seguros de que el proyecto seguiría para adelante.
Nos emocionamos tanto, que ya pensamos en la posibilidad de ofrecer la lectura de partes de bajas médicos como servicio. En 2019, había un total de 12.604.572 bajas médicas en España. El número de partes era mayor porque una baja como mínimo tiene el parte de baja y el parte de alta. También averiguamos que la duración media de las bajas era de 38,56 días. Teniendo en cuanta que las revisiones eran semanales, teníamos que en España se gestionaban más de 80 millones de partes al año.
He entrado en detalle, y no todo porque no puedo, para que quede constancia que todo estaba analizado. Incluso nos tomamos la molestia de hacer 3 plantillas para la demostración a nuestro cliente interno. Extraía la información perfectamente. Estábamos seguros de que nuestros compañeros de Recursos Humanos iban a rendirse a nuestros pies y nos iban a estar eternamente agradecidos.
Montamos una reunión para compartir con nuestros compañeros de Recursos Humanos el trabajo que habíamos hecho y para que nos dieran la aprobación al proyecto para ponernos manos a la obra.
Nuestra sorpresa fue que cuando estábamos compartiendo el Business Case, el responsable de administración de Recursos Humanos nos trasladó que toda la gestión de los partes de bajas médicos lo hacía una persona de su equipo en media jornada. Quizás los días que había más partes tardaba un poco más, pero se compensaba con los días que había menos.
¡Nuestro gozo en un pozo! Después de todo el trabajo que habíamos desarrollado, el proyecto no salió adelante porque no había ahorro y no compensaba hacer la inversión que proponíamos. Desde el otro lado no lo consideraban inversión, para ellos era un coste.
El gran error que se cometió fue no verificar adecuadamente los datos de volumetría y tiempo empleados en el proceso antes de desarrollar nuestra propuesta. Asumimos que el proceso de gestión de partes de bajas médicas requería mucho más tiempo del que realmente necesitaba.
Se debió confirmar directamente con el equipo de Recursos Humanos la realidad operativa del proceso, lo que resultó en una sobreestimación de los ahorros potenciales y, en última instancia, llevó al rechazo de nuestra propuesta por falta de justificación económica.
Pero de todo error salen importantes lecciones aprendidas que me gustaría compartir con vosotros, porque así podréis conseguir proyectos exitosos sin necesidad de tropezar en esta piedra.
Es muy importante validar los datos de partida. El error que cometimos se debió en gran parte a no haber confirmado antes que nada los datos de volumetría y tiempo que se empleaban en ese proceso. Es crucial validar los datos con las personas que están directamente involucradas en el proceso diario antes de hacer cualquier análisis o propuesta. Esto incluye hablar directamente con los operativos y obtener datos reales y actualizados.
Para verificar esta información se nos ocurre implementar una metodología que nos ayude a evitar estos problemas. Siempre que comencéis un proyecto de exploración de las posibilidades de automatización podría ser recomendable hacer alguna o todas de las siguientes acciones.
- Entrevistas en Profundidad: Realizar entrevistas detalladas con las personas que ejecutan los procesos y sus supervisores.
- Observación Directa: Pasar tiempo observando el proceso en acción para comprender las realidades operativas.
- Recolección de Datos Históricos: Utilizar registros históricos para validar la frecuencia y duración de las tareas.
- Simulación del Proceso: Realizar simulaciones del proceso para comprobar las estimaciones de tiempo y recursos.
No estaría mal que a la hora de sacar las conclusiones de estas acciones, tuviéramos una sesión de revisión de los expertos en el tema para que revisen las suposiciones y cálculos antes de ponernos manos a la obra. Si esto lo combinamos con una comunicación continua y abierta con todos los interesados en el proyecto mientras lo estamos bocetando, seguro que el resultado no deja de ser una certificación de la realidad, tanto anterior como deseada.
Con esta forma de actuar, se puede evitar que caigáis en errores similares, asegurando que las propuestas de automatización y eficiencia sean tanto viables como efectivas. La clave está en la verificación y validación constante de los datos y suposiciones iniciales, así como en la comunicación continua con todas las partes involucradas.
Espero que os sea de utilidad y os animéis a compartir vuestros errores y fracasos con la comunidad. Aunque siempre nos quedará la duda de que los interesados nos hubieran dicho toda la verdad en la reunión.
————-
Acerca de RPA Technologies:
RPA Technologies es una empresa innovadora dedicada a impulsar la transformación digital en organizaciones de todo el mundo. Con una fuerte creencia en el poder de la hiperautomatización, ofrecemos soluciones de vanguardia y capacitación de primer nivel para ayudar a las empresas a mejorar su eficiencia, productividad y éxito general.
