¿Como lo logre?

Pues gracias al trabajo comunitario, usando un editor de codigo con el que estoy bastante familiarizado. VSCode

Solo necesite 3 descargas.

• Visual Studio Code
• MSYS2 (Binario)
• C/C++ extension VScode

La configuracion:

• Instalar VSCode.exe
• Instalar C/C++ Extension, desde la UI. Extensiones -> Buscar C/C++ -> Instalar.
• Ejecutar MSYS2
• pacman -S mingw-w64-ucrt-x86_64-gcc
• pacman -S –needed base-devel mingw-w64-ucrt-x86_64-toolchain
• Y agregar el siguiente Path en windows, C:\msys64\ucrt64\bin

Con eso ya quedo configurado todo el ambiente, al nivel mas basico.

¿Como probarlo?

En un terminal: g++ –version

En una carpeta nueva

code .

#include <iostream>
#include <vector>
#include <string>

using namespace std;

int main()
{
    vector<string> msg {"Hello", "C++", "World", "from", "VS Code", "and the C++ extension!"};
    
    for (const string& word : msg)
    {
        cout << word << " ";
    }
    cout << endl;
}

Ejemplo tomado de los ejemplos de VSCode

Guardar como helloworld.cpp

Presionar F5, y elegir g++ como opcion de debug o run.

Esto crea un archivo de configuraciones task.json para vscode. Y ejecuta tu sencillo programa de pruebas.

Conclusiones

El mundo ha avanzado bastante :p

Ultimamente en mis busquedas y anuncios personalizados de google siempre me aparecen herramientas de tecnologia, cada vez una tecnologia mas nueva, y con mas brillos y colores que por alguna razon todas son comunes en su capacidad ‘Low Code’.

El contexto

Mi trabajo es de tecnologia, una persona simple, que busca documentacion de sistemas propietarios, o sintaxis de lenguajes de programacion, o funciones de powershell o bash, docker, y kubernetes. Tambien hago bastantes busquedas de diagramacion, y organizacion de equipos y personal.

Constantemente uso herramientas como Visual Studio Code, Godot, Git, draw.io que son geniales y gratuitas.

Por eso ahora sufro anuncios donde la palabra clave de estos anuncios es ‘Low Code’ y enserio lo detesto, son una molestia cualquier variacion del siguiente anuncio parafraseado

Y nuestra nueva tecnologia, con capacidades de Low Code, le permitira ser mas productivo en su trabajo

¿Que es y para que ‘Low Code’?

‘Low Code’ es una frase de ventas, similar a ‘Nube’ que se acuño en los ultimos años y basicamente, es la capacidad de escribir rutinas de software con pocas lineas de codigo y/o asistentes de configuracion. Dentro de una herramienta propietaria. Para no tener que aprender todas las complejidades del desarrollo de software, solo del software por el que pagas.

Estas tecnologias tienen su objetivo, tienen su razon de ser, y tienen su utilidad, sin embargo ese publico objetivo no son las personas con el mismo perfil que yo. Son personas de ventas, personas de procesos, aquellos que desempeñan un trabajo, no saben como crear sistemas, y quieren hacerlo mas rapido y de forma sencilla.

Una amiga mia tiene su tienda en linea, y para ella es sumamente valioso poder configurar, automatizacion de boletas o facturas, configurar chatbots para atender a sus compradores, con pocos clicks. Y esto es genial, es increible que este individuo o negocio no necesite de un area o consultor de desarrollo de software. Aun asi para su caso es idiota, porque ‘Low Code’, no significa ‘No Code’, igual tiene que aprender alguna sintaxis para lograr lo que quiere en la herramienta con pocos pasos.

La critica

Volviendo a mi caso, yo soy un desarrollador de aplicaciones, yo hago este tipo de sistemas genericos o especializados, ya lo hago con poco codigo, normalmente que construyo o heredo, mucho mas rapido y estable que con su tonto software privado y que invade espacios publicitarios. Es como si los publicistas apuntaran a gente aleatoria, sin capacidad de razonamiento, o que los inspira la musica motivadora del video o sus graficos porcentuales relativos de productividad.

Yo no quiero su tonto software, que me evita el control detallado de mi codigo (que puede ser perfectamente modular, funcional, y separado). ¿Por que perderia el control de todo un sistema? Solo para empezar a usar sus ventanas y tontas cajitas de configuracion. Cajitas de configuracion propietaria, normalmente no intercompatible, para su producto cualquiera que hace ABCD.

Todo para terminar haciendo, lo mismo que haria en cualquier sistema integrado que permita automatizacion de procesos. Solo son variaciones de:

• Automatiza tus tareas en nuestra plataforma de low code
• Construye tus tableros en nuestra plataforma de low code
• Crea tus flujos en nuestra plataforma de low code.

¡Que normalmente cualquiera puede hacer! (Con la respectiva diligencia y paciencia). Solo se aprovechan de que el mundo busca ‘velocidad’.

Una historia corta

Realmente el mundo es ciclico, yo era muy joven para esto, pero he visto revistas, y libros sobre Visual Basic, y Visual Fox Pro, que vendian precisamente esto, ventanas configurables para ‘facilitar’ el trabajo. Porque todo era Copy&Paste de codigo y plantillas.

La gente lo empezo a repudiar, y se hizo popular nuevamente el codigo en duro, y seguido de eso la generacion de plantillas, y ahora el Low Code.

En conclusion

Realmente, estoy tan harto de ellos, los programas y los anuncios, para el caso de los anuncios ya hasta los clickeo y sufro el tiempo de conversion de sus tontos productos, como si estuviera interesado y luego cancelar, para que les cobren. A ver si dejan los anuncios invasivos en los proximos años.

Para el caso de los programas, es tolerancias hasta que pase la moda, va a ser normal escuchar en sus trabajos estimados lectores, que alguien quiere comprar el producto ‘xyz’ porque permite ‘Low Code’ y el vendedor parecia un ‘Experto’. Solo den la vuelta, volteen sus ojos y suspiren.

Sugerencias

Si realmente una compañia, quieren hacer y distribuir su tonta herramienta lowcode y que un publico desarrollador o con un fuerte trasfondo en automatizacion y sistemas.

• Haganla interoperable, con los sistemas bases u otros.
• Hagan que el lowcode, permita edicion detallada, den alternativas. No solo su cajita de texto.
• Dejen de hacer anuncios confusos y dudosos, expliquen su herramienta.
• No traten al desarrollador de software como un niño de primaria que se cree hacker por usar wireshark en su red local.

Este componente puede ser cualquier software que sea capas de ejecutar remotamente acciones en un ordenador segun una logica ordenada y definida.

En general se pueden usar las propias capacidades del sistema operativo, Powershell, Bash, entre otros. Pero como recordaran RPA se trata de usar la interfaz de usuario y estos lenguajes tienen problemas para trabajar con Browsers y Grabacion de pantalla principalmente.

Hay diversas iniciativas de software que se pueden utilizar, de codigo abierto y para el caso de este experimento (en vez de construir una propia) vamos a utilizar https://robotframework.org

Robotframework provee de un marco de trabajo para automatizar en un lenguaje de scripting propio las tareas que requeramos, y ya se han desarrollado algunas utilidades como la integracion con Selenium y Apium que serian nuestras estrellas para la navegacion web y mobile.

No hay mucha documentacion disponible o sencilla de robotframework es bastante de la vieja escuela, librerias y modulos para documentar, pero no van a encontrar un tutorial como el de Heroes de angular.

¿Que necesitamos para usar robotframework?

Tener un equipo con Python

¿Como lo podemos instalar?

• Primero necesitamos python: https://www.python.org/downloads/
• Podemos usar estos comandos: pip install robotframework
• Validamos la instalacion con : robot –version
• Y ahora instalamos selenium: pip install –upgrade robotframework-seleniumlibrary
• Y ahora los drivers de browsers con
  • pip install webdrivermanager
  • webdrivermanager firefox chrome –downloadpath . –linkpath .

¿Como funciona?

Robotframework funciona en base a archivos .robot

El archivo tiene diversas secciones, pero las relevantes inicialmente seran, las separaciones estan fuertemente tipadas por Tabs y espacios, asi que puede llevar algo de aprendizaje empirico acostumbrarse o un buen validador de sintaxis. (Yo estoy usando notepads para estas pruebas asi que pendiente recomendar uno)

• *** Settings ***: Puede contener la informacion de RPA, descripcion, asi como sus dependencias
  • Documentation: Permite escribir la necesidad
  • Libraries: Permite incluir las librerias que incluye, normalmente selenium
  • Resources: Permite referenciar otros archivos .robot
• *** Variables ***: Permite definir variables para esta ejecucion. Las variables se nombran con la siguiente sintaxis ${nombre}
• *** Keywords ***: Permite definir funciones predefinidas para realizar ciertas acciones
• *** Test Cases ***: Son el cojunto de pasos a ejecutar, cada grupo se le asigna un nombre.

Para nuestro ejemplo tengo dos archivos

resource.robot

*** Settings ***
Documentation   A file with variables.
...
...             some data

*** Variables ***
${SERVER}       duckduckgo.com
${BROWSER}      Chrome
${DELAY}        0
${QUERY}        hola
${QUERY_URL}    https://${SERVER}/
${VALID_TITLE}  DuckDuckGo — Privacy, simplified.
${VALID_URL}    https://duckduckgo.com/?q=hola&t=h_&ia=web

query.robot

*** Settings ***
Documentation     A test for a single query.
...
...               This test has a workflow that is created using keywords in
...               the imported resource file.
Library           SeleniumLibrary
Resource          resource.robot

*** Test Cases ***
Valid Navigation
    Open Browser    ${QUERY_URL}   ${BROWSER}
    Maximize Browser Window
    Set Selenium Speed    ${DELAY}
    Title Should Be       ${VALID_TITLE} 
    Input text            search_form_input_homepage    ${QUERY} 
    Click Button          search_button_homepage
    Location Should Be    ${VALID_URL}
    

¿Como ejecutar?

Una vez creados los archivos, posicionarse en una carpeta y ejecutar

webdrivermanager firefox chrome --downloadpath . --linkpath .
robot .

Y listo eso deberia generar su automatizacion (prueba) y sus resultados. (Quiza tengan que hacer algunos ajustes) y pueden explorar los archivos output.xml, log.html, report.html a su propio ritmo.

Simple, pero algunos detalles.

La libreria de selenium y robot framework tienen un grupo de palabras y funciones predefinidas para facilitar el trabajo como ‘Open Browser Param1 Param2’

Su referencia la pueden encontrar en : https://robotframework.org/robotframework/latest/libraries/BuiltIn.html

y para selenium en https://github.com/robotframework/SeleniumLibrary/

Conclusiones.

Robotframework debido a su alta portabilidad, y a su alta personalizacion puede actuar como nuestro cliente. En la gran foto, nosotros vamos a ser capaces de empaquetar robotframework en un Container Image de docker, conjunto a nuestro grupo de archivos .robot y ejecutar via Cron o via comando ‘robot .’ donde aplique. via nuestra implementacion de kubernetes.

Teniendo en consideracion que estaremos principalmente usando el modo headless de los browsers. Y/o control remoto sobre otros equipos Desktop pero con las capacidades de los archivos .robot

En futuros post haremos mas detalles sobre Robotframework, tambien es algo bastante nuevo para mi, para casos de usos mas extremos.

Entonces esta es el borrador inicial de mi propuesta, que probablemente va a ser mucho mas refindo y modificado a lo largo de mis publicaciones (y hasta ahora tengo planificadas 52).

Entonces como ya mencione en mis dos post anteriores los componentes a planificar son

• Centro de Control: Una web personalizada que permite agendar, monitorear, construir, bots.
• Dispositivo de ejecucion: Un dispositivo dedicado que ejecuta tareas, como un equipo de una persona.
• Mecanismo de programacion de bots: Alguna interfaz grafica de cajitas o pseudocodigo propietario.
• Mecanismo de ejecucion de bots: Alguna interfaz programable o visual que permite disparar un bot.

Pensando bastante sobre ello, los principales beneficios de una solucion son sus interfaces graficas, su web personalizada que ejecuta tareas remotamente en un equipo con un cliente de software propietario.

Este cliente de ejecucion normalmente usa las caracteristicas del propio sistema operativo (Powershell,Cmd,Bash) e interfaces programaticas o captura de pantalla para ejecutar acciones de usuario.

Donde el control room envia una señal, el Cliente de Bot la recibe, descarga el juego de instrucciones y las ejecuta de forma secuencia sobre el Desktop. Que tiene acceso a todas sus caracteristicas nativas.

Entonces surgen las siguientes preguntas.

¿Si, no importa la interfaz grafica, como podemos controlar nuestra infraestructura, para usar sus recursos de computo, en multiples tareas independientes que no se bloqueen entre ellas?

La primera respuesta para esto son Maquinas Virtuales, pero no queremos tener que crear una VM para cada Bot, lo interesante es la reutilizacion.

Entonces la segunda respuesta es Kubernetes. Que nos permite utilizar Nodos de computo (equipos/vms), para desplegar Pods (que es una unidad minima de computo dentro de los conceptos de kubernetes)

¿Si, ya tenemos un controlador de recursos, como vamos a crear los bots sobre pods, los pods se basan en contenedores?

Excelente pregunta, y vamos a usar contenedores, al crear un contenedor de Docker, no solo podemos crear un paquete de software con dependencias pre-instaladas y unicas para una gran cantidad de actividades mundanas. Sino que podemos tener muchos en paralelo en la misma infraestructura. Lo cual es un problema comun en las soluciones de RPA comerciales. (Normalmente se resuelve con mas infraestructura y costo)

¿Si, podemos crear pods, pero los pods no tienen interfaz grafica, como podemos hacer tareas que requieran de ello?

Esto depende del alcance, podemos hacer muchas tareas en lenguaje de sistema operativo, la mayoria segmentemos las actividades que podria hacer una persona

Actividades sin UI:

• Crear, Copiar, Borrar archivos: Cmd,Bash,Powershell
• Navegacion web, Selenium en modo headless
• Edicion de documentos: herramientas de bulk, python puede ser una buena opcion

Actividades con UI

• Interfaces Web Flash u otras tecnologias obsoletas que requieren del desktop
• Uso de perifericos de un equipo fisico, por ejemplo la camara
• Reaccion a cambios de pantalla.

Todas las activiades con UI no se podrian hacer con un contenedor. Pero nada impide hacer un contenedor con un script, que se conecte a una maquina remota y use la interfaz (Aqui puede ser util python nuevamente).

¿Kubernetes tiene su propio log de pods, si nuestros pods son bots, cada va pod necesita enviar sus datos y registrar sus acciones en algun lugar?

Esto va a requerir un poco (bastante) trabajo manual al momento de construir el pod y el Contenedor. Pero podemos usar en kubernetes almacenamientos persistentes, y diseñar una base de datos que gestione los bots, cada bot, y cualquier necesidad que tengamos. Es un poco de procedimiento extra sobre cada dockerfile y sobre cada script de ejecucion pero todo por el bien mayor.

¿Necesitamos un cliente, y un interprete de comandos dentro de los pods, no vamos a hacer todo en bash/powershell?

Si se puede hacer todo en bash y powershell, pero hay una mejor opcion. Una de ella es robotframework (link pendiente)

Es una iniciativa de software libre, para testing funcional, que podemos empaquetar dentro del contenedor, y nuestro script en lenguaje semi-natural. Con el.

¿Necesitamos un ambiente de programacion?

Y lo tenemos, Un editor de codigo cualquiera, La documentacion de RobotFramework, Un editor de Python (por facilidad), y un Registro de Contenedores.

Cada nuevo bot es un Container Image.

¿Necesitamos crear bots que se ejecuten periodicamente los pods se despliegan y estan en demanda?

Kubernetes puede crear CronJobs y estos CronJobs pueden gestionar Pods.

Y de momento esas son todas las preguntas. Quedariamos con un modelo asi.

Con los siguientes componentes

Kubernetes como control room

Un container Repository, como repositorio de codigo

Un BotClient, compuesto por un Contenedor y un grupo de tecnologias

• Ubuntu
• Python
• xfreerdp
• RobotFramework
• ScriptPersonalidad

CronJobs para agendar pods en el tiempo

Un Persistent Storage + Pod Base de datos: Para control del sistema, ejecucion y auditoria (por diseñar)

Un Pod webserver: Que permita hacer Hooks hacia nuestros pods en demanda.

En conclusion, seria factible con algo de trabajo manual y organizacion construir una solucion de rpa en casa, sin pago extra de licencias, y tratando de maximizar el consumo de equipos.

El proximo post del tema, hablare en detalle de las capacidades de Imagenes de Docker como Clientes de Bot.

Sin embargo, cuando iba a hacer mi tabla comparativa, me di cuenta de lo mucho que detestaba, me deprimian, y desanimaban las paginas, sus precios y la forma de presentacion de la informacion (en mi opinion, nada de informacion util, y el consumidor objetivo debe ser bastante carente, alguien que espera magia), y dar una opinion negativa probablemente no sea la mejor idea para un blog referente y que esta empezando.

Por lo tanto voy a hablar de todos los productos a la vez, los diferentes tipos de licencias para los diferentes componentes a nivel general que pueden encontrar. Y la importancia de cada uno de los mismos al momento de tomar su desicion

Tambien encontraran una tabla con cada uno de los componentes mencionados y sus caracteristicas. No podran elegir pero si les da mayor sentimiento uno u otro, o su acesor de ventas pues siganlo.

Orquestador

Lo primero, el orquestador, Panel de Control, Centro de Control, Controlador, o cualquier otro nombre similar, como mencione en el articulo de introducion, normalmente un bot es un programa que ejecuta en un horario periodico en el tiempo, o bajo demanda. Pero esto debe ser indicado en algun lugar.

Estas configuraciones se hacen normalmente en una plataforma central, que gestiona cada Bot, asi como las cuentas de usuarios, cuentas de bots, dispositivos, y la mayoria de conexiones que realiza la plataforma.

Los vendedores la pueden vender de dos formas diferentes.

• En Premisas (On Premise): Esto significa que nosotros los compradores vamos a adquirir equipos de computo fisicos o virtuales, y vamos a instalar su programa en nuestros equipos. Esto incluye bases de datos, sistemas operativos, conexiones de red, firewalls, proxies, etc. Y no necesariamente es inclusivo a los Dispositivos que ejecutan los bots. Ellos nos dan los instaladores, soporte, licencias, etc. Nosotros administramos nuestros equipos y su conectividad.
• En Nube (SaaS): Esto significa que el orquestador principalmente va a estar en equipos de computo del proveedor. Y en algunas ocaciones nosotros podemos dar dispositivos para ejecucion de bots. Un punto adicional normalmente es considerablemente mas economico este tipo de servicios. Porque no se necesita llevar al infraestructura, y porque convenientemente las otras licencias son mas caras.

No todos los vendedores actuales aceptan el modo en premisas, por ejemplo Power Automate, esta diseñado como un software como servicio (SaaS). Podremos interconectar con OnPremise pero es Microsoft quien gestiona y opera el orquestador en su propia infraestructura.

¿Tengo que elegir entre En Premisas y Nube para mi caso de negocio o empresa? Puedes seguir esta lista de cotejo y llegar a tu propia conclusion.

• ¿Puedo pagar la infraestructura, incluyendo su mantenimiento fisico o virtual?
  • Si la respuesta es que si, entonces es considerable el costo extra de llevar en premisas.
• ¿Me interesa tener control de la infraestructura?
  • Si la respuesta es si, entonces debes ir En Premisas.
• ¿Es importante que todos los datos que manejo esten en un perimetro fisico, por ejemplo por auditorias legales, como la de gobiernos?
  • Si la respuesta es si, entonces debes ir en premisas. (O revisar con un buen abogado y el proveedor de su eleccion)
• ¿Mi compañia tiene estrictas politicas de comunicacion con provedores a traves de internet?
  • Si la respuesta es si, entonces deben indagar seriamente sobre los requisitos para usar nube.

Un punto adicional, normalmente estas plataformas incluyen uno o varios usuarios de configuracion o administracion como parte del precio. Pues es quien gestiona la plataforma,sus accesos y pago del mismo.

Bots desatendidos

Estas son conceptos, o licencias normalmente facturadas por ‘Usuario’, que permiten en un equipo remoto ejecutar un Bot. Este tipo de licencias significa que un usuario humano no monitorea o no es necesario para la ejecucion del bot.

Por lo tanto, un Bot desatendido es un equipo de computo (en premisa o nube) registrado en el Orquestador con un software cliente propietario. Al que el orquestador manda tareas a ejecutar, sin que un humano intervenga o pueda intervenir segun el proveedor.

Normalmente es una por equipo o usuario de ejecucion.

Bots Atendidos

Estos normalmente estan relacionadas a usuarios humanos, que necesitan ejecutar tareas en su PC local, o de forma remota, y esperar un resultado. Sus licencias tienden a ser mas costosas que las licencias de bots desatendidos pero es solo una casualidad.

De igual forma siempre requiere de un equipo de computo.

Cuentas de Desarrolladores

Normalmente son un tipo licencias que permiten acceder a una interfaz de usuario propietaria, comunmente de bloques para la construcion de los bots (bajo el concepto de low code). Y estos usuarios pueden ejecutar cualquier bot, y puede analizarlos, ejecucion paso a paso y otras actividades comunes del desarrollo de software.

Recuerden que un bot normalmente hace acciones de usuario final, por lo tanto estas herramientas tienen tecnicas avanzadas de grabacion de pantalla, acceso a openXml osea excel, word, powerpoint, acceso a navegadores como Google Chrome, Firefox, Opera, Internet Explorer, o Edge, acceso a bases de datos, y muchos otros (de hecho es algo de una competencia decir cuantos conectores o comandos tiene una plataforma) a traves de sus comodos bloques de ‘facil’ configuracion.

Y cabe mencionar que algunas soluciones pueden cobrar mas o menos segun la cantidad de conectores ustedes necesiten para desarrollar. Lo que significa que los Desarrolladores pueden ser de diferentes niveles.

No tienden a considerar como el flujo de usuario final, son un poco mas costosas, y tienden a tener algunas restricciones de ejecucion.

Otros conceptos de Licencias

Los paneles de control, pueden tener diversas funciones, y diferentes soluciones brindan diferentes costos y caracteristicas, normalmente relacionadas a:

• Descubrimiento de Procesos: Son algunos tipos de interfaces, que escanean y/o reciben datos, de los pasos de un trabajo e indican si pueden ser automatizados en un bot. Comunmente validan que software se usa, o la forma de navegacion web, o tienen interfaces como UML para casos de uso, que ayudan a escribir el proceso. Son de gran ayuda para empresas que no tienen ni idea de que hacen. Los ayuda a ordenar su trabajo.
• Descubrimiento de bots: Aveces escanean software, o programas y recomiendan automatizaciones. Es bien comun con SAP o entre migraciones de plataformas y bots.
• Optimizacion de Costos: Para reducir los pasos de bots por ejemplo.
• Modulos de Administracion de usuarios: Para gestion de roles y servicios
• Modulos de Paneles y Visualizacion: Para la presentacion de datos y retorno de inversion.

Y puede que una o todas de estas licencias u otras funcionalidades, tengan un costo adicional para su proveedor.

Bots por Flujos

Es una combinacion de los bots desatendidos y atendidos, donde los usuarios pueden invocar el flujo y esperar una salida. Los vendedores cobran por cantidad de flujos y por tiempo de ejecucion.

Bots por Ejecucion

Algunos proveedores pueden decirles que pueden ejecutar y construir cuantos bots quieran pero les van a cobrar por el proceso de computo.

Paquetes de Productos

Entonces una solucion de RPA esta compuesta generalmente por los siguientes componentes que pueden existir y tener las siguientes caracteristicas:

Conclusiones

Una solucion de RPA les va a brindar los componentes necesarios para que pueden crear bots, agendarlos en el tiempo o ejecutarlos en demanda, y puedan trabajar con ellos en conjunto o de forma aislada.

Todos los productos mencionados al inicio de este post, son de alta calidad, tienen soporte premium, son reconocidos, tienen multiples clientes, y soportan diferentes casos de uso.

Todos van a brindar esas caracteristicas globales con diferente palabreo, y caracteristicas unicas que los diferencia uno de otros ¿como pueden elegir la mejor solucion? Pues bien les tengo otra lista de validacion

• ¿Tienen documentados aquellos procesos que necesitan la automatizacion paso a paso?
  • Antes de comprar cualquier solucion de RPA, asegurarse que sus procesos necesitan ser automatizados.
  • Es una mala estrategia, comprar y luego organizar, quiza a una empresa grande no le importa gastar ciento de miles de dolares antes de entender como funciona. Pero una empresa pequeña puede recibir un golpe financiero.
• ¿Su plataforma tecnologia es compatible con el vendedor?
  • Por ejemplo si la mayor parte de su trabajo es a traves de Office 365, entonces la mejor decision seria usar Power Automate.
• ¿Tiene sentido para la organizacion, empezar a preocuparse por el desarrollo de soluciones de negocio automatizadas?
  • Para cada proceso, ahora van a surgir nuevas preocupaciones, que van necesitar de un especialista de RPA. Que pueda gestionar la plataforma.
• ¿Necesitan tener todo el software en premisas?
  • Referirse a la lista de En Premisas vs Nube.
• ¿Una vez cotizan el costo de la solucion, proyectar si es mas eficiente, y rentable a largo plazo, que nuevos empleados que se dediquen a ello?
  • Normalmente la respuesta es que si es mas rentable y conveniente la automatizacion, Pero deben tener en cuenta que para cada solucion de RPA, van necesitar desarrolladores de RPA, que pueden ser mas costosos que los otros recursos que ejecutan la tarea.
• ¿Se sienten comodos, con el vendedor? Es decir, ¿responde constantemente, el soporte valida sus opiniones?
  • Recuerden que una vez firman este contrato, es a muy largo plazo.

Un concepto más formal lo podemos conseguir en el siguiente link:

Una automatización robótica de procesos, o RPA (Robotic Process Automation), es una forma naciente de automatización de los procesos de negocio que replica las acciones de un ser humano interactuando con la interfaz de usuario de un sistema informático

Wikipedia

Esto puede se puede lograr mediante diferentes interacciones:

• Humano a Robot: donde un individuo realiza una acción que desencadena en la ejecución de un robot.
• Robot a Robot: donde una maquina se encarga realizar acciones para ser ejecutadas por otra máquina.
• Robot a Humano: donde un robot se encarga de realizar una acción que va a ejecutar un humano.

Cualquiera de estas interacciones con el fin de lograr un trabajo.

Tipos de RPA

De igual forma los flujos de trabajo o grupos de tareas que ejecuta un robot, a los que normalmente acuñamos como ‘RPAs’, podrían clasificarse en:

• Supervisados: Que ejecutan las tareas con supervisión de un humano, normalmente trabajando en el mismo espacio de trabajo (Ordenador personal)
• No supervisados: Que ejecutan sus tareas sin interacción y sin monitoreo. Normalmente en forma aislada

Uso de RPA

Los RPA se consideran ‘robots’ de software que realizan un grupo de tareas en particular, sobre la misma interfaz de usuario que un humano. A diferencia de una aplicación de software común que se comunica vía APIs (Independientemente de su género).

Esto quiere decir que, si se utiliza Windows, o KDE, o Gnome, etc. El robot va a mover el puntero, abrir ventanas, hacer clics, escribir vía el teclado. Y necesita el mismo tipo de accesos que un operador humano.

Plataformas de RPA

Existen muchos vendedores de productos de RPA, entre los más populares están UIPath, Automation Anywhere, Power Automate Microsoft, Blueprint, IBM RPA, entre otros.

Estas plataformas brindan servicios similares, con el propósito de cumplir con los objetivos básicos de RPA.

• Grabar acciones de una interfaz de usuario
• Normalmente bajo el concepto ‘Low Code’
  • Esto incluye tener ‘conectores’ o interfaces con programas comunes como Excel, Word, Chrome, Explorador de Windows
  • Interfaces de usuario de autocompletado
  • Algún tipo de ‘Inteligencia artificial’.
• Tener un controlador central que ejecuta y despliega robots.
• Trabajar con un fuerte licenciamiento por Bot o Ejecución.
• Llevar métricas de productividad.
  • Cuantos clics ‘ahorras’
  • Cuánto dinero por persona ‘ahorras’
  • Cuantos tecleado ‘ahorras’
  • Alguna otra métrica que signifique ‘ahorro’

Unidad Central o Control Room

Las plataformas también tienen algún un centro de comando, que normalmente es quien se encarga de conectar con Dispositivos, para ejecutar las tareas. Ya sea en demanda o de forma programada.

Las unidades centrales, también permiten funcionalidad básica de RBAC, y funcionalidad de paneles de control y consumo de licencias y computo.

Dispositivos o Ejecutores

Son las unidades que se conectan a la unidad central, y están disponibles para ejecutar las actividades. Pueden ser comúnmente ordenadores físicos o virtuales.

Diferencias con la automatización clásica

En general la principal diferencia son los fundamentos de la automatización, los productos de RPA están enfocados en usar la interfaz de usuario, para repetir tareas que realiza un operador humano.

Mientras que la automatización clásica, busca usar comunicaciones maquina a máquina mediante un API’s.

Y es esta misma naturaleza que lleva a los productos de RPA estar orientados a usuarios de negocio, no a desarrolladores de software. Y esto último revela

Posibles Problemas

Estos son básicos para un desarrollador de software, entre ellos yo me he encontrado con:

• Las interfaces de diseño, normalmente no son exportables, te vinculan fuertemente.
• Necesitan equipos dedicados para realizar ciertos tipos de tareas.
• Necesitan configuraciones especiales sobre los sistemas operativos y sus sesiones.
• Es considerablemente más lento que una interfaz vía API.
• Lo cual requiere de más Dispositivos para realizar más acciones en paralelo. (Lo que eleva más su costo)
• Debido a su propio ambiente de desarrollo, son rara vez interoperables entre proveedores
• Debido a su vinculación con ambientes de creación cerrados y sus tendencias ‘low code’, el versionar código fuente y el trabajo colaborativo es sumamente básico.

Que son problemas originales del desarrollo de software al volverse masificado, o al tener muy alta demanda de servicios.

El desarrollo de robots

Este aspecto es muy positivo en todos los proveedores, la mayoría permite realizar las mismas conexiones a programas de usuario sin mayor problema. Y un robot queda totalmente en manos del usuario que lo genera, debería ser un usuario de negocio, pero estos no tienen tiempo comúnmente, lo cual lleva a un submercado de consultores y expertos que crean RPAs equivalentes a un desarrollador de software.

Así que dependiendo de su organización, y su rol, siempre van a ver anuncios y los van a contactar empresas que tercerizan este trabajo como gurús

¿Que se necesita para un robot exitoso?

• Una lista de pasos claro.
• Un caso de negocio exitoso
• Mapear el tipo de valor que genera.

Con esa información, cualquier individuo podrá generar un robot.

En conclusión

Los RPA son un producto muy rico en capacidades, que puede aumentar la productividad de las personas de una empresa.

Son de fácil uso, y son configurables. Generando mayor ahorro de tiempo y costos.

Sin embargo, no siempre son la opción más viable, ni más económica. Es un intercambio entre horas útiles de un empleado para generar más valor contra costo de la automatización.

Otro punto adicional es que no son un ‘Jack of all trades’ están enfocadas a cierto tipo de usos, y en esos casos son excepcionales.

Muchas empresas según sus políticas cuestionables, pueden incluso orgullosamente, reemplazar las personas que tengan tareas simples como copiar archivos de una carpeta a otra por robots y retirar al recurso humano. Fallidamente porque luego necesita contratar a otra persona que monitoree al robot o haga otro trabajo similar o trabajos adicionales que hacia la persona que despidieron.

En el blog ire publicando conceptos fundamentales (y muy discutibles) en base a mi experiencia en las diferentes areas.

Y particularmente, la construccion de un proyecto para un Producto RPA que no utilice licencias de un proveedor, sistema operativo, sea autosustentable, mediante tecnologias de codigo abierto, solo con esfuerzo, experiencia y codigo gestionado por la organizacion que lo necesite.

De forma que el contenido sea bastante abierto y controversial, para que siempre haya de que reir sarcasticamente (conmigo o de mi).

Se podran suscribir y recibir correos eventualmente.

Saludos.