Mantenibilidad de los Robots

Una de las dudas que a menudo aparecen en aquellos que tiene pensado implementar soluciones de automatización es el cual será el coste de operación y mantenimiento de estas soluciones. Vamos a revisar los factores que influyen en que aparezcan actividades asociadas al mantenimiento de los procesos automatizados por robots.

Antes de nada, vamos de definir las actividades que se engloban en el concepto de Operación y Mantenimiento (OyM).

La Operación es la ejecución de los procesos automatizados. En general, las soluciones de automatización disponen de orquestadores o salas de control que permiten la planificación de la ejecución de los procesos. Sin embargo, según sea el proceso, cuales son los desencadenantes que lanzan su ejecución, duración de la ejecución del mismo puede variar según el numero de transacciones que tenga que procesar cada día, y eso hace que haya que supervisarlos para ajustar el calendario de ejecución de él o de otros procesos. Esta carga de operación de solventa mediante acciones manuales de un operador o empleando otras soluciones de mercado que permiten priorizar procesos, inclusión de niveles de servicio en su ejecución, e incluso una monitorización avanzada. En definitiva, un posible coste adicional en trabajo de operación o herramientas.

El Mantenimiento se corresponde con acciones correctivas para solventar errores o incidencias que impiden la ejecución normal de un proceso (mantenimiento correctivo) o con acciones evolutivas para añadir nuevas funcionalidades a los procesos por necesidades del negocio (mantenimiento evolutivo).

A veces existen dudas entre que se considera garantía del proyecto y mantenimiento. La garantía cubre aquellos funcionamientos definidos en el alcance del proyecto, es decir, en la toma de requerimientos, en el Documento de Definición del Proceso (PDD) y en el SDD (Documento de Diseño de la Solución). Es decir, que todo funcione como se había pensado que debía funcionar. Errores generados por cambios de aplicaciones, sistemas, etc. no forman parte de la garantía de un proyecto de automatización, sino de mantenimiento.

En definitiva, nada diferente a lo que requiere cualquier otra aplicación o sistema implementados en una empresa.

Si reflexionamos en los elementos que componen un proceso automatizado nos aparecerán:

• El proceso, es decir, la secuencia de actividades y reglas de negocio que se automatizan
• Los datos que manejan estos procesos automatizados.
• Las aplicaciones que dan soporte al proceso.
• Los sistemas y comunicaciones sobre los que se ejecutan las aplicaciones y que dan soporte a las aplicaciones y también a la solución de automatización.

Analicemos uno por uno para identificar como afectan a los servicios de OyM.

Los Procesos

Uno de los criterios que empleamos a la ahora de automatizar procesos es que éstos sean estables, es decir no estén en un proceso de modificación continua. Las modificaciones en los procesos implicarán tareas de rediseño, construcción, pruebas y documentación de la automatización, y por tanto generará un coste no deseado. Además, debemos recordar, que uno de los mayores costes en el desarrollo de un proceso son el asegurar su resiliencia y las pruebas, ya sean unitarias, integrales o UAT (pruebas de aceptación de usuario).

Por lo tanto, en la medida que un proceso no esté estabilizado, los costes de mantenimiento, en este caso evolutivo, serán directamente proporcionales a su variabilidad.

Los Datos

Podemos considerar dos visiones en la gestión de datos, los datos en si que maneja cada una de las transacciones del proceso y el numero de transacciones que se ejecutan.

La gestión de la tipología de los datos que emplea un proceso incide directamente la estabilidad y resiliencia del mismo. No obstante, esto se realiza en la fase de desarrollo. En ella el programador debe asegurar que si un campo es, por ejemplo,  un DNI, debe verificar su formato o gestionar correctamente el mensaje de error de la aplicación al introducir un campo con el formato erróneo. Es lo que se conoce como excepciones de negocio y su control y correcta gestión debe realizarse en fase de desarrollo. Por lo tanto, si se han seguido buenas prácticas, no deberían producirse estos errores y por tanto influir en los costes de mantenimiento.

El volumen de transacciones, no influyen en el mantenimiento correctivo o evolutivo. Si se han seguido unas practicas de desarrollo, un proceso que sufre un incremento excepcional de transacciones debe ser capaz de ejecutarse, bien parando otros procesos, o si se dispone de capacidad suficiente, asignando varios robots para ejecutar dichas transacciones en el tiempo definido por el nivel de servicio. Puede ocasionar algún coste de operación o inversión en herramientas más eficaces en la supervisión de robot, pero no implica otras actividades de mantenimiento correctivo o evolutivo.

Las Aplicaciones

Las aplicaciones, si que influyen de manera notable en el mantenimiento, ya sea correctivo como evolutivo. Si una aplicación se modifica, por ejemplo, introduciendo una pantalla nueva en un flujo de trabajo, implicará, primero un error en el proceso, si no hay una correcta gestión de cambios y en el cambio de la aplicación no se ha tenido en cuenta que la ejecución es realizada por robots. Y segundo, habrá que adaptar la automatización del proceso a los cambios introducidos en la aplicación.

Por otro lado, esta excepción de aplicación, al ser nueva no estará controlada y puede hacer que el proceso se pare, incluso que el robot se quede bloqueado y no puede ejecutar los procesos planificados a continuación.

Por lo tanto, es primordial integrar a los equipos de automatización en los procesos de gestión de cambios, incluso disponer de una CMDB (Base de Datos de Configuración) correctamente gestionada y actualizada para saber las implicaciones que tiene cada cambio

Los Sistemas

Los sistemas, bases de datos, y comunicaciones son los cimientos en los que están instaladas aplicaciones, así como lo sistemas de automatización. Cambios en los mismos, ya sea por actualizaciones de sistemas operativos, cambios en las políticas y permisos de usuarios, incluso cambios en los direccionamientos de las redes o firewall pueden afectar al comportamiento de las aplicaciones, y por tanto generar un error de sistemas que se extiende a toda la pila de la aplicación. A modo de ejemplo, una actualización de Windows puede cambiar determinados privilegios de ejecución o políticas, etc. que hacen que bien la aplicación que da soporte al proceso deje funcionan como lo hacia con anterioridad o que provoque un error en el sistema de automatización, virtualización o problemas en la red. Esto implicará al mantenimiento correctivo para que entre todos los implicados, sistemas. comunicaciones, equipo de desarrollo de aplicaciones y equipo de automatización trabajen conjuntamente, primero para resolver la incidencia y posteriormente el problema. Si bien estos errores no son comunes, si son complejos de diagnosticar y resolver y tiene gran repercusión porque pueden parar la operación de los procesos automatizados.

La transferencia a Operación y Mantenimiento

El ultimo paso tras el paso a producción de un proceso automatizado es la transferencia a Operación y Mantenimiento. Es decir, el equipo de proyecto finaliza la entrega y pasa a ser gestionado por el servicio de OyM. En esta ultima fase, se deben proporcionar todos manuales de operación del proceso, las aplicaciones, sistemas, ficheros, configuraciones necesarias y por supuesto el paquete de instalación release que está en producción.

El equipo o servicio de OyM debe verificar que dicha información es completa y suficiente para operar el proceso y validar dicha entrega. Es a partir de ese momento en el se hace responsable de la ejecución y mantenimiento de los procesos automatizados.

En definitiva, siempre existe la necesidad de disponer de un servicio de operación y mantenimiento y coordinado con todos los segundos niveles de soporte (sistemas, comunicaciones, aplicaciones, etc) sean capaces de solventar, primero los errores que se puedan producir, y segundo, adaptar la automatización a las evoluciones de aplicaciones, procesos, en definitiva, a las necesidades del negocio. Sus costes vendrán derivados de la frecuencia con la que se cambian los sistemas, aplicaciones y procesos.

Marcos Navarro Alcaraz

Team Leader Grupo Expertos itsm4RPA-AI

Comité de Estándares de itSMF España