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...


viernes, 2 de noviembre de 2018

Capas de servicios SOA


La filosofía SOA tiene todo que ver con el orden y la estructura, con la articulación inteligente y práctica de los componentes software con que se teje el entramado de los sistemas corporativos. En ese afán por poner orden, también tiene cabida la estructuración de la propia naturaleza de los servicios. Y una forma de poner orden es estructurar en Capas de servicios SOA, el conjunto de esos servicios, conforme a su diferente naturaleza.

En su libro 'Service-Oriented Architecture: Analysis and Design for Services and Microservices' Thomas Erl propone una estructura de cuatro capas de servicios SOA.

Antes de pasar a verlas conviene comentar la clasificación que menciona el autor en cuanto a servicios agnósticos y no agnósticos, basándose la diferenciación en si el servicio tiene 'conocimiento' y dependencia de su contexto y muy en concreto de la tarea en que se enmarca la funcionalidad del servicio, o es ajeno a él. En el segundo caso hablaríamos de servicio agnóstico y tienen como beneficio el hecho de ser más ampliamente reutilizables. Si existe ese 'conocimiento' y dependencia nos encontraríamos ante un servicio no agnóstico.

Según eso, y siguiendo una dirección de abajo a arriba, el autor distingue estas cuatro capas:

Capas propuestas por Thomas Erl antes de la llegada de los microservicios

  • Servicios de tarea: Un servicio no agnóstico y que en general se corresponde con una actividad o tarea de un proceso de negocio.

  • Microservicios: una capa que no se encontraba en el primer planteamiento de Erl (por eso no aparece en la figura superior) y que consiste en un servicio no agnóstico con un alcance funcional reducido. No suelen ser reutilizables de forma general, pero sí dentro de la aplicación en que se enmarcan.

  • Servicios de entidad: Un servicio agnóstico y que se relaciona con una o más entidades de negocio (por ejemplo, Cliente, Factura o Contrato). Tienen un contexto agnóstico. Por ejemplo, un servicio 'Orden de compra' tendría como contexto el procesamiento de cada orden de compra específica.

  • Servicios de utilidad: Un tipo de servicio agnóstico y reutilizable y que ofrece una funcionalidad puntual que no deriva de unas especificaciones de proceso. Suele encapsular funciones técnicas de bajo nivel como, por ejemplo, temas de seguridad o trazado (logs).

Existen otros planteamientos de tipos o capas de servicios no totalmente coincidentes con las propuestas por Erl, aunque sí bastante próximas en sus ideas.

Al final, se trata de poner orden en un conjunto amplio de servicios y diseñar de forma que se respeten algunos de los principios y objetivos de SOA como son la alta cohesión interna y bajo acoplamiento externo de los servicios y la 'reutilizabilidad' de los mismos en el contexto más amplio posible.