En el último evento de presentación de Microsoft, bastante eclipsado por la prominencia del anuncio de Microsoft Mesh sobre el posible futuro de la realidad aumentada, había un anuncio mucho más discreto en torno a una tecnología, Power Automate Desktop, que entronca con un concepto que lleva tiempo vendiéndose desde el mundo de la consultoría como la última ola que interesa a los directores de tecnología corporativos: el Robotic Process Automation (RPA). Básicamente, procesos de automatización basados en software que posibilitan el desarrollo de tareas rutinarias, y que muchos ven como una forma de incrementar la productividad de los trabajadores.
El anuncio de Power Automate Desktop, una herramienta gratuita para Windows que posibilita la creación de ese tipo de flujos de trabajo automatizados, es visto por muchos como una forma de automatización que podría llegar a sustituir a muchos trabajadores en empleos rutinarios, aunque en la práctica, tiene bastante poco de novedoso. Módulos de este tipo llevan estando disponibles en entornos como Apple o Linux bastante tiempo, y nunca han recibido una atención excesiva. Que ahora sea Microsoft quien proponga su alternativa y la ofrezca de manera gratuita integrada en Windows, sin duda el entorno que más penetración tiene en los entornos corporativos, podría tal vez acelerar el proceso y posibilitar incrementos de productividad derivados de ese tipo de automatizaciones de procesos rutinarios, con la consiguiente liberación de tiempo. En otros casos, se habla de la posibilidad de que el RPA lleve a cabo procesos que antes, en muchas compañías, se llevaban a cabo en modo outsourcing en compañías externas en países con costes laborales más bajos, que podrían por tanto pasar a ser realizadas con recursos locales.
El concepto de RPA es, como tal, bastante antiguo, y va desde la captura de datos en otras aplicaciones o servicios, hasta la integración de APIs en otras aplicaciones empresariales, de conectores en sistemas de gestión de servicios, de servicios de terminal o, cada vez más, de aplicación de algoritmos de machine learning como el reconocimiento de imágenes o de patrones de datos. El RPA está recibiendo una atención creciente precisamente debido a este tipo de posibilidades, a la incorporación de machine learning al proceso (Cognitive RPA, RPAAI o simplemente RPA 2.0), y al uso de plataformas de software de uso cada vez más sencillo y fiable. Sin embargo, está por ver que incluso con esas herramientas de uso relativamente sencillo, este tipo de procesos de automatización deban ser asumidos por los propios trabajadores – que pueden verlos como una mayor comodidad, pero también, como ya hemos comentado, como una amenaza de sustitución – o por los departamentos de tecnología corporativos.
Si evocamos los ejemplos de hace tiempo, la difusión tecnológica del RPA podría parecerse a, por ejemplo, el uso de macros en hojas de cálculo como Excel: formas de automatización relativamente sencillas que prácticamente cualquiera podía utilizar con una curva de aprendizaje relativamente baja y que podían dar lugar a resultados bastante brillantes, pero también a errores o a procesos difícilmente estandarizables, generalmente muy dependientes de la persona que los había puesto en marcha. Obviamente, el trabajador es quien mejor conoce sus rutinas y las partes de las mismas que pueden ser automatizadas, pero también es posible que los resultados sean mejores si esos procesos son supervisados, documentados y gestionados por los departamentos de sistemas corporativos.
¿Generará el actual énfasis en herramientas de RPA una mejora en la calidad de vida de determinados trabajadores que llevan habitualmente a cabo procesos rutinarios, o irá más allá y provocará procesos de sustitución? ¿Conseguirá Microsoft, mediante la incorporación de herramientas de RPA al sistema operativo más habitual en entornos corporativos, una extensión del uso de esas herramientas, o seguirán siendo de uso relativamente marginal?
This article is also available in English on my Medium page, «Is RPA finally about to realize its potential?«
Existe un ideal casi obsesivo en las mentes de los fabricantes de estas herramientas de automatización, como antes las herramientas BPM (Business Process Management), y antes las herramientas de workflows, y es que los usuarios finales de negocio, o los analistas funcionales, puedan crear soluciones informáticas «sin escribir código» (el «low code» o «no code») mediante interfaces visuales, conectores, ventanas de propiedades, etc. Sin entrar en detalles, tales aproximaciones en manos inexpertas no reutilizan cosas ya hechas sino que las repiten («copy & paste»). Y aunque muchas de ellas ofrecen crear bibliotecas de elementos reutilizables («templates», etc.) es mucho pedir que los usuarios finales reutilicen cosas si ya cuesta en muchos casos inculcar a los programadores profesionales las bondades de la reutilización de código.
En el caso más extremo que conozco de reducir la barrera de entrada, Microsoft llegó a traducir a otros idiomas como el español las sentencias Basic del lenguaje de macros de Excel (VBA) para que los usuarios no tuvieran que aprender el inglés mínimo para escribir o leer sentencias «For», «While», «If» sino sentencias «Para», «Mientras», «Si», etc.
Es un ideal bienintencionado pero con escaso recorrido. En mi experiencia, salvo casos puntuales de usuarios muy motivados, autodidactas y muy avanzados, estas herramientas son usadas por «los informáticos» (no por los usuarios de negocio) para crear soluciones con menos esfuerzo. Ocurre mucho el efecto contrario: usuarios sin conocimientos sólidos de informática que se meten a construir soluciones, por ejemplo en un Excel (como si fuera una base de datos), hasta que aquello revienta por algún lado, y entonces tienen que levantar la mano y pedir ayuda al departamento de IT, que se queda horrorizado al ver lo que se han construido.
Por tanto, creo que estas herramientas no serán usadas los usuarios finales para hacer más llevadero su trabajo, sino por el departamento de IT para reducir tiempo. La consecuencia para los usuarios finales dependerá de si estos usuarios tienen tareas de más valor añadido, o si solo están para hacer tareas rutinarias.
PD: En el caso de Microsoft, solamente distinguir la oferta de productos (y sus cambios de nombre) como Power Apps, Azure Logic Apps, Power Automate, Flow, etc. y sus casos de uso para elegir la herramienta apropiada ya conlleva un esfuerzo.
Por tanto, creo que estas herramientas no serán usadas los usuarios finales para hacer más llevadero su trabajo, sino por el departamento de IT para reducir tiempo
Nada nuevo bajo el sol… ya desde los 80 teníamos las Herramientas CASE… que eran mas un incordio que otra cosa… llevar estas herramientas al user final, es una complicación para ellos, y para IT.
La máxima (reconozco que irrespetuosa) que he empleado siempre es: “el usuario es tonto y así debe seguir siendo”, porque cuanto mas “sabe” el user (luser) más complicación en IT. No hay nada peor que el “enteradillo” de turno… Por tanto, vamos a dárselo todo mascadito, que es lo mismo que “haz bien tu trabajo y que el user se limite a apretar teclas”
La traduccion de EXCEL a idiomas, no es tal. Todas las funciones Excel son en realidad un codigo (numero), para evitar que un excel hecho aqui, no deje de funcionar en Alemania y se traduzca automaticamente. Eso es una ventaja.
Como profesor de ofimatica (sobretodo, Word, Excel) te digo que las macros producen sarpullidos en los alumnos… Meterse en VBA, hasta a mi…XDD
Allá por 1990 tuve un programador que conectando los cinco programas de ofimática de Windows, con unas macros en Visual Basic hacia autenticas virguerías.
Muchas cosas similares a lo que con muchos días de trabajo de muchas personas. haciamos nosotros a nuetros clientes.
Por ello, propùse a la dirección explorar ese camino, pues estaba seguro que mucho de lo que hacíamos se podía hacer asi mas rápido, Llevé ejemplos de lo que habia hecho ese chico y relammente se quedaron sorprendidos de las posibilidades.
Pero mi proyecto no fue estimado y cuando pregunté por qué, se me dijo, que si la mitad de un proyecto se resolvia con solo la Ofimática de Windows, los clientes se negarian a pagar lo que valía el análisis, (o sea mi trabajo).
Desgraciadamente el trabajo se mide por el esfuerzo que cuesta relizar un objeto, si no hay tal esfuerzo se tiende a devaluar el valor del objeto, aunque lo que el objeto produzca sea igual.
Me dejas a cuadros y lo peor es que me lo creo. Siempre hay gente con una visión estrecha, y lo peor, a veces al mando.
Pero mi proyecto no fue estimado y cuando pregunté por qué, se me dijo, que si la mitad de un proyecto se resolvia con solo la Ofimática de Windows, los clientes se negarian a pagar lo que valía el análisis, (o sea mi trabajo).
Estoy de acuerdo, porque lo he vivido. A mediados/finales de los 90 ya le decia a mis colegas analistas que llegaria un momento, en que los departamentos de IT nos veriamos desbordados (o mas bien, aniquilados) por la ofimatica, y en concreto por Excel/Access. La programacion «a medida» tendria sus dias contados, al menos en PYMES. Sumale la aparicion de los ERP’s (SAP, Navision…)
De todas formas, afina esa fecha que das, que chirria un poco XDD
(los OLE/COM empezaron en el 93 y los ActiveX en el 95) :P
A mi de esta historia lo que más me ha llamado la atención siempre es que los jefes de IT aún no dominan sobre los demás jefes, y todavía tenemos jefazos con salarios de 6 dígitos PROGRAMANDO macros Excel y Word para hacer el clásico «executive reporting» en la reunion mensual de operaciones.
Resulta incompresible las horas perdidas (y dineral) en hacer las mismas, o cuasi las mismas hojas de cálculo para hacer un seguimiento mensual de la marcha de la empresa. Eso debería de estar TOTALMENTE AUTOMATIZADO. Yo lo he visto desde los 90, y hoy siguen igual.
No conocen Microsoft Project??? XDD
Power Automate es una herramienta extremadamente divertida e interesante para gente analítica y motivada. Puede eliminar procesos repetitivos dejando a las personas más tiempo para hacer trabajo analítico.
Con las empresas que he trabajado si se automatiza algo así simplemente se añade más trabajo que antes no se hacía porque no era económicamente viable.
Pero como la gente menciona también genera muchos problemas. El que me parece más importante y que nadie menciona aquí es que la gente deja de pensar y confía ciegamente en la herramienta creada. Tratando unas reglas predefinidas, como a una inteligencia superior confiable en lugar de un gran pero tonto asistente. Otra de las muchas cosas que no mencionan las universidades o los departamentos de marketing.
Nicholas Carr cubre este problema muy bien en The Glass Cage: Where Automation is Taking Us
Iba a probarlo pero…
Enrique nos dice «una herramienta gratuita para Windows»
ERROR
Microsoft lo que da gratuito es que el «Try it» (el viejo truco para monos)
Iba a ser muy «crítico» a esta presunta novedad de Microsoft (que si es una copia de la idea de automator(mac) o que se hace todo más sencillo con scripts de bash) pero si el otro día os pareció diseñar la bomba atómica usar el lenguaje de programación más sencillo de aprender y que se puede usar con esa técnica tan usada por estos lares, (el copy paste) pues entonces simplemente dar la bienvenida a un SW que puede hacer feliz a unos cuantos anti programadores, aunque con perspectiva de más pereza aprenderse ese interfaz que usar cuatro líneas de código. En fin algo tendrán los «plátanos» que le gustan tanto a los monos
Allow individual users to create unlimited flows based on their unique needs.
Buy Now
$40
per user/month
Allow individual users to create unlimited flows, plus automate legacy applications through robotic process automation (RPA) and AI.
Includes 5,000 AI Builder service credits per month.
Requires access to the Microsoft 365 admin center with global administrator or billing administrator roles.
PS: «mono» dícese del espécimen presuntamente humano que tiene aversión a usar la línea de comandos de un OS.
(Relax…. aqui dan titulos de analista en los paquetes de pipas) XDDD
El equipo de Office, no para de hacer progresos. Me sorprendieron en 2016 cuando se implementó el poder vincular tablas en Excel haciendo algo que solo era posible en Access.
Sumado a esto, lanzaron un nuevo lenguaje de programación Power FX (low code)
Será cuestión de empezar a toquetear…
A que te refieres con «vincular tablas»???
Que yo sepa, eso se puede hacer ya desde las versiones 2000/2003 (si no antes)
Imagino que dices que un cambio en una se refleje en otra enlazada…
Crear una relación entre tablas en Excel
Errata 1: sí, el término «vincular» es ambiguo (tampoco es que estemos en Stack Overflow, no te pongas quisquilloso XDDDD)
Errata 2: fue a partir de la 2013
No soy quisquilloso.. te repito que puede hacerse al menos desde la version 2003.
De hecho, cuando empleamos las «tan temidas» tablas dinamicas, son justamente eso… las hojas se convierten (internamente) en tablas y se vinculan entre ellas.
Si te refieres a partir de 2013, quizas hagas referencia a las Power Pivot, que una vez las tienes por la mano, son una bestialidad… :P (no aptas para cardiacos) XDDD
Otra cosa, es que la gente en general, considere la hoja como tal, una hoja, sin saber, que le puedes dar rango de tabla
Te añadire algo…
Como bien digo arriba, a Excel le cogi una mania que ni te imaginas, porque en esa epoca (finales de los 90) tenia claro que se iba a cargar la labor del «informatico interno» en Pyme.
Cuando empece en la formacion en 2005, Excel era mi asignatura principal, y pase de odiarlo a amarlo, porque me di cuenta de su potencial (y poca gente lo imagina) y eso, sin meterse en VBA.
Ahora bien, el problema de Microsoft con Excel, es que no deja de hacerle «añadidos», en lugar de potenciar lo existente. Y Power Fx es un ejemplo mas…
Todos los lenguajes de programación si son un sistema de Turing completo son equivalentes y pueden emularse entre sí.
Que en resumidas cuentas viene a decir que cualquier programa que emule una máquina de Turing se puede realizar en otro lenguaje completo. Pero no significa que el esfuerzo que te suponga esa emulación en uno o en otro lenguaje sea el mismo. De ahí que existan benchmark entre distintos lenguajes de programación y que unos sean más usados que otros. En el caso que nos ocupa «algo que no se pueda hacer» hoy con excel en principio es imposible si se puede hacer con otro lenguaje de programación lo que hará falta es conocer la suficiente programación para desarrollar esa funcionalidad no implementada hoy en día en excel.
En cuanto a BD y Excel, si vamos a hacer cosas serias de BD, lo suyo es usar sistemas que lo usen como mucho como visualizador de tablas y procesarlas desde fuera. (Es lo que hace la gente que sabe…)
Pero por poner un ejemplo imaginemos que no se pueda «hace relaciones con tablas» pues no es cierto, antes de ese parche de Microsoft, cualquiera que sepa podría haberlo hecho. ¿Pero a quien le va a interesar hacer updates de Excel para eso? Si la respuesta es solo a Microsoft.
El problema en general con un SW privativo suele ser
1) No tienes acceso a las tripas de ese sistema
2) O no hay interfaces publicados por ejemplo para hacer rutinas en ensamblador o en C
¿Qué significa eso? Que los SW privativos son sistemas cerrados por el fabricante, e implementarán lo que les apetezca en cada momento según sus necesidades de marketing o comerciales.
Una vez que hemos visto que por muy estúpido feo o poco usable sea un lenguaje de programación es posible añadirle una determinada feature o función tenemos por otro lado tenemos otros aspectos muy importantes para el usuario:
a) El benchmarking : velocidad CPU, gasto de memoria, …. Si un determinado parche hace una determinada función pero es muy lento, o está limitado a ficheros pequeños, etc etc. entonces podremos pensar que ese update no es adecuado para esa tarea. (Eso me ha pasado que he intentado emular una determinada historia con matrices y como soy un programador muy aficionado y nada profesional, el resultado es mucho peor que recurrir a una libreria especializada como Numpy)
b) Curva de aprendizaje. Normalmente si cualquier lenguaje hace cualquier cosa, nos interesará optar por el que más use la comunidad, o por el que tiene una curva de aprendizaje más rápida, o el que está disponible en más OSs. Así si vamos al top de 50 lenguajes más usados o es algo muy bueno en cierta materia (p.ej. R y estadística) o estamos haciendo el canelo aprendiendo algo que no se usa, y en cuanto no sea rentable el fabricante lo dejará de actualizar. Y nuestro esfuerzo en training se habrá malgastado. O si la empresa se pasa del mundo windows al mundo mac o linux, tendremos que aprender otro sistema. Aunque es cierto que aprender algo siempre da background, aunque lo dejemos de usar.
c) Por último es importante que si es muy usado, elijamos un SW libre donde va a ver una comunidad que por ejemplo haya librerias (P.ej. en machine learning las más usadas son scikit-learn y tensorflow) a nuestra disposición.
https://medium.com/the-open-manuel/top-50-programming-languages-in-the-world-508a119cb714
Efectivamente, toda la razón en todo. No me gusta entrar en tecnicismos, porque no todo el mundo en este blog, es “informático” (aunque a algunos la etiqueta autoimpuesta les vaya bien a costa del ridículo).
Cada lenguaje, tiene sus pros y sus contras, de ahí que siempre se hable de FORTRAN para matemática y física, COBOL para gestión, o BASIC para aprender… y con los años, es tal la multitud de lenguajes y su alcance que se han vuelto casi todos ellos polivalentes.
Ahora bien, en tanto lo que hablaba con JAVIER, que es la potencia de EXCEL, yo me he especializado (últimamente) en migraciones y te aseguro, que las chapuzas que pudiera hacer en C o cualquier otro, Excel me las trajina en un pispas, sobre todo para diferenciación de datos, cambio de formatos y como no, el import/export (que si me lo dices hace 25 años, aun me estoy riendo).
Los sistemas privativos son un problema? Si y no.
He vivido migraciones, que han costado en euros, lo que toda la implementación inicial (privativo a SAP o Navision), el precio de los consultores no compensaba el resultado final. Eso se da mucho en ERP’s, donde te venden, que el ERP se adaptara a ti, y al final acaba siendo la empresa la que se adapta al bicho.
Pero como esas decisiones quedan en manos de los MBA… es el descanso de tu conciencia…
Lo de usar SAP, lo he sufrido en carne propia.
Funcionaba muy bien con Excel, de hecho era mi herramienta favorita, y en tratar datos, formatos, visualizar es un campeón, sin duda…
Cuando tienes algo «virguero» hecho en excel, el MBA te mira mal, porque empieza a pensar este tío como se pire nos hace un agujero…. y luego que en el fondo sabe que en cualquier momento el sr. Microsoft te mete un parche que te cambia un parámetro y hasta que no lo localizas/n te dejada fundido a negro….
Por otro lado, alguien compra SAP o MAXIMO y como la empresa no quiera pagar una mega integración, lo que hay que hacer es adaptar los procesos de tu empresa al standard que te ponen, y esa es otra cagadita… y muy habitual. Y luego el jefe del MBA porque el dashboard que hacía «Sin Censura» le encantaba y el mega sistema que ha costado millones es una mierda. Y tu en medio. Y el MBA mirándote por tener tu dashboard niquelado…y la orden directa, coge los datos de las bases de datos del SAP y me actualizas el Dashboard como el de antes. Y todos contentos…
Entiendes ahora porque me dedique a descargar camiones y montar escenarios??? XDDDD