Xtreme BPM (Extreme BPM) o Agile BPM 2.0

Registered at RegisteredCommons.org

Implementar procesos de negocio bajo el enfoque BPM es una tarea compleja que requiere de la Organización bastante disciplina, y un nivel de madurez metodológico y en estándares alto, esto se traduce en:

  • Tener un acabado conocimiento de los Procesos del Negocio.
  • Dominar la orientación a servicios (SOA).
  • Aplicar varias tecnologías nuevas (XML, WebServices, EBUS, BAM, Portlets, J2EE, .NET, BPEL, BPEL4People, etc.)
  • Tener un esquema de control y apoyo adecuado (Governance).

Luego con tanto prerrequisito implementar BPM puede o tomar mucho tiempo, o involucrar una alta inversión inicial. Entonces ¿Como podemos comenzar a implementar BPM ahora, sin tener que hacer una inversión tan riesgosa?.

A continuación se presentará una alternativa utilizando el enfoque “Ágil” (Agile), el mismo en el que se fundamenta “Xtreme Programming” (XP), a este nuevo enfoque le llamaremos XtremeBPM.

Los principios “Ágiles” son:

  • Simplicidad: consiste en desarrollar solo lo que se necesita actualmente, entregar soluciones simples pero escalables. Los proyectos deben ser de corto plazo. Es muy complejo predecir el futuro.
  • Retroalimentación: el proyecto se divide en pequeñas partes que se desarrollan y prueban, obteniendo una retroalimentación del usuario antes y oportuna.
  • Comunicación: propone una comunicación directa y continua entre clientes y desarrolladores, el cliente se integra en el equipo para establecer prioridades y resolver dudas, y de esta forma ve el avance día a día.
  • Decisión (Courage): enfrentar los problemas inmediatamente, mejorar el sistema si la retroalimentación lo sugiere, y enfrentar los cambios de plan apenas se identifican.

Si nos detenemos en estos principios podremos ver que están en total concordancia con los objetivos de BPM:

  • Integración de TI y Negocio: BPM acorta la brecha entre negocio y TI, y refuerza el concepto de que las soluciones estén basadas directamente en los objetivos de negocio, y en los procesos de negocio. Esto esta directamente relacionado con los principios ágiles de comunicación y retroalimentación.
  • Enfoque Evolutivo: BPM descarta totalmente los enfoques BigBang (revolución en los sistemas), propone un enfoque evolutivo, comenzando por la implementación de algunos procesos de negocio, los principales, y al igual que SOA realizando primero los componentes mas reutilizables, y con el tiempo ir sumando soluciones. A lo mismo que apunta el principio de la “simplicidad” (enfoque ágil).
  • Time2Market: otro objetivo de BPM es salir con las soluciones en forma oportuna, y lograr adecuarse lo mas rápido posible a los cambios del mercado, a los cambios de negocio. El principio ágil de la “Decisión” (Courage) para enfrentar los cambios va en la misma dirección.
  • Ciclo de Vida Procesos: BPM se basa en el ciclo de mejoramiento continuo de los procesos de negocio pasando por el modelamiento, simulación, publicación, ejecución, y monitoreo de los procesos, donde el monitoreo retroalimenta al modelo con estadísticas reales del proceso. Los mismos fundamentos que hay detrás de los principios ágiles de simplicidad y retroalimentación; soluciones que van a mejorando en el tiempo.

La idea de XtremeBPM es ir avanzando en forma acorde al desarrollo de las capacidades de la Organización, comenzando por los pasos mas fáciles de BPM, e ir aumentando la complejidad, y mejorando la solución en forma continua.

Antecedentes de BPM.

Un proceso de negocio se puede definir como una secuencia de actividades para lograr un objetivo o meta de negocio, por ejemplo en un Banco el proceso para “Otorgar un Crédito de Consumo”. En esta definición es importante recalcar lo de “objetivo de negocio”, porque permite diferenciarlos de los otros procesos, por ejemplo el proceso de “Impresión Masiva de Contratos” no es un proceso de negocio, porque no logra una meta de negocio sino una meta operativa, es un proceso informático, lo que si; puede ser parte de un proceso de negocio.

Proceso de Negocio Otorgar Credito de ConsumoEl modelo del proceso de negocio es el componente fundamental de BPM, porque este modelo (o flujo) es el que de cierta forma se ejecuta en el motor de BPM (el Process Server).

El proceso de negocio (su modelo BPM), se compone principalmente de:

  • Actividades: son las tareas que debe hacer una persona (tarea interactiva, human task), o debe hacer un sistema (servicio, o system task) dentro del proceso de negocio. Por ejemplo “Revisar Antecedentes Financieros” (actividad interactiva), o “Imprimir Contrato” (servicio de un sistema).
  • Roles y Usuarios: son los responsables de ejecutar las tareas interactivas, por ejemplo un “Ejecutivo” de un Banco.
  • Objeto de Negocio: es la información o documento que fluye a través del proceso de negocio, por ejemplo la “Solicitud de Crédito”, o el “Crédito de Consumo” (en que se transforma la solicitud), o la “Ficha del Cliente”.
  • Flujos (flechas): es la secuencia que se define entre las actividades.
  • Decisiones: criterios para tomar distintas opciones en el procesos, distintas direcciones en el flujo.
  • Subproceso: otro proceso interno.

Componenetes Modelo BPM

Obstáculos que enfrenta BPM.

A continuación presentaremos los principales obstáculos que presenta un proyecto BPM.

Modelar la Realidad una Tarea Compleja

Como se indicó; el modelo del proceso de negocio es el núcleo de la solución BPM, pero plasmar un proceso real en un modelo es una tarea compleja. Lo que sucede es que la realidad tiene excepciones, es variable, y un modelo trata de “fijar” las reglas.

Otro alcance en BPM es que como el modelo del procesos es el motor de la solución, el nivel de detalle requerido es mucho mayor, porque el modelo ya no solo tiene un objetivo “didáctico” o de documentación de los procesos, en BPM tiene que tener el suficiente detalle como para ser ejecutado.

Si nos damos cuenta un modelo “tradicional” de un proceso de negocio se centra en el “camino feliz” (HappyPath), es decir en el caso que todo anda bien, como en el ejemplo del diagrama anterior “Otorgar un Crédito de Consumo” donde el flujo muestra el caso de un Cliente “ideal”, que cumple todos los requisitos para que se le otorgue un crédito: tiene un patrimonio adecuado, no tiene deudas, y no tiene antecedentes penales, este modelo para efectos de “mostrar” el proceso puede ser suficiente, pero el “camino feliz” es solo la punta del iceberg en un proceso real cada excepción determina varios nuevos caminos en el flujo (decisiones), incluso las excepciones en combinación pueden determinar otros caminos:

  • Que sucede si le patrimonio no es suficiente.
  • Que sucede si tiene deudas en el sistema.
  • Que sucede si tiene antecedentes
  • Que sucede si se arrepiente de firmar una vez aprobado el crédito.
  • Que sucede si tiene antecedentes pero en el ultimo tiempo es un Cliente ejemplar, y su patrimonio es importante.

Luego las excepciones hacen bastante mas complejo el modelo, pero son necesarias para su ejecución.

Y hay otro tipos de excepciones que son comunes, y que también “dificultan” la implementación de un proceso, como la “generalización” de los roles, por ejemplo el “Supervisor” (de una sucursal) es quien “Autoriza el Crédito”, pero en la realidad existe una sucursal pequeña donde lo autoriza específicamente “Juan Perez” que es un Ejecutivo Senior, en este caso no podemos asignarle el rol de supervisor a “Juan Perez” porque le entregaríamos otros privilegios, y dependiendo de la solución BPMS la alternativa incluso puede ser crear un rol especial para un solo caso.

También en la realidad se da el caso de que el flujo depende del criterio de un experto el cual decide cual es la próxima tarea, y la próxima tarea puede ser un subconjunto grande de posibilidades, luego difícilmente vamos a modelar todas las flechas de salida hacia todas las actividades posibles.

caso Experto

Incluso puede ser aun mas complejo: un experto no solo determina la próxima actividad sino toda una forma de flujo especial en cada caso.

Luego, el modelo para realmente operar, se comienza a alejar del modelo inicial entregado por el área de negocio, y tratar de lograr obtener una primera versión funcional del proceso se hace realmente difícil de lograr.

Generalmente lo que se hace en estos casos es que se implementa solo el “camino feliz” y las excepciones se manejan como cajas negras, o simplemente se dejan fuera de la implementación inicial del proceso, pero esto deja muchas funcionalidades sin implementar.

Importancia del Manejo de Excepciones.

El “camino feliz” generalmente es la ejecución (flujo) mas común de un proceso de negocio, que puede corresponder el 70% de los casos reales, luego una solución BPM que implemente solo este flujo estaría apoyando el 70% de los procesos que se ejecutan, pero desde el punto de vista de gestión, el 30% que queda fuera, puede ser tanto o mas importante en cuanto a información , seguimiento y control.

Un caso especial o excepción puede transformarse en un”taco” dentro del flujo del proceso, luego es importante conocer las actividades que se realizaron en el manejo de la excepción, y cuanto demoraron. Si las excepciones se manejan como “cajas negra” entonces ¿Como identificaremos los casos especiales, que se hacen tan comunes que ya deberían ser parte del flujo?.

Modelar por Partes.

Otra forma de hacer mas manejable la implementación de un proceso de negocio con BPM, es empezando con una parte del proceso, donde si se manejen la mayoría de sus excepciones, en el ejemplo del proceso de “Otorgar un Crédito de Consumo” podría ser la parte de la evaluación del Cliente que hace el ejecutivo con todas sus excepciones., dejando fuera las actividades del supervisor. Y esta parte del proceso se lleva a producción, luego en etapas siguientes se implementan las otras partes del procesos hasta completarlo.

El problema de este enfoque es que sigue siendo una solución a medias, es como pavimentar una parte del camino solamente, lo que a vista del usuario final no es considerado como una solución.

Catálogo de Servicios en Desarrollo.

Una de las diferencias importantes entre implementar BPM y el enfoque tradicional de los WorkFlows, es que BPM integra en el flujo a los “servicios” (actividad automatizada realizada por un sistema , y bajo el estándar SOA).

Luego si en una empresa los servicios SOA aun están en desarrollo, es decir, se cuenta solo con un conjunto pequeño de servicios implementados bajo SOA, entonces implementar un proceso de negocio funcional implica una fuerte carga de trabajo en el desarrollo de los servicios necesarios, lo que suele demorar la implementación de un proceso bajo BPM.

Este es otro escollo que suele determinar que un proceso de negocio se realice por partes, o que se opte por implementar primero los servicios de un solo sistema legado (uno de todos los sistemas que están involucrados en el proceso de negocio).

Tareas Interactivas Legadas.

BPM supone una interfaz común para las tareas interactivas, es decir se espera que la solución BPM provea las interfaces necesarias para que un participante del proceso de negocio (un usuario) realice sus actividad, por ejemplo una pantalla que le permita al Supervisor “autorizar el Crédito”, donde se le muestren los datos principales del cliente y de la solicitud, quizás se adjunte la solicitud de crédito (el documento), y donde el tenga la opción de aprobar ,o rechazar el crédito.

Pero muchas veces esta interfaz existe en la empresa y esta implementada en un sistema (legado), y migrarla a la plataforma BPM es una tarea compleja.

Evitar Doble Tarea.

En las soluciones WorkFlow tradicionales, generalmente el usuario tenia que por un lado ingresar al sistema legado hacer su tarea interactiva, y después meterse en el ambiente del WorkFlow para registrar el avance, es decir por cada actividad interactiva tenia que hacer 2 tareas. En BPM se propone evitar esto con la integración de los sistemas (a través de los servicios), y mediante la interfaz común. Así en BPM un actividad como “Registrar el Crédito” internamente y automáticamente registra el avance del proceso a la siguiente tarea, y no lo tiene que hacer expresamente el usuario.

Pero si finalmente para efectos de tener una primera implementación del proceso, se implementa por partes, o solo se implementan algunos servicios, entonces lo mas probable es que se den casos en que el usuario deba registrar su avance en BPM porque el servicio se sigue haciendo en el sistema externo.

Practicas y Principios de XtremeBPM

A continuaciones mostraremos las practicas de desarrollo de XtremeBPM, que tratan de minimizar el impacto de los obstáculos antes mencionados.

Este nuevo enfoque muestra una forma de enfrentar el problema, partiendo por los componentes mas simples, pero mejorando la solución en un proceso continuo, logrando finalmente lo mismo que el enfoque tradicional, que es: el proceso de negocio implementado.

La idea de este enfoque es lograr desde un principio los siguientes objetivos (de la administración de un procesos de negocio):

  • Seguimiento y Control del Proceso de Negocio.
  • Entregar Información de Gestión del Proceso (en tiempo real).

Modelo Centrado en las Actividades.

Lo mas complejo de modelar un procesos de negocio no es determinar las actividades que lo componen, sino representar los distintos flujos o secuencias que existen entre las actividades, gráficamente hablando lo mas complejo es colocar las “flechas” en el modelo.

Tomando ejemplos anteriores, el problema en el manejo de excepciones en un proceso de negocio, no es que agregan tantas nuevas actividades, sino que agrega nuevas secuencias a las actividades existentes, mas flechas y en distintas combinaciones, lo cual desordena el modelo, por ejemplo para el “Otorgamiento de un Crédito”, un Cliente que tuvo antecedentes penales, pero que tiene un patrimonio excelente, quizás este caso especial mas que una nueva actividad, determina que el flujo salte directo a la actividad “Autorizar Crédito” (actividad que ya existe).

Esto incluso lo respaldan metodologías como UML, aquí lo primero que se define son los “Casos de Uso”, es decir, se determinan las distintas funcionalidades por tipo de usuario, o en metodologías orientadas a objeto (OO), aquí se indica que lo primero es comenzar a identificar los objetos y los métodos a partir de los requerimientos del usuario. Fácilmente podemos entonces hacer un paralelo, donde lo primordial es determinar las actividades de un BPM (o modelo de procesos de negocio) al igual como los casos de uso UML, o los “métodos” de OO.

XtremeBPM se basa en ese hecho: de que es más fácil e inmediato determinar las actividades de un proceso que identificar sus flujos, luego la primicia es:

Implementar Primero las Actividades sin los Flujos

En vez de simplificar la implementación del proceso tomando solo una parte de él, o dejando fuera las excepciones, XtremeBPM propone tomar todas las actividades del proceso pero dejando fuera (en primera instancia) los flujos (las flechas). Es decir la primera implementación del proceso de negocio será principalmente actividades, sin flechas (o con muy pocas de ellas).

Participante Determina Flujo.

¿Pero entonces quien determina la secuencia de las actividades?

Respuesta: Las determina cada participante del proceso, es decir un usuario determina cual tarea es la próxima, y quien la realiza.

Manejo de los Estados y Restricciones de Entrada

Una parte importante de esta primicia (XtremeBPM), es que se deben determinar los estados principales de los objetos de negocio, y para las actividades se debe definir los estados que son prerrequisito “obligatorios” de entrada, por ejemplo para al actividad “Autorizar Crédito” la solicitud de crédito debe cumplir con los estados “Patrimonio Verificado”, “Deudas Verificadas” y “Antecedentes penales verificados”, es decir un CheckList de estados.

De esta forma no interesa el orden en que se realizaron las actividades previas, lo que si importa es que se cumplan ciertas condiciones, o estados. El ejemplo esta bastante simplificado, porque las condiciones no son solo si se cumple un estado u otro, sino a veces son condiciones un poco mas complejas, como:

§ El Patrimonio supere cierto monto.

§ Las deudas estén por debajo de un monto.

Estas condiciones “obligatorias” o “estado obligatorios” son los que se deben validar como entrada de una actividad.

Validar Estados en la Entrada

Aquí hay otra característica importante de XtremeBPM, que es; que condiciona la simplificación del modelo, porque muchas veces los estados se tratan de evaluar en la salida de una actividad, dependiendo hacia que actividad se va a saltar, lo cual hace que se tenga que manejar repetidas veces las condiciones, por ejemplo supongamos que N actividades desembocan en la actividad “Autorizar Crédito”, pero en vez de validar en la entrada de esta ultima, validamos en las actividades previas como condiciones para saltar a “Autorizar Crédito”, entonces debemos implementar N veces la validación.

Validar Estados en la Salida

Si no se cumple con las Condiciones se Devuelve.

Si un objeto de negocio no cumple con las condiciones o estados de entrada de una actividad se devuelve a la actividad previa, y al usuario previo, de esta forma se evitan las asignaciones erróneas, y el objeto de negocio vuelve a quien trato de asignarlo.

Actividades “EstereoTipo” (StereoType)

Este es otro aspecto fundamental de este enfoque, las actividades “Estereotipo” son una forma de extender el modelo del proceso de negocio, y son una forma manejar las posibles actividades nuevas o que no están aun en el proceso implementado (no están en el modelo).

En el mismo ejemplo del proceso de “Otorgar un Crédito”, supongamos que hay un caso excepcional que implica la actividad especial “Aprobación del Crédito por el Gerente de Área”, ¿Que se hace en este caso, si el modelo no incluye esa tarea?; lo mas probable es que se realice la tarea pero sea “obviada” en el flujo BPM (no se registre que se hizo), luego dicha actividad especial queda fuera del seguimiento, y control del proceso, y la información de control queda inconsistente, por ejemplo pareciera que la tarea previa o posterior demoro mas porque suma el tiempo de esta tarea especial.

En XtremeBPM se propone que cada proceso de negocio tenga una actividad genérica a la cual llamamos “Actividad Estereotipo”, la cual cualquier participante puede asignar en cualquier punto del flujo. Lo mínimo que tiene que tener esta actividad es:

§ Campo Estereotipo: campo que indica el tipo de actividad, en el ejemplo seria “Aprobación del Gerente”.

§ Descripción Actividad: campo que indica a grandes rasgos que se debe hacer para cumplir la actividad. Este lo define quien enviá la tarea.

§ Desarrollo u Observaciones: campo que indica el detalle de lo que se hizo, o las observaciones de su ejecución. Este lo define quien recibe y/o ejecuta la tarea.

Este concepto es parecido a los estereotipos en UML que permiten extender la metodología a componentes nuevos que no existen en los diagramas base.

Una ventaja esta en que como la actividad “estereotipo” esta dentro del proceso, entonces tiene acceso a los objetos de negocio del flujo, luego por ejemplo para la actividad “Aprobación del Gerente”, el Gerente tiene acceso a los datos de la “Solicitud de Crédito”, tal como cualquier otra actividad del flujo.

Además como cualquier otra actividad aparece en el historial, y en las distintas vistas de control, asegurando de esta forma el seguimiento de estas tareas extraordinarias.

Control y Seguimiento desde un Inicio.

La principal ventaja de XtremeBPM es que se cuenta desde un principio con el “Control y Seguimiento” del proceso de negocio, como BPM mantiene el historial del desarrollo de las actividades entonces en todo momento podemos saber por donde paso el flujo: quien hizo que actividad, cuando se demoro, y luego cual fue la siguiente actividad.

Como este enfoque toma todas las actividades del proceso, a diferencia de tomar solo una parte del proceso, no existen espacios vacíos en el seguimiento del proceso.

Los gráficos de monitoreo (BAM) también cumplen su funcionalidad, por ejemplo gráficos (de barra) que indiquen “Cantidad de Procesos por Actividad” o “Actividades que son Cuellos de Botella” son consistentes bajo esta solución “XtremeBPM”.

Flujos van Apareciendo

Lo primero es “aclarar” que este enfoque es un proceso de mejoramiento continuo, es decir, no se pretende que los procesos nunca tengan flujos (flechas), sino que solo como una forma de enfrentar el problema se implemente primero sin flujos, pero a medida que se va ejecutando el proceso se vayan implementando los flujos.

Y aquí hay otra ventaja de este enfoque; es que lo flujos comienzan a aparecer, no es necesario un análisis detallado de requerimientos, basta con ver algunos “historiales” de ejecución de los procesos para determinar los flujos mas comunes del proceso.

Por otro lado no necesariamente las actividades van a necesitar tener definido un flujo, en la realidad hay actividades que no van a necesitar nunca un orden o secuencia predeterminado, en estos casos bajo XtremeBPM no debería implementarse tampoco un flujo (las flechas).

Manejo de Errores de Asignación

El principal problema de que el flujo no este predefinido (no existan flechas) es que “por error o por mala intención” se asigne una tarea incorrectamente, o se salte alguna tarea.

“El Manejo de Estados y Restricciones de Entrada” prevén esta situación en la mayoría de los casos, pero puede haber excepciones donde no haya forma de controlar (todavía) el cumplimiento previo de actividades, o la asignación a la persona adecuada.

Pero esto hay que analizarlo desde el siguiente punto de vista; si actualmente no hay WorkFlow o proceso BPM implementado, tampoco se esta controlando este problema, y es más existe mayor “riesgo” que con XtremeBPM, porque por lo menos:

  • Con XtremeBPM podemos revisar el historial y queda evidenciado cualquier flujo erróneo, y eso los participantes del proceso lo saben.
  • Con XtremeBPM podemos saber si una persona tiene muchos procesos de negocio estancados.
  • En XtremeBPM las posibilidades están mas limitadas que en la realidad (sin WorkFlow); dentro del proceso de negocio solo se puede asignar tareas que corresponden al proceso, y asignar a participantes validos dentro del proceso, es decir, existen ciertas restricciones mínimas. Por ejemplo sin Workflow una persona puede enviar la “Solicitud de Crédito” por email a cualquier otra persona, y de cierta forma perderse este proceso, o lo que es peor aún llegar a la persona inadecuada.

También están los aspectos de seguridad manual como respaldo, por ejemplo, esta bien un ejecutivo se equivoco y asigno a otro ejecutivo para “Autorizar el Crédito”, y no al Supervisor, pero como la solicitud de crédito debe llevar al firma y timbre del supervisor , aquí hay otro resguardo de que el error no va a seguir curso.

En resumen hay que sopesar ventajas versus desventajas, y claramente son mayores las ventajas en tener todas las actividades en el modelo, y darle de forma efectiva seguimiento al proceso, que esperar a tener un flujo totalmente definido, o tener una parte pequeña del proceso implementada.

Seguridad versus Flexibilidad.

Ahora siempre va a haber casos donde la seguridad prime, donde no haya cabida a asignaciones erróneas, y donde este bien definido el rol que ejecuta una actividad. En este caso la actividad se asigna al rol determinado:

Supongamos que la actividad “Autorizar Crédito” solo lo puede hacer un supervisor, no existe otra posibilidad, entonces esta actividad se restringe al rol “Supervisor”, reduciendo así el riesgo de asignación a la persona inadecuada, pero por otro lado se pierde la flexibilidad o se hace mas compleja la solución, por ejemplo que hacemos con el “Ejecutivo Senior” de la pequeña Sucursal que no puede ser Supervisor, pero si “Autoriza Crédito” en su sucursal (hemos perdido flexibilidad en pro de la seguridad).

Modelo XTremeBPM

Según el principio de “Modelo centrado en las Actividades” , la siguiente es la implementación inicial del ejemplo “Proceso para Obtener Crédito de Consumo”:

Proceso de Negocio bajo XtremeBPM

Esta es la implementación sin flujos (con muy pocas flechas), pero donde en cada actividad se permite determinar cual es la próxima tarea, y a la persona que se asigna.

Se agrega una actividad inicial “Recibir Solicitud”, que es la actividad que permite dar el puntapié inicial en el flujo. Cuando llega un Cliente con una “Solicitud de Crédito”, es la actividad que realiza quien lo recibe, y que permite después poder asignar cualquier otra actividad válida del proceso.

Por “Participante Valido del proceso” se entiende que son todos los roles o usuarios validos en el proceso de “Otorgar un Crédito”, por ejemplo pueden ser ejecutivos , supervisor, o gerente de una sucursal.

En este caso la tarea “Autorizar Crédito” se restringe solo al “Supervisor” por prioridades de seguridad del proceso.

Se supone que en este modelo también contempla las principales actividades de los casos de excepción.

En un principio el orden de cómo se ejecutan las actividades “Verificar Patrimonio”, “Verificar Antecedentes”, “Verificar Deudas”, o “Avisar Rechazo” son irrelevantes, con el tiempo, y si es realmente necesario se van a comenzar a definir los distintos flujos (flechas), apoyados en el historial de ejecución.

Levantar la Interfaz Legada.

Si para los procesos interactivos existe una interfaz en los sistemas existentes (legados) XtremeBPM propone usarla directamente, es decir levantar la aplicación legada y saltar a la funcionalidad correspondiente, de forma tal de aprovechar la interfaz de usuario existente.

Esta claro que esto supone la intervención del sistema legado, y existirán casos en que no se puede hacer.

Pero esta solución es bastante manejable en sistemas Web (legados) donde se puede construir un Portlet, sección (IFrame) que acceda directamente a la funcionalidad Web (legada).

Recordar que esta es la solución para implementar de forma mas inmediata un proceso de negocio, pero con el tiempo se debe ir pasando las interfaces legadas a una interfaz propia de BPM (interfaz única), como parte del mejoramiento continuo de un proceso de negocio.

Servicio de Avance BPM.

Para evitar el problema de doble tarea (hacer actividad interactiva y además registrar avance en BPM) en el caso anterior, se propone intervenir el sistema legado para que llame a un “Servicio de Avance BPM” una vez completada la funcionalidad, para que automáticamente el Flujo avance a la siguiente actividad.

Generalmente existen conectores en las soluciones BPMS para realizar esto.

Generadores de Servicios, o Adaptadores de Servicios para Sistemas Legados.

Una forma de tener antes los Servicios SOA necesarios para implementar el proceso de negocio, es utilizar generadores de código, o adaptadores para poder componentizar los sistemas legados.

En algunos BPMS se provee de dichas herramientas, en otras ocasiones puede convenir incluso desarrollarlos.

Por ejemplo si nuestro sistema legado tiene gran parte de su funcionalidad de negocio en “Stored Procedures”, quizás conviene utilizar un generador de código o adaptador que permita darle una cara Java al procedimiento, para que sea más fácil implementar un WebService bajo los estándares SOA. Hay que recalcar que no se recomienda una herramienta que transforme un “Stored Procedure” directamente en un WebService, por que lo mas probable es que ese WebService no cumpla ninguno de los principios SOA de reusabilidad, y de ser un servicio de negocio, porque difícilmente el Stored Procedure cumple dichos principios SOA, luego queda como resultado un servicio orientado a la base de datos, mas que un servicio SOA.

Desafíos Extremos para las Suite BPM (BPMS) Actuales

El futuro de XtremeBPM es que las suites (BPMS)provean las herramientas necesarias para facilitar este enfoque, es decir, que las herramientas BPM en un futuro provean ciertas características que permitan acortar el ciclo para alcanzar el proceso de negocio totalmente implementado.

Generador de Flujos.

Una herramienta bastante útil seria que los BPMS propusieran los flujos, basados en el historial de ejecución de un proceso..

Es decir se implementa con XtremeBPM un proceso basado solamente en las actividades (centrado en actividades), y a medida que se va ejecutando en producción, el BPM determina los flujos (la secuencia de actividades) mas comunes, gráficamente hablando el BPM determina las flechas entre las actividades.

Luego mediante un asistente grafico (Wizard) se fijan los flujos, es decir, se determina cual es el flujo definitivo.

Generador de Roles.

Lo mismo se puede aplicar a los roles, primero se deja la libertad de que cualquier usuario valido del procesos realice la actividad, y después de acuerdo al historial de ejecución se ofrece la lista de personas o roles que ejecutan comúnmente dicha actividad.

Robots para Levantar Sistema Legados.

Las suites BPM (BPMS) podrían incluir robots que permitieran grabar secuencias que permitieran levantar funcionalidades de los sistemas legados, parecidos a los robots para ejecutar test de pruebas. Estos mismos robots deben incluir la capacidad para evaluar el resultado de la funcionalidad (legada), y poder registrar el avance en el flujo BPM.

Manejo de Actividades Estereotipo.

La herramientas BPM deberán contemplar el manejo de las actividades estereotipo, por ejemplo deberían incluirse por defecto en la implementación de cualquier proceso. Y los módulos de seguimiento, control y monitoreo deberían también contemplarlas como actividades tipo, por ejemplo en un grafico de barra (BAM) debería aparecer una barra por cada estereotipo.

Manejo de Asignación de Tareas y Restricciones de Entrada.

Las herramientas BPMS deberán contemplar el manejo por defecto de que en una tarea se pueda asignar la siguiente actividad, y quien la realiza, también se debe manejar las condiciones de entrada, y automáticamente si no se cumplen devolver el flujo al origen (actividad y persona anterior).

Asignación de Roles y Personas Especificas a una Actividad.

Algunas herramientas BPMS de cierta forma lo ofrecen actualmente, que es la posibilidad de asignar roles a una actividad, pero que se puedan ademas incluir y excluir personas especificas, de forma de contemplar los casos excepcionales.

Registered at RegisteredCommons.org

Xtreme BPM
was created by Luis Alberto Espinoza Bustamante
on 2007-11-12.
License: http://creativecommons.org/licenses/by-nc-nd/2.0/cl/ .
Description: Design and Development Principles for BPM and tools definitions

Advertisements

3 thoughts on “Xtreme BPM (Extreme BPM) o Agile BPM 2.0

  1. Interesante el tema que planteas, podrias darme algunas pautas para implementar un BPM Agile? quizás alguna documentación o algún caso de uso? Mi correo es eocardenas@gmail.com

    Like

  2. Hola!

    Muy bueno el artículo. Muy interesante. Estoy finalizando una Tesina de Grado, en la cual analizamos varias herramientas BPM y la verdad es que me interesa mucho el tema. Si tienen mas información sobre esta metodología me harían un gran favor en decirme como puedo acceder a ella, les dejo mi correo facundor@gmail.com

    Saludos!

    Like

  3. Hola muy interesantes esta metodologia, me gustaria ponerme en contacto con el autor, pues me interesa saber si ha logrado ponerla en practica y si puedo encontrar algo mas sobre su aplicacion. mi email es rmaceissoft@yahoo.com.
    gracias de antemano.

    Like

Comments are closed.