domingo, 23 de noviembre de 2008

Manejo de Eventos en Intalio BPM


Uno de los elementos gráficos de la notación BPMN son los eventos. En este ejemplo, podemos ver el comportamiento del motor BPEL, para el manejo de eventos intermedios y timers, elementos fundamentales en la comprensión de BPMN para el modelado de procesos de negocio.

Primero un poco de teoría. Un evento es algo que pasa durante la ejecución de un proceso. Estos eventos afectan el flujo del proceso, y usualmente tienen una causa (disparador o trigger), o un impacto (resultado - result). Los eventos son representados con círculos, sobre diversas marcas que representan diferentes disparadores y resultados. Existen tres tipos de eventos basado en como afectan el flujo del proceso: inicio, intermedio, finalización (start, intermediate, end).

Por ejemplo tenemos un evento timer, donde podemos establecer un período de tiempo (fecha), o un ciclo (por ejemplo, todos los miércoles a las 6am), con el cual podemos condicionar el inicio o disparo de un evento.

Otro tipo de eventos son los intermedios, los cuales son utilizados para condicionar la entrada de un mensaje dentro del flujo. Un evento intermedio, según definición, ocurre entre un evento de inicio (Start Event) y uno de fin (End Event), y afecta el flujo de el proceso, pero no inicia o finaliza el proceso directamente.

Por lo general, los eventos timers, son utilizados en tareas, y generalmente pueden representar una condición de timeout para un Web services, que puede disparar un evento para enviar la solicitud a una cola de mensajeria de excepciones.

En este ejemplo, estamos utilizando un timer, que permite observar el comportamiento de un evento intermedio; en resumen, el proceso de negocio no ejecutara la tarea B, hasta que pasen 2 min. (timer), y se ejecute la tarea C.

sábado, 15 de noviembre de 2008

Proceso y actividades en BPM, una vision pragmatica

Hace unos días, me invitaron a una reunión, en la cual un proveedor muy importante en el área de BPM, realizaba demostraciones sobre un producto para el modelado de procesos de negocio. Quiero compartir con la comunidad algunas apreciaciones y diferencias de opiniones, que considero muy importantes.

La mayoría de las presentaciones sobre BPM disponibles en la red, y los mensajes de proveedores importantes en esta área, se centran en: “el primer paso es el modelado de los procesos”. En primer lugar considero vital, que en los primeros pasos no hablemos de procesos, hablemos de actividades que son ejecutadas por personas.

En la mayoría de las organizaciones, desde un punto de vista pragmático, no existe en el vocabulario de los trabajadores la palabra proceso; la cual inicialmente es percibida como algo complejo; la realidad; las organizaciones están formadas por personas que ejecutan actividades; y en la mayoría de los casos, no se conoce el objetivo estratégico que esta relacionado a su trabajo. La clave es como llevar el trabajo del día a día (actividades) a un proceso, promocionándole una esencia organizacional más formal.

El objetivo de un consultor BPM, es identificar las actividades, responsables, relaciones con otras actividades, participantes, identificar que variables pueden ser medidas, y si están enmarcadas dentro de un objetivo estratégico de la organización, y como estas pueden ser mapeadas en un marco de procesos referencial. Este trabajo, define, forma, y establece el concepto de un proceso, pero no es de el; donde se inicia el trabajo. Este modelo es una aproximación más humana, y pragmática para introducir el concepto de proceso en la organización.

Otro aspecto, es que asumimos que el diseño de los procesos esta basado en un lenguaje natural, por ende; para la organización es muy fácil modelar sus procesos. Esta premisa no es cierta; en realidad no es un lenguaje natural, ya que requiere de un análisis, practicas de modelado, reglas; inclusive si se cuenta con un marco referencial.

Por ultimo, algunos proveedores aseveran que el modelamiento de los procesos de negocio los llevara al camino de SOA; en realidad este camino se inicia con el entendimiento de este estilo de arquitectura en las gerencias responsables de las infraestructuras de hardware y software que sustentas las operaciones de negocio de la organización.

Algunas Recomendaciones
  1. No introducir el término de proceso, en la organización en las primeras fases, si el de actividades.
  2. Cuando el rompecabezas este armado, identificamos un proceso (actividades, participantes, reglas, etc.), y le damos un firma mas formal.
  3. Es imprescindible establecer una buena estrategia para capacitar a las personas en el modelamiento de procesos; recuerde que en realidad no es un lenguaje natural, y requiere del conocimiento de prácticas y reglas.

lunes, 8 de septiembre de 2008

Capitulo II El Diagnostico

El Diagnostico
Una estrategia para crear la necesidad, es impulsar actividades del diagnostico de la documentacion existente de los procesos, actividades, etc.

Sobre la Calidad del Diagnostico
No importa que los datos no sean levantados y recopilados de forma exhaustiva durante las sesiones iniciales, el objetivo es hacer un diagnostico preliminar de la documentación o existencia de procesos, para potenciar la necesidad de implantar soluciones que estandaricen y automaticen toda la definición de los procesos en la organización. Recuerde que el objetivo inicial es identificar la presencia de toda la documentación relacionada con los procesos de cada unidad organizacional, sin hacer análisis de la calidad de los documentos.

Recomendaciones para Diagnostico

La clave para comenzar con un buen diagnostico, es detectar la existencia y utilización de herramientas que son utilizadas regularmente en la organización para documentar los procesos, por ejemplo, word, visio, etc; este análisis potenciara la necesidad de uniformizar o estandarizar las herramientas para documentar los procesos, la necesidad de tener un repositorio único, basado en una norma de modelado como BPMN, que permita simular y proporcionar algunos elementos dinámicos a esa documentación. Este trabajo abrirá un abanico muy amplio de las mejoras que pueden sustentar un cambio organizacional.

Nota: Recuerde, que el objetivo preliminar del diagnostico no es analizar los macro procesos, ni realizar un análisis cualitativo de los mismo.

Areas claves:
  1. Numero de procesos existente por cada unidad organizativa.
  2. Proporción de macro procesos existentes en las unidades.
  3. Evaluar el número de procesos documentados.
  4. Evaluar la existencia de indicadores de gestión para procesos.
  5. Procesos con Indicadores vs. Procesos sin Indicadores.
  6. Proporción de herramientas utilizadas para diagramas (PowerPoint, Visio, docs, pdf, etc.).
Los Resultados del Diagnostico

El diagnostico se convertirá en una herramienta para establecer conclusiones sobre la situación actual de los procesos de la organización, por ejemplo el numero de procesos documentados, la existencia de herramientas para su documentación. Este diagnostico, será el insumo preliminar para detectar procesos repetidos y serán una referencias que luego utilizaremos para asociar los procesos con un modelo referencial, hablaremos mas adelante sobre este marco referencial.

Detectar Áreas de Apoyo

En muchas organizaciones, podrían existir iniciativas orientadas en la mejora continua de procesos, por ende; es importante detectar todas estas iniciativas existentes y utilizarlas como mecanismo de participación para acelerar y potenciar todas las iniciativas. Recuerde: Unificar iniciativas, evitar redundancia, lo mejor no es imponer, sino acordar y avanzar.

La importancia de un Marco de Referencia

Una recomendación importante es utilizar un marco referencial de procesos que pueda ser extendida y adoptada, y responda a todas las necesidades presentes y futuras de la organización, articulando diversos enfoques.

Algunas organizaciones cuentan con marcos de referencia, en el cual se describen las áreas generales o macro procesos, el Comité extendido de procesos, debe acordar un marco de referencia, en el cual puedan ser mapeados todos los procesos actuales de la organización.

El marco de referencia responde a preguntas como cual es el modelo que queremos? se equilibra con la realidad existente en la corporación?, estamos todos referenciados ahí?

Los marcos de referencia contribuyen con la formalización de los procesos de la organización, y es el punto de partida para soluciones como cuadro de mandos par medir las áreas claves de procesos y los acuerdos de servicios.

El Marco Referencial y el ajuste.

Los marcos de referencia, deben especificar todos los macro procesos actuales de la organización y futuros, e incluir características y necesidades particulares, para ajustarla. Esto es responsabilidad del Comité Extendido de Procesos.

Se pueden presentar escenarios, donde algunas unidades organizaciones ya cuenten con un marco referencial propio, el cual puede ser extendido o actualizados según las necesidades de toda la organización, la clave: todos deben verse reflejados.

Un ejemplo particular es NGOSS, que es un marco referencia para empresas de telecomunicaciones, el cual puede ser extendido o modificado acorde con las características y necesidades de la organización.

jueves, 3 de julio de 2008

Seminario de Intalio BPMS en Costa Rica Presentaciones Intalio

Introduccion a Intalio BPMS



Algunas Demostraciones



Saludos;

Seminario de Intalio BPMS en Costa Rica Presentaciones

Hola a todos, lo prometido es deuda... Estas son las presentacion que utilice para los seminarios.

SOA y ESB, la combinacion perfecta


Arquitectura de un ESB Gobierno



Introduccion a Mule ESB



Introduccion a la Gestion de Procesos de Negocio (BPM)



Saludos;

miércoles, 2 de julio de 2008

Seminario de Intalio BPMS en Costa Rica

Hace poco tuve la oportunidad de ir a la Universidad Nacional de Costa Rica a impartir dos seminarios "SOA y ESB" y "BPM utilizando Intalio BPMS", donde aborde diversos temas de arquitectura empresarial y gestión de procesos de negocio utilizando las alternativas Open Source y de software libre: Mule ESB, ActiveMQ, e Intalio BPMS.

Quiero agradecer la hospitalidad que los tico me brindaron durante mi estadía; a Xenia y Dinia por toda la colaboración prestada, y al Sr. Francisco por su visión y capacidad de vigilia en el tema de nuevas tecnologías. La UNA (Universidad Nacional de Costa Rica), tiene un programa de especialización en el área de las tecnologías de información y la gestión de proyectos (PMI) llamada Progestic. Progestic esta planeando incorporar la Gestión de Procesos de Negocio (BPM) como un elemento dentro de su plan integral de capacidades, para convertirse en una guía en Centro América.

Ha sido una experiencia invaluable, donde he podido compartir con la comunidad estudiantil, empresarial y de gobierno; la importancia de incluir SOA, ESB y BPM como estrategia para utilizar las tecnologías de información y comunicaciones de forma efectiva y con una orientación clara en la gestión de procesos de negocio y todas las disciplinas que lo comprende; por supuesto utilizando software libre y open source.

Anexo para toda la comunidad las areas que comprenden estos dos seminarios, para que conoscan los temas y las relaciones existentes; pronto colocare las presentaciones.

Introducción a las Arquitecturas Orientadas en Servicios (SOA) y Bus de Servicios Empresariales (ESB).
  • Arquitectura Orientadas en Servicios
    • Definición de SOA?
    • Beneficios de SOA.
    • El Reuso y el ROI.
    • Estándares y Especificaciones disponibles.
      • WS-I, OASIS, W3C
      • Xml, Xml Schemas, WSDL, SOAP, UDDI, etc.
      • Estándares WS-*
      • Análisis y diseño orientado en servicios.
    • Análisis y diseño orientado en servicios.
    • Interfase vs. Contrato.
    • Principios de orientación en servicios.
    • SOA y Web Services.
    • Alternativas de Implementación.
    • Arquitecturas SOA.
    • Metodologías disponibles.
    • Mejores Prácticas.
  • Modelo de Implementación para la construcción de Web Services.
    • Apache Axis 2.
    • Xfire (CXF).
    • Spring Web Services.
    • Utilitarios (SoapUI, Jmeter).
  • Demostración A
    • Creación de un Web Services (Servicio Web).
    • Consumo de un Web Services.
    • Generación de Proxys mediante WSDL.
    • Herramientas SOA Open Source.
  • Bus de Servicios Empresariales
    • Que es un ESB?
    • Beneficios de un ESB.
    • Funciones de un ESB.
    • Alternativas ESB Propietarias vs. Open Source.
    • Introducción a Mule ESB
      • Arquitectura de Mule ESB.
      • Componentes de Mule: Conectores, Transformadores, Interceptores, Router, endpoint, inbound-router, outbound-router, etc.
      • Integración de Mule ESB con Spring y ActiveMQ.
      • Mejores Prácticas.
  • Demostración B
    • Ejecutar el ejemplo Echo.
    • Exponer un UMO como servicio (Axis, Xfire).
    • Consumir un Web services.
    • Integración de Mule ESB con Intalio BPMS.
    • Integración de Mule ESB con ActiveMQ.
  • Patrones de Integración Empresarial.

Introducción a la Gestión de Procesos de Negocio (BPM) y la alternativa Open Source Intalio BPMS.

  • Introducción a Business Process Management (BPM)
    • Definición de BPM.
    • Objetivos de BPM.
    • Disciplinas Relacionadas (BPMN, BPEL, BAM, BRE, SOA, Web Services).
    • Conceptos Básicos (proceso, participante, notación, etc.).
    • Ciclo de Vida de un proceso de negocio (Modelado, diseño, despliegue, ejecución, optimización).
    • Orquestación de Procesos e interacciones.
  • Introducción a BPMN (Business Process Modeling Notation).
    • Notación BPMN.
    • Reglas generales de la notación BPMN.
    • Modelado de procesos de negocio con BPMN.
    • BPMN vs. Workflow.
    • Recomendaciones y Mejores Prácticas de Modelado.
  • Demostración A
    • Modelado de Procesos con BPMN.
    • Reglas Generales de Modelado.
  • Introducción a BPEL (Business Process Execution Language).
    • Componentes BPEL.
  • Introducción a BAM (Business Activity Monitoring).
    • Objetivos de BAM.
    • Que son los KPI (Key Performance Indicator).
    • Funcionalidades de un Dashboard.
  • Introducción a Introducción a BRE (Business Rules Engine).
    • Gestión de Reglas de Negocio.
  • Demostración B
    • Utilización de Reglas de Negocio en Web Services.
    • Ejemplo de BAM.
  • Alternativa BPM: Intalio BPMS.
    • Arquitectura y estandares de Intalio BPMS (BPMN, BPEL, BPEL4People, Wsdl, Xforms).
    • Productos y Modelo de Suscripción.
    • Introducción a Intalio BPMS.
    • Intalio BPMN Modeler.
    • Intalio BPMS People Workflow.
    • Intalio BPMS BPEL.
    • Intalio BPMS Mapper.
    • Intalio BPMS Server.
    • Partners de Negocio.
      • Liferay (http://www.liferay.com).
      • Alfresco (http://www.alfresco.com/).
      • Apache (http://www.apache.org/)
      • Eclipse (http://www.eclipse.org/)
      • OpenLexicon (http://www.openlexicon.org/)
      • Orbeon (http://www.orbeon.com/)
  • Demostración C
    • Componentes de Intalio BPMS Designer.
    • Intalio BPMN 1.1 Modeler.
    • Modelado de Procesos con Intalio BPMN.
    • Recomendaciones de modelado (n1, n2, n3).
  • Intalio BPMS y Web Services.
    • Reglas Generales de Construcción.
    • Mejores Prácticas.
  • Demostración D
    • Consumo de Web Services con Intalio.
    • Orquestación de Servicios con Intalio.
    • Workflow con Intalio.
    • Patrones de Workflow
    • Creación de Formularios (Xform).
    • Manejo de Roles.
    • Integración Web Services con Workflow.
    • Despliegue de Procesos de Negocio.
Algunas fotos:





Saludos;

lunes, 19 de mayo de 2008

Capitulo I: La organización y la estrategia

Desde hace algunos meses, he estado escribiendo mis apreciaciones sobre el proceso necesario para implantar las diversas disciplinas que comprenden BPM. Mi objetivo es lograr escribir un libro con las mejores practicas. Estas son mis primeras notas.

Capitulo I: La organización y la estrategia

Para asegurar la diseminación de la gestión de procesos de negocio en la organización, es vital desarrollar un conjunto de estrategias que minimicen la resistencia al cambio y maximicen las posibilidades de éxito de su inserción en la cultura organizacional.

Una de las estrategias que debe ser considerada es la creación de un comité extendido de procesos que represente y contenga el conocimiento de todos los procesos de la organización, el cual estará conformado por expertos en cada una de las áreas operativas. La facilitación dentro de este comité debe sustentarse sobre la proposición y la toma de decisiones concertadas y la creación de equipos más que grupos de trabajo.

Antes de comenzar un proyectos BPM es importante considerar:
  1. Creación de un Comité Extendido de Procesos.
  2. Realizar un diagnostico Preliminar del estado de la documentación de procesos.
  3. Establecer un Marco de Referencia Organizacional.
  4. Establecer un Marco de Arquitectura Tecnológica.
  5. Evaluación y Selección de las herramientas para implantar BPM en la Organización.
Comité Extendido de Procesos

El comité extendido de procesos es el motor de todas las iniciativas para crear y acelerar el cambio de la organización. El objetivo del comité es desarrollar discusiones, puntos de vistas, enfoques, opiniones diversas, y establecer conclusiones y recomendaciones concretas sobre la situación actual y futura de los procesos.

El comité tiene una amplia variedad de objetivos, pero los principales son:
  1. Establecer el Marco de Procesos Referencial de la Organización.
  2. Evaluar y Seleccionar un Marco de Arquitectura Tecnológica que implemente los requerimientos mínimos para la Gestión de Procesos de Negocio.
Equipo vs. Grupo de trabajo.

Una recomendación que consideramos importante es utilizar dentro del comité extendido de procesos, facilitadotes que contribuyan en convertir el grupo de trabajo, en un equipo donde los objetivos se encuentren alineados. Es necesario incentivar los mecanismos para mejorar las ideas y planteamientos exhaustivos y el dinamismo propositito.

Propuesto no impuesto

Una estrategia es contribuir con propuestas y no la imposición de modelos de trabajo, la discusión y la toma de decisiones debe ser concertada, y debe convertirse en la piedra angular de todo el proceso.

Quien es el dueño del proceso

Es importante comprender que cada unidad será la responsable de establecer sus procesos de negocio, dentro de su visión organizacional.

Las Responsabilidades de las Unidades

Estratégicamente, es vital establecer cuales son las responsabilidades de cada una de las unidades dentro del proyecto de implantación de BPS en la organización.

Recomendaciones:
  1. Cada unidad de negocio es dueña de sus procesos.
  2. Cada unidad de negocio debe documentar y modelar sus procesos.
  3. Cada unidad de negocio debe conocer sus indicadores de gestión.
  4. Cada unidad debe establecer sus macro procesos.
  5. Los Macro procesos deben ser mapeados en un Marco Referencial Corporativo.
El Diagnostico Preliminar

Las organizaciones cuentan con procesos para desempeñarse en sus áreas de negocio; una buena práctica es armar un diagnostico general de las condiciones generales de los procesos presentes: documentación, diagramación, normas y procedimientos, herramientas, etc.

Ver la proporción existente entre las herramientas utilizadas para documentar los procesos, su diagramación, la existencia de manuales de normas y procedimientos, cualquier documentación asociada a los procesos, herramientas mas utilizadas, la presencia de indicadores para los procesos, etc.

Cada representante del Comité Extendido de Procesos, deberá proveer la información de sus procesos actuales para diagnosticar su situación.

El Diagnostico Preliminar Como impulsor de Cambios

Desarrollar esta actividad, contribuirá con establecer y fortalecer la necesidad de impulsar los cambios necesarios para uniformizar las herramientas para documentar los procesos, y estandarizar todo el trabajo relacionado en todas las unidades o gerencias de la organización.

sábado, 3 de mayo de 2008

Como introducir BPM en la organizacion con Intalio BPM

Actualmente existen diversas alternativas tecnológicas disponibles en el mercado en el área de GPN/BPM; basadas en Software Libre y Open Source; productos que implementan las disciplinas de Gestión de procesos de negocios (GPN) / Business Process Management (BPM).

Hace 6 meses, inicie un trabajo de evaluación, selección y ejecución de pruebas de concepto, para potenciar una plataforma de servicios que existía, y contribuir con las lineas estrategicas existentes del estado y la organizacion. Se selecciono “Intalio BPM”, como herramienta. Se realizaron dos pruebas de concepto para conocer las capacidades iniciales de Intalio para implementar procesos de negocio de larga vida, utilizado la infraestructura de servicios actual, que provee una plataforma de integración.

En lineas generales, intalio ofrece un modelo ágil para el despliegue de procesos de negocio, donde podemos integrar dos tipos de actividades : Automáticas y humanas. Procesos como la consulta de un servicio de información, notificacion y la aprobacion de un tareas establecen el marco inicial para unir ambos mundos.

Las organizaciones que desean introducir estos conceptos tecnologicos, por lo general ya cuentan con una plataforma de servicios, con la cual pueden introducir una nueva capa : Orquestación de Servicio y procesos de negocio. Para implementar estas disciplinas la organizacion debe contar con una base tecnológica sustentada sobre SOA y ESB.

Que funciones pueden ser evaluadas en un piloto?
  1. Consumo de Servicios Web (Web Services).
  2. Flujos de Trabajo (Workflows) de Aprobación, Rechazo y notificación.
  3. Utilización de varios participantes (CDC, Operaciones, Ventas).
  4. Proceso de negocio iniciado desde una interfase Web.
  5. Proceso de negocio expuesto mediante un Web Services.
  6. Aplicar Reglas de negocio.
Estas son algunas recomendaciones para iniciar un proyecto con Intalio BPM.

1.- Utilizar un diagrama Base para probar el consumo de servicios Web con Intalio BPM.
2.- Utilizar broker de condiciones, e implementarlos sobre servicios.

3.- Integrar Web Services con brokers de condiciones.

4.- Utilizar BPMN para modelar un proceso.

Saludos.

miércoles, 13 de febrero de 2008

Workflow y Web Services a la lista.

Un aspecto importante en la utilizacion de BPM mediante intalio, es su capacidad para unir los conceptos de Web Services y Workflow en un procesos de negocio. En este ejemplo podemos ver como se introducen ambos conceptos para una empresa de telecomunicaciones que vende productos diversos a sus clientes. Este proceso tiene la resposabilidad de notificar a diversas unidades, la aprobacion o rechazo de la solicitud de un nuevo producto para un cliente, y la configuracion de sus servicios.

En este ejemplo, tenemos dos web services que son invocados por el proceso de negocio, y la participacion de 2 actores, uno para notificacion y el otro para aprobacion.