Lo que hace un Robot, que no lo destroce el Hombre
Autor: Txema Fernández | Client Success Manager
Como ya comenté en el artículo anterior (ENLACE a artículo https://rpatechnologies.es/no-es-oro-todo-proceso-que-reluce/), el propósito de este tipo de artículos no es otro que compartir los errores que hemos cometido. Estoy convencido que de ellos aprendemos todos y mucho más que de los éxitos que en muchas ocasiones lo único que hacen es embriagarnos y hacernos no ver la realidad.
Como bien dijo Paulo Coelho: «Nacimos para cometer errores, no para fingir ser personas perfectas». En España estamos acostumbrados a contar sólo lo buenos que somos y lo bien que lo hacemos, y creo que esto es un error. Es fundamental que empecemos a hablar abiertamente sobre nuestros fracasos, ya que nos brindan valiosas lecciones y oportunidades de crecimiento.
En esta ocasión quiero compartir con todos la experiencia de un proyecto de RPA en el ámbito del front office que lamentablemente no alcanzó el éxito esperado. Este proyecto tenía un gran potencial para mejorar la eficiencia y productividad del servicio de atención al cliente que se prestaba a una compañía referente en el sector de la moda a nivel mundial.
Pongámonos en situación. Era el año 2018. En aquel tiempo no se oía hablar todavía de UiPath en España y lo poquito que se hablaba de Blue Prism eran en grandes corporaciones del IBEX y con resultados no muy buenos. Nosotros trabajábamos con un software de automatización llamado Jacada, un software israelí que tenía un módulo de RPA mediante programación en .net. Las licencias se adquirían de forma perpetua y había un mantenimiento anual para acceder a sus actualizaciones. En definitiva era económicamente accesible.
Pero todo este proyecto se comenzó a gestar después del verano de 2017, donde hicimos una inmersión de un mes en los servicios de contact center para conocer cómo eran las gestiones que se realizaban y recabar toda la información posible para armar un business case y un argumentario del proyecto que convenciera a los directores. Y está claro que les convencimos, aunque nos llevara más de 6 meses de reuniones periódicas para ir puliendo todos y cada uno de los detalles. Era más económico y de despliegue, que de conceptualización del proyecto.
Lo bueno que te da ver proyectos con la lejanía del tiempo pasado es que puedes ser más crítico. El motivo principal es que tienes más experiencia acumulada que te permite ver el problema con una visión completamente distinta que en aquel momento. Cometimos muchos errores en este proyecto, muchos empujados por terceros, pero me voy a centrar en los aspectos que han motivado esta confesión pública.
El título de este artículo: «Lo que hace un robot que no lo destroce el hombre», evoca una analogía poderosa con la frase que pronuncia el sacerdote en una boda: «lo que ha unido Dios, que no lo separe el hombre». Esta analogía se centra en la importancia de proteger y valorar la relación simbiótica entre la tecnología y los seres humanos. En el contexto de nuestro proyecto RPA esta interacción se convirtió en nuestro talón de Aquiles.
Aunque los robots fueron diseñados para mejorar la eficiencia y reducir la carga de trabajo de los agentes telefónicos, la falta de inclusión y comunicación con estos empleados clave durante el desarrollo y las pruebas del proyecto resultó en una resistencia activa y, en última instancia, en el fracaso del proyecto. Los robots, trabajando en el mismo equipo que los agentes humanos, se vieron boicoteados debido a la percepción de amenaza que estos empleados sentían. Esto subraya la necesidad crítica de una colaboración armoniosa y bien gestionada entre humanos y tecnología, evitando así que las fricciones humanas socaven los beneficios potenciales que la automatización puede ofrecer.
Vamos por partes. Empezando por el primer punto el proyecto fue concebido por nosotros junto a los altos directivos, quienes en muchos casos no participaban en el día a día de las operaciones. En lugar de fomentar un diálogo directo con los responsables del servicio, coordinadores y especialmente con los propios teleoperadores, mantuvieron una distancia considerable. Es importante permitir que los colaboradores interactúen directamente con todos los niveles operativos.
Para nosotros era más cómodo hacerlo así. Tan despegados del día a día, no habría objeciones a todas y cada una de nuestras propuestas. Lo desarrollamos desde un punto muy teórico, por no decir idealizado, y muy tecnológico. Hubiera sido mucho más lógico crear las dinámicas necesarias para obtener el feedback de los teleoperadores y sus responsables directos y crear conjuntamente la solución ideal que con su visión podría ayudarles a atender a los clientes de la forma más eficiente y certera. Sigo visualizando esas dinámicas de grupo con muchos post-it y papeles pintados y repintados.
La falta de interacción directa llevó a una visión distorsionada de las necesidades y desafíos reales del equipo operativo. Incluso cuando presentamos el prototipo de una casuística al CEO del Contact Center su comentario fue revelador: «Si hasta yo mismo podría atender una llamada sin problemas». Ese comentario subrayaba la falta de comprensión profunda de las complejidades y matices del trabajo diario de los teleoperadores. La ironía de esta afirmación es que con ella nosotros nos crecimos y pensamos que nuestra solución era la mejor del mundo.
La implementación de soluciones tecnológicas debe ser un esfuerzo colaborativo que incluya las perspectivas y el conocimiento de aquellos que estarán interactuando directamente con las nuevas herramientas. En este caso la falta de participación activa de los teleoperadores y sus supervisores en el diseño y pruebas del sistema resultó en una resistencia natural y, eventualmente, en el sabotaje del proyecto. La lección aquí es clara: la inclusión y la comunicación abierta son esenciales para evitar que la desconexión entre la gestión y la operación diaria comprometa el éxito de las innovaciones tecnológicas.
El otro reto fue la realización de las pruebas del proyecto una vez finalizado su desarrollo. Resultó ser mayor desafío que el anterior y en gran parte fue una consecuencia directa de la falta de participación de los teleoperadores en las etapas iniciales del proyecto. Esta desconexión inicial se tradujo en una falta de confianza y comprensión por parte de los teleoperadores respecto a la funcionalidad y eficacia de los robots. Al no haber sido incluidos en el proceso de diseño y desarrollo, los teleoperadores enfrentaban la nueva tecnología con escepticismo y desconfianza.
Un factor crítico que exacerbó los problemas durante las pruebas fue que los robots operaban en los mismos equipos que los teleoperadores. Aunque las máquinas abrían una sesión de navegación independiente, los teleoperadores, que no se sentían parte del proyecto y tenían serias dudas sobre su funcionamiento, interferían directamente con estas sesiones. La apertura de la sesión de navegación del robot por parte del teleoperador y cualquier interacción subsecuente con el teclado o el ratón generaba un caos total. Estos conflictos técnicos no sólo provocaban problemas inmediatos en la ejecución de las tareas, sino que también reforzaban la percepción de que la tecnología no funcionaba bien.
La intervención humana no prevista en las sesiones de los robots provocaba fallos que los teleoperadores utilizaban para justificar su desconfianza en el sistema. Cada interacción no deseada actuaba como un sabotaje involuntario haciendo que los robots fallaran en tareas simples y fomentaran la idea de que el sistema era ineficaz e inestable. Este ciclo vicioso de desconfianza y problemas técnicos alimentaba aún más la resistencia al cambio.
El duro trabajo llevado a cabo por el equipo durante las semanas que duraron las pruebas, incluso trasladándonos físicamente a uno de los centros para ver su uso, no fueron suficientes para conseguir el éxito en un proyecto que además llevó aparejado grandes retos tecnológicos, como el uso de una herramienta del fabricante nueva de la que había experiencias previas, o el desarrollo de una capa de comunicación propia porque esta solución no soportaba Firefox, el único navegador donde funcionaban el CRM y el gestor de pedidos de la marca de moda. Pero esto nos llevaría varios artículos o incluso un libro.
La implementación exitosa de proyectos de hiperautomatización, más cuando hay un “human in the loop” importante depende en gran medida de la inclusión y colaboración de todos los actores involucrados. Basándonos en nuestra experiencia, a continuación se presentan algunos consejos prácticos para quienes afrontéis este tipo de proyectos:
- Involucra a los Usuarios Finales desde el inicio: Asegúrate de incluir a aquellos que van a interactuar y tocar la solución en las etapas iniciales del proyecto. Su feedback es esencial para diseñar soluciones que realmente se adapten a sus necesidades y desafíos diarios.
- Fomenta la Comunicación Abierta: Establece canales de comunicación claros y abiertos entre los desarrolladores, los directores y los usuarios finales. Esto ayuda a construir confianza y a asegurar que todos estén alineados con los objetivos del proyecto.
- Realiza Pruebas en Entornos Controlados: Asegúrate de que las pruebas del sistema se realicen en entornos controlados donde los robots no compartan los mismos equipos con los teleoperadores, para evitar interferencias no deseadas.
- Proporciona Capacitación Adecuada: Ofrece capacitación y soporte continuo a los teleoperadores para que se familiaricen con la nueva tecnología y se sientan cómodos utilizándola.
- Monitorea y Ajusta Continuamente: Después de la implementación sigue monitoreando el desempeño de los robots y recolecta feedback para realizar los ajustes necesarios. La mejora continua es clave para el éxito a largo plazo.
Muchos de estos consejos que muchos consideráis triviales los llevamos a la práctica de forma consciente y constante. Pero con la perspectiva del tiempo realmente el principal error que cometimos fue no hacer que la solución fuera considerada propia por los teleoperadores. Ya no sólo haciéndoles parte del proyecto desde el inicio, sino incorporándoles en un proceso de creación conjunta continuo y no faseado. Si se lanza un proyecto que consideran suyo desparecerán todos los problemas de un plumazo.
A modo de conclusión, desde entonces siempre que nos proponen hacer un importante proyecto de transformación en una empresa, ya sea global o departamental, proponemos una primera fase independiente donde explorar conjuntamente los problemas, interactuar directamente con las personas que realizan las tareas y conocer sus opiniones sobre los cambios que ellos mismo harían. Después de esta exploración sabemos que seremos capaces de proponer un plan de implementación totalmente personalizado al cliente donde sabremos con qué personas interactuar para desarrollar conjuntamente las soluciones de futuro.
Escucha el Audio: