Business Process Management (BPM) Reflexiones y Recomendaciones

Actualmente existen diversos enfoques de gestión organizacional; uno de los más comunes en el funcional, el cual sigue prevaleciendo sobre modelos de última generación más efectivos, eficientes y agiles. En este sentido, el enfoque orientado en procesos se ha convertido en la opción urgente para mejorar el desempeño organizacional; para resumir, una organización funcional no tiene la capacidad de medir, mejorar y optimizar sus acciones porque no realiza énfasis en los procesos, solo en sus actividades. Una organización BPM se comparta como un carro de carrera en fórmula 1, con un equipo que mide todas las variables necesarias para ganar.

En todas las organizaciones donde he realizado asesorías y consultorías BPM han persistido los siguientes hallazgos:

1. No existe una clara definición y caracterización de procesos.
2. No se entiende la diferencia entre un proceso y un procedimiento.
3. Los procesos no están alineados y vinculados a un objetivo organizacional.
4. Los procesos no están alineados y vinculados a un producto o servicio.
5. Los procesos no tiene asociados acuerdos de servicios.
6. Los procesos no tiene asociados indicadores.
7. Los procesos no pueden ser monitoreados y medidos.
8. La mayoría de los procesos no son transversales, solo se ven los árboles y no el bosque.
9. Los procesos no tiene asociadas políticas.
10. Los procesos no tiene asociados procedimientos.
11. El levantamiento de procesos no se realiza sobre un enfoque participativo y multidisciplinario.
12. El levantamiento de procesos se realiza sin métodos y técnicas que faciliten su especificación.
13. El levantamiento de procesos no se basa en la comprensión profunda de modelos y prácticas que evitaran modelar el desastre.
14. Los procesos no son categorizados o clasificados.
15. No existe una notación estándar para el modelado de procesos.

Establecer acciones para cerrar cada una de estas brechas sería muy extenso para describirlas en este blog, sin embargo comparto algunas recomendaciones que contribuirán con ejercicios de mayor valor en esta materia.

Recomendaciones

1. Describa y caracterice un proceso para estandarizar y homologar el lenguaje antes de iniciar cualquier iniciativa.
2. Comunique de forma clara y concisa la diferencia entre una actividad,  un proceso y un procedimiento a su equipo. Es diversas asesorías en las que he participado he encontrado inconsistencias, procesos que son actividades y viceversa.
3. Evalué el nivel de profundidad en la descripción de sus procesos que requiere. Comience con descripciones generales y luego vaya realizando una inmersión mayor de forma iterativa.
4. Recuerde que cada proceso debe estar asociado a la entrega de un producto o servicio.
5. Recuerde que cada proceso debe estar asociado al cumplimiento de un objetivo organizacional.
6. Evalué y seleccione la herramienta de modelado de procesos que más se adapte a sus necesidades.
7. Establezca una categorización de procesos: macroprocesos, procesos, subprocesos. Es importante establecer una organización mínima de sus procesos para posteriormente mapearlos.
8. Defina los indicadores de desempeño y resultado de sus procesos para medirlos, mejorarlos y optimizarlos antes de ir a la automatización.
9. La actividad de modelado de procesos requiere de técnicas y métodos no tradicionales.
10. Realice énfasis en la descripción de políticas (normas y directrices), son ellas las que establecen las fronteras y condiciones de sus procesos.
11. Modele primero la ruta de éxito y luego enriquezca.

Saludos;

Entrenamiento Mule ESB en Banco Central de Venezuela

Hace algunos meses tuve la experiencia de dictar un entrenamiento de Mule ESB en el Banco Central de Venezuela para un proyecto integración de gran envergadura. Durante el intercambio de experiencias en el campo de integración, el equipo de trabajo enriqueció muchos conceptos, que quisimos compartir con la comunidad.  Mule ESB es una plataforma de integración ligera basada en Java que permite conectar  aplicaciones de forma rápida y sencilla, actuando como un sistema de transporte e intercambio de datos. En líneas generales se utiliza un bus de servicios cuando se requiere:

1. La creación y alojamiento de servicios web reutilizables en un contenedor de servicios ligero.
2. El enrutamiento de mensajes, para enrutar, filtrar, agregar, y redirigir mensajes entrantes o salientes basados en su contenido o en reglas.
3. La transformación e intercambio de datos a través de distintos formatos y protocolos de transporte.
4. Servicios de mediación para el manejo de formatos, mensaje y protocolos, además de lógicas de integración.

Cuando debemos utilizar un ESB?

1. Cuando se requiere la integración de 3 o más aplicaciones o servicios.
2. Cuando se requiere conectar más aplicaciones en un futuro.
3. Cuando es necesario utilizar más de un tipo de protocolo de comunicación.
4. Cuando se requiere capacidades de enrutamiento de mensajes, tales como bifurcación y agregación de flujos de mensajes, o enrutamiento basado en contenido.
5. Cuando es necesario  publicar los servicios destinados al consumo de otras aplicaciones

Recomendaciones para el uso de Mule ESB

1. El patrón de intercambio seleccionado para un flow o flujo incide en el número de hilos que mule utiliza para la ejecución de servicios de integración. Si el patrón es Request-Response, este se desarrolla sobre un solo hilo; si el patrón es Onew-Way se desarrolla sobre un pool de hilos (inbound, core y outbount). Es necesario considerar esta política durante el diseño de los servicios.
2. Por defecto Mule ESB solo gestiona 16 hilos, por ende, es importante monitorear el número de hilos y aumentarlo según la demanda de un servicio de integración específico.
3. Mule ESB proporciona patrones de configuración, que están optimizados para casos comunes de procesamiento de mensajes. Los cuatro patrones de configuración incluidos en Mule son: Servicio simple (componente que expone servicios web SOAP/ JAX-WS , beans, REST/JAX-RS, JAXB, XML y el contenido de simples componentes POJO), Web Service Proxy ( Proxies de servicios web remotos que pueden realizar transformaciones), Bridge ( establecen un canal de comunicación directo entre un endpoint de entrada y uno de salida), por ultimo Validador (Valida los mensajes entrantes contra un filtro de aceptación definido. Devuelve una respuesta ACK o NACK sincrónica y envía mensajes válidos de forma asíncrona).
4. Utilice el Scope Pool para ajustar el desempeño de un servicio de integración mediante pool de objetos.
5. Utilice wiretap para realizar auditorías en los flows o flujos de servicios.
6. Si requiere utilizar multiples entradas en un mismo flow utilice composite source.
7. Si requiere establecer rutas alternativas al fallar una rama de ejecución utilice first successfull.
8. Si requiere reorganizar la secuencia de mensajes utilice un resequencer.
9. Si va a realizar mapeo recomiendo utilizar smooks y dozer.
10. La información del header de un mensaje en el inbound no se propaga al siguiente flow, solo de outbound a inboud, considere esta característica cuando diseñe sus servicios.

Agradezco al equipo que con su participacion y observaciones enriquecieron los talleres.

Ejemplo: Como enviar un mensaje a multiples destinos.
 

 Ejemplo: Como realizar el procesamiento de una coleccion de datos.

 Ejemplo: Como exponer un servicio web implementado en un POJO.

  Ejemplo: Como filtrar el mensaje entrante de un servicio.

  Ejemplo: Como realizar auditorias a un servicios de integracion:

Saludos;