Automatización. ¿On premise vs Cloud?

Uno de los primeros retos cuando una empresa esta definición su estrategia de automatización es la selección de la solución técnica. Dentro de esas consideraciones hay que tener en cuenta si dicha solución dispone de componentes onpremise y en cloud o si se puede instalar en servicios cloud de terceros proveedores. 

El inicio del camino hacia la automatización de procesos empleando la tecnología de RPA (Robotics Process Automation), implica la toma de decisiones sobre tecnología, arquitectura, modelos de precios, etc. Todas ellas son importantes de cara a que la solución proporcione el rendimiento adecuado, sea escalable y mantenible y el caso de negocio sea positivo.

Una de ellas es elegir si la solución técnica o alguno de sus componentes se quieren que estén instalados en cloud o en su propio centro de datos, es decir, bajo una arquitectura más o menos tradicional de servidores, en general, con un alto grado de virtualización (on-premise). Esta decisión está influida por varios elementos, como puede ser la estrategia cloud de la empresa, la latencia de las aplicaciones, las funcionalidades que aporta en cloud u on-premise e incluso el modelo de precios de cada opción.

Solución Técnica

Cuando se evalúa la solución técnica a seleccionar para implementar nuestra estrategia de automatización hay varios factores a tener en cuenta entre los que están la facilidad de implementación y de uso, la arquitectura técnica, la tecnología que emplea y funcionalidades o módulos que incluye, la escalabilidad, la red de Partners que dispone a nivel local, la mantenibilidad y soporte del fabricante y el coste total de propiedad (TCO). Para más información se puede consultar el articulo Criterios para elegir la herramienta de Automatización de Procesos correcta publicado por el grupo de ITSM4RPA-AI.

Sin embargo, ahora, principalmente, vamos a centrarnos en los factores relacionados con la disponibilidad de arquitectura cloud u on-premise.

Dentro del panorama actual, existen diversidad de soluciones que las podríamos clasificar de la siguiente manera:

• Arquitectura Cloud pura o híbrida integradas. Aquellas con algunos de sus componentes en cloud. A modo de ejemplo hay fabricantes que proporcionan el orquestador de manera nativa en cloud (SaaS), aunque también es posible obtenerlo on-premise de manera nativa proporcionan el orquestador en cloud, siendo los robots instalados on-premise.
• Arquitectura Cloud pura o híbrida independientes. Aquellas que proporcionan la solución on-premise o con servicios en En definitiva, existe 2 maneras de adquirir el producto, una on-premise y otra en servicios Cloud, y no se pueden mezclar componentes.
• Arquitectura on-premise certificada para Cloud. Las que disponen de instalación on-premise, pero que además tienen arquitecturas certificadas para varios proveedores cloud.
• Arquitectura on-premise. Las que disponen únicamente de instalación on-premise.

En general, las restricciones impuestas por cada solución técnica nos pueden hacer bascular la decisión sobre una u otra. Pero antes de elegir a un fabricante, debemos reflexionar sobre cual es la arquitectura que necesitamos, y no elegir el fabricante primero y luego pensar en que arquitectura se adapta mejor a nuestras necesidades.

Arquitectura

Antes de nada, vamos a partir de base de que no hay una estrategia Cloud definida para la toma de decisiones y que hay que reflexionar sobre la mejor alternativa para nuestra solución de automatización.

La definición de la arquitectura a elegir depende, en gran medida, de la arquitectura de nuestras aplicaciones. Si nuestras aplicaciones están basadas en aplicaciones web, API, microservicios, o similares, no tenemos ninguna restricción que nos impida pensar en una arquitectura Cloud. Sin embargo, la existencia de aplicaciones cliente/servidor, entre otras, puede ser una clara restricción para la selección de una solución de servicios Cloud pura y requiera una instalación mixta, con partes en cloud y otras on-premise o ir a una solución exclusivamente on-premise.

Dentro de los elementos a tener en cuenta, además, en nuestra arquitectura de aplicaciones, es la arquitectura de red. Si queremos automatizar procesos que dependen de un conjunto de aplicaciones instaladas en una red local on-premise, y nuestra solución de automatización está en cloud, deberemos “extender” nuestra red al cloud para que dichas aplicaciones sean accesibles por los robots instalados en cloud. Estamos en arquitecturas hibridas, cloud y on-premise conectadas por VPN. Como vemos, ante la ausencia de estrategia cloud previa, debemos reflexionar sobre como es nuestra arquitectura actual, de sus restricciones, antes de tomar una decisión. En definitiva, la arquitectura de automatización va a depender en gran medida de cómo es la arquitectura de nuestras aplicaciones y de red.

En caso de que ya exista una estrategia de Cloud, la toma de decisión estará definida por dicha estrategia. Si ya disponemos de un modelo de cloud para nuestra empresa podremos contemplar la instalación de soluciones con arquitecturas certificadas para Cloud públicas, obtenemos todas las ventajas del Cloud, pero con nuestras políticas de arquitectura, seguridad, servicios cloud, etc.

Modelo de Precios

Dentro del mercado de automatización hay varios modelos de precios:

• Modelo de precios gratuitos, en los que no existe coste por licencia o suscripción. Algunos de estos fabricantes ofrecen también los robots en cloud en diferentes modelos SaaS/PaaS/IaaS.
• Modelo de suscripción anual/plurianual, en los que el cliente “adquiere” por periodos anuales la licencia de uso del software. En él se incluyen las actualizaciones. Bajo este modelo de precios, los fabricantes incluyen su solución de RPA y otros módulos, así como diferentes tipos de soporte de producto. Algunos módulos relacionados con inteligencia artificial pueden ir por procesamiento de páginas, caracteres, imágenes, etc. Bajo este modelo trabajan casi todos los fabricantes, ya sea su solución on-premise o en cloud.
• Modelo de pago por tiempo de transacción. Corresponde a proveedores (no fabricantes) que han montado diversas soluciones de automatización en cloud que lo ofertan a sus clientes en diferentes modelos de pago por uso. Este pago por uso va vinculado a tiempo de proceso que se requiere al mes, realizando un pago por minuto. Esta solución está especialmente indicada para aquellos clientes que no tienen capacidad de procesamiento transaccional suficiente para cubrir toda la capacidad de 1 robot o a aquellos que tienen cargas periódicas y no desean tener una infraestructura dedicada a la automatización en sus instalaciones. Es en definitiva un modelo RaaS (Robots como servicio), que incluye licencia de producto, actualización y migración de producto, infraestructura gestionada y el tiempo de procesamiento.

Como vemos existen modelo de precios de varios tipos para elegir y adaptarse a las necesidades de todo tipo de clientes, aunque, como vemos, los fabricantes siguen centrados en modelos más o menos tradicionales de licencias.

Toma de Decisión

Como vemos los elementos a tener en cuenta para decidir el tipo de arquitectura de automatización que necesito son, la arquitectura actual de las aplicaciones que dan soporte a los procesos que se quieren automatizar que puede ser una restricción a la hora de tomar la decisión, y, por otro lado, analizar los costes que supone la arquitectura cloud frente a on-premise. No debemos olvidar que no solo está el coste de IaaS/Paas sino la gestión de las bases de datos, infraestructura y redes.

Finalmente debemos analizar cual es nuestra hoja de ruta de automatización y proyectar las cargas de trabajo hacia el futuro para hacer un análisis de costes del número de robots y costes de infraestructura necesarios vs los costes por tiempo de transacción en cloud. Esta comparación nos permitirá tomar decisiones más acertadas pensando en el futuro.

Por supuesto, todo lo anteriormente indicado debe estar alineado en caso de que exista una estrategia cloud ya definida.

Como vemos tanto los fabricantes como otros proveedores están tratando de adaptarse a las necesidades de los clientes en cuanto arquitectura y modelo de pago por uso en el diseño de sus soluciones, y no solo eso, sino que están en constante evolución de funcionalidades. Solo hay que esperar que esa evolución continúe y este alineada con las necesidades del mercado

 

Marcos Navarro Alcaraz

Líder del Grupo de Expertos en RPA-AI ITSM4RPA-AI de itSMF