¿Por qué falla el despliegue del RPA?

Escuchamos muchas historias de éxito, pero no los fracasos, que son muy importantes.

El RPA se debe usar para procesos que se pueden automatizar a través de una interfaz de usuario sencilla e intuitiva. Si intentamos automatizar más y más procesos complejos en una sola tarea o solución, se producirán muchos errores ya que la mayoría de las excepciones no se perderán.

La mayoría de las aplicaciones ERP se crean a 300 metros de altura y estamos utilizando RPA para llenar el vacío del nivel del mar a 300 metros. Cuanto más lo reducimos, la eficiencia y la calidad aumentan y se obtienen grandes beneficios a través de FTE (Full Time Employee).

Estamos automatizando la oportunidad en un proceso, no todo el proceso. Cada proceso contiene múltiples oportunidades. El proceso de extremo a extremo puede automatizarse en combinación con las soluciones RPA + Analytics + Artificial Intelligence.

Entonces, ¿por qué lo llamamos Automatización de procesos en lugar de Automatización de oportunidades?

Este término generalmente se refiere a la automatización de una pequeña parte de la automatización completa del proceso. En gran medida, depende del tamaño del proceso. Solo hay que automatice el camino feliz. Automatizar las excepciones requiere la mayor parte del esfuerzo para procesar cualquier transacción.

Como regla fundamental debemos aplicar el principio de Pareto para identificar lo que debe considerarse en el alcance. Se debe seguir estrictamente la Regla 80/20.

Pero salvadas estas nociones básicas, cuando llegamos a la implementación de RPA, los principales fallos vienen producidos porque (no te preocupes que no se suelen ver las 35 a la vez, aunque en algún caso están cerca):

1. Tratamos la automatización como un proyecto tecnológico normal.
2. Intentamos dar lógica de negocio al proceso utilizando la herramienta RPA. La herramienta RPA deve servir para trabajar con información a través de las pantallas de la interfaz de usuario.
3. No agrupamos todo el conocimiento teórico. Hay que capturar todo lo que el equipo está haciendo para completar la transacción.
4. No usamos las técnicas correctas. Hay un orden de precedencia que debe seguirse cuando estamos tratando de obtener el control de un objeto.
5. Nos centramos en crear una mejor interfaz de usuario de la herramienta. Haz que funcione y luego dedícate a ponerlo bonito.
6. No realizamos en el orden correcto las secuencias de comandos de automatización que se requiere para obtener resultados exitosos.
7. No nos hacemos preguntas para capturar los detalles. Nos vamos a lo general y perdemos foco.
8. Tratamos de igual manera aplicaciones web, de Escritorio y Mainframes.
9. Evitamos entrar en detalles de los escenarios de excepción.
10. No revisamos el proceso. Lo lanzamos sin hacer revisiones con usuarios o pasando olímpicamente de su feedback.
11. Pensamos en el problema futuro. Piensa en lo que está sucediendo en ese momento. No resuelvas lo que no ha ocurrido sin solventar lo que tienes delante de tus narices.
12. Aplicar la metodología Ágil al crear una solución base y ya está. A partir de allí nos olvidamos de lo ágil y seguimos los procedimientos tradicionales.
13. No tenemos en cuenta todos los escenarios de inicio. Si al menos contemplásemos dos… Todo comienza en un primer escenario y eso es complicado que realmente suceda.
14. No borramos casos de uso.
15. Existen desajustes entre la versión del sistema de destino del entorno de prueba al entorno de producción.
16. Incluimos demasiadas oportunidades en una única solución.
17. No utilizamos la herramienta RPA correcta para automatizar el proceso ya que no tenemos en cuenta los procesos para tomar la decisión.
18. Estamos convencidos que la herramienta hace lo que se requiere. La herramienta RPA es una herramienta tonta que debes definir y aportarle tu inteligencia a la hora de dibujar la solución.
19. La consultora que participó en la creación del business case o en el estudio de proceso y redacción de requisitos no implementa ni está capacitada para ello. Entonces ¿Por qué nos fiamos de ella?
20. Los desarrolladores que tenemos no tienen la mentalidad de trabajar en un Think Tank de Automatización. Las ideas tienen que llover y compartirse. Ningún camino debe descartar por muy cutre o descabellado que parezca.
21. Asumimos muchas cosas. No asumas nada y deja que sucedan las cosas.
22. No obsesionamos en la reutilización. Estamos tratando de automatizar el proceso personalizado y nos obsesionamos por crear actividades que se puedan utilizar en varios proceso.
23. El proceso no está maduro y va a cambiar. O incluso cambia mientras estamos automatizando.
24. Las prisas son malas consejeras y sobre todo si has llegado a este punto ¿Te has dado cuenta todo lo que tienes y no tienes que hacer?
25. Queremos estar demasiado seguros y eso provoca que cualquier duda la veamos como una amenaza en vez de una oportunidad. Hay que excavar más hondo.
26. Faltan sesiones de Brainstorming antes del inicio de la automatización.
27. Obviamos los requisitos mínimos de reingeniería de procesos. No nos creamos más listos de los que ya han hecho este camino muchas veces.
28. No consideramos límites.
29. Las expectativas son poco realistas.
30. Nos quedamos atrapados en un problema particular.
31. Intentamos automatizar en sistemas o aplicativos poco estables. Mejor no empieces porque vas a acabar frustrado.
32. Consideramos que hay una única solución para todo y quizás haya que tratar excepciones de una manera particular, siempre que haya retorno en ese tratamiento.
33. No nos centramos en los eventos a través de pulsaciones de teclado y ratón. Queremos ir más allá y la herramienta RPA hace lo que hace.
34. No tenemos traza de lo que sucede y pasamos de auditar las cosas. Luego nos pasaremos mucho tiempo revisando todo.
35. No comprendemos perfectamente bien los flujos de entrada y salida. Esto es un básico.

Hemos repasado las principales causas que provocan problemas de diferente envergadura en el despliegue. Los software RPA no son malos. Si lo fueran no cobrarían lo que cobran por una licencia. Lo que hay que pensar también es ¿Me he equivocado con la elección de la empresa o equipo que está llevando a cabo el proyecto?

Darle poder a los empleados para automatizar

Una nueva visión que quiere poner encima de la mesa Harpia es darle el poder de automatizar a los trabajadores sin que tengamos que contar con extraños que pueda que no entiendan cómo hacéis las cosas en vuestras empresas.

La versatilidad de que sea el propio trabajador quien automatice su trabajo además procura la mejor forma de tener los automatismos bien mantenidos y actualizados sin depender de la disponibilidad de otros, y sin tener que volver a contar la historia desde cero.

Ellos no están en el día y si vuelven a los seis meses, no se acordarán de lo que hicieron. Han estado con otros proyectos o incluso esos desarrolladores ya no están en ese proveedor.

No pierdas más el tiempo y descárgate Harpia para comenzar a automatizar los procesos que tanto tiempo te quitan y poco valor aportan. ¡A por ello!