Una visión irregular del uso de Blue Prism en proyectos RPA

'Blue Prism for RPA projects' es un libro que pretende explicar el uso de la herramienta de RPA Blue Prism para la realización de proyectos de robotización de una manera lo mas clara y práctica posible...un objetivo que sólo cumple parcialmente. Se trata, si, de una introducción a la herramienta Blue Prism y aporta de cuando en cuando consejos prácticos útiles, pero falla un tanto en dar una visión uniforme, completa y orientada a la acción.

El libro se estructura en siete capítulos:

• 'Chapter 1. All about Blue Prism': Se inicia con un breve repaso de la historia de Blue Prism como empresa y luego hace una visión rápida de la arquitectura de Blue Prism para pasar luego a describir rápidamente lo que hacen algunos de sus componentes: interactive client, application server y runtime resources. Luego explica los componentes de Blue Prism (Object Studio, Process Studio, Control Room y Release Manager) y finalmente habla de cómo adquirir licencias Blue Prism.


• 'Chapter 2. Setting up Bots in Environment': Habla de la instalación y configuración. Primero revisa los prerrequisitos y luego revisa la instalación y configuración en las diversas variantes y repasando detalles como el esquema de encriptación o el single sign-on.


• 'Chapter 3. Usage of Process Studio in real time': Comienza revisando las herramientas fundamentales de desarrollo (Process Studio y Object Studio) con principal foco en el primero, pero señalando las diferencias entre ambos. Propone un ejemplo simple del uso de Process Studio y luego dedica mucho espacio al uso de Web Services.


• 'Chapter 4: Blue Prism - Exception Handling': Un capítulo, como el siguiente, un poco de 'nicho' en el sentido de enfocarse en un aspecto muy específico aunque importante: en este caso el tratamiento de excepciones que explica con bastante detalle, tanto en su tipología como en su uso en los robots.


• 'Chapter 5: Work Queues': Otro aspecto muy específico aunque relevante: las colas. Se explica el concepto y uso de los tags, el manejo de los items y su status o la priorización. También se explica el uso de múltiples colas y las relaciones padre/hijo entre las mismas.


• 'Chapter 6: Object Design': Un corto capítulo dedicado al desarrollo de objetos de negocio (business objects) como forma de encapsular el acceso a aplicaciones.


• 'Chapter 7: Browser Automation in Blue Prism': Explica brevemente la interacción con páginas web y el uso de algunas 'stages' específicas.

'Blue Prism for RPA projects' es un libro irregular, que explica muy bien aspectos muy específicos como el uso de web services o, en menor medida, las colas, las excepciones o el diseño de objetos de negocio pero falla un tanto en dar una visión realmente general y práctica. Además, comete algunos errores básicos de edición, especialmente al principio del libro. Unos errores y una irregularidad que le restan valor al conjunto aunque es preciso reconocer que existen partes bien desarrolladas. A falta de literatura de calidad y en abundancia sobre RPA en general y sobre la herramienta Blue Prism en particular, este libro puede ayudar algo, pero no es, en cualquier caso, una guía brillante ni definitiva.

Ficha técnica:

TITULO: Blue Prism for RPA Projects: Learn Blue Prism End to End

AUTOR: Vullam

EDITORIAL: Vullam

AÑO: 2019 

ISBN: N/A
PAGINAS: (no definido - solo eBook)

La nube, la inteligencia artificial y el poder de los grandes

En un post anterior de este blog, cuando hablábamos de los motivos que explican el auge de los chatbots, señalábamos como uno de ellos, los avances en inteligencia artificial.

Pero al mencionar esos avances, el driver no era únicamente el progreso tecnológico o algorítmico per se, que también, sino el que los grandes del sector, Microsoft, Google, Amazon e IBM facilitaban el acceso a estas complejas tecnologías mediante servicios en la nube a precios competitivos, cuando no gratuitos.

Avanzando un poco en la lectura que inspiró ese artículo, a saber, el libro Practical Bot Development' de Szymon Rozga, y entrando en un campo específico de la inteligencia artificial como es el procesamiento de lenguaje natural, el autor señala, precisamente, que gran parte de la funcionalidad que necesitamos para construir un chatbot que procese lenguaje natural, se encuentra disponible en la nube como servicios. Y enumera cinco sistemas que identifica como las mejoras opciones, y que son los siguientes:

• Microsoft con LUIS (Language Understanding Intelligence Service)
• Google con Dialogflow (antiguamente, Api.ai)
• Amazon con Lex
• IBM con Watson Conversation
• Facebook con Wit.ai

No sorprende la lista, pero sí que refuerza claramente la idea de que dos grandes tendencias afectan a las tecnologías de la información actual, especialmente a las más avanzadas como la inteligencia artificial, a saber: la migración hacia la nube y la concentración del poder en unos pocos 'grandes'.

Es verdad que el mismo autor cita que existen otras alternativas, en concreto menciona el producto Amelia de IPsoft (que, por cierto, ha tenido un gran relieve en los últimos días con su concepto de sus 'digital employees') o Nina de Nuance, pero parecen ser un poco soluciones más de nicho y que no creo que alteren la foto general de ese predominio de los grandes y esa migración a la nube.

La migración hacia la nube es un cambio de paradigma muy potente y que, en general, y aunque no sin alguna contrapartida, considero que es positivo y un gran habilitador de una TI más avanzada, más eficiente, más segura y más disponible

La concentración en los grandes, sin embargo, es más arma de doble filo y produce, difícil negarlo, una cierta prevención. Que algo tan importante para el progreso humano como es el mundo digital en general y la inteligencia artificial en particular, se concentre en tan pocas manos, y tan poderosas, hace temer un poco, sea de forma fundamentada o no, por aspectos tan importantes como la privacidad, el peso de los individuos e incluso los estados o la gestión de regulaciones y directrices éticas. 

Sin embargo, creo que ambas tendencias, la nube y la concentración, son imparables ahora mismo, así que habrá que extraer los beneficios que traen consigo (que son muchos) y vigilar y actuar, si llega el caso, sobre los riesgos y peligros.

Las tres tareas comunes del Procesamiento de Lenguaje Natural

El Procesamiento del Lenguaje Natural (NLP, Natural Language Processing) es uno de los campos de procesamiento automático donde más éxitos ha obtenido la Inteligencia Artificial.

En el mundo de los robots software usamos, por ejemplo NLP para el tratamiento de correos electrónicos (un uso común en Automatización Robótica de Procesos) pero se usa en abundancia en los bots conversacionales, tanto para procesar el texto de un chat como la comunicación basada en voz.

Un campo, pues, interesantísimo y de amplia aplicación en robotización.

No vamos a entrar en detalles en este artículo sobre las interioridades del procesamiento de lenguaje natural, pero sí quería recoger las tres tareas comunes del Procesamiento de Lenguaje Natural, y más específicamente, del Entendimiento del Lenguaje Natural (NLU, Natural Language Understanding) que a alto nivel identifica Szymon Rozga en su libro 'Practical Bot Development'

Son éstas:

• Análisis sintáctico: que, básicamente, consiste en tomar un texto de entrada y descomponerlo en las partes que lo integran. Una caso sería, en el caso de la voz, segmentar el sonido de entrada en los denominados morfemas y construir estructuras que representen lo hablado en una cierta gramática. Otra tarea es el etiquetado de las palabras clasificándolas como sustantivos, adjetivos, verbos...


• Análisis semántico: En este caso se trata de buscar significado a la entrada en lenguaje natural. Entre las aplicaciones que el autor identifica para el caso de los chatbots tenemos:
  
  
  • Extracción de entidades como por ejemplo, extraer los sustantivos y saber si representan localizaciones, personas, etc
  
  
  • Análisis de sentimiento identificando, por ejemplo, si lo que se expresa tiene una valoración general positiva, negativa o neutra.
  
  
  • Segmentación de temas es decir, para un texto de entrada, segmentarlo por los temas de que trata e identificar esos temas.
  
  
  • Extracción de relaciones, es decir, identificar las relaciones entre los objetos que aparecen en el texto.


• Análisis del discurso: proceso por el que se miran a unas estructuras linguísticas de mayor tamaño, obtener sentido de ello como una unidad y, por ejemplo, ser capaz de hacer algún tipo de resumen.

La verdad es que el campo del procesamiento de lenguaje natural, como tantas otras partes de la inteligencia artificial, es fascinante y casi parece milagroso que se puedan obtener los resultados de que disponemos hoy día. 

No abandonamos del todo el tema del procesamiento de lenguaje natural y hablaremos próximamente todavía un poco más de tratamiento de lenguaje en el contexto de los chatbots.

Bases de datos relacionales y NoSQL con Andreas Meier y Michael Kaufmann

'SQL & NoSQL databases' subtitulado 'Models, Languages, Consistency Options and Architectures for Big Data Management' es un tratado ordenado, científico y formalista del campo de las bases de datos, tanto relacionales como no relacionales, aunque quizá con un poco más de foco y profundidad en las primeras. Un tratado muy atento a los fundamentos, las reglas y el rigor.



El libro se estructura en 7 capítulos:

• '1. Data Management': Un capítulo introductorio repleto de definiciones donde introduce el concepto de base de datos, las claves de identificación, el modelo relacional, SQL y algunas ideas de Big Data y bases de datos NoSQL. También dedica un espacio a explicar la disciplina del Data Management que es lo que presta título al capítulo.


• '2. Data Modeling': Tras una introducción al tema del modelado explica con bastante profundidad el modelo entidad-relación detallando, por ejemplo, los tipos de asociaciones, las formas normales y las reglas de mapeo a un schema. Luego aborda las bases de datos gráficas, explicando primero el modelo de grafos para luego entrar en las reglas de mapeo de este caso. Finaliza hablando de la arquitectura de datos a nivel de empresa y sugiriendo unos pasos o fases para llevar a cabo el diseño de una base de datos.


• '3. Database languages': Comienza por explicar el álgebra relacional con sus operadores relacionales y de conjuntos, explica de una forma no muy larga pero a pesar de ello bastante competa, el lenguaje SQL. También menciona el lenguje QBE (Query By Example) y los lenguahes de grafos, especialmente Cypher. Sigue con los lenguajes embebidos y el concepto de procedimientos almacenados así como JDBC. Y finaliza con una serie de aspectos a tener en cuenta como el manejo de variables NULL, las restricciones de integridad o aspectos de protección de datos.


• '4. Ensuring Data Consistency': Comienza explicando la situación del acceso de múltiples usuarios a una base de datos y aborda la definición de transacciones y las propiedades ACID. Luego trata el problema de la consistencia en bases de datos distribuidas y habla de los teoremas CAP y BASE y hace una comparativa entre el enfoque ACID propio de las bases de datos relacionales y el BASE, más usado en NoSQL y Big Data.


• '5. System Architecture': Comienza hablando del manejo de datos no estructuradosy de conceptos de almacenaje y acceso incluyendo una explicación de los mecanismos de hashing o de estructuras de datos multidimensionales. Luego aborda con cierto detalle la optimización de bases de datos relacionales. A continuación explica los algoritmos Map Reduce y finaliza con un modelo en capas para bases de datos relacionales y una visión holística de uso coordinado de diferentes bases de datos


• '6. Postrelational Databases': Es un repaso rápido pero interesante de diferentes tipos o conceptos de bases de datos no relacionales incluyendo bases de datos federadas, bases de datos temporales, bases de datos multidimensionales, data warehouse, bases de datos orientadas a objetos, bases de datos de conocimiento y bases de datos difusas (fuzzy).


• '7. NOSQL Databases': Primero hace una breve introducción con la historia y motivaciones de las bases de datos NoSQL para luego repasar diferentes alternativas como los repositorios atributo-valor, las bases de datos columnares, los almacenes de documentos, las bases de datos XML y las bases de datos gráficas.

Todos los capítulos finalizan con una lista comentada de sugerencias y referencias bibliográficas.

'SQL & NoSQL databases' es un tratado austero pero muy riguroso del campo de las bases de datos, amplio en cuanto a las tipologías que contempla (con mucho más detalle, eso sí, sobre el modelo relacional y el gráfico) y muy atento al rigor, a las reglas y álgebra muy claramente explicadas y aplicadas. Un libro serio, completo y útil.

Andreas Meier

(Fuente: Traducción y ligera elaboración propia de su ficha de autor en Springer)

Andreas Meier

Andreas Meier fue miembro de la Facultad de Economía y Ciencias Sociales de Friburgo donde fue profesor de Tecnologías de la Información. Se especializa en empresa electrónica, gobierno electrónico y gestión de la información. Es miembro de la GI (Gesellschaft für Informatik), de IEEE Computer Society y de ACM.

Tras estudiar música en Viena, se licenció con un grado en matemáticas en el Federal Institute of Technology (ETH) en Zurich, realizó su doctorado y fue aceptado como profesor universitario en el Institute of Computer Science.

Fue ingeniero de sistemas en el laboratorio de investigacion de IBM en San José, California, director de un banco internacional y miembro del comité ejecutivo de una compañía aseguradora.

Puedes saber más del autor visitando su ficha de profesor en la Universidad de Friburgo.

Michael Kaufmann

(Fuente: Traducción y ligera elaboración propia de su ficha de autor en Springer)

Michael Kaufmann

Michael Kaufmann es profesor de Ciencia de Datos y Big Data en la School of Information Technology de la Lucerne University of Applied Sciences and Arts. Es también el coordinador en la universidad del equipo de investigación en Inteligencia de Datos en que estudia y desarrolla métodos y tecnologías para la gestión inteligente de datos.

Michael Kaufmann estudió ciencia de los computadores, leyes y psicología en la universidad de Friburgo. Con estudios doctorales, recibió su doctorado en ciencia de los computadores sobre clasificación borrosa inductiva en analítica de marketing.

Trabajó en PostFinance como superusuario de desarrollo corporativo en un datawarehouse, como arquitecto de datos en la unidad de arquitectura en Mobiliar Insurance y como analista de negocio en FIVE Informatik AG, donde lanzó y dirigió un proyecto de investigación y comenzó a impartir clases como profesor a tiempo parcial en Kalaidos University of Applied Science.

Desde 2014 ha estado trabajando en Lucerne University of Applied Sciences and Art en la enseñanza e investigación como profesor de bases de datos, donde ha fundado y conseguido financiar el equipo de investigación de inteligencia de datos.

Puedes saber más sobre él visitando su perfil en LinkedIn.

Ficha técnica:

TITULO: SQL & NoSQL Databases: Models, Languages, Consistency Options and Architectures for Big Data Management

AUTOR: Andreas Meier y Michael Kaufmann

EDITORIAL: Springer

AÑO: 2019 

ISBN: 978-3658245481
PAGINAS: 248

Artículos de este blog relacionados

• Una visión holística del uso combinado de bases de datos relacionales y NoSQL

Tres motivos que explican el auge de los chatbots

Es indudable el auge creciente de las tecnologías de automatización y el interés de las empresas por su adopción. Una de las formas de automatización son los robots software, principalmente la Automatización Robótica de Procesos (RPA) por un lado, y los robots conversacionales o chatbots por otro.

Hace ya más de un año reflexionaba sobre las motivaciones (y también los riesgos) del auge de los robots software. En aquella ocasión se trataba, simplemente, de mis impresiones un poco a bote pronto. Leyendo ahora el libro 'Practical Bot Development' de Szymon Rozga, me encuentro con una argumentación que hace el autor acerca de por qué ahora, por qué está cambiando la forma en que nos relacionamos con la tecnologúa y, específicamente, el porqué del auge de los chatbots.

Y este autor identifica tres motivaciones:

1. Avances en Inteligencia Artificial

Unos avances que se sitúan, por un lado, en los éxitos propiamente dichos a nivel científico, con mejores algoritmos y mejores entrenamientos que han permitido avances en materias como la detección de emociones o el entendimiento del lenguaje natural. 

Pero quizá, tan importante o más que los avances técnicos y algorítmicos es que las grandes empresas del software y de la inteligencia artificial, Microsoft, Google, Amazon e IBM entre otros, ha colocado sus soluciones cognitivas como servicios bajo demanda en la nube a un coste más que razonable cuando no gratuito. Así, por ejemplo, se nos dice que Microsoft ofrece más de 30 APIs del ámbito cognitivo. 

Con esto, una tecnología muy avanzada y sofisticada queda al alcance casi de cualquiera a un coste razonable y con bastante facilidad de uso.

2. Apps de mensajería como plataformas para la conversación

Uno de los canales más comunes para los chatbots son las aplicaciones de mensajería: Facebook Messenger, Whatsapp, Slack, etc. De hecho, parece que ya desde 2015 este tipo de aplicaciones se emplean más que las redes sociales. 

Dado que los chatbots 'viven' habitualmente en este tipo de aplicaciones, su popularidad arrastra consigo también la de los chatbots.

3. Asistentes inteligentes activados por voz

Iniciado con Siri en 2011, la existencia y difusión de los asistentes de voz, Cortana (lanzado en 2014), Amazon Echo (lanzado el mismo año y seguido luego por Alexa) o Google Assistant y Google Home, han promovido, por un lado, el conocimiento y uso por parte del gran público y, por otra, la competencia entre los grandes fabricantes de software, llevando consigo a las mejoras de sus productos y tecnologías.

*****

Tres buenas razones que creo que explican, en efecto, el auge de los chatbots. 

A ellas cabe añadir, el hecho de que sean realmente útiles para las personas y rentables para las empresas. 

Y quizá convenga también destacar que las razones primera y tercera influyen no sólo en el auge de los chatbots sino, en general, en la adopción y popularización de la inteligencia artificial y la automatización cognitiva.

Dos definiciones de chatbot

Me encuentro leyendo el libro  'Practical Bot Development' de Szymon Rozga, un libro dedicado al mundo de los chatbots, especialmente en el entorno de Microsoft Bot Framework / Azure Bot Service, pero que también pone unas buenas bases conceptuales incluyendo, por ejemplo, fundamentos de Machine Learning y de Procesamiento de Lenguaje Natural. Un libro del que, en su momento, haré una reseña en este blog pero que, de momento, me está gustando mucho.

Bastante al principio del libro y, como es natural, el autor propone una definición de chat bot, más que nada para centrar cuál es el tema del libro. En próximos artículos, comentaré algún tema interesante adicional en relación con los contenidos de este libro, pero de momento consigno aquí la definición práctica que propone:

chat bot [] is a computer program that can take user input in natural language and return text or rich media to the user.

Una definición bastante simple y, al tiempo, bastante acertada aunque debo mencionar que, en mi opinión, se autolimita un poco en esta definición en dos aspectos:

• Por un lado, porque supone que en la entrada se va a encontrar lenguaje natural. Es cierto que con muchísima frecuencia es así y que, además, es probablemente la forma de entrada más característica y útil en un chatbot, pero creo que también se puede considerar como chatbot un robot software que mantiene conversaciones usando algunos elementos más convencionales como opciones de menú, imágenes, etc. No me parece una limitación grave, no es demasiado importante en la práctica, pero no quería dejar de reseñarla.


• Más limitante, quizá, es entender que la salida, lo que se ofrece al usuario, sea 'rich media'. En realidad, quizá, conviene aclarar qué se entiende exactamente por 'rich media'. A mi ese término me parece que excluye la voz sintetizada y me parece que se queda más en texto, imágenes, etc. Si es así, es una limitación porque, desde ya y cada vez más, los chatbots nos  'hablan de viva voz'.

Por establecer un punto de comparación, recojo la definición que ofrezco en mi libro "La Carrera Digital" del término interfaz conversacional, término que, aunque más rebuscado, pero también más descriptivo, considero equivalente a chatbot, . Reza así:

Un robot conversacional es un módulo software cuya misión es interaccionar con personas de forma abierta y natural mediante conversaciones.

En mi definición, pongo más foco en el establecimiento de conversaciones naturales, que en el canal o medios usados para ello. Creo que, con ello, consigo una definición más generalista y que, al tiempo, capta mejor la naturaleza de lo que es un chatbot (una interfaz conversacional).

Sin embargo, y a efectos prácticos, la propuesta de Szymon Rozga, me parece razonablemente atinada y que, en el fondo, ambas definiciones son muy convergentes a efectos prácticos.

Una guía al conocimiento en la disciplina de BPM

El BPM CBOK (Business Process Management Common Body Of Knowledge) es la publicación principal de la ABMPP (Association of Business Process Management Professionals) en la que intenta, si no estandarizar, si al menos recoger y estructurar todo el conocimiento y mejores prácticas existentes en el ámbito de la Gestión de Procesos de Negocio y usarlo como texto base para preparar las certificaciones que otorga esta asociación. Sigue en ese sentido, la práctica adoptada en el campo de la dirección de proyectos por el Project Management Institute con su PMBOK o en el ámbito del Business Analisys, el International Institute of Business Analysis con su BABOK. Se trata, pues, de un texto bastante extenso y aséptico.

En este caso nos encontramos ante la versión 4 del libro, lanzado a finales de 2019, una versión que aporta nuevos contenidos especialmente en el ámbito más ligado a la estrategia y en lo relativo a tecnología y transormación digital.

El contenido se estructura en 10 capítulos y una serie de apéndices:

• '1. The BPM Profesional Career Path Architecture:' explica las áreas de conocimiento recogidas en el CBOK, el modelo de competencias que propone la ABMPP y las certificaciones profesionales ofrecidas (CBPA, CBPP y CBPL)


• '2. Introduction:' un capítulo muy cortito que explica el propósito y motivaciones del CBOK,


• '3. Business Process Management:' presenta la disciplina del BPM en su conjunto. Da una definición de esta disciplina y propone un ciclo de vida que luego guía el resto del documento. Además, analiza los tipos de procesos y actividades que nos podemos encontrar, los roles usados en las actividades de BPM y las relaciones de la gestión de procesos con la estrategia y la transformación empresarial..


• '4. Business Process Modeling:' Un capítulo largo y nuclear en que habla del modelado de procesos. Empieza explicando lo que son los modelos de procesos y extendiéndose sobre los repositorios y herramientas para gestionar modelos. Luego explica la importancia del modelado y repasa algunas de las notaciones más populares como BPMN, diagramas de flujo, EPC, UML, IDEF0 o Value Stream Mapping. Comenta la estructuración de los modelos en niveles, técnicas para la captura de la información del proceso, los modelos de referencia y la simulación y validación de modelos.


• '5. Process Analysis:' Otro capítulo clave. Comienza explicando en qué consiste el análisis y cómo y cuando realizarlo. Y luego desarrolla la forma de llevarlo a cabo en distintos planos como son el entorno de negocio, los sistemas de información, el proceso propiamente dicho y las interacciones entre personas.


• '6. Process Design:' Comienza definiendo en qué consiste el diseño de procesos y esbozando la forma de hacerlo. Aporta luego una serie de principios de diseño de procesos para luego ir desgranando aspectos específicos como las reglas de negocio, la simulación, el 'compliance' etc.


• '7. Process Performance Measurement:' Un capítulo corto en que se habla del seguimiento y monitorización de procesos. Comienza con definiciones sobre medidas, métricas e indicadores y luego comenta algunas definiciones y métricas. Finaliza con el alineamineto de los procesos con el desempeño conjunto de la empresa.


• '8. Technology and Transformation:' Un largo y novedoso capítulo dedicado a la transformación digital y la tecnología. Comienza en un plano más estratégico hablando de transformación empresarial y de un enfoque de arquitectuira de negocio y luego hace un recorrido por las principales tecnologías con paradas en las tecnologías empresariales (ERP, CRM, SCM), en los BPMS Inteligentes, RPA, Blockchain, Inteligencia Artificial e Internet de las Cosas.


• '9. Building a Process Oriented Organization and Culture:' Habla de los aspectos más relacionados con las personas y la organización. Así, aborda el tema del liderazgo, del cambo cultural o del cambio organizativo incluyendo los roles implicados y los cuerpos de gobierno. Finaliza hablando del Centro de Excelencia BPM.


• '10. Enterprise Process Management:' Capítulo final en que desarrolla la evaluación de la empresa a alto nivel. Define en qué consiste ese EPM y sus beneficios. Entre otros aspectos se aborda la gestión del porfolio, el repositorio de procesos o la madurez BPM.

Finaliza el libro con una serie de apéndices en que se desarrolla un modelo de competencias, se detalla ampliamente un currículum en BPM (contenidos para un máster en BPM), el código ético de ABMPP y estándares de conducta. FInalmente se aportan referencias bibliográficas.

CBOK es un libro con el estilo habitual de otros BOK, un estilo formalista y austero, orientado a estructurar información de una forma muy seria. Un libro que, aunque extenso, no desarrolla en detalle ninguna de las disciplinas, técnicas o tecnologías que explica porque su propósito es dar una visión común y razonablemente estable. En ese sentido proporciona perspectiva y orden, pero no conocimiento en profundidad.

En el caso de esta versión 4.0 me ha parecido que, en cierto sentido, ha sido lanzada con cierta precipitación. Quiero decir que, en algunos capítulos, muy especialmente el dedicado a tecnología, que es el que más interés tenía personalmente en leer, no se observa una verdadera madurez y estructuración de contenidos como para llevarlo a un CBOK y la ligadura entre la transformación digital y la gestión de procesos creo que no se ha explicado demasiado bien. Tampoco me ha convencido mucho el ciclo de vida que se propone ni cómo se ha enlazado con el contenido del libro.

Un manual, en fin, que creo de obligada lectura para cualquier interesado en la gestión de procesos, que aporta estructura y punteros para ampliar información, pero que creo que necesita un cierto repaso y maduración de contenidos, un repaso, sin embargo, que no es previsible que se produzca antes de dos o tres años, que es el tiempo habitual de lanzamiento de versiones en este tipo de documentos.

Ficha técnica:

TITULO: BPM CBOK Guide Version 4.0

AUTOR: ABPMP (Association of BPM Professionals),

EDITORIAL: ABPMP (Association of BPM Professionals)

AÑO: 2019 

ISBN: 978-1704809342
PAGINAS: 419

Artículos de este blog relacionados

• Dieciséis principios de diseño de procesos de negocio
• Procesos de negocio y Transformación Digital: ¿Qué hay de nuevo en el mundo del BPM?
• Otras tres definiciones de Transformación Digital

Colaboración: "La carrera de la transformación digital: claves para alcanzar el podio" en Think Big / Empresas

Este pasado Lunes 10 de Febrero, se publico en el blog Think Big / Empresas, antiguo A un CLIC de las TIC, el artículo titulado "La carrera de la transformación digital: claves para alcanzar el podio", un artículo firmado por Mercedes Nuñez, quien es autora del texto, pero en donde, como elemento central, se incluye un vídeo en que cuento lo que considero algunas claves de la Transformación Digital, aportando ideas que proceden de mi libro "La Carrera Digital".

El vídeo ha sido grabado y producido de una forma innovadora y atrevida por el equipo de social media de Telefónica y, en concreto, por Manuel Caarballo y Fernando Cabello.

Si quieres ir al artículo original, puedes seguir este enlace.

¡Que lo disfrutes!

Una visión holística del uso combinado de bases de datos relacionales y NoSQL

Durante muchos años el mundo de las bases de datos ha estado dominado por las bases de datos relacionales. Aunque han existido desde siempre otras alternativas, las bases de datos relacionales han sido las reinas del lugar. En el fondo, todavía son, seguramente, las más preponderantes.

Sin embargo, algunos fenómenos de los últimos años, la hiper-abudancia de datos con fuentes como social media o Internet de las cosas, la importancia de los datos no estructurados y la eclosión del Big Data, han hecho que ganen relevancia otras formas de gestionar los datos más aptos para ese tratamiento masivo de datos no estructurados.

Constituyen lo que, de forma resumida, se denominan bases de datos NoSQL, cuya implementación no sigue el esquema de tablas propio de las relacionales y que ofrecen otras formas de consulta en paralelo o alternativo al uso de SQL.

Hay una gran variedad de ellas: repositorios atributo-valor, bases de datos columnares, bases de datos de grafos, bases de datos documentales, etc Las bases de datos NoSQL no son, por tanto, una solución única sino una variedad de opciones más adecuadas o menos según el caso.

He estado leyendo recientemente el libro 'SQL and NoSQL databases: Models, Languages, Consistency Options and Architectures for Big Data Management' de Andreas Meier y Michael Kaufmann, un libro muy ordenado y riguroso.

En el libro desarrollan muy bien la parte más teórica sobre gestión de datos, modelado, lenguajes de consulta, etc.

Sin embargo, lo que quería traer a este post es algo más simple, pero quizá más ilustrativo. Se trata de un ejemplo que proponen bastante avanzado el libro sobre la combinación de varias de estas tecnologías de bases de datos para soportar distintos tipos de informaciones en el caso de una tienda en la web.

El ejemplo se recoge en la figura, tomada del libro:

En ella se puede observar el uso de cinco tecnologías diferentes:

• Bases de datos relacional: el modelo más tradicional para almacenar la información estructurada disponible sobre clientes, cuentas, transacciones, etc


• Almacenes atributo-valor: para el almacenamiento de datos más transitorios como el carrito de la compra o las sesiones y pensando, sobre todo, en la alta disponibilidad.


• Bases de datos documental: para almacenar pedidos, entendiendo que el cuerpo de éstos podrían estar contenido, por ejemplo, en documentos XML o JSON o quizá, incluso, en PDF.


• Bases de datos de grafo: para el tratamiento de información procedente de medios sociales como, por ejemplo, debates en blogs o hilos en twitter. 


• Bases de datos en memoria: para la parte analítica se propone un datawarehouse complementado con herramientas especializadas de data mining o análisis predictivo. Para mejorar las prestaciones en el análisis de esos datos, se propone mantener la información en memoria.

Finalmente, y aunque no se aprecia en la figura, los autores proponen, a modo de ejemplo, y de cara a la integración, el uso de una arquitectura REST. 

La verdad es que parece un esquema un poco de laboratorio o, mejor dicho, de libro o Powerpoint. Es difícil imaginar que en una solución real se mezclen cinco tecnologías de bases de datos por más que, individualmente, cada una pueda ser óptima para una de las labores descritas.

Sin embargo, me gusta por lo ilustrativo y panorámico que resulta, porque ayuda a entender y recordar... y por eso he querido dejarlo consignado en este post.

Mi actividad: Enseñando RPA y BPMN para favorecer el empleo joven

El pasado viernes 7 de Febrero tuvo lugar el cierre del programa sobre RPA que ofrecen conjuntamente Generation Spain (Fundación de McKinsey) y la Escuela de Organización Industrial.

Se trata de un programa muy interesante, de cariz social, financiado por el Fondo Social Europeo, en su Iniciativa de Empleo Juvenil orientado a ayudar a los jóvenes a encontrar empleo mediante la formación. 

Debido a la subvención, a los estudiantes el curso les sale gratis. pero hablo de gratis desde el punto de vista económico, porque sin duda se les pide implicación y mucho esfuerzo. 

Se trata de un programa intensivo de diez semanas, en que los jóvenes asistentes, rigurosamente seleccionados, reciben formación tanto de análisis de procesos, como de tecnología (desarrollo y operación de robots con la herramienta UiPath) y también desarrollo de habilidades personales e interpersonales y orientación para el empleo.

En el acto final, ese que tuvo lugar este Viernes, los alumnos presentan, por equipos, unos trabajos finales consistentes en la aplicación de todas las actividades extremo a extremo (análisis de proceso, diseño, desarrollo y pruebas de robots) para disponer de unos robots funcionales y realistas. Y a esa presentación acuden ya empresas interesadas en el perfil de los alumnos.

Esta es la segunda edición en que participo. Mi aportación en esta ocasión ha sido triple:

• Realizar una introducción inicial a RPA


• Explicar la gestión de procesos de negocio, el levantamiento de procesos y su modelado mediante BPMN


• Tutorizar los proyectos finales en la parte más funcional y de aplicación de la metodología extremo a extremo

Se trata de un programa bastante diferente a los de naturaleza más 'executive' que imparto normalmente. Diferente por la edad y perfil de los alumnos, diferente por su intensidad pero diferente, sobre todo, por ese cariz social, por esa sensación tan vívida de estar ayudando a unas personas a un objetivo vital tan importante como es encontrar un empleo.

Sin duda, una gran experiencia.

Dieciséis principios de diseño de procesos de negocio

Dentro de la disciplina del BPM (Business Process Management), la gestión de procesos de negocio, disponemos de bastante teoría acerca de cómo hacer un levantamiento de un proceso, cómo medirlo, cómo modelarlo e, incluso, cómo automatizarlo.

Sin embargo, el objetivo más importante de BPM no es simplemente conocer los procesos de negocio o documentarlos. Lo más importante realmente es mejorarlos, es decir, hacer un rediseño de esos procesos que nos lleve a conseguir objetivos de negocio entre los que se suelen encontrar la disminución de los tiempos medios, el ahorro de costes, la eliminación de errores, la mejora de la experiencia de cliente, etc

Paradójicamente, escasea la literatura sobre cómo rediseñar un proceso y qué podemos hacer para que éste sea mejor, en el sentido que nos interese, que el proceso actual. Parece como si hubiese un algo de misterio, de arte o de inspiración en ese rediseño.

Es cierto que no es fácil proporcionar una receta universal, porque cada proceso es diferente, cada empresa es diferente y los objetivos del rediseño pueden ser diferentes. Sin embargo, tampoco parece razonable dejarlo todo a la improvisación. Parece que el analista debe acudir a un rediseño armado, aunque sólo sea, de una serie de buenas prácticas o estrategias que habitualmente dan buenos resultados.

Los dieciséis principios de diseño de procesos de ABPMP

En la última versión (la versión 4.0) del BPM CBOK (Business Process Management - Common Body of Knowledge) Guide que edita la ABMPP (Association of BPM Professionals), se nos proponen lo que denominan principios de diseño y que, sin constituirse desde luego en unas recetas definitivas, sí nos aportan algunas ideas sobre cómo podemos rediseñar un proceso.

Se trata de estas dieciséis ideas:

• Diseña de fuera hacia adentro comenzando por las interacciones con clientes: La experiencia de cliente depende de los procesos nucleares que entran en contacto con él. En una visión orientada a cliente es fundamental que en todos los puntos de contacto con el cliente la interacción se encuentre afinada.


• Diseña alrededor de las actividades que aportan valor: Para lo cual, de nuevo, es importante entender qué es lo que valora el cliente y, por tanto, qué actividades del proceso aportan ese valor o son imprescindibles para aportarlo, y cuáles son menos importantes y se podrían, incluso, eliminar.


• Minimiza los traspasos: Los traspasos son los puntos del proceso en que se transfiere la responsabilidad sobre una tarea de una persona a otra o de un grupo a otro. Son puntos propensos al error, a las malas interpretaciones de los datos, a su distorsión y a las esperas. Por todo ello, conviene mantenerlos en el menor número posible.


• Haz que el trabajo se realice donde tiene más sentido: Es evidente: la tarea debe ser realizada por el perfil, rol o equipo que mejor la puede realizar. Es importante recordar que eso puede conducir, durante un rediseño de procesos, a la creación de un nuevo rol opuesto de trabajo.


• Proporciona un punto único de contacto: Un único punto de contacto, por ejemplo, para los clientes, simplifica los procesos y elimina errores. Un punto único de contacto puede ser una persona o rol (jefe de proyecto, consultor), una unidad (un service desk) o, incluso, un repositorio o sistema único.


• Crea un proceso separado para cada cluster: En aquellos procesos en que, partiendo de un inicio común, luego se producen tratamientos especializados según el caso, conviene definir un subproceso para cada uno de esos tratamientos especializados, precedido de un punto en que se realiza la clasificación, algo así como el 'triage' que se lleva a cabo en las urgencias médicas.


• Asegura un flujo continuo: con especial foco en el flujo de valor (value stream) que proporciona el valor al cliente.


• Reduce el tamaño del lote (batch) El trabajo en lotes, especialmente en lotes grandes, tiende a crear inventario, con las ineficiencias que ello conlleva. Es preferible en general reducir el tamaño de los lotes. Idealmente, un lote unitario nos lleva a un flujo continuo y en tiempo real.


• Trae aguas abajo la información que se necesita aguas arriba: se puede hacer haciendo consciente a la persona aguas arriba de las necesidades de los equipos aguas abajo, o bien subiendo aguas arriba a personas que conocen las necesidades.


• Captura la información necesaria una sola vez en su origen y compártela: El objetivo es introducir la información en el proceso/sistema una sola vez, eliminando fuentes de error y las consiguientes tareas de reconciliación de información y, de paso, consiguiendo ser más eficientes al evitar repetir tareas de introducción de datos.


• Involucra al menor número de actores posible Un principio complementario del relativo a la disminución de traspasos. Cuando involucramos a más actores se producen deformaciones en la información y cuellos de botella. Una forma de involucrar a menos actores es aumentar la formación de las personas, de manera que sean capaces de realizar más tareas sin traspasarlas a otros actores.


• Rediseña primero, luego automatiza: El rediseñar antes de automatizar nos permite automatizar el proceso correcto, mejorar aquellas partes del proceso que no dependen exclusivamente de la automatización y, además, nos proporciona mejor perspectiva a la hora de elegir la solución de automatización que más nos conviene.


• Asegura la calidad desde el principio Principio se refiere en este caso a 'aguas arriba'. Lo que este principio quiere decir es que los problemas de calidad aguas arriba del proceso se transmiten y amplían aguas abajo, por lo que es importante asegurar la calidad desde el principio del proceso.


• Estandariza el proceso: Estandarizar el proceso tiene varias ventajas. En primer lugar, es muy difícil rediseñar algo que no ocurre siempre igual. Cuando un proceso no estándar falla, además, es difícil saber si ha fallado el proceso o la persona que lo ejecuta y también es más complicado hallar la causa raíz. Un proceso no estándar, además, es difícilmente automatizable.


• Utiliza equipos co-locados o en red para los temas complejos: en la resolución de problemas complejos, es necesario que las personas interactuen e intercambien información e ideas en formas que no se pueden prever por anticipado. Ese intercambio es más sencillo si todas las personas involucradas trabajan en el mismo espacio físico o, en su defecto, virtual.


• Considera la externalización del proceso: Una opción importante y que en ocasiones se olvida: la externalización. Externalizar un proceso puede permitir delegarlo en organizaciones mejor preparadas y eficientes para llevarlo a cabo y liberar recursos de la propia empresa para otras tareas más valiosas o para las que estamos mejor preparados.

Como se ve, algunas ideas son más generalistas y otras algo más concretas. En cualquier caso, y a falta de una doctrina más definida, son ideas a tener en cuenta y repasar de vez en cuando. Son ideas que añado a la lista de voy confeccionando y que se recoge abajo en las entradas de este blog relacionadas con la mejora de procesos.

Otros artículos relacionados (censo de mejoras en procesos de negocio)

• Recordando las siete formas de desperdicio en procesos
• Diez formas de mejorar un proceso de negocio
• Cuatro principios y ocho buenas prácticas para la gestión de procesos de negocio
• Dónde ahorra Lean Manufacturing... y mucho más
• Cinco oportunidades para mejorar la operación de un negocio
• Ideas para mejorar procesos de negocio
• Las cuatro reglas fundamentales de la productividad y la eficiencia
• Aplicando los principios lean al mundo del software: 7 fuentes de desperdicio a eliminar
• Doce pistas para el rediseño de procesos de negocio
• Seis técnicas para la mejora de procesos de negocio

Procesos de negocio y Transformación Digital: ¿Qué hay de nuevo en el mundo del BPM?

Cuando en el capítulo 4 de mi libro "La Carrera Digital" hablo de las áreas de la empresa donde se puede llevar a cabo la transformación digital, una de esas áreas que identifico son los procesos de negocio y menciono, en concreto, aspectos como el CRM y nuevos modelos de relación con cliente, la automatización en general y la Automatización Robótica de Procesos RPA) o los chatbots en particular.Y así, una serie de ideas adicionales.

Quizá, y como comentaba hace un tiempo en el artículo "La caracola: Transformación Digital y procesos", periódicamente las empresas se olvidan del mundo de los procesos de negocio. A oleadas como las ya pasadas de la calidad total o de la reingeniería de procesos, le suceden otras en que parece que ya los procesos de negocio no son relevantes o no hay nada nuevo que añadir.

Bueno, pues no es cierto, los procesos de negocio, siempre son importantes. 

Más allá de metodologías y formalismos de modelado, los procesos de negocio son el funcionamiento mismo de una compañía: cómo presta sus servicios, cómo se relaciona con el cliente, como gestiona las tareas administrativas, cómo hace la planificación estratégica... es el cómo de toda la organización. Y, por tanto, sea cual sea nuestro foco estratégico, ya sea la excelencia en la relación con cliente, la rapidez, la comodidad, la eficiencia o lo que sea, los procesos de negocio, es decir, nuestro funcionamiento, deben estar alineados con ello.

Así que ya tenemos claro que los procesos de negocio son muy importantes. Vale pero, ¿y hay algo nuevo que decir sobre ellos que no se haya dicho ya?

Pues si, hay mucho nuevo que decir, y gran parte de eso nuevo que hay que decir viene dado por los nuevos avances en tecnología, por la aparición en el mundo de la automatización de nuevas soluciones algunas de las cuales ya he mencionado arriba como son la Automatización Robótica de Procesos (RPA) o los robots conversacionales. No sólo eso, otras nuevas tecnologías, en apariencia menos relacionadas con los procesos, tecnologías como blockchain y muy especialmente lo que tiene que ver con contratos inteligentes y aplicaciones distribuidas, el uso de Internet de las Cosas en soluciones diversas, los cambios en la logística surgidos de la robotización del transporte (drones, vehículos autónomos, robots móviles...), el uso de la inteligencia artificial en soluciones como la visión artificial o incluso en la automatización de decisiones complejas, y así un largo etcétera, traen consigo inmensas posibilidades de rediseño y automatización de procesos.

En la BPM CBOK Guide editada por por la ABPMP (Asociación de Profesionales de Gestión de Procesos de Negocio), en su recientemente lanzada versión 4.0, leo en las secciones preliminares, donde se explica el por qué de una nueva versión de este documento, supuestamente la Biblia de la gestión de procesos de negocio, lo siguiente:

the decision was made to update de BPM CBOK Guide again since BPM, BPMS, and Enterprise Technologies have changed, especially with the introduction of Agile methodologies, low-code and no code technologies  such as robotic process automation (RPA), and newer platforms  like blockchain, artificial intelligence, machine learning and Internet of Things (IoT).

es decir, mucha nueva tecnología, acompañada también, de una cada vez mayor adopción de los modelos agile de dirección de proyectos y de gestión de la innovación.

Es decir, una gran parte de lo que está sucediendo en el mundo de los procesos, que aunque a veces nos olvidemos de ellos, nunca han dejado de ser relevantes, viene de la mano de la tecnología, y de la tecnología digital.

Adquiere pues, pleno sentido, la idea de que los procesos de negocio son, precisamente, una de las áreas de actuación prioritaria en una transformación digital.

No lo olvidemos...y actuemos...

Otras tres definiciones de Transformación Digital

Llevo ya desde hace un tiempo recogiendo en este blog las definiciones de Transformación Digital que me van saliendo al paso, principalmente en la lectura de libros, informes y blogs.

Y recientemente he descubierto tres nuevas definiciones y en una fuente donde no esperaba encontrarlas, a saber, en el BPM CBOK (Business Process Management - Common Body of Knowledge) que edita la ABMPP (Association of BPM Professionals), es decir, en lo que es el resumen de conocimiento en materia de gestión de procesos de negocio.

En realidad las tres definiciones que en ese documento se recogen no son propias sino que provienen de otras fuentes que citan. Veamos cuáles son.

La primera es una definición dada por The Enterprisers Project y dice así:

Digital Transformation is the integration of digital technology into all areas of a business fundamentally changing how you operate and deliver value to customers.

La segunda es obra de George Westerman, del cual hemos reseñado en este blog el libro del cual es co-autor 'Leading digital'. Según Westermann:

Digital Transformation marks a radical rethink of how an organization uses technology, people and processes to fundamentally change business performance.

Finalmente, la última definición la aporta la empresa Salesforce, y dice:

Digital Transformation is the process of using digital technologies to create new - or modify existing - business processes, culture, and customer experiences to meet changing business and market requirements

Las tres definiciones se parecen un tanto y no las veo descaminadas. Las tres hacen referencia a la tecnología digital y de ésta como medio de impactar en el negocio. Y esa es la esencia, en el fondo, de la transformación digital: la dualidad entre la tecnología digital como habilitadora y los objetivos de negocio como resultado buscado.

En tiempos en que con tanta frecuencia se dan definiciones borrosas y bastante desnaturalizadas de lo que es una transformación digital, es bueno ver tres definiciones razonablemente acertadas y que, sobre todo, no hurtan a la tecnología su papel motor de la transformación, al contrario de lo que otras definiciones y autores, por desgracia, hacen.

Y no puedo, claro, dejar de recordar una vez más, mi propia definición de transformación digital que aporto en el capítulo 4 de mi libro "La Carrera Digital" y que dice así:

Transformación digital es un cambio profundo que realiza una organización para adaptarse a los retos y aprovechar las oportunidades que genera la tecnología digital.

Está formulada de otra manera, pero también se observa el papel motor de la tecnología y el uso de ésta para que la organización consiga sus resultados de negocio mediante el aprovechamiento de oportunidades y bloqueo o mitigación de amenazas.

Seguiré buscando y consignando definiciones...

Artículos de este blogs relacionados

• La nueva definición de Transformación Digital de Brian Solís
• Mi definición de Transformación Digital
• La definición de Transformación Digital de Incipy
• ¿Qué nos dicen desde McKinsey que es la Transformación Digital?
• La "casi" definición de Transformación Digital de Raquel Roca
• Tres definiciones de transformación digital y una lista de objetivos
• #macrotweet: una definición de transformación digital