viernes, 30 de noviembre de 2018

Aprender a desarrollar chatbots con Srini Janarthanam

'Hands-on Chatbots an conversational UI interfaces' es un libro de carácter eminentemente práctico, orientado a desarrolladores pero cuyo intento, más que profundizar en una herramienta o tecnología concreta es, más bien, dar una idea razonable del abanico de canales, herramientas y recursos que se puede utilizar para la construcción de chatbots e interfaces conversacionales. Eso si, aunque sea a un nivel básico, se ejemplifica perfectamente con código y uso de herramientas concretas los fundamentos reales del desarrollo de chatbots.

El autor selecciona algunos escenarios o aplicaciones prácticas de chatbots y con base en ellos define los capítulos y aborda las diferentes herramientas, y técnicas. Con esa estrategia, el libro se estructura en los siguientes nueve capítulos:
  • 'Introduction': Da información de carácter general sobre los chatbots e interfaces conversacionales, explicando el concepto, su evolución histórica, la arquitectura básica, una clasificación y algunas aplicaciones y beneficios. Además, enumera ya algunas herramientas y directorios de chatbots.

  • 'Tour guide to your city': Toma como primer escenario un chatbot que sirve de guía turístico por una ciudad. Aprovecha el escenario para hablar de Chatfuel y cómo usar el canal Facebook Messenger. También nos habla de la integración con servicios JSON y de analítica

  • 'Let's talk weather': Se trata ahora de construir un chatbot que ofrezca información sobre el tiempo atmosférico. Continuamos con Chatfuel y Facebook Messenger y ahora introducimos el uso de Node.js. Además, también utilizamos App Facebook y profundizamos en la integración de backoffice.

  • 'Building a persona bot': El escenario elegido para este capítulo es un chatbot que represente a Albert Einstein. Aprovechando ese escenario, se introduce el uso de lenguaje natural y empezamos a trabajar con Dialogflow incluyendo la integración del chatbot en una página web y Facebook.

  • 'Let's catch a train': Ahora se usa un escenario consistente en un chatbot que proporciona información sobre horarios de trenes. Y cambiamos completamente de canal pasando a utilizar los SMSs para lo que nos apoyamos en la herramienta Twilio.

  • 'Restaurant search': Un nuevo escenario: en este caso la búsqueda de restaurantes. Este escenario se usa para ilustrar el desarrollo con Microsoft Bot Framework junto con la librería Node.js. Además, aprendemos a usar Skype como canal y la integración a través del API Zomato para obtención de datos.

  • 'The news bot': Se desarrolla el escenario consistente en un bot que proporciona noticias. Con él, cambiamos de nuevo de canal pasando a usar Twitter. También exploramos la API del propio Twitter, NewsAPI o el apoyo en MongoDB.

  • 'My TV guide': Construimos un bot enfocado a la programación de televisión. Y con él, aprendemos a desarrollar para Amazon Alexa y desplegar 'skills' en Amazon Echo.

  • 'My man friday': En el último escenario, construimos algo así como un ayudante personal. Con esta base, exploramos el desarrollo con Google Assistant y despliegue de 'actions' en Google Home.

El libro finaliza con una serie de anexos donde nos proporciona información y recursos tales como artículos, conferencias, revistas o grupos en medios sociales.

Todo el libro se ilustra con fragmentos de código y capturas de pantalla de las herramientas utilizadas. En definitiva, 'Hands-on Chatbots an conversational UI interfaces' es un libro interesante y práctico que no nos vale para hacernos especialistas pero sí para tener una idea muy clara´, amplia y realista de las diferentes alternativas para desarrollar chatbots e interfaces conversacionales.

Un buen recurso para empezar.

Srini Janarthanam

(Fuente: Traducción y ligera elaboración del perfil en perfil en LinkedIn)

Srini Janarthanam
Autocalificado como resolutor de problemas, programador y en continuo aprendizaje, es un apasionado de las máquinas que hablan y piensan y ha estado construyendo chatbots usando inteligencia artificial y técnicas de tratamiento de lenguaje natural desde sus días de estudiante universitario.

A lo largo de los años ha construido un gran cantidad de asistentes en una variedad de dominios y acumulado experiencia acerca de lo que funciona y lo que no. Cree que los chatbots pueden proporcionar a los usuarios una experiencia cautivadora y ausente de esfuerzo sirviendo como una interfaz autoservicio a los negocios.

Ha dirigido y desarrollado chatbots que han sido premiados y tiene más de 10 años de experiencia en tecnología conversacional (esto es, tecnología donde convergen los sistemas de diálogo, el procesamiento de lenguaje natural, machine learning e Inteligencia Artificial.

Srini está doctorado en Inteligencia Artificial y Procesamiento de Lenguaje Natural por la Universidad de Edimburgo y ha sido autor de más de 50 artículos de investigación.

Recientemente ha publicado un libro sobre Chatbots e Interfaces Conversacionales ('Chatbots and Conversational UIDevelopment') que se encuentra disponible en Amazon. También bloguea sus pensamientosen Medium y ha sido publicado en revistas sobre chatbots como ChatbotNewsDaily y ChatbotsMagazine.

Puedes saber más del autor visitando su perfil en LinkedIn o siguiéndole en Twitter donde se presenta como @srinivasancj.

Ficha técnica:

EDITORIAL: Packt Publishing
AÑO: 2017
ISBN: 978-1788294669
PAGINAS: 392

Artículos de este blog relacionados

miércoles, 28 de noviembre de 2018

Beneficios que traen consigo los chatbots


Los chatbots, las interfaces conversacionales, son mucho más que unas soluciones de moda, o unas aplicaciones divertidas o curiosas. Realmente tienen muchísimo sentido de negocio puesto que aportan grandes beneficios en el entorno corporativo. ¿Cuáles son esos beneficios que traen consigo los chatbots?


En su libro 'Hands-On Chatbots and Conversational UI Development', Srini Janarthanam nos dice que las interfaces conversacionales traen lo mejor de dos mundos: la tecnología digital y la interacción natural al estilo humano, e identifica estos seis beneficios de esas interfaces conversacionales:

  • Disponibilidad: como cualquier solución digital, las interfaces conversacionales tienen una disponibilidad 7x24 sin las problemáticas que conseguir esa misma disponibilidad supone en el caso de seres humanos.

  • Experiencia personalizada: Al contrario de lo que sucede con aplicaciones tradicionales, las interfaces conversacionales proporcionan una experiencia personal y personalizada, natural y adaptada a su interlocutor.

  • Bajo coste: Son soluciones que son relativamente baratas de construir y, desde luego, son muchísimo menos costosas que un servicio similar proporcionado por seres humanos.

  • Consistencia: Además de natural y personalizada, la experiencia que se obtiene con los chatbots es consistente, no sujeta a cambios de humor o diferentes personalidades.

  • Cortos tiempos de respuesta: En general los chatbots proporcionan mejores tiempos de respuesta que los operadores humanos, no tanto por su diferencia de velocidad intrínseca sino por la capacidad de realizar tantas ejecuciones en paralelo como sean necesarias sin necesidad de que el interlocutor al otro lado tenga que esperar para que un operador se encuentre disponible.

  • Escalabilidad: En la línea de lo dicho en el beneficio anterior, es relativamente sencillo escalar chatbots para que manejen la carga de trabajo que se precise sin necesidad, evidentemente, de contratar o formar a nuevos agentes.

Si a los beneficios anteriores le añadimos, ahora sí, que proporcionan una experiencia natural, divertida y atractiva, se comprende que sean tendencia y se deduce que toda compañía debería examinar en serio la posibilidad de incluir chatbots e interfaces conversacionales en las diferentes interacciones con empleados y, sobre todo, con clientes.


lunes, 26 de noviembre de 2018

La arquitectura básica de una interfaz conversacional (chatbot)


Los chatbots y las interfaces conversacionales incluyen en su interior tecnología avanzada, tecnología con frecuencia procedente del campo de la inteligencia artificial y que es la que le permite tratar el lenguaje natural o reconocer la voz humana. Sin embargo, la arquitectura básica de una interfaz conversacional, entendida como un diagrama de bloques genérico, no es difícil de entender.

En su libro 'Hands-On Chatbots and Conversational UI Development', Srini Janarthanam propone una arquitectura básica con los principales bloques de este tipo de soluciones. No he podido conseguir la imagen original, pero los bloques son los que se muestran en la figura de abajo:


¿Qué tenemos?

En primer lugar, dos bloques para el tratamiento de la voz, dos bloques que sólo tienen sentido cuando nuestra interfaz conversacional, nuestro chatbot, se comunica por voz. En ese caso tendremos un módulo de reconocimiento de voz, para atender a lo que dice el usuario y un módulo de síntesis de voz para que el chatbot pueda 'hablar'.

Luego tenemos el gestor de la conversación, es decir, el módulo que de alguna forma decide el flujo de la conversación o qué contestar ante lo que el usuario exprese. Es de alguna forma el elemento central, el que define la conversación, la personalidad, el estilo y lo que el chatbot es en el fondo capaz de ofrecer.

Además, existe un módulo para el entendimiento del lenguaje natural (NLU, Natural Language Understanding), es decir, para sacar el sentido de lo que el usuario ha querido decir, sea por voz o por escritura de texto.

Además, existe un módulo de integración con el backend. Los chatbots normalmente se apoyan en informaciones y servicios que exponen otros sistemas o aplicaciones mediante APIs. El módulo de integración con el backend se encarga de interaccionar con esas aplicaciones o sistemas vía las APIs que éstos ofrecen para poner a disposición del chatbot y, a través de éste, a disposición del usuario todo tipo de informaciones y servicios: tiempo atmosférico, horarios de autobuses o aviones o reserva de entradas para un espectáculo, por poner algún ejemplo.

Finalmente, tenemos el canal, es decir, el medio en el que habita y a través del cual se comunica el chatbot. Canales habituales son sistemas de mensajería como Facebook Messenger, Skype o Slack, aplicaciones web, Twitter, SMSs, etc

****

Como se puede ver, una arquitectura fácil de comprender lo cual es afortunado. Sin embargo, eso no debe hacernos olvidar que hay mucha tecnología por detrás de esta arquitectura sencilla, tecnología especialmente para el tratamiento del lenguaje natural y la voz. También mucho diseño y trabajo en lo que tiene que ver con definir la personalidad del chatbot y los flujos de conversación y, finalmente, mucha funcionalidad e información a la que normalmente accedemos como servicios de terceros vía la integración.

Un afortunado equilibro entre complejidad subyacente unido a una relativa sencillez para disponibilizar estos chatbots e interfaces conversacionales gracias al esfuerzo y buen hacer de los creadores de este tipo de tecnologías.


viernes, 23 de noviembre de 2018

Aprender a construir robots con UiPath con la ayuda de Vaibhav Jain

En el momento de realizar esta reseña, Noviembre de 2018, UiPath es la solución de RPA (Robotic Process Automation) líder en ventas y crecimiento del mercado y 'Crisper learning for UiPath' es una explicación de en qué consiste esa herramienta y cómo se trabaja con ella, especialmente en el desarrollo de robots con UiPath Sudio.


El libro, no muy largo, se compone de catorce capítulos:

  • 'A glimpse into the future:': Un capítulo muy, muy breve que introduce el cambio de orientación en automatización.

  • 'What is RPA?:': Define RPA, proporciona los pasos para hacer un robot (con la perspectiva UiPath) y realiza una rápida comparación entre tres soluciones: UiPath, Automation Anywhere y Blue Prism.

  • 'UIPath essentials:': Explica la diferencia entre robots atendidos y no atendidos, comenta los elementos de la suite de UiPath y profundiza un poco más en las partes de UiPath Studio, la herramienta de desarrollo.

  • 'Data variable & types:': Habla de variables y tipos de datos, incluyendo aspectos como el ámbito ('scope') o los argumentos

  • 'Data operations:': Explica las operaciones fundamentales con datos, como las operaciones aritméticas, de cadenas o lógicas. También habla brevemente de las actividades de control de flujo y los bucles.

  • 'Recording:': proporciona los fundamentos de la grabación de acciones de usuario, explicando los distintos tipos de grabadores en UiPath y comentando muy brevemente cada uno de ellos.

  • 'Ui Elment interactions:': Habla de los distintos métodos de entrada ('Default', 'Windows messages' y 'Simulate Type/Click') y salida ('FullText', 'Native' y 'OCR') en la interacción de los robots con interfaces de usuario, con sus características diferenciales, ventajas y desventajas y cuándo es mejor aplicar uno u otro.

  • 'Selectors:': Profundiza en el concepto de selector, un aspecto complejo de UiPath que se usa para identificar los elementos de las interfaces de usuario. Nos habla de lo que son, la diferenciación entre selectores completos y parciales, cómo estabilizarlos y el uso de caracteres comodín e índices en ellos.

  • 'Image & advanced citrix automation:': Explica la forma de grabar y trabajar cuando se automatiza con una interfaz de usuario virtualizada como el caso de Citrix. Explica las actividades específicas que se emplean en este caso y también el uso del teclado.

  • 'Spreadsheet automation:': Explica el tratamiento específico de la integración con hojas de cálculo así como las actividades dedicadas a trabajar con datos de tipo tabla.

  • 'PDF automation:': Explica cómo trabajar con ficheros PDF, tanto `para la extracción de grandes bloqwues de texto como para el acceso a datos concretos.

  • 'Email automation:': Trata de cómo trabajar con los protocolos de correo electrónico en sus distintas variantes (SMTP, POP3, IMAP, Exchange y Outlook) tanto para el nvío como para la recepción y tratamiento de correos.

  • 'Error handling:': Nos explica cómo depurar un robot, el tratamiento de excepciones y algunos errores típicos.

  • 'Project management:': recoge algunas buenas prácticas en la gestión de proyectos de automatización con UiPath, cómo generar workflows a modo de componentes e invocarlos desde otro superior y finaliza explicando brevemente UiPath Orchestrator, la herramienta dedicada al despliegue, monitorización y control de robots ya en operación.

'Crisper learning for UiPath' da una visión bastante completa, aunque no del todo profunda, del uso de UiPath en desarrollo de robots y sigue mucho tanto en su estructuración como en sus contenidos, el planteamiento del curso inicial de desarrolladores ofrecido por la propia UiPath. Se trata, creo, de una buena propuesta para introducirse en UiPath o para un repaso rápido, aunque no tiene el nivel de detalle necesario para convertirse ni en el material de aprendizaje definitivo ni en un manual de referencia para consulta.

Vaibhav Jain

(Fuente: Traducción y ligera elaboración del perfil en su página oficial pro-rpa)

Vaibhav Jain
Vaibhav Jain es un asesor senior de tecnología en Ernst & Young LLP con base en Los Ángeles. Ha estado implicado en la comunidad RPA durante más de dos años y dirigido varios proyectos de automatización robótica, tanto interna como externamente. Además ha impartido cursos sobre RPA a profesionales de forma que les permita delegar en robots software sus tareas manuales y repetitivas, haciendo más fácil para ellos sacar tiempo para un trabajo más productivo.

Puedes saber más del autor visitando su página oficial o siguiéndole en Twitter donde se presenta como @vaib20331.

Ficha técnica:

AUTOR: Vaibhav Jain.
EDITORIAL: Autoeditado
AÑO: 2018
ISBN: N/A
PAGINAS: 120

Artículos de este blog relacionados

miércoles, 21 de noviembre de 2018

Algunos hitos en la historia de los chatbots


Los chatbots son un tipo de soluciones con mucho presente y, sobre todo, con mucho futuro. Pero también tienen una historia y unos hitos relevantes a recordar. A modo de mera curiosidad, en este artículo quiero enumerar algunos de esos hitos en la historia de los chatbots.

Y para ello me apoyo como referencia en el libro 'Hands-On Chatbots and Conversational UI Development', de Srini Janarthanam donde, en sus primeras páginas, relata brevemente la historia de los chatbots e interfaces conversacionales, y enumera los siguientes hitos:

  • En 1964 Joseph Weizenbaum del MIT desarrolló el muy renombrado programa Eliza que emulaba a un terapeuta y que constituye uno de los iconos de la historia de la inteligencia artificial. El sistema conseguía que usuarios poco avispados no se diesen cuenta de que estaban conversando con una máquina en lugar de con una persona.

  • En 1991 se instituye el premio Loebner para animar a los investigadores a construir programas, digamos chatbots, capaces de superar el famosísimo test de Turing.

  • En 2011 Apple lanza Siri como primer asistente virtual personal.

  • También en 2011 introduce Watson, que consigue vencer en el concurso Jeopardy a los anteriores ganadores humanos Brad Rutter y Ken Jennings. Esto constituye otro famosísimo hito en la historia de la inteligencia artificial. Posteriormente, Watson se ha reconfigurado como un conjunto de herramientas y servicios cognitivos en el área de entendimiento de lenguaje natural (NLU, Natural Language Understanding), análisis de sentimiento, gestión de diálogos, etc

  • En 2013 Microsoft lanza Cortana

  • En 2014 un chatbot llamado Eugene Goostman, que retrataba a un niño de 13 años, logró 'confundir' a un 33% de los jueces de un concurso realizado para conmemorar el 60 aniversario de la muerte de Turing y, de esta forma, superó el propio test de Turing. A continuación se desarrollan AIML (Artificial Intelligence Markup Language) y ChatScript como una forma de simplificar la construcción de scripts para estos chatbots

  • En Noviembre de 2014, Amazon presenta en sociedad su asistente personal denominado Alexa que posteriormente se introduce en el mercado a través del producto Echo, el primero de los dispositivos para el hogar en forma de un altavoz y que utilizaba la voz como interfaz para relacionarse con el usuario y proporcionarle servicios.

  • En Abril de 2016, Facebook abre su Messenger a los chatbots y como plataforma para desarrolladores, introduciendo así un esquema diferente al de Siri, Cortana o Alexa. Le siguen muy pronto en ese planteamiento otras plataformas como Skype o Telegram.

  • En Mayo de 2016, Google anuncia Assistant, su propia plataforma de chatbots accesible desde diversas plataformas incluyendo su propio dispositivo denominado Google Home.

  • A partir de esta época, tanto Alexa como Assistant se puede personalizar mediante las denominadas, respectivamente, skills o actions.

Y, evidentemente, la historia no se detiene aquí, pero ya la dejamos muy cerca de nuestros días. O sea, que lo que nos toca a partir de ahora es seguirla muy de cerca y, si es posible, contribuir a ella.


martes, 20 de noviembre de 2018

Mi Actividad: Hablando de Agile y Automatización Robótica de Procesos en el marco del Programa Ejecutivo de Transformación Digital de EOI en Santander


El pasado viernes 16 de Noviembre tuve el placer de impartir una doble sesión dentro del marco del Programa Ejecutivo de Transformación Digital que imparte la Escuela de Organización Industrial en Santander.

Y hablé de dos temas que enfocan de forma diferente la necesidad de responder con agilidad ante los cambios continuos y acelerados que plantea la revolución digital.

Por un lado, una visión más de gestión, hablando de la gestión de proyectos con filosofía Agile. Repasamos los antecedentes, el porqué del surgimiento de Agile, los principios del manifiesto Agile y las principales características de Scrum, para acabar con alguna visión intermedia como la TI Bimodal.

Por otro lado, y en la segunda parte, adoptamos un cariz más tecnológico y con filosofía low-code, para hablar de RPA (Robotic Process Automation), revisando primero lo que es un proceso de negocio y las diferentes tecnologías que se emplean en su digitalización, para luego abordar la definición de RPA, las funcionalidades más habituales, su relación con la inteligencia artificial y aspectos relacionados con los proyectos de puesta en marcha o el centro de excelencia RPA, sin olvidar alguna breve demostración con la herramienta UiPath.

Cuatro horas intensas, con mucho diálogo y que espero que hayan sido tan provechosas para los alumnos como interesantes han resultado para mi.


lunes, 19 de noviembre de 2018

Sobre interfaces conversacionales y sus beneficios


Quizá si hablo directamente sobre interfaces conversacionales, el término  pueda sonar extraño. Si en vez de eso emplease términos como chatbot, interfaces de voz o asistentes virtuales. etc, podría resultar más conocido.

Lo cierto es que el término de interfaces conversacionales agrupa un conjunto de soluciones que tienen en común el servir para interactuar de manera automatizada con humanos mediante conversaciones basadas en (aunque no exclusivamente) lenguaje natural. Un lenguaje natural que se puede canalizar mediante texto sobre, por ejemplo, herramientas de mensajería como Facebook Messenger o Slack o que puede utilizar la voz como hacen Siri o Cortana y que, en algunos casos, 'habitan' un dispositivo especializado como Amazon Echo o Google Home.

Aunque el uso, el canal y los medios para expresarse pueden variar en las distintas soluciones, lo importante, y lo específico del conjunto de soluciones denominadas interfaces conversacionales, y que tendemos a denominar simplemente chatbots, es esa idea de automatizar los diálogos con seres humanos.

En su libro 'Hands-On Chatbots and Conversational UI Development', Srini Janarthanam nos resume esa diversidad de interfaces conversacionales al tiempo que destaca su sustrato común cuando dice: 


The actual difference between these systems is in terms of the background integrations (for example, databases, ans task/control modules), modalities (for example, text, voice, and visual avatars), and channels they get deployed on. However, one of the common themes among these systems is their ability to interact with users in a conversational manner using natural language.


El mismo autor y en la misma obra, nos resume los principales beneficios que este tipo de soluciones traen consigo, unos beneficios que combinan las ventajas del diálogo natural con el hecho de usar tecnología digital, y que serían:


  • Disponibilidad: Ya que al tratarse de software y no de personas, su disponibilidad puede ser 7x24 sin mayores problemas ni sobrecostes.

  • Experiencia personalizada: A diferencia de otro tipo de canales de relación como las páginas web o las Apps, los chatbots e interfaces conversacionales proporcionan unas interacciones muy personalizadas y adaptadas al usuario y la conversación particular que esté manteniendo.

  • Bajo coste: comparado con el coste de emplear a humanos para realizar las mismas labores.

  • Consistencia: es decir, una coherencia en el estilo y mensajes que no siempre es fácil de conseguir con equipos humanos.

  • Rápidos tiempos de respuesta: Así, por ejemplo, usando chatbots no es precisa la típica espera a que un operador se encuentre disponible. Además, los chatbots pueden procesar varias conversaciones simultáneamente.

  • Escalabilidad: Ya que, en caso de picos de actividad, es muy sencillo atender esa actividad mediante asistentes digitales, mientras que en el caso de operadores humanos es caro y lento el aumentar la plantilla que atiende a los clientes/usuarios.


Esos beneficios, unido al evidente progreso de los últimos años de las tecnologías del campo de la inteligencia artificial relacionadas fundamentalmente con el reconocimiento de voz y con el tratamiento y entendimiento del lenguaje natural, y también a la sencilla y barata disponibilidad de esta tecnología, en parte porque gigantes como Google, IBM o Microsoft han decidido que sea así, explican el auge actual y el más que previsible auge futuro de este conjunto de soluciones que familiarmente tendemos a llamar chatbots y que de una forma mucho más general y quizá más exacta, denominamos interfaces conversacionales.


viernes, 16 de noviembre de 2018

Actualizándonos en SOA con Thomas Erl.

En 'Service Oriented Architecture: analysis and design for services and microservices' Thomas Erl realiza un repaso actualizado de su trabajo sobre orientación a servicios llevado a cabo en los últimos años y recogido en numerosos libros. Se trata de un libro que más que de la tecnología en sí, trata del análisis y diseño de servicios y soluciones orientadas a servicios y, en ese sentido, resulta con frecuencia algo abstracto y un poco alejado del software real.

El libro se estructura en diez capítulos y cuatro apéndices, agrupados en tres partes:
  • 'Introduction:' que simplemente presenta el libro pero sin entrar en materia.

  • 'Case Study Backgrounds:' cuanta los casos de estudio que se utilizarán a lo largo de todo el libro a modo de ilustración y ejemplo.

  • 'PART I FUNDAMENTALS:'

    • 'Understanding Service Orientation:' explica lo que son los servicios y la orientación a servivicios como paradigma, presenta los principios de la orientación a servicios e identifica los problemas que se resuelven con la orientación a servicios.

    • 'Understanding SOA:' continúa con los conceptos básicos y en este caso explica lo que son las arquitecturas orientadas a servicios, las características que presentan y una tipología con los cuatro tipos más comunes de SOA presentados como cuatro capas: arquitectura de servicios, composición de servicios, inventario de servicios y empresa orientada a servicios. A continuación revisa los objetivos estratégicos y beneficios esperados y presenta un ciclo de vida y metodología para proyectos SOA.

    • 'Understanding layers with services and microservices:' propone una estructuración de los servicios empresariales en cuatro capas: servicios de utilidad, servicios de entidad, microservicios y servicios de tarea y cuenta cómo llegar a esa estructuración.

  • 'PART II SERVICE ORIENTED ANALYSIS AND DESIGN:'

    • 'Analysis and modeling with web services and microservices:' presenta un proceso para el modelado de servicios web que detalla paso a paso basándose en los casos de estudio propuestos en el segundo capítulo.

    • 'Analysis and modeling with REST services and microservices:' muy similar al anterior pero en este caso orientado a servicios REST y microservicios.

    • 'Service API and contract design with web services:' entra en un nivel mayor de detalle exponiendo cómo diseñar los servicios, incluyendo incluso aspectos como el nombrado, las operaciones, los documentos WSDL, etc

    • 'Service API and contract design with REST services and microservices:' de nuevo, muy parecido al anterior pero en este caso orientado a servicios REST y microservicios

    • 'Service API and contract versioning with web services ans REST services:' aborda la problemática del versionado y la compatibilidad tanto hacia adelante como hacia atrás.

  • 'PART III APENDICES:'

    • 'Service-orientation principles reference:' censa los principios SOA que se han tocado a lo largo de todo el libro
    • .
    • 'REST constraints reference:' es un censo de las diferentes restricciones en servicios REST abordadas en el libro, con una tabla perfil por cada una de ellas.

    • 'SOA design patterns reference:' censo de los patrones de diseño SOA mencionados en el libro proporcionando una tabla descritpiva por cada uno de ellos.

    • 'The annotated SOA manifesto:' versión comentada del manifiesto SOA.

A lo largo de todo el libro se nota que el autor pone énfasis en explicar los conceptos de una forma por un lado sencilla (con abundancia de ilustraciones y esquemas) pero también rigurosa y ordenada. A pesar de ello, en mi opinión, no consigue del todo comunicar con claridad las ideas, quizá por ese alto nivel de abstracción que, de todas formas, es preciso reconocer que el autor intenta paliar, con éxito solo parcial, mediante ejemplos y casos de uso. Por ejemplo, una de las ideas 'estrella' de este nuevo libro, los microservicios, apenas se entiende en qué consisten realmente. Por otro lado, es un libro que se hace algo largo y las explicaciones se hacen a veces inacabables. Es preciso de todas formas, reconocerle un tratamiento amplio, muy ordenado y sistematizado del campo de la orientación a servicios. Además, se trata de las pocas fuentes bibliográficas actualizadas disponibles hoy en día y esas tres cosas, amplitud, orden y actualidad son méritos a reconocerle.

Thomas Erl

(Fuente: Traducción y ligera elaboración propia de la página personal del autor)

Thomas Erl
Canadiense nacido en 1967, Thomas Erl es un escritor de éxito sobre IT y fundador de Arcitura Inc. Thomas ha sido el autor sobre tecnología de servicios más vendido durante más de siete años y es el editor de la Prentice Hall Service Technology Series (www.servicetechbooks.com), así como editor de la Service Technology Magazine (www.servicetechmag.com). Con más de 200.000 ejemplares vendidos, sun nueve libros publicados se han convertido en bestseller internacionales y han sido formalmente respaldados por miembros senior de las mayores compañías de IT como IBM, Microsoft, Oracle, Intel, Accenture, IEEE, HL7, MITRE, SAP, CISCO, HP y otras.

Cuatro de sus libros, 'Cloud Computing: Concepts, Technology & Architecture', 'SOA Design Patterns', 'SOA Principles of Service Design' y 'SOA Governance' fueron escritos en colaboración con la comunidad IT y han contribuido a la definición de los mecanismos tecnológicos del cloud computing el modelo arquitectural de la orientación a servicios y de la propia orientación a servicios como un paradigma con entidad propia. Thomas actualmente trabaja con más de veinte diferentes autores en varios libros dedicados a materias especializadas como cloud computing, Big Data, tecnologías de servicios modernas y orientación a servicios.

Como CEO de Arcitura Education Inc, en en colaboración con SOA School, Cloud School y Big Data Science School Thomas ha dirigido el desarrollo del plan de estudios para los internacionalmente reconocidos programas de acreditación SOA Certified Professional (SOACP), Cloud Certified Professional (CCP) y Big Data Science Certified Professional (BDSCP).

Thomas es miembro fundador del SOA Manifesto Working Group y autor del Annotated SOA Manifesto (www.soa-manifesto.com). Es miembro del Cloud Education & Credential Committee, SOA Education Committee, y además supervisa las iniciativas SOAPatterns.org, CloudPatterns.org y BigDataPatterns.org, dedicadas al desarrollo de catálogos de patrones maestros para arquitectura orientada a servicios, cloud computing y Big Data.

Thomas ha viajado a lo largo de más de veinte paises como conferenciante e instructor para eventos privados y públicos y participa regularmente en conferencias internacionales. Ha publicado más de 100 artículos y entrevistas en numerosos medios, incluyendo The Wall Street Journal y CIO Magazine

Puedes saber más del autor visitando su perfil en LinkedIn.

Ficha técnica:

AUTOR: Thomas Erl.
EDITORIAL: Prentice Hall
AÑO: 2016
ISBN: 978-0-13-385858-7
PAGINAS: 416

Artículos de este blog relacionados

miércoles, 14 de noviembre de 2018

Pensamientos sobre el auge y riesgo de los robots software


Algunos de los últimos artículos de este blog los he dedicado a RPA (Robotic Process Automation), es decir, robots software que automatizan total o parcialmente procesos de negocio. En breve, dedicaré algún artículo también a los chatbots, voicebots, asistentes virtuales o, si se prefiere, interfaces conversacionales. Son dos tipos de soluciones que se encuentran en pleno auge como negocio y, desde luego, en lo mediático. Dos tipos de soluciones en que, personalmente, tengo mucho interés en la doble vertiente tecnológica y de utilidad para los negocios. Aunque todavía hay mucha información que quiero recopilar, asimilar y, sobre todo, estructurar, me ha apetecido hoy hablar de forma un poco genérica de la foto general y, muy en concreto, del auge y riesgo de los robots software.

Son pensamientos un poco improvisados, tal vez precipitados incluso, por lo que pueden ser sometidos a revisión y ampliación, pero he querido ir recopilando ya algunas ideas.

Razones para el auge de los robots software

Me pregunto: ¿Por qué ahora? ¿Por qué se encuentran tan de moda los robots software, el RPA y los chatbots en sus diferentes vertientes cuando, especialmente RPA, tienen antecedentes ya lejanos en, por ejemplo, las herramientas de screen scrapping?

Se me ocurren algunas razones.

  • Porque han aparecido productos bien empaquetados. Por ejemplo, el caso de RPA, aunque es cierto que desde un punto de vista tecnológico, muchos de sus elementos constituyentes ya existían hace años, lo cierto que es ahora, hace muy pocos años, cuando se han estructurado en productos completos, de alta calidad, atractivos. Eso democratiza el uso por ejemplo del screen scrapping que pasa a dejar de ser una solución casi oculta y para gurús, a estar al alcance de cualquiera. Y algo parecido sucede con los chatbots y con la aparición de herramientas tan sencillas como Dialogflow o Chatfuel.

  • Porque esos productos incluyen en su mayoría la filosofía del low-code, es decir de un tipo de desarrollo de software con pesudolenguajes de muy alto nivel, basados en general en atractivas y sencillas herramientas gráficas que apenas exigen conocimientos informáticos, al menos para el desarrollo de robots sencillos

  • Muy importante es también la intencionada caída de barreras de entrada para este tipo de aplicaciones. Por un lado caen las barreras de entrada económicas ya que algunas soluciones (por ejemplo, UiPath en RPA y lo smismo sucede con muchas herramientas de desarrollo de chatbots) incluyen versiones gratuitas de sus productos con muy buenas funcionalidades y el acceso a una formación también gratuita. Pero también una eliminación en las barreras de entrada del conocimiento y expertise, tanto por la facilidad de desarrollo (low-code) como por el fácil acceso a formación.

  • Mención especial requiere el desarrollo de la Inteligencia Artificial. Aunque tanto RPA como los chatbots pueden proporcionar soluciones muy interesantes sin usar inteligencia artificial, lo cierto es que los grandes avances de los últimos años en tratamiento de lenguaje natural, reconocimiento de imágenes, reconocimiento de voz, síntesis de voz, etc enriquecen sobremanera las capacidades de los robots. Se ha facilitado también hasta límites insospechados el acceso a librerías e incluso entornos de desarrollo de calidad con complejos algoritmos de inteligencia artificial, tanto porque existe mucho en software abierto como porque los grandes actores de la inteligencia artificial como IBM, Google, Microsoft, etc dan muchas facilidades para incorporar sus API en un afán por posicionarse en este más que atractivo segmento de soluciones.

  • Además, tanto RPA como los chatbots permiten el desarrollo muy rápido de soluciones útiles e incluso brillantes y afectando poco o nada a la base de sistemas instalados. Y eso elimina riesgos y encaja muy bien con esa tendencia a la búsqueda de los resultados a corto y los quick-win, a la innovación rápida e iterativa según inspiración lean startup y a la adopción de filosofías de base 'agile' que buscan resultados, quizá más pequeños, pero mucho más rápìdos e incrementales.

  • Y si, también voy a mencionar el marketing, ese marketing tecnológico que interesa adoptar a fabricantes de software y consultoras, que suelen hinchar las expectativas, mezclar conceptos y rebautizar tecnologías existentes pero que, sin duda, consiguen el efecto de llamada de atención y de contribución a catalizar mercados. Un marketing que, no de forma exclusiva, pero que sí ha prestado mucha atención a los robots de software especialmente en lo que a su vertiente de inteligencia artificial se refiere.

Puede que haya otras razones. Tal vez si lo pienso más o más despacio, se me ocurran otras o matice algo éstas, pero creo que el ramillete de razones expuestas ya explican bastante del auge de los robots software

Riesgos asociados a los robots software


Pero si. también veo riesgos y no me voy a referir al ya casi convertido en lugar común debate sobre si la automatización creará o destruirá empleo. No. Me voy a fijar en otros aspectos:

  • En primer lugar, me voy a referir al exceso de expectativas. En este caso, el marketing como factor negativo. Mucha de la literatura sobre los robots software, de la literatura superficial en medios digitales y blogs, pero también en la comunicación en eventos profesionales, está tan sobrecargada de promesas infundadas, de triunfalismos poco realistas y de conceptos tan y tan confusos cuando no erróneos, que puede conseguir un efecto boomerang en que la expectativas se conviertan en decepción y volvamos a un nuevo invierno de la inteligencia artificial que arrastre consigo al mundo de los robots software.

  • Se puede caer en el error también de olvidar que, en el fondo, los robots software, tanto RPA como chatbots son soluciones enfocadas, en cierto modo de nicho. Es decir, automatizan tareas concretas en casos concretos y donde tiene sentido, pero no se pueden considerar  soluciones generalistas de automatización extremo a extremo de procesos de negocio. Sin embargo, no estoy nada seguro de que todo el mundo tenga esto claro, ni siquiera entre profesionales de la tecnología. Y ese malentendido puede conducir a un empleo en situaciones inadecuadas, y por lo tanto con una estrategia avocada al fracaso, de este tipo de soluciones, muy especialmente RPA. De nuevo, el marketing triunfalista no ayuda a clarificar esta cuestión.

  • Dado que el mercado de los robots software es muy goloso, parece lógica la tentación de que las grandes empresas del mundo del software, digamos Oracle, SAP o Microsoft, quieran introducirse en el mundo de los robots software para lo cual, una opción posible es la compra de las empresas líderes (por ejemplo UiPath, Automation Anywhere o Blue Prism). Eso es una dinámica de mercado y en principio no se puede decir que sea intrínsecamente buena ni mala pero sí podría llevar a tres afectos adversos. Uno de ellos sería eliminar competencia y sobre todo la innovación rápida y constante que está caracterizando a las empresas que abanderan el desarrollo especialmente en RPA. Otro sería de naturaleza técnica: si una gran empresa adquiere una solución de otro fabricante de RPA o Chatbots es muy fácil que la quiera integrar en sus grandes 'suites'. Como en su diseño y arquitectura no fueron concebidos para integrarse directamente, es probable que la solución de fusión de herramientas lleve a una especie de Frankenstein tanto técnico como funcional y con resultados no óptimos.

  • Existe una posibilidad, que apunto más que como un factor de atención que como un riesgo explícito, hacia la convergencia y difuminación de fronteras entre soluciones de BPMS, RPA y de chatbots. Los BPMS, añadiendo screen scrapping y quizá algo de inteligencia artificial, pueden perfectamente absorber RPA. De la misma forma, un RPA que trabaje algo mas la visión y diseño de proceso extremo a extremo, que permita el diseño de formularios de entrada y salida, incremente sus posibilidades de integración vía servicios  y que mejore en el seguimiento (BAM) de los procesos y la analítica, puede convertirse en un BPMS. Y ambos, BPMS y RPA pueden integrar sin muchas dificultades, interfaces conversacionales como un tipo particular de actividades del proceso. Sin embargo, y aunque BPMS y RPA compartan muchas funcionalidades, sus filosofías son diferentes, por lo que una eventual fusión de conceptos debería entender bien cuándo se trabaja en modo BPMS y cuándo en modo RPA, aunque sea en la misma herramienta.De nuevo, esta convergencia no tiene por qué ser necesariamente mala... pero si se hace correctamente.

  • Se puede poner en riesgo las automatizaciones y mejoras estructurales. Es decir, dado que RPA y chatbots pueden dar soluciones de corto plazo y muy efectivas y brillantes, se puede olvidar que en ciertos casos, la problemática de un proceso de negocio mal diseñado, o ineficiente, o con una defectuosa digitalización, seguramente no se solucione mediante una solución táctica con RPA y en algún momento haya que plantearse evolucionar el ERP, la arquitectura de servicios, el BPMS o, en fin, los elementos más estructurales de una digitalización de procesos extremo a extremo.

Reflexión final



Y esta es la lista improvisada, y un poco precipitada, de motivaciones para el auge y riesgos relativos a los robots software. Veo que algunos de los puntos son más complejos de explicar y desarrollar de lo que inicialmente pensaba y que quizá precisarían una explicación más profunda. Además, por supuesto, es posible que existan otros factores no identificados en estas listas o que no todo el mundo esté de acuerdo con mi visión.

Pero espero que sirva como un punto de partida y, especialmente en lo relativo a los riesgos, un toque de atención y una llamada al realismo, la cordura y el análisis sensato.


lunes, 12 de noviembre de 2018

Cinco buenas prácticas para implantar RPA (Robotic Process Automation)


Aunque RPA (Robotic Process Automation) es una disciplina o, más bien, un tipo de soluciones bastante novedosas, ya existe suficiente experiencia como para hablar de buenas prácticas para implantar RPA.Y más teniendo en cuenta que, en general, son buenas prácticas que derivan del sentido común y, sobre todo, de la innegable herencia de dos disciplinas existentes desde hace muchos años, la gestión de procesos de negocio (BPM, Business Process Management) y la Ingeniería de Software. Porque, en el fondo, no lo olvidemos, hacer un robot no deja de ser una forma algo especial de desarrollo software y porque, además, el objeto de esos desarrollos es la automatización de secciones de un proceso de negocio.

Aunque seguro que hay más consejos y buenas prácticas que vale la pena observar, en este post vamos a recoger cinco buenas prácticas que nos propone Vaibhav Jain en su libro 'Crisper Learning for UiPath'. Hay que hacer notar que el libro habla exclusivamente de RPA y, además, un RPA implementado sobre la solución de UiPath. Sin embargo, las propuestas son bastante generalistas y, además, vamos a intentar ponerlas en contexto para que se entienda mejor su sentido y la herencia de que son deudoras.

Práctica 1 - Establece el diseño del workflow antes de construir el robot


Los robots de RPA automatizan, normalmente de forma parcial, un proceso de negocio. Por tanto, esta buena práctica es muy simple: antes de ponerte a automatizar nada (esto es, antes de desarrollar), primero entiende y define bien el proceso que vas a automatizar. Esta es una buena práctica que es aplicable a cualquier automatización de procesos, la hagamos mediante la parametrización de software empresarial como un ERP o un CRM, la hagamos mediante un BPMS (Business Process Management System), la hagamos mediante un desarrollo a medida o la hagamos, en este caso, mediante RPA.

En el caso específico de RPA y UiPath se habla más de flujos o workflows que de procesos y el software que desarrollamos es un robot, de ahí la manera de formularlo: 'diseñar el workflow antes de construir el robot'. Pero la buena práctica aplica tanto a RPA como a cualquier automatización de procesos: antes de automatizar, define y optimiza bien el proceso que vas a automatizar y luego ya empieza con el software..

Práctica 2 - Divide los problemas de negocio complejos en implementaciones lógicas más simples


Esta es una buena práctica de ámbito casi general: descomponer los problemas complejos en otros más simples.

Cuando esto se lleva al ámbito de la ingeniería de software, eso conduce a la subdivisión en módulos y componentes buscando, además de tratar con problemas más simples, la posibilidad de reutilización de los componentes así definidos.

Cuando esto lo trasladamos al ámbito de RPA estamos hablando de disponer de robots que hagan tareas más sencillas y puedan ser invocados por otros. Específicamente en el caso de UiPath, una de las formas de reutilización es definir unos workflows reutilizables que luego pueden ser invocados desde otros.

Práctica 3 - Manejo de excepciones exhaustivo


Esta buena práctica la conocerán muy bien todos aquellos que se hayan enfrentado a un software real puesto en producción real.

Tendemos a definir los procesos de negocio y el software pensando en la situación más limpia, el llamado 'happy path' o 'sunny day' en que todo funciona como tiene que funcionar. Pero la experiencia demuestra que lo inesperado sucede y los errores y situaciones extrañas abundan, Y todo software, sea de automatización de procesos o no, debe estar preparado para reaccionar de una forma razonable y no catastrófica ante cualquier error que aparezca.

Lo que esta buena práctica nos está diciendo es que debemos diseñar el software, en este caso los robots, para que reacciones adecuadamente ante cualquier posible error o situación inesperada.

Cuando hablamos de una RPA basada en UiParh eso quiere decir, fundamentalmente, que tenemos que ser capaz de hacer un adecuado tratamiento de excepciones, es decir, capturar todas las excepciones posibles y prever e implementar un tratamiento adecuado.

Los mecanismos que para ello proporciona una herramienta como UiPath, las excepciones, son conceptualmente muy similares a cómo se tratan las excepciones, por ejemplo, en un lenguaje como Java.

En cualquier caso, la buena práctica nos exhorta a este tratamiento exhaustivo de errores, en este caso en forma de excepciones.

Práctica 4 - Mantener el sistema limpio


Lo que esta buena práctica quiere decir es que seamos frugales en el uso de los recursos computacionales, tanto por un mayor orden en el software como también por no agotar los recursos de la máquina.

Eso, llevado al campo de un software general nos hablaría, por ejemplo, de liberar toda memoria dinámica que ya no vayamos a utilizar, o cerrar todos los ficheros que hayamos abierto si ya hemos acabado su tratamiento.

Trasladado al caso de RPA, la idea es la misma pero se nos habla, más bien, de cerrar todas las ventanas que ya no vayamos a utilizar, todas las aplicaciones con las que ya no vayamos a interactuar o todos los ficheros cuyo tratamiento hemos finalizado.

Práctica 5 - Control de versiones y backup periódico


Esta buena práctica es bastante general para cualquier desarrollo de software. Dado que éste evoluciona, es preciso mantener un buen control de versiones, de manera que éstas sean conocidas, coherentes y se puedan gestionar, incluyendo una eventual marcha atrás si la implantación de una nueva versión nos trae problemas inesperados y graves.

¿Y qué decir del backup? Ésta es una buena práctica tan general, que apenas precisa comentario. Lo que se necesita, en realidad, es su aplicación rigurosa y continua, sea en el campo de RPA o en cualquier otro.


*****


Como se puede ver, aunque existen pequeños matices derivados del hecho de tratar con RPA y la automatización robótica de procesos de negocio, éstas buenas prácticas son mero sentido común y fruto de una experiencia de años en gestión de procesos y desarrollo de software, que antecede a RPA (Robotic Process Automation) y de la que ésta es heredera.


viernes, 9 de noviembre de 2018

Preparando SOA y BPM para el cambio con Marc Fiamante

'Dynamic SOA and BPM' es un libro de carácter netamente técnico, que explora conjuntamente los campos del BPM (Business Process Management) y SOA (Service Oriented Architecture) pero no de una forma general sino, muy expecíficamente, analizando las mejores prácticas para que ambas técnicas/tecnologías sean capaces de adaptarse con agilidad al dinamismo que se produce en la vida y negocios reales.

Se trata. además, de un libro bastante avanzado que da por sentados importantes conocimientos del lector en estos campos y no se detiene mucho en explicaciones previas sino que ataca directamente la temática que se propone. En ese sentido, no resulta un libro demasiado fácil de leer ni de entender salvo para personas expertas o al menos buenas conocedoras de estas materias.

El libro se estructura en ocho capítulos:

  • 'From simplified integration to dynamic processes': Comienza analizando errores comunes en la aplicación de BPM y SOA que limitan su valor. Luego propone una arquitectura empresarial con tres capas paralelas (infraestructura, aplicaciones y negocio) y otra transversal (información) y comenta su 'mapping' a algunos modelos de referencia como eTOM, PCF o SCOR y termina aportando unos principios para conseguir el dinamismo.

  • 'Streamlining the enterprise architecture for dynamic BPM and SOA': Un capítulo complejo en que realiza varios planteamientos a nivel de arquitectura empresarial para prepararla para la variabilidad.

  • 'Implementing dynamic enterprise information': explora técnicas que flexibilizan el tratamiento de información a diferentes niveles de detalle, desde algunos más arquitecturales, a otros en el nivel de diseño e incluso otros muy cercanos ya a la implementación de datos.

  • 'Implementing variable services': enfoca ahora la variabilidad desde el punto de vista de los servicios de negocio SOA, analizando temas como patrones de diseño, los contratos de servicios en WDSL, las arquitecturas de componentes o los servicios REST.

  • 'Implementing dynamic business processes': Se centra ahora en el nivel de procesos de negocio tratando técnicas de un modelado para la variabilidad, aspectos relacionados con reglas de negocio o eventos.

  • 'Implementing the enterprise expansion joint': Habla de los aspectos más relacionados con el nivel de infraestructura como el Enterprise Service Bus y técnicas relacionadas con la mediación entre servicios.

  • 'Tooling for dynamic SOA and BPM processes': Cambia ahora un poco la orientación analizando el tipo y casos concretos de herramientas que se pueden utilizar en las tareas vistas hasta el momento, incluyendo la gestión del ciclo de vida de la arquitectura empresarial y el modelado e implementación de sus diferentes capas como procesos, servicios e información.

  • 'Managing and monitoring a dynamic BPM and SOA environment': Finaliza hablando de aspectos más de gestión, incluyendo la monitorización, la gestión del ciclo de vida de procesos y servicios y la gestión operativa

Un libro, en fin, interesante pero de un nivel avanzado y que precisa de una lectura muy cuidadosa y experta para sacarle todo el beneficio.

Marc Fiamante

(Fuente: Traducción y ligera elaboración propia de la ficha de autor en InformIT)

Marc Fiamante
Marc Fiammante es un Ingeniero Distinguido de IBM, elegido para la IBM Academy of Technology en 2003, con amplia experiencia en la arquitectura de grandes proyectos y en desarrollo de software en múltiples entornos. Es arquitecto jefe del equipo de Enterprise Integration Solutions en Europa, Medio Oeste, África y Asia-Pacífico. Marc tiene más de veinte años de experiencia en TI. Ha registrado varias patentes en el dominio del software y ha publicado varios artículos en relación con tecnología e-business. Dirige equipos de arquitectura en grandes proyectos industriales. Tiene 'expertise' técnico y arquitectural con la arquitectura orientada a servicios, web services, Enterprise Application Integration y tecnologías orientadas a objetos y e-business, incluyendo variedad de sistemas de middleware, lenguajes de programación y estándares.

Marc es titulado por la Ecole Centrale de Paris.

Puedes saber más del autor visitando su perfil en LinkedIn.

Ficha técnica:

AUTOR: Marc Fiamante.
EDITORIAL: IBM Press Books
AÑO: 2009
ISBN: 978-0137018918
PAGINAS: 216

Artículos de este blog relacionados

miércoles, 7 de noviembre de 2018

Una definición de Robotic Process Automation (RPA) y una llamada al realismo


Como por desgracia ocurre con tantas tecnologías novedosas, especialmente cuando incorporan algo que tenga que ver con la inteligencia artificial RPA (Robotic Process Automation) es una tecnología, más bien un tipo de soluciones, sobre los que existe mucha literatura confusa, cuando no directamente exagerada. Puede venirnos bien, pues, disponer de una definición de Robotic Process Automation.

Aunque es quizá excesivamente simplificada, me ha gustado la propuesta que hace Vaibhav Jain en su libro 'Crisper learning for UiPath'. Nos dice:

Robotic Process Automation is the process of imitating the job a normal person would do in front of a computer system.

En esa seudo-definición, he resaltado en negrita dos aspectos que pueden parecer triviales pero que son muy importantes. 

El primero es el hecho de que RPA imita a un ser humano. Es decir, interactua con aplicaciones existentes, usando la pantalla, el teclado, el ratón o tratando por los mismos medios con ficheros ofimáticos, como hojas de cálculo o documentos PDF. 

Y he resaltado que es 'en frente' de un sistema de computación precisamente para hacer más patente que RPA trabaja sobre unos sistemas de información previamente existentes. Eso es muy importante entenderlo porque uno de los valores que creo mayores de RPA es que trabaja con los sistemas corporativos ya en operación, pero sin alterarlos en absoluto ya que hace exactamente lo mismo que haría un operador humano con esas mismas aplicaciones.

Y aquí una nueva llamada de atención. RPA son robots software. Es decir, cuando afirmamos que los robots de RPA interactuan con la pantalla, el teclado o el ratón, no imaginemos a un robot físico (como el que aparece en la imagen de cabecera) tecleando. Los robots de RPA interactuan con los dispositivos del ordenador a nivel de drivers o del sistema operativo. De cara a la aplicación con la que interactua, es exactamente igual que si lo hiciese una persona...pero seguimos hablando de robots software, exclusivamente software, nada de androides.

Una definición parecida a la anterior pero más completa es la que nos ofrece Roland Berger en el documento 'RPA – Tomorrow's must-have technology How robotic process automation can speed up your business'

Robotic process automation (RPA) is a software solution that simulates a "virtual employee". It interacts with existing applications in the same way that a human being would, but faster, more transparently and with greater efficiency

De nuevo, se nos habla de que RPA es un software que imita el comportamiento humano y que interactua con las aplicaciones de la misma forma que éste lo haría.

Y ahora es cuando viene al caso la llamada al realismo. Existe mucha literatura confusa, ya sea con intención o por ignorancia, que mezcla RPA con la inteligencia artificial como si RPA fuese esencialmente una tecnología de inteligencia artificial o un subconjunto de la misma. Y para aquel lector inadvertido, el nombre de este tipo de soluciones, que incluyen el término robótico, unido a la confusa mezcla con la inteligencia artificial, le pueden hacer pensar en un software que piensa como un humando, razona como un humano y decide de forma autónoma como un humano.

No es así. No exactamente así.

Las tareas que fundamentalmente resuelve hoy día RPA sen, precisamente, las menos inteligentes. Las que son masivas, repetitivas y basadas en reglas muy claras. Es decir, las tareas que la mayoría de los humanos consideramos tediosas, rutinarias, burocráticas... 

Sí que es cierto que las soluciones dominantes hoy día de RPA incluyen elementos de inteligencia artificial pero hay qué saber qué. Fundamentalmente las aportaciones basadas en inteligencia artificial se usan en el reconocimiento de imágenes, en un OCR (reconocimiento óptico de caracteres) avanzado,  y en el tratamiento del lenguaje natural. Pero todo ello, fundamentalmente para ser capaces de extraer la información de la imagen de una pantalla (especialmente en entornos virtualizados con herramientas de tipo Citrix) o para extraer información de documentos en texto libre, no estructurado. No se trata, pues, de usar una inteligencia avanzada para razonamiento creativo o toma de decisiones complejas, sino para interpretar correctamente una información desestructurada presente en pantallas y documentos. Nada más... y nada menos.

Es cierto también que se trabaja, y mucho, para incorporar más elementos de inteligencia artificial. Es cierto que la arquitectura de estas herramientas permite ya incluir scripts desarrollados por ejemplo en Python que muy bien pudieran hacer uso avanzado de machine learning, por ejemplo.

Tal vez estén a la vuelta de la esquina avances que incorporen a RPA unas capacidades cognitivas más avanzadas.Parece que así va a ser... y es muy estimulante el avance en esa dirección.

Pero, mientras eso llegue, aplica una llamada al realismo. De momento, RPA sigue aportando su valor principal en la automatización de tareas repetitivas, basadas en reglas y apoyándose siempre en sistemas existentes. Y aunque así formulado puede parecer menos 'bonito', lo cierto es que el valor que aporta a las organizaciones es muy, muy grande.

RPA tiene muchísimo valor que aportar a las empresas que lo empleen con criterio y realismo. Y es una pena que las fantasías en la formulación de lo que es RPA, pueda confundir y ahuyentar a posibles usuarios que se podrían haber beneficiado, y mucho, de ella, o en el otro extremo que se llegue a una desilusión, como se formula en la famosa curva de Gartner, por unas expectativas infladas que luego no se alcanzan.

RPA tiene mucho, muchísimo que ofrecer, y no necesita de fantasías para ello sino, todo lo contrario, necesita más bien una llamada al realismo.  

lunes, 5 de noviembre de 2018

La robotización como llamada a la inteligencia


Valoro mucho el conocimiento y admiro la inteligencia. 

El primero, el conocimiento, depende muchísimo de nosotros mismos, del esfuerzo que hayamos puesto cuando fuimos estudiantes en asimilar datos y adquirir habilidades. Y, mucho más importante aún, del empeño y dedicación que hayamos puesto en seguirnos formando cuando ya no somos esos estudiantes. O, si se prefiere, mejor aún, el empeño en no dejar de ser nunca un estudiante.

La inteligencia, sin entrar en teorías profundas, creo que tiene una parte innata y otra que se desarrolla pero, en cualquier caso, al menos parcialmente, sigue estando en nuestra mano el potenciarla.

Son virtudes, conocimiento e inteligencia, que creo nos potencian como personas y ciudadanos, que proporcionan íntimas satisfacciones al tiempo que nos preparan para afrontar retos y problemáticas de toda índole.

Y por eso vale la pena dedicarles esfuerzo.

En el ámbito específicamente laboral, y a pesar del indudable peso que tienen otros factores como el liderazgo, la capacidad de relación, la empatía y otras cualidades 'soft', no se puede negar la utilidad que el conocimiento y la inteligencia nos prestan para hacernos valiosos y para progresar.

Mucho se está hablando, normalmente, creo, de forma superficial y tópica, del impacto que la robotización y la inteligencia artificial tendrán en el empleo. Soy de los que tiende al optimismo, porque, aunque con disfunciones puntuales y también, preciso es reconocerlo, con algunos colectivos perjudicados, la tecnología siempre ha impulsado hacia adelante a la humanidad no sólo en lo meramente técnico sino también en el bienestar material y social.

Pero eso no obsta para que en la definición y aplicación de los nuevos puestos de trabajo vayamos a ver, estamos viendo ya, un indudable impacto de lo tecnológico. Y para salir 'bien librados' en este nuevo entorno tenemos dos armas conocidas: el conocimiento y la inteligencia.

El conocimiento para ser capaces de entender y aplicar las nuevas tecnologías y sacarles el mayor partido. Un conocimiento que no se va a adquirir por un esfuerzo puntual sino que implica aprendizaje continuo.

E inteligencia porque aunque las máquinas se hagan progresivamente más inteligentes, el desarrollo de nuestra propia inteligencia nos hará más valiosos y diferenciales y, además, nos ayudará también a ser capaces de reconocer situaciones y adaptarnos a ellas. 

No esperaba un canto a la inteligencia en un libro técnico pero, precisamente, leyendo 'Crisper learning for UiPath' de Vaibhav Jain, un libro muy orientado a desarrolladores en el ámbito de RPA (Robotic Process Automation) y centrado en una solución específica, UiPath,, me he encontrado en sus primeras líneas con esta afirmación:

With progression of information technology in today's era, the ask from professionals is to work smarter, not just harder.

No estoy seguro, quisiera pensar que si, de si realmente a los profesionales del futuro se les permitirá trabajar menos duro, pero de lo que me cabe poca duda es de que para tener émpleabilidad y éxito, será muy importante trabajar de forma más inteligente.

Y, al menos en lo que a mi respecta, si la llegada de los robots y la inteligencia artificial, supone una exigencia de conocimiento y una llamada a la inteligencia, bienvenida sea...