Mostrando entradas con la etiqueta BPM. Mostrar todas las entradas
Mostrando entradas con la etiqueta BPM. Mostrar todas las entradas

lunes, 11 de diciembre de 2023

Estrategia, procesos y burocracia: la lucha contra una percepción equivocada

A pesar de que con frecuencia, cuando se habla de transformación digital, o de transformación empresarial en general se suelen mencionar los procesos, lo cierto es que, o al menos esa es mi percepción, habitualmente no se hace con rigor, no se está pensando en una verdadera reingeniería de procesos, o en una mejora continua o alguna forma más o menos sistemática de revisión y mejora de los procesos de negocio. En el fondo creo que con frecuencia no se sabe siguiera muy bien de qué se habla al hablar de procesos.

No solo eso, creo que, en el fondo, existe una cierta incomprensión sobre lo que es la gestión de procesos e, incluso, una sutil pero absolutamente cierta resistencia a trabajar con procesos.

Creo que, desconocimiento aparte, se tiende a ver el levantamiento, análisis y rediseño de procesos como una labor larga y poco productiva, más generadora de reuniones y papeles que de resultados de negocio.

Y en cierto modo como algo, digamos, 'viejuno', apartado de la velocidad digital actual y de los enfoques ágiles.


Procesos y burocracia: una percepción equivocada


Me encuentro leyendo el libro 'The delicate art of bureaucracy' de Mark Schwartz, un libro no específicamente dedicado a a procesos de negocio sino, más bien, a la burocracia, especialmente en relación con la gestión TI, y los enfoques ágiles y DevOps.

En un momento dado, sin embargo, el autor se refiere a la mejora de procesos y nos dice:


Process improvement had led unthinkingly to bureaucracy. This is common. The cycle of formalizing, optimizing, documenting, and then applying a process uniformly is the essence of bureaucratic art.


Para ser justos con el autor, para entender bien la frase y antes de comentarla, conviene señalar que, aunque el autor es muy crítico con formas de burocracia que se ha encontrado en su práctica profesional especialmente en el sector público, no descalifica a la burocracia como tal. De hecho, y puede que lo refleje en este blog en otro post, identifica aspectos tanto negativos como positivos en la burocracia, y ve los enfoques ágiles y DevOps, por los que sin duda apuesta, como otras formas de burocracia.

No obstante lo anterior, la lectura de la frase nos hace pensar en la mejora de procesos, y estoy seguro que refleja un estado de pensamiento común, como algo burocrático y, por tanto, como algo que asociamos a tareas incómodas, farragosas y con poco o nada de valor añadido.

No es esa la visión que el autor tiene realmente de la burocracia, pero creo que sí la percepción común en el mundo empresarial unida esa asociación de procesos con burocracia, a una burocracia, además, de 'la mala', de la que encorseta y molesta.


Razones para una percepción equivocada de los procesos


No niego que en ocasiones, puede que más de las deseables, una iniciativa de análisis y mejora de procesos pueda dar como resultado final unos procesos de negocio encorsetados, inflexibles, poco realistas, sobre-controlados, asfixiantes, burocráticos en el peor de los sentidos.

No niego que, con frecuencia, el discurso de la gestión por procesos tienda a ser aburrido, poco atractivo y, en apariencia (solo en apariencia recalco) desconectado de las necesidades del acelerado mundo actual. De hecho, creo que habría que revisar en profundidad ese discurso general, precisamente para hacerlo más ligero, más moderno, más atractivo.

No niego que los propios trabajos de identificación, descubrimiento, modelado y análisis de procesos, a veces se cubran de una capa metodológica que se pueda percibir como excesiva y aburrida.

Todo ellos son razones que parecen confirmar esa identificación de la gestión de procesos como algo burocrático.

Y sin embargo...


Luchando contra la percepción equivocada


Y sin embargo, esa percepción es injusta y es equivocada.

Asociar la gestión de procesos de negocio con burocracia es un error.

Seguramente se puedan aportar más argumentos, pero me voy a centrar en dos.

En primer lugar, simplemente, quiero destacar algo que creo que ya he mencionado en este blog a propósito de algún otro tema diferente: 


No se debe identificar una disciplina con las malas prácticas a ella asociada.


Es un vicio muy común, especialmente cuando se quiere presentar en sociedad una nueva tecnología o una nueva metodología, descalificar a la que la tecnología o metodología precedente, asociando esa metodología o esa tecnología con malas prácticas en su aplicación, probablemente unas malas prácticas y unos fracasos reales, pero solo eso, malas prácticas, que no afectan a la esencia de la metodología. Es algo que me encuentro, por ejemplo, de forma recurrente cuando, en materia de dirección de proyectos, se vende de forma poco rigurosa el enfoque ágil frente al predictivo.

En ese sentido, que históricamente se hayan realizado iniciativas de mejora de procesos que hayan tenido como resultado unas procesos burocráticos e ineficientes, no es esencial en la práctica de la gestión de procesos, sino sólo una mala aplicación de la disciplina, una mala aplicación sobre la que debemos estar prevenidos, por supuesto, pero que no la caracteriza y, sobre todo, no la descalifica.

El otro argumento tiene que ver con la cierta identificación de la mejora de procesos únicamente con el control y la búsqueda ciega de la eficiencia. Y no es así.

En la mejora de un proceso se pueden buscar muchas cosas. Es muy común, es cierto, y además es bueno, la búsqueda de la eficiencia. Pero también se puede buscar la rapidez, o la comodidad, o la mejora de la experiencia de cliente. Esa diversidad de objetivos, en ocasiones contradictorios y sometidos a decisión, se ha expresado ya hace años, por ejemplo, en el denominado 'cuadrilátero del diablo' que, en el fondo, lo que nos hace ver es que en una iniciativa de mejora de procesos, existen objetivos con frecuencia contrapuestos y tenemos que reflexionar sobre qué objetivos realmente buscamos para elegir, o al menos priorizar, las acciones.

Mensaje: en una mejora de procesos no siempre buscamos los mismos objetivos.

Si pensamos que la mejora de un proceso sólo busca el control, tenderemos a identificarla con burocracia.

Pero si pensamos que la mejora de un proceso lo que busca es la agilidad y la experiencia de cliente, seguramente pensamos de forma distinta.

Y esa forma distinta es la adecuada, la útil, la real.


Procesos y estrategia


Y no olvidemos que un cambio de procesos, como cualquier transformación empresarial, como la propia transformación digital, debe estar siempre orientado a los resultados de negocio y guiada y alineada con la estrategia de la compañía.

Es la estrategia la que nos debe iluminar sobre dónde ponemos el foco a la hora de mejorar los procesos.

Y lo más probable hoy en día es que esa estrategia no nos dicte un mayor control, una mayor burocracia, sino, seguramente, agilidad, flexibilidad y experiencia de cliente.


Conclusión: una transformación consciente


Huyamos de tópicos y huyamos de esa visión de la mejora de procesos como algo 'viejuno' y burocrático. 

Esa es una percepción equivocada. Sin duda.

Seamos realistas. Seamos rigurosos. Seamos conocedores de, y tengamos clara nuestra estrategia de compañía y con base en ella tomemos, de forma consciente e informada, las decisiones más oportunas sobre nuestros procesos 


viernes, 11 de septiembre de 2020

BPMN y modelado de procesos fácil con Bruce Silver


'BPMN quick and easy with method and style' es un libro que explica, de forma muy concisa pero también muy eficaz, los elementos fundamentales del lenguaje de modelado BPMN, el estándar de la industria para el modelado de procesos de negocio. Y viene a constituir una versión revisada y, sobre todo, concentrada, del famoso 'BPMN Method and Style' de este mismo autor. 

El libro consta de nueve capítulos estructurados como sigue:
  • 1. What is BPMN?: proporciona unas ideas preliminares sobre lo que es BPMN comparándolo con los tradicionales y menos formales flowcharts pero reconociendo también alguna limitación en BPMN.

  • 2. BPMN by example: Un capítulo muy importante porque en él explica los elementos básicos de BPMN a medida que va ejemplíficándolos en un proceso. Habla sucesivamente de las actividades, de las bifurcaciones paralelas, de pools y lanes, de flujos de mensaje, de eventos de inicio, de los tipos de tareas, de eventos de inicio y fin, de objetos de datos y de anotaciones. Es una forma de exposición que, si bien puede parecer poco ordenada, es muy efectiva a la hora de comprender de manera incremental los principales elementos del lenguaje.

  • 3. The Method: Introducidos los formalismos principales en el capítulo anterior, en éste el autor expone su propio método de trabajo para, con un enfoque 'top-down', ir construyendo un modelo en seis pasos.

  • 4. BPMN Style: Y, como complemento del anterior, en este capítulo el autor aporta una serie de reglas de estilo, reglas que no son obligatorias según la especificación de BPMN pero que, en la experiencia del autor, conduce a mejores diagramas.

  • 5. DMN and decision tasks: Introduce de manera breve el nuevo lenguaje de modelado para reglas de negocio y decisiones: DMN, (Decision Model &Amp; Notation) y como encaja con BPMN

  • 6 Parallel flow: Un breve capítulo para hacer alguna consideración más específica sobre bifurcaciones y flujos paralelos.

  • 7. Events: Una explicación, inevitablemente un poco más compleja, sobre los eventos como el temporizador y los mensajes, cómo actúan los eventos en frontera de actividad, cómo se relacionan los eventos y las actividades de mensaje, etc

  • 8. Instance alignment: Habla, brevemente, sobre bucles y actividades multi-instancia.

  • 9: Becoming proficient y finaliza el libro con un par de indicaciones sobre cómo seguir aprendiendo y mejorando. Así, explica primero bpmnPRO, una App con conceptos de gamificación pensada para el aprendizaje de BPMN, y luego menciona la propia oferta del autor en materia de formación y certificación.

'BPMN quick and easy with method and style' es un libro que consigue, a la vez, dar una idea bastante completa de BPMN pero de una forma que no se hace larga ni farragosa aunque quizá no sea del todo completa. De todas formas, comparado con lo que he podido leer hasta la fecha sobre BPMN creo que es claramente, la mejor introducción que he encontrado. 

Bruce Silver

(Fuente: Traducción y ligera elaboración de la ficha de autor en la versión Kindle de su libro 'BPMN Method and Style') 
Bruce Silver

Bruce Silver es el presidente de Bruce Silver Associates, un proveedor de servicios de consultoría y formación en el área de Gestión de Procesos de Negocio. Es también fundador y presidente de BPMessentials, proveedor de servicios de formación y certificación.

Sus aportaciones originales a BPMN incluyen el enfoque bautizado como 'Method and style' y el perfil BPMN-I para intercambio de modelos.

Su sitio web (www.brsilver.com) es conocido por sus informes y comentarios acerca de los últimos desarrollos en estándares BPM, herramientas y productos. Fue miembro del equipo técnico que desarrolló la especificación BPMN 2.0 en el OMG y contribuyó a la sección de BPMN del examen de certificación OMG OCEB BPM.

Antes de fundar Bruce Silver Associates en 1994, fue vicepresidente responsable de workflow y gestión documental en la firma de analistas BIS Strategic Decisions, que posteriormente se convertiría en Giga (actualmente integrada en Forrester Research).

Bruce Silver es poseedor de un grado universitario y un doctorado en Física por la Universidad de Princeton y el MIT, y cuatro patentes americanas en el campo de la imagen electrónica.

Puedes conocer más, visitando su Method & Style, la página de su compañía, o siguiéndole en Twitter donde se identifica como @bpmswatch

Ficha técnica:

AUTOR: Bruce Silver
EDITORIAL: Code-Cassidy Press
AÑO: 2017 
ISBN: 978-0982368169
PAGINAS: 124

viernes, 20 de marzo de 2020

Más y mejor Business Process Management con Dumas, La Rosa, Mendling y Reijers

'Fundamentals of Business Process Management' es un excelente libro que cubre, con una profundidad seguramente algo más allá que esos fundamentos que predica su título, los aspectos más relevantes de la disciplina de gestión de procesos de negocio. Un libro del cual esta es su segunda edición, y cuya primera edición ya tuve el placer de leer y comentar en este mismo medio hace ahora algo más de un año.

La nueva edición es algo más larga, más actualizada y con mayor cobertura, pero mantiene el mismo tono de rigor, buenas explicaciones y multitud de ejemplos y ejercicios ya presente en la primera porque, en el fondo, está escrito por profesores universitarios y de escuela de negocio y seguramente concebido como un libro de texto.

El contenido del libro se estructura, en gran medida, en torno al ciclo de vida de BPM que los autores proponen ya en el primer capítulo. En esa estructuración nos encontramos con doce capítulos, como sigue:
  • '1. Introduction to Business Process Management:' Un capítulo inicial en que se repasan los ingredientes que componen un proceso de negocio, se proporciona una perspectiva histórica de las principales disciplinas que han precedido al BPM como la reingeniería de procesos, y luego se presenta el ciclo de vida de la gestión de procesos de negocio que proponen los autores y que incluye las fases de identificación, descubrimiento, análisis, rediseño, implementación y monitorización, fases que ocupan muchos de los capítulos que siguen.

  • '2. Process Identification:' Aborda la primera de las fases del ciclo de vida, la que tiene como objetivo llegar a una arquitectura de procesos y por otra priorizar los que se eligen para seguir profundizando. A ese respecto se repasan primero algunos elementos de contexto como el cuadro de mando integral. Luego se dan algunas directrices sobre cómo reconocer lo que es un proceso de negocio para luego explicar en qué consiste una arquitectura de procesos y luego se finaliza proporcionando criterios e ideas sobre cómo seleccionar los procesos de negocio en que se va a profundizar en el análisis y rediseño.

  • '3. Essential Process Modeling:' Como paso previo a explicar la fase de descubrimiento, se aborda en los dos siguientes capítulos el modelado de procesos. Se basa en una explicación del uso del lenguaje BPMN y se subdivide en dos capítulos. En este primero, se abordan los aspectos más básicos del lenguaje y de las situaciones de proceso en que se aplican. Así, se explican las actividades, los flujos de secuencia, las ramificaciones (paralela, exclusiva e inclusiva) y el patrón del retrabajo. Igualmente se explica el uso de los objetos de datos, los pools y los lanes. Finalmente se habla de subprocesos y de la reutilización de modelos de proceso.

  • '4. Advanced Process Modeling:' Segundo capítulo dedicado al modelado donde se abordan los artefactos y situaciones más complejas. Se empieza profundizando en el tema del retrabajo. Luego se aborda un tema fundamental y complejo: los eventos, seguido del manejo de errores, excepciones y compensaciones.

  • '5. Process Discovery:' Con el bagaje adquirido en los dos capítulos anteriores, se aborda en este capítulo la fase de descubrimiento cuyo resultado es, precisamente, un modelo de proceso, en concreto el llamado modelo AS-IS que refleja la situación de partida del proceso. Se habla de los roles que intervienen, especialmente el del analista de procesos y del experto de dominio. Luego se presentan algunos métodos y técnicas para el descubrimiento, como son los talleres, las entrevistas o los métodos basados en evidencias. Se finaliza proponiendo una mecánica para guiar esta fase de descubrimiento.

  • ':6. Qualitative Process Analysis:' La fase de análisis se subdivide en dos capítulos. En este primero se explican los métodos cualitativos de análisis de procesos. En concreto se revisan y explican el análisis de valor añadido, el análisis de desperdicio, muy conectado con Lean Management, el análisis de stakeholders y documentación de problemáticas ('issues') y el análisis de causa raíz.

  • '7. Quantitative Process Analysis:' Segundo capítulo dedicado al análisis ahora con foco en los métodos cuantitativos. En concreto, se explican el análisis de flujo, la teoría de colas y la simulación.

  • '8. Process redesign:' Se dedica, como el título indica, a la fase de rediseño. Primero se dan algunos conceptos generales, como los objetivos a conseguir y el llamado cuadrilátero del diablo y luego se explican someramente algunas disciplinas de rediseño, divididas en aquellas que son transaccionales (es decir, los que apuestan por mejoras incrementales y donde se incluyen, por ejemplo 7FE o el rediseño heurístico de procesos) y los transformacionales (aquellos que apuestan por un cambio radical, como son la reingeniería de procesos o el diseño basado en producto).

  • '9: Process-Aware Information Systems' Se hace un cierto cambio de tercio dedicado a la tecnología de digitalización de procesos, muy relacionada, eso sí, con la fase de implementación. Dos, casi tres capítulos, cubren los aspectos relacionados con la digitalización de procesos (tres si incluimos el capítulo dedicado a la monitorización). En este primero, se da una panorámica más general y se tratan sistemas 'conscientes del proceso' (como pueden ser los ERP, CRM, SCM o PLM), los BPMS (Business Process Management Systems) o los Sistemas de Case Management. Y se dedica mucho más espacio a los BPMS para explicar su funcionalidad, su arquitectura y las ventajas que traen consigo, así como algunos retos aparejados a su implantación.

  • '10. Process Implementation with Executable Models:' Un capítulo algo más específico y que de alguna manera hace converger el modelado en BPMN y los sistemas BPMS hablando de cómo profundizar en el modelo para llegar a convertirlo en algo ejecutable por un BPMS.

  • '11. Process Monitoring:' Se habla, la verdad que brevemente, sobre la monitorización de procesos mencionando los cuadro de control y brevemente alguna forma de implementación como visualizadores de datos o BAM. Y, a lo que más espacio de se dedica es al Process Mining, es decir, a la obtención de información y conclusiones de los procesos a partir de los logs dejados por los sistemas que los automatizan para tareas como son: el descubrimiento automatizado de procesos, el análisis de rendimiento del proceso, el análisis de conformidad de los procesos a lo recogido en normas y al análisis de variantes del proceso.

  • '12. BPM as an Enterprise Capability:' Un capítulo completamente nuevo en esta segunda edición en que se mira al BPM como una importante disciplina corporativa y donde, sobre todo, se habla de modelos de madurez de BPM.
Para finalizar se incluye un muy interesante y relevante anexo, 'Redesign heuristics', que recoge las heurísticas de rediseño de procesos que se usan en el método de rediseño heurístico de procesos.

'Fundamentals of Business Process Management' es un libro magnífico, con una muy razonable cobertura de todos los temas relevantes, bien estructurado, bien explicado y lleno de ejemplos y ejercicios.

Muy bueno y, en mi opinión, el mejor texto actualmente sobre gestión de procesos de negocio, al menos de los que yo he leído.

Marlon Dumas

(Fuente: Ficha de profesor en Universidad Internacional de La Rioja - UNIR)

Marlon Dumas
Doctor y Máster en Informática de la Universidad de Grenoble Alpes (Francia) y Licenciado en Matemáticas e Informática de la Escuela Normal Superior de París (Francia). Muy conocido internacionalmente por sus contribuciones en el campo de gestión de procesos de negocio, particularmente como co-autor del libro de texto 'Fundamentals of Business Process Management' que es usado en más de 200 universidades mundialmente.

Nacido en Honduras, es científico informático e investigador activo en los campos de BPM y Analítica de Datos de Negocio. Actualmente, profesor de Sistemas de Información en la Universidad de Tartu en Estonia, donde dirige un grupo de investigación en ingeniería de software y sistemas de información, y el Programa Internacional de Maestría en Ingeniería de Software. Profesor adjunto en la Escuela de Sistemas de Información, Facultad de Ciencias e Ingeniería de Queensland University of Technology (Australia), donde contribuye en el MOOC "Fundamentals of Business Process Management" que ha sido completado por más de 10000 participantes. Durante su carrera, el profesor Dumas ha participado en proyectos de investigación con varias empresas líderes, incluyendo SAP AG, Microsoft/Skype, IBM, y Swedbank. El profesor Dumas es co-autor de más 200 publicaciones científicas y de 10 patentes registradas en EUA y UE, incluyendo siete en el campo de BPM.

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

Marcello La Rosa

(Fuente: Traducción y ligera elaboración propia de la biografía en su página oficial)

Marcello La Rosa
Profesor de Sistemas de Información con la School of Computing and Information Systems en la Melbourne School of Engineering, en The University of Melbourne (UoM), Australia. Antes tuvo un puesto académico en la escuela de Sistemas de Información, en la Science & Engineering Faculty de la Queensland University of Technology en Brisbane, Australia, donde dirigió la asignatura de BPM (2016-17) y fue director académico de agenda corporativa (2012-2017). También recibió una beca de investigación en Sistemas de Información de la University of Liechtenstein (2012-14) y ocupó un puesto a tiempo parcial como investigador principal en NICTA, actualmente Data61 (2012-15).

Adopta un enfoque de ingeniería a la investigación en sistemas de información. Su investigación dirige el diseño, implementación y validación de artefactos de sistemas con modelos, métodos y técnicas con foco en la tecnología. Se esfuerza para implementar los resultados de su investigación a través de herramientas de software libre para maximizar el alcance de la comunidad.

El área de aplicación de su investigación es la gestión de procesos de negocio, Business Process Management (BPM). Postula la idea de analizar el rendimiento organizacional a través de la lente de proceso, empezando por entender que el rendimiento organizacional es funcion del rendimiento de los procesos. Su investigación abarca diferentes materias de BPM, con foco en la búsqueda de procesos, modelado de procesos y consolidación, así como automatización de procesos. Dada la naturaleza multidisciplinar de BPM, en su investigación toma prestadas técnicas de un gran número de disciplinas, más allá de la ingenieria de sistemas, incluyendo gestión de sistemas, arquitectura empresarial, modelado conceptual, ingeniería de software, data mining y machine learning, investigación de operaciones y métodos formales.

Su investigación está expuesta en repositorios públicos como Google Scholar, UoM Minerva Access, arXiv, QUT ePrints y BPMCenter.

Ha estado enseñando diferentes aspectos de BPM; desde los más operacionales como el modelado de procesos, análisis, mejora, automatización y descubrimiento, hasta aspectos de gestión como el alineamiento estratégico y gobierno, para estudiantes tanto de grado como posgrado en Australia y otros países. También ha formado a cientos de mandos, analistas y arquitectos de soluciones en el campo del BPM.

Con base en esta experiencia, ha sido co-autor de 'Fundamentals of Business Process Management', el primer libro abarcador sobre BPM. Este libro ha sido incluido en el currículum de más de 200 universidades e instituciones de enseñanza del mundo.

Después, los autores han usado este libro de texto para diseñar un MOOC en tres partes titulado 'Fundamentals of Business Process Management' acreditado con ABPMP, que imparten a través de la plataforma EdCast, y un segundo MOOC de naturaleza introductoria llamado 'BPM: An Introduction to Process Thinking'disponible en la plataforma FutureLearn. En conjunto, estos dos MOOC han atraído a más de 26.000 participantes hasta la fecha.

Valora el desarrollo de software abierto como medio de llegar a diferentes comunidades: académica, estudiantes y practicantes. Por ese motivo, lidera la iniciativa Apromore, una colaboración estratégica entre varias universidades, que ha recbido financiación pública y privada para el desarrollo de una plataforma de analítica avanzada de procesos de negocio. Esta plataforma combina técnicas para la gestión de grandes colecciones de modelos de proceso mediante técnicas de minado de procesos, con un foco especial en los usuarios finales. También contribuye a la plataforma Nirdizati para la monitorización predictiva de procesos. Otros proyectos abiertos sobre BPM que ha dirigido o a los que ha contribuido en el pasado incluyen Process Configuration, que recoge esfuerzos en la gestión de la variabilidad en sistemas orientados a procesos y YAWL, un sistema BPM basado en comunidad y orientado a la investigación.

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

Jan Mendling

(Fuente: Ficha de profesor en Universidad de Viena)

Jan Mendling
Jan Mendling es profesor a tiempo completo en el Institute for Information Business de la Wirtschaftsuniversität Wien (Universidad de Viena), Austria. Sus áreas de interes en investigación incluyen varias materias en relación a la gestión de procesos de negocio y sistemas de información. Ha publicado más de 250 artículos de investigación, entre otros en ACM Transactions on Software Engineering and Methodology, IEEE Transaction on Software Engineering, Information Systems, Data & Knowledge Engineering, y Decision Support Systems. Es miembro del comité editorial de siete revistas internacionales, miembro del comité de la Austrian Society for Process Management y uno de los fundadores de la comunidad BPM de Berlín, organizador de varios eventos académicos sobre gestión de procesos y miembro de la IEEE Task Force on Process Mining. Su tesis doctoral ganó el premio Heinz-Zemanek de la Austrian Computer Society y el premio German Targion-Award para disertaciones en el área de gestión estratégica de la información.

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

Hajo A. Reijers

(Fuente: Ficha de profesor en Universidad de Tecnología de Eindhoven)

Hajo A. Reijers
Profesor a tiempo completo de informática de negocio en el Department of Computer Science de la Universidad de Amsterdam, donde dirige el grupo de Business Informatics. También es profesor a tiempo parcial en el grupo AIS del Department of Mathematics and Computer Science de la Eindhoven University of Technology (TU/e). Su investigación y docencia se centran en la gestión de procesos de negocio, analítica de datos y modelado conceptual. Coopera estrechamente con empresas en el dominio de los servicios de cuidado de la salud así como con varios investigadores internacionales.

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

Ficha técnica:

miércoles, 18 de marzo de 2020

Retos para una transformación de procesos: cuatro barreras de libro... y dos de mi cosecha


Creo que es muy difícil acometer una transformación profunda de una compañía, y en concreto, una transformación digital de una compañía u organización, si no se aborda una perspectiva de procesos de negocio, de BPM (Business Process Management).


Transformación digital y transformación de procesos


En mi libro "La Carrera Digital" hablo de seis áreas de una compañía que pueden ser objeto de transformación digital: la gestión de TI, el puesto de trabajo, el porfolio de productos y servicios, las relaciones con los clientes, los procesos de negocio y el modelo de negocio.

No intento hacer una taxonomía perfecta de categorías disjuntas que tomadas en conjunto sumen el total de posibilidades, sino orientar al lector sobre cómo se aplica la transformación digital. Pero si se observa detenidamente esa propuesta, aparte de la mención explícita a los procesos de negocio como área de transformación, éstos, los procesos, subyacen también a las relaciones con los clientes, al modelo de negocio e, incluso, a la gestión de TI. Y es que como alguna vez expongo en mis clases, los procesos de negocio, en el fondo, nos cuentan cómo funciona una compañía, tanto a nivel interno como en sus relaciones con el exterior así que, en cierto modo 'lo son todo': la empresa es sus procesos (bueno, y sus personas).

Por tanto, si te propones transformar una compañía, casi indefectiblemente, seas consciente o no, vas a transformar también sus procesos de negocio. Y casi mejor que seas consciente...

Y hablo a propósito de transformación de procesos y no de reingeniería, para, por un lado, indicar un cambio profundo (de la misma forma que uso ese término cambio profundo en la definición e transformación digital que aporto, de nuevo, en mi libro "La Carrera Digital") pero, al mismo tiempo, marcar distancias con la Reingeniería de Procesos tal y como la explicaron en su momento, Hammer y Champy y marcar distancias, simplemente en el sentido de no asimilar un cambio profundo de procesos a una orientación o metodología concreta, como es la reingeniería.


Retos de libro para la transformación de procesos


Establecido el interés e incluso la necesidad de la transformación de procesos de negocio, lo que también tenemos claro es que se trata de un cambio estratégico y profundo y que, como tal, se va a encontrar con los retos, resistencias y barreras que todo cambio profundo, y toda transformación digital, se encuentra.

Hablando específicamente de BPM y procesos de negocio, en su excelente libro "Fundamentals of Business Process Management", Marlon Dumas, Marcello La Rosa, Jan Mendling y Hajo A. Reijers, identifican, ya muy al final de su obra, cuatro retos o, más bien, cuatro motivos frecuentes del fracaso de iniciativas BPM. Son éstos:

  • Foco en los métodos y herramientas BPM pero no en los objetivos de negocio

  • La creencia de que BPM es la única fuente de la verdad, en lugar de engarzarlo con otras iniciativas corporativas.

  • Proyectos BPM gestionados aisladamente, en silos

  • Incapacidad inherente para el cambio

Los tres primeros son bastante específicos del campo del BPM y el cuarto recogería, en cierto sentido, la resistencia al cambio o incapacidad para el cambio que atenaza a cualquier iniciativa de transformación de la naturaleza que sea.

Pero, aparte de los retos 'de libro' recogidos arriba, quisiera aportar otros dos retos de mi cosecha, dos retos si se quiere, algo heterodoxos, algo alejados de la erudición de publicaciones y docencia, pero en mi percepción tremendamente reales e influyentes.


Reto de mi cosecha: el divorcio de teoría y práctica


El primero, en realidad, tiene que ver con el equilibro (o más bien, la falta de equilibrio) entre la metodología y el negocio, la teoría y la práctica. Y enlaza parcialmente con el primero de los puntos que proponen Dumas et al. Percibo en el campo del BPM (y no sólo en BPM, pero sí particularmente agudo en él) una suerte de divorcio entre la disciplina y su aplicación y entre los expertos de la misma y el resto del negocio. Un desequilibro del que creo que, en el fondo, son culpables ambas partes.

Con frecuencia, los teóricos y expertos del BPM pecan de exceso de burocracia y metodología, de abundancia de palabrería y términos especializados, de prolijidad de documentación y palabras altisonantes, pero una cierta lejanía de los problemas del día a día, de la realidad del negocio. Falta quizá, pragmatismo, empatía y disponibilidad para 'tirarse al barro', para enfrentarse a la vida real que nunca, nunca, es tan nítida y gestionable como enseñan los libros y las teorías.

Pero también pecan las unidades operativas, los negocios, de un agudo descreimiento y pereza intelectual. Descreimiento que les lleva a desconfiar de todo lo que no sea lo que conocen de forma cercana, de cualquier persona que no esté en su mismo día a día, de cualquier enfoque que no sea 'lo que hemos hecho toda la vida'. Y una pereza intelectual que les lleva a despreciar cualquier teoría o metodología y colgarle el 'sambenito' de burocracia o inutilidad porque sí, sólo porque en lugar de tratarse de acción inmediata, viene respaldada por análisis, estudios y teoría.

Y esta tensión es difícil de deshacer. En primer lugar porque es algo más que un malentendido (el pecado existe realmente por ambas partes) y en segundo porque tiene mucho que ver con actitudes profundas y arraigadas.

Se precisa, por una parte, de mucho conocimiento y, por otra, de líderes de 'ambos lados' con visión transversal, empatía y capacidad de movilización... algo así como el Santo Grial de la gestión del cambio.


Reto de mi cosecha: la moda


Y el segundo reto de mi cosecha, quizá pueda sorprender pero en mi opinión es muy, muy real: simplemente, los procesos de negocio y el BPM no están de moda. Como suena: que no están de moda.

Es cierto que con el impulso actual de la automatización y robotización y la emergencia de tecnologías como RPA parece que, tímidamente, se está relanzando la disciplina del BPM pero aún así, creo que sigue muy aquejada del hecho de no estar de moda.

Si hablamos de transformación digital vamos con la moda y, aunque con mayor o menor acierto en su elección y mayor o menor capacidad de ejecución real, las empresas y directivos prestarán atención al concepto e intentarán invertir en ello y lanzar y apoyar iniciativas de transformación digital.

Si hablamos de agilidad vamos con la moda y, de nuevo, con mayor o menor acierto o empeño, las empresas y los directivos estarán dispuestos a invertir y apoyar y a intentar ser 'agiles'.

Pero BPM parece cosa ya antigua, 'viejuna', del pasado y, por tanto, con frecuencia empresas y directivos, esta vez en claro desacierto, no le prestarán atención, ni estarán dispuestos a invertir, ni apoyar, probablemente ni siquiera a escuchar.

Y sin embargo, estimado directivo: ¿cómo pretendes hacer una transformación digital sin transformar tus procesos? ¿cómo vas a cambiar la relación con tus clientes sin transformar tus procesos? ¿cómo vas a implantar la agilidad sin transformar tus procesos? ¿cómo vas a ser más rápìdo y eficiente sin transformar tus procesos? ¿cómo pretendes reinventar un modelo de negocio sin transformar a tus procesos?

Recuerda que los procesos son tu compañía (bueno, junto con las personas). Si vas a transformar a tu compañía, tienes que transformar tus procesos (y a tus personas).

Muchos son los retos para una transformación de procesos, muchas las dificultades y barreras a superar, pero la más grave, la más difícil de superar es también la más triste y, perdón por la expresión, la más tonta, la más absolutamente tonta: que, simplemente, la transformación de procesos no está de moda...

lunes, 16 de marzo de 2020

Diez principios para una buena gestión de procesos de negocio


He estado leyendo recientemente la segunda edición del libro 'Fundamentals of Business Process Management' de Marlon Dumas, Marcello La Rosa, Jan Mendling y Hajo A. Reijers, un libro excelente que reseñaré en breve.

No he recogido apenas artículos sobre el mismo en este blog, porque, a pesar de su indudable calidad, es un libro muy centrado en explicar su materia y no he encontrado, o no he sabido encontrar,  ese tipo de ideas, a veces colaterales, pero brillantes, distintas o curiosas que alimentan muchos de los artículos de este blog.

No obstante, y ya al final del libro, me he encontrado con un contenido que sí quisiera plasmar aquí. Se trata de diez principios para una buena gestión de procesos de negocio, diez principios que en realidad no son invención de los autores sino que a su vez recogen de un artículo de terceros, diez principios compactos en su enunciado, aunque retadores en su ejecución práctica, diez principios que, en concreto, son éstos:

  • Conciencia del contexto: BPM no se puede aplicar como una receta rígida, sino que debe adaptarse a la situación y contexto de la organización en que se realiza.

  • Continuidad: BPM es una actividad para realizar de forma continua, no como un proyecto aislado.

  • Habilitación: es decir, BPM no debe actuar como un proyecto 'apagafuegos' sino crear capacidades en la organización en que se aplica.

  • Holismo: es decir, amplitud de miras. BPM no debe concentrarse en un foco aislado sino ser amplio e inclusivo en su alcance.

  • Institucionalización: BPM debe embeberse en la estructura organizativa, no mantenerse como una actividad ad-hoc.

  • Implicación: BPM debe involucrar a los diferentes 'stakeholders', incluyendo la participación de los empleados.

  • Entendimiento compartido: BPM debería crear un significado compartido, no limitarse a un lenguaje y actividad de expertos.

  • Propósito: BPM debe añadir valor estratégico, no hacerlo por sí mismo.

  • Simplicidad: BPM debe tener sentido económico y no tener mayor alcance o complejidad que el realmente necesario.

  • Apropiación de la tecnología: BPM debería hacer un uso oportuno de la tecnología y no considerar a la tecnología como un mero subproducto.

Si se observa con atención, podríamos eliminar las siglas BPM de los enunciados y aplicarlos en casi su totalidad a prácticamente cualquier iniciativa estratégica y de transformación. 

Aunque no creo que eso les reste validez. En realidad, lo que eso viene a confirmar, es que BPM es una iniciativa estratégica y de transformación. Una iniciativa, incluso, de transformación digital, dada la importancia de la tecnología digital en cualquier actividad de mejora de procesos.

Así que, ya puestos, podríamos decir que estos diez principios son aplicables a la transformación digital y, si se repasan con calma, creo que así es.

viernes, 14 de febrero de 2020

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:

AÑO: 2019 
ISBN: 978-1704809342
PAGINAS: 419

Artículos de este blog relacionados

lunes, 10 de febrero de 2020

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)

miércoles, 5 de febrero de 2020

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

jueves, 4 de julio de 2019

El contexto de los procesos de negocio


Cuando trabajamos con procesos de negocio, una de las actividades típicas es el descubrimiento y el modelado del proceso, es decir, la recopilación de la forma en que se ejecuta un proceso y su plasmación en un lenguaje formal, normalmente de naturaleza gráfica.

El modelo de un proceso de negocio describe, de alguna forma, un prototipo, un patrón de cómo se debe ejecutar luego cada instancia concreta (caso) de ese proceso. Si,por ejemplo, hemos modelado la gestión de pedidos de una empresa eCommerce, lo que define el modelo de proceso es, de forma general, cómo se trata un pedido, mientras que, cuando un cliente concreto hace un pedido concreto, estamos ante un caso de ese proceso.

Asumimos, y es bastante lógico, que el caso real se ajusta al modelo de proceso y, en cierto sentido, esas es la intención.

Sin embargo, la realidad tiende a matizar los modelos teóricos.

He retomado la lectura del libro 'Process Mining. Data Science in action' de Wil van der Aalst que, por diversos motivos, tuve que detener hacia la mitad. Y, en un momento dado, el autor se detiene a hablar de lo que denomina el contexto del proceso, es decir, factores que rodean al proceso y que hacen que la ejecución real de un caso puede estar matizada de alguna manera respecto al comportamiento prototípico del modelo. Cierto que van der Aalst nos habla del contexto en relación al Process Mining, pero creo que el planteamiento de ese contexto es relevante en cualquier caso. siquiera como advertencia.




Para este autor, hay cuatro niveles de contexto:

  • Contexto del caso propiedades específicas del caso que pueden cambiar el comportamiento. Así, por ejemplo, en el caso de los pedidos, el comportamiento se puede ver alterado en el caso, por ejemplo, de clientes muy importantes (pueden recibir mayor atención o prioridad) o pedidos muy grandes.

  • Contexto del proceso En este caso, hablamos de interacciones entre instancias del mismo proceso. Así, por ejemplo, esas instancias pueden competir por los mismos recursos, por ejemplo, el equipo humano que ejecuta alguna tarea o, en el caso de los pedidos, las existencias en almacén. Y eso puede hacer que diferentes instancias del mismo proceso, no se comporten de una forma completamente similar.

  • Contexto social Se refiere a aspectos que afectan a personas y organizaciones y que recoge influencias como las derivadas de que las mismas personas o grupos puedan trabajar en diferentes procesos o a que puedan existir roces de todo tipo entre esas personas y organizaciones.

  • Contexto externo Finalmente, este contexto abarca elementos de un ecosistema que supera las barreras de la organización. Hablamos, por ejemplo, de la situación económica, regulatoria o incluso climática.

La existencia de estos contextos hace que el valor del modelo de proceso como prototipo, siendo muy alto, no sea completamente definitorio y debamos estar advertidos de que las diferentes instancias de un procesos seguirán comportamientos algo diferenciados. Es importante para process mining, pero también para análisis de tiempos, para indicadores, etc


lunes, 20 de mayo de 2019

Un framework para process mining

El process mining, es decir, el análisis y la gestión de procesos de negocio con base en información de la ejecución de esos procesos, es un campo bastante complejo, lleno de álgebra y algoritmia aunque, en el fondo, la idea que se persigue es bastante fácil de entender.

En su libro 'Process Mining. Data Science in action' de Wil van der Aalst, el autor hace una excelente descripción de todos los conceptos y algoritmos usados en process mining hasta la fecha.

Sin embargo, es cierto que, aun siendo un libro excelente, a veces resulta farragoso y difícil de seguir por la abundancia de formalismos y de algoritmia.

Quizá por eso el propio autor, hacia la mitad de la obra, nos proporciona un 'framework' que sirve de marco general para entender todo el campo del process mining y para agrupar y resumir de alguna manera todo lo visto hasta ese momento.

Por lo ilustrativo y clarificador que resulta, me ha parecido interesante traerlo a este blog. El 'framework' es el que se ilustra en la figura inferior (propiedad del autor y de Springer):



En la parte superior de ese framework se sitúa el 'mundo real' ('world'), un mundo real que es donde existen organizaciones y personas que ejecutan procesos de negocio.

Esos procesos de negocio, en mayor o menor medida están soportados por unos sistemas de información ('information system(s)'. Esos sistemas de información son el origen o procedencia ('provenance') de unos datos en forma de trazas ('logs').

Esas trazas, a su vez, pueden tomarse de instancias o casos de procesos ya finalizados ('historic data') o bien de instancias o casos aún en curso ('current data'). El primer caso nos servirá para lo que se conoce como análisis 'post-mortem' (para, por ejemplo, a nivel individual conocer qué fue mal en una instancia o, a nivel agregado, obtener medidas de los procesos) mientras que en el segundo caso hablaríamos de un análisis 'pre-mortem' que nos debería servir para monitorizar y guiar la ejecución.

En la parte inferior de la figura se observan los modelos de proceso de negocio. Unos modelos que incorporan la información de flujo ('control-flow'), de los datos y reglas de negocio ('data/rules') así como de la organización que los ejecuta y los recursos que utiliza ('resources/organization').

Estos modelos de negocio pueden ser modelos teóricos o 'de jure' es decir los procesos que en teoría se están o deberían estar ejecutando, y los procesos 'de facto' que son los que en la realidad suceden. Las dos flechas, una ascendente y otra descendente, nos hablan de cómo se relacionan los modelos con el mundo real. Los modelos 'de iure' intentan moldear la realidad e influir en ella, es decir, que los procesos que suceden en el mundo real se correspondan con el modelo de proceso teórico (flecha ascendente). Los modelos 'de facto' intentan recoger y representar lo que sucede en el mundo real (flecha descendente).

En la zona media, entre los logs y los modelos de procesos, se desarrolla la actividad del process mining propiamente dicho. Y ahí tenemos las siguientes actividades, recorriendo la figura de derecha a izquierda:

  • 'Cartography:' Se ocupa de describir la realidad, realizando un cierto nivel de abstracción sobre ella. En cierto sentido, se trata de un bloque que mira hacia el pasado. Incluye tres actividades:

    • 'Discover:' quizá lo más representativo del process mining, a saber, deducir el modelo de procesos a partir de la información de las trazas.

    • 'Enhance:' Es decir, revisión de modelos de procesos existentes, bien para hacer correcciones en los mismos, bien para enriquecerlos de alguna manera.

    • 'Diagnose:' En realidad no exactamente process mining, sino análisis de procesos más tradicional. Se ocupa de diagnosticar los procesos de negocio detectando cuellos de botella, ineficiencias o, en general, posibilidades de mejora.

  • 'Auditing' Ahora miramos al presente de los procesos de negocio con la idea, fundamentalmente, de asegurarnos que dichos procesos se ejecutan conforme a lo diseñado y previsto.

    • 'Detect:' Compara los procesos que se están ejecutando con los modelos de proceso 'de jure' y, en caso de detectar inconsistencias, se eleva una alarma o aviso.

    • 'Check:' Compara datos 'post-mortem' de los procesos con los modelos 'de jure' con el objetivo de detectar desviaciones y medir el nivel de cumplimiento 'compliance'.

    • 'Compare:' Compara los modelos 'de facto' con los modelos 'de iure' aunque ahora sin utilizar ya directamente los logs.

    • 'Promote:' Con base en el análisis anterior se `puede promover que algunos aspectos del modelo 'de facto' pasen a los modelos 'de iure', incorporándose como buenas prácticas.

  • 'Navigation:' Finalmente, ahora nos enfocamos al futuro con la idea, por ejemplo, de hacer recomendaciones.

    • 'Explore:' Se comparan los casos en ejecución con las ejecuciones pasadas del mismo modelo de proceso

    • 'Predict:' Combinando la información de los casos actualmente en ejecución con los modelos de proceso, se pueden hacer predicciones respecto al futuro.

    • 'Recommend:' La misma información usada para predecir el futuro se puede usar para emitir recomendaciones (por ejemplo, para intentar minimizar tiempos y/o costes).

La verdad es que visto el framework y entendiendo sus conceptos resulta mucho más sencillo de entender, casi trivial, este, por otro lado, bastante farragoso, campo del process mining.