Inteligencia de Negocio: Parte I

   Saludos lector! En esta ocasión quiero hablarte un poco sobre Inteligencia de Negocios. Te estarás preguntando ¿Con qué se come eso?. Pues la Inteligencia de Negocios consiste en analizar la información proveniente de los niveles operacionales de tu empresa, permitiendo saber cuáles son las mejores tácticas a implementar para que sigas creciendo en el mercado. ¿Suena interesante?

  La inteligencia de negocios yace en los últimos niveles de la pirámide que mencionamos en ocasiones anteriores. Si la recuerdas, era algo así:

   Siendo el nivel Operacional, aquel donde capturamos y registramos operaciones (transacciones) que posteriormente, en los últimos dos niveles, se contabillizarán y evaluarán para la toma de decisiones.

  SISTEMAS DE APOYO A LA TOMA DE DECISIONES: Este nivel se basa en el análisis de grandes cantidades de datos, por lo que necesitamos contar con una herramienta un poco más adaptada a este tipo de trabajo. Dicha herramienta será el esquema o modelo estrella, el cual es el As bajo la manga para obtener acceso a la información de manera rápida y sencilla. Todo esto será posible gracias a OLAP.

  Se entiende por OLAP un motor de Base de Datos que nos permite hacer consultas a grandes cantidades de registros sin pasar por lo engorroso de hacer un Query en SQL. De hecho OLAP, no usa SQL, ya que es muy diferente al esquema relacional; el cual se usa más que todo en el nivel operacional, donde se conoce como OLTP  (bases de datos transaccionales que por lo general se encuentran en 3FN ).

  Un ejemplo de como trabaja este tipo de sistemas:
        La gerente Mariet pertenece al grupo ejecutivo de una empresa de ventas de telas, que desea saber la cantidad de ventas de una cierta tela a nivel nacional durante el último mes. Este tipo de problema, podría resolverse con un query al modelo OLTP, sin embargo, Mariet desea filtrar esa información tomando en cuenta varios aspectos, por lo que armar un query diferente para cada análisis, puede hacerse muy engorroso y lento. Nuestra ejecutiva necesita entonces un modelo estrella, que no es más que una base de datos que consta de dos tipos de tablas escenciales: Tabla de Hechos y Tablas Dimensiones.

Las Tablas de Hechos son aquellas que modelan el proceso de negocio (en el ejemplo: Ventas).

Las Tablas Dimensiones son aquellas que contienen los aspectos a evaluar del proceso de negocio  (en el ejemplo: Estado y Mes). Estas tablas a su vez, se pueden jerarquizar (por ejemplo, tener en "Tiempo" las divisiones: día, mes y año) para permitir varios niveles de análisis.

   Este esquema se construirá dejando la tabla de hechos como la tabla central y las dimensiones están unidas  a ella formando una especie de estrella.

   Hacer esta transformación del modelo OLTP a OLAP, se conoce como ETL y no es un proceso trivial, lo trataremos con más detalle en futuros post, por el momento la idea es hacer contraste y ejemplificar por qué se usa este tipo de esquema en lugar del relacional.

  La respuesta al planteamiento anterior, es que el esquema relacional viene dado por lo general en 3ra forma normal, lo que quiere decir, que para poder relacionar las tablas entre ellas, hay que recurrir a una cantidad exagerada de "JOINS", esto en aspectos de tiempo de respuesta, será muy lento. Por otro lado, si usamos el esquema estrella, nuestra BD podrá realizar las consultas haciendo un máximo de 1 JOIN, puesto que todas las tablas están directamente relacionadas a través de la tabla central, reduciendo de manera considerable los tiempos de ejecución y permitiendo además hacer de manera sencilla consultas que en SQL serían engorrosas.

   Otra ventaja es que teniendo las dimensiones, si se deseara obtener las ventas a nivel nacional de los útlimos 2 años, bastaría con usar en la tabla dimensión tiempo, sin tener que rehacer todo el trabajo de transformación Relacional-Estrella (conocido como ETL).

   Estas caracterísiticas permitirán a Mariet y  a su comité analizar las ventas como lo deseen sin mucha acesoría.

  SISTEMA PARA EJECUTIVOS: Queda entonces, la otra cara de la moneda (donde está Mariet), los sistemas para ejecutivos, que se basan en el modelo OLAP ya creado en el nivel de soporte a la toma de decisiones, generan los reportes con la data y formato que deseen los ejecutivos para finalmente tomar las decisiones. 

¿Cómo manipulan el modelo OLAP?

      Los ejecutivos utilizan otro esquema, conocido como cubo OLAP o MOLAP, que no es más que una base de datos, que contiene toda la información sobre el OLAP, organizada bajo un esquema xml el cual será intepretado por la herramienta de análisis para extraer data de la BD OLAP ya creada.

  Mencionamos entonces 3 conceptos nuevos, que son conocidos como la arquitectura de la inteligencia de negocios. OLTP, OLAP y CUBOS a continuación un gráfico que representa todo lo antes expuesto.

 Repaso y acotaciones finales:

     Tenemos una data origen (por lo general una base de datos en 3FN OLTP) que puede ser de cualquier tipo. Al aplicarle ETL, la transformamos en un modelo estrella, el cual se almacena en un repositorio diferente, llamado Data Warehouse (cada modelo estrella se conoce como  Data Mart)  que es manejado por un motor OLAP. Una vez hecho todo esto, tenemos la implementación de otro esquema que manipulará la data almacenada en el Data Warehouse, se conoce generalmente con el nombre de cubo, cada una de las 3 etapas coincide con un nivel de la pirámide.

OLTP - Transaccional.
OLAP - Soporte de Decisiones.
CUBO - Ejecutivos.

  Los 3 en conjunto,  conforman la arquitectura de Inteligencia de Negocio.

Tiempo Invertido en realizar este post:

aprox 3 horas.
Dedicado al primer seguidor que tuvo este blog.

"Nadie puede impedirte más progresar que tu mismo..."

Referencias consultadas:

http://www.slideshare.net/wilfredorangel/inteligencia-de-negocio-introduccin

http://www.slideshare.net/wilfredorangel/inteligencia-de-negocio-soluciones-analticas

http://www.slideshare.net/wilfredorangel/inteligencia-de-negocio-arquitecturas-de-soluciones-analticas

http://www.slideshare.net/wilfredorangel/inteligencia-de-negocio-modelos-dimensionales-y-esquemas-estrellas

Punto de vista personal. Tabla de Hechos vs Tabla de Dimensiones

Saludos querido lector, continuando con la línea que plantee en el último post, en esta ocasión quiero exponer la diferencia que hay desde mi punto de vista, entre dos conceptos claves de este último nivel de la pirámide. Cómo ya mencioné en el último post, partiremos de la 3FN para armar el esquema de BD con el cual trabajaremos, esto con el fin de optimizar el tiempo de respuesta de la BD ante consultas que requieren los altos cargos para sus análisis.

El objetivo de este esquema es apoyar la toma de decisiones, por esa razón debe manipular toda la información referente a los procesos de negocio de la compañía que se ha registrado en el nivel operacional, ya sea por regiones, fechas, productos, entre otros atributos que puedan servir de parámetro para un análisis de desempeño.

El proceso de negocio en cuestión estará en la que llamamos tabla de hechos, y los parámetros que se usan para evaluar estarán en lo que se conoce como tablas dimensiones. Las dimensiones agrupan toda la información necesaria en una sola tabla de modo que al hacer una consulta, la cantidad de "Joins" a hacer sea solo uno. Por otro lado, en la tabla de hechos tendremos todos los registros relacionados al proceso que estamos analizando. He aquí una primera diferencia entre estas dos tablas: La información que guardan.

La segunda diferencia que veo, es que las tablas dimensiones pocas veces cambiarán, es decir si tu tabla tiempo está programada para almacenar los 5 años anteriores, el actual y los 5 años siguientes, tendrás suficientes registros como para no actualizar esa tabla durante un buen tiempo, por lo menos 5 años. por otro lado, la tabla de hechos, que es la qe refleja el proceso de negocio, si cambiará constantemente, por qué? pues una compañía crecer lo más que pueda, tener un buen mercado, entre otros objetivos. Siendo así, los procesos de negocios cada vez deberían tener más registros, si por ejemplo alcanzas 500 ventas en un mes, al siguiente querrás tener 600 o más y eso significa 100 o más registros nuevos que tomar en cuenta, por esta razón, se dice que las tablas de hechos están pensadas para crecer mucho y actualizarse constantemente, mientras que las tablas de dimensiones se piensan como que no cambiarán constantemente. He allí la segunda diferencia.

En conclusión, existen dos diferencias a mi parecer, la priemra, el tipo de información que contiene cada tabla y la segunda es la frecuencia con la cual se actulizarán estas tablas.

Es todo por ahora, me despido :)

Importancia de la 3FN (tercera forma normal)

Saludos lector, estamos ahora entrando al último bloque de la materia de Sistemas de Información, en el cual trabajaremos con el último nivel de la pirámide de los sistemas. En este nivel vamos a tomar las decisiones que forman parte de la estrategia del negocio. Necesitaremos manejar grandes cantidades de datos en le menor tempo posible, para ello nuestra base de datos debe estar bien diseñada. En este artículo introductorio mencionaré brevemente la  importancia de la tercera forma normal para nosotros en este nivel.

La tercera forma normal:
-Elimina las dependencias transitivas entre atributos no claves de las tablas en la BD.
-Elimina por completo cualquier tipo de reduncia que haya en la BD.

Cuál es su importancia?
  Por lo antes visto, vemos que con la 3era forma normal, obtenemos un diseño  correcto de la BD, y auque aún puede mejorarse, en este nivel, la base de datos es lo suficientemente adaptable a las necesidades de las aplicaciones. En este nivel las tablas presentan una estructura relacional que nos permite manipular la data de manera sencilla ya que cada campo esta relacionado solo a una clave primaria, con lo cual el insertar o eliminar un registro no pone en riesgo la integridad de la base de datos. Este modelo nos permitirá además tener una base para la herramienta que usaremos en el último nivel (OLAP) la cual mencionaré en otro post.

En resumen, la 3FN es una manera elegante y muy sencilla de manejar, además de lo segura que es en cuanto al manejo de datos, nos servirá de base para lo que deseamos hacer en este nivel. No se usa directamente, porque este nivel requiere bases de datos que estén organizadas de manera jerárquica y no relacional, sin embargo, con la 3FN podemos partir para crear ese modelo, en otro post profundizaré más en esos tópicos, hasta una próxima :)

BPMS: Del diseño (BPMN) a la ejecución (BPEL)

Saludos lector! En esta ocasión continuaremos modelando otro tipo de ejercicios en Intalio antes de pasar a la creación de formularios.

Hasta ahora hemos visto que para modelar necesitamos.
-Analizar el problema. Ver cuáles son los participantes involucrados en el proceso de negocio y luego plantear un flujo de trabajo analizando cuáles elementos del modelado BPMN funcionan mejor para nuestros propósitos.
-Modelar cada participante visualizando qué acciones debe realizar y no asignarle más de las que les corresponden.

En esta ocasión,  te propongo ejercicios con un poco más de interacción y por tanto un poco más difíciles de modelar. No te asustes! con paciencia todo se logra. Manos a la obra entonces....

El primer proceso a modelar es el de lámina 5 de la siguiente presentación.
Podrás encontrar la solución en la misma presentación.
http://www.slideshare.net/wilfredorangel/procesos-ejecutablesparte-i

Te planteo el siguiente análisis:
Los participantes: Tenemos un empleado que es quien envía la información para ser procesada, y tenemos un gerente que es quién procesa la información y se encarga de aprobarla o no. Es todo? No, estamos olvidando un participante importante, fíjate que en el enunciado te dicen que "algo" recibe la solicitud del empleado y se la envía al gerente, y es ese mismo "algo" quien luego comprueba si fue aceptada o rechazada para informarle al empleado lo que debe hacer, y si se da el caso, también al gerente. Ese "algo" es un participante más, y es el más importante,  porque es nuestro sistema. Yo lo llamaré "Revisión" también puede llamarse Proceso de Revisión, Revisión de Información, etc, lo dejo a tu criterio :)
Piensa tú cuáles carriles deben ser ejecutables y cuales no.

El flujo:  Bueno inicialmente, el empleado debe enviar la información, allí se puede colocar una actividad de inicio, o puedes colocar un evento de inicio seguido de una actividad llamada "envío de información" esto tratando de que sea lo más sencillo de entender posible. Ese envío lo recibe nuestro participante "Revisión" quién se lo debe enviar al participante gerente. El gerente debe recibir la información, procesarla y enviar una respuesta. El gerente podría terminar luego de esta acción, pero ojo, el enunciado dice, que si es rechazada, el gerente debe esperar una confirmación de que la información fue corregida por el empleado, Te sugiero entonces que el siguiente paso en tu proceso gerente, sea una compuerta exclusiva, donde puedas controlar el recibir o no el mensaje, luego de eso, puedes terminar el proceso (No olvides sincronizar las compuertas, es decir, toda compuerta que abras la debes cerrar con su homóloga). Volviendo al lado del proceso "Revisión" este debe recibir la respuesta del gerente y tomar una decisión, si resulta ser aprobada envía un mensaje al empleado y finaliza, sino debe decirle al empleado que corrija, luego recibir la corrección y enviar una notificación al gerente. Por último está el empleado, quién luego de enviar. no sabe que respuesta recibirá por parte del gerente, así que puedes usar una compuerta de carrera para simular esta acción.

Ahora a modelar!

Antes de ver la solución, intenta hacer el ejercicio, recuerda que nadie hace músculos viendo a los demás haciendo ejercicio...

Aquí te dejo:
Mi propuesta de solución.


El segundo proceso a modelar lo puedes conseguir en la lámina 92 de la siguiente presentación:
También podrás encontrar la solución dentro de la misma presentación.
http://www.slideshare.net/wilfredorangel/introduccin-a-bpmn-12335494

Te planteo el siguiente análisis:
Este es mucho más complejo, e incluye el uso de elementos de modelado que hasta el momento no habíamos usado.
Los participantes: Primero tratemos de identificar el proceso. Puesto que es un sistema que busca aprobación de fondos, éste será nuestro participante principal. Además tenemos el proceso empleado que es quien hace la solicitud de aprobación de fondos, y un gerente que debe aprobar o rechazar. Por otro lado, se nos menciona un jefe de área (puedes llamar a este participante departamento contable o contabilidad, si deseas abreviar) y un departamento de finanzas. Serían entonces, 5 participantes (wow).

flujo de eventos: El evento de inicio es la solicitud que recibe el sistema del empleado, seguidamente el sistema envía la solicitud al gerente quien decide si aprueba o rechaza. Esta respuesta es recibida por el sistema (proceso principal) quien debe ver si fue aprobada o rechazada. Si fue rechazada, debe solicitar de nuevo la información  al cliente, para simular esto, el sistema puede tener subproceso cíclico que se ejecute hasta que la solicitud del empleado sea aprobada. Por otro lado, si es aprobada, debemos solicitar información contable al jefe del área o departamento contable y una revisión al departamento de finanzas. Con la respuesta del departamento de finanzas debemos decidir si volvemos a solicitar la información al empleado, volvemos a solicitar información contable o si completamos el proceso, esta actividad también es un subproceso cíclico. Este ejercicio en particular me resultó difícil modelarlo pero no te rindas! si se puede! recuerda que no hay soluciones únicas, puede que tu lo veas de otra forma mucho más sencilla, realmente no podremos saber si nuestros modelos funcionan o no hasta completar el proceso y hacerlo ejecutable.

Mi propuesta de solución.

En una próxima ocasión veremos como hacer ejecutables todos nuestros modelos para saber si cumplen o no con las características que deseamos automatizar del proceso. Lo lograremos mediante el uso de BPEL, un lenguaje interpretable por servidores para permitir la ejecución de nuestro modelo.

Por el momento es todo, hasta una próxima! que estés bien :)

Resumen Clase # 5 : Procesos Ejecutables I

Saludos lector, en los últimos post de éste blog, he estado tratando el tema de BPM, que es el proceso de modelado y automatización de procesos de negocio de una empresa, para mejorar su eficiencia y hacerla más adaptable a cambios. Este tipo de efecto se logra porque se flexibilizan los procesos.

¿Cómo flexibilizar procesos?

    Los procesos se pueden flexibilizar, administrando las tareas de la empresa. Esto quiere decir que debemos darles un objetivo útil, y una táctica de ejecución acorde a dicho objetivo. Hacer esto, permite llegar a un mejor entendimiento de estructura y funcionamiento del proceso, permitiendo determinar el cómo actuar ante cualquier situación que pueda presentarse, esto se conoce como tolerancia a cambios, i.e. flexibilidad.

    Después de este pequeño resumen, puedo empezar el tema de hoy. Te habrás preguntado cuál es la relación entre BPM y ERP? por qué hicimos un salto tan brusco en la linea que veníamos tratando desde el resumen # 1. La verdad yo tampoco lo entendía, hasta que en clase se aclaró este punto y ahora quiero compartir la respuesta contigo. Verás, ERP nos permite unificar elementos dentro de la misma empresa, pero con BPM podemos lograr una interacción con elementos que no pertenezcan a nuestro mismo entorno, puesto que se nos presenta una estructura de sistema orientado a la comunicación entre entes, recuerda que un ente no es solo una persona (cliente), puede ser también otro sistema o proceso, por eso, podemos decir que BPM puede conectar ERP's. He allí su relación.

   En esta ocasión, corresponde dar una introducción a procesos ejecutables. Hasta ahora hemos visto como BPMN nos permite modelar un proceso de negocio a través de los diversos eventos, compuertas y actividades que tiene, pero si queremos automatizar un proceso necesitamos más que un modelo. Procesos ejecutables se refiere a la parte práctica de BPMN, dónde los modelos son convertidos en un lenguaje que puede ser ejecutado por un servidor (sistema) para llevar a cabo el proceso de forma automática.

  Este nivel se enfoca más en el funcionamiento del proceso que en el modelado del mismo, esto no quiere decir que nos olvidamos de BPMN, sino que el modelo que se hace en este nivel, es muy básico, porque se busca primero que el proceso realice su tarea de manera correcta. Una vez logrado esto, del modelo básico, se genera el modelo detallado.

   Las interacciones que habrá en el sistema entre los participantes, se darán a través de documentos, por el momento estudiaremos el más básico: Los formularios.

   Los formularios permiten hacer solicitudes, realizar notificaciones, entre otras cosas, más adelante, en otro resumen veremos como usarlos en Intalio, para hacer dinámicos los modelos que hasta el momento hemos dejado como simples imágenes exportadas. Existen 3 tipos básicos de formularios, Intalio tiene un motor que se encarga de hacer el trasporte de formularios entre los diversos componentes del sistema y una vez que entrega el formulario al destino, envía una confirmación al remitente. Este motor se llama ODE, y maneja las variables request y response de cada formulario (sólo la variable request tiene valor, la response es vacía).

INIT:  Los formularios que inician un proceso, normalmente son enviados por personas, ya que corresponden a solicitudes realizadas a otro componente del sistema. Cuando este formulario se crea se crean las variables InitProcessRequestMsg y InitProcessResponseMsg. Este tipo de formulario es editable.

CREATE-COMPLETE : Es un formulario que no se completa en el ente o actividad donde es creado, sino en otro diferente. Es el tipo de formulario donde el cliente rellena una parte y el gerente llena otra por ejemplo. Genera las variables: CreateTaskRequestMsg y CreateTaskResponseMsg. Este formulario es también editable.

NOTIFY: Es el tipo de formulario que solo se usa para notificar de un participante a otro, no es editable, y genera las variables NotifyRequestMsg y NotifyResponseMsg.
  
  En otra oportunidad, te enseñaré a crearlos en Intalio para ir logrando poco a poco automatizar tus procesos. Hasta la Próxima!


Fuentes:
-Apuntes de la clase.
-Láminas de la clase, disponibles en: http://www.slideshare.net/wilfredorangel/procesos-ejecutablesparte-i


Duración de la actividad: 1h. 29min. (lectura del material y redacción)
Hora inicio: 7:17pm 21/04/2012
Hora fin: 8:46pm 21/04/2012

Laboratorio # 5 Modelación en Intalio.

 Un saludo cordial querido lector, a continuación te daré a conocer los primeros pasos que debes seguir para modelar un BPM en la herramienta Intalio. Pero te preguntará, cómo modelar sino conozco el lenguaje? A continuación una serie de tips básicos para que inicies con el pie derecho.

BPMN es un lenguaje que nos permite modelar procesos, usando ciertos elementos. hay básicamente 3 cosas que podemos modelar:

Eventos:
Marcan la ocurrencia de un suceso, los eventos pueden o no ocurrir durante la ejecución del proceso.

observa el siguiente cuadro, en él encontrarás los tipos básicos de eventos que podemos tener.

No es necesario que entiendas todos, con los ejemplos espero ilustrarte mejor el cómo se usan.

Actividades.
Son tareas que realiza el proceso y que posteriormente desencadenan eventos.
Se representan mediante un rectángulo, y si a su vez, conformadas por otras tareas, se les llama tareas compuestas.

Compuerta.
Permiten controlar el flujo de trabajo, ya sea para ejecutar tareas u eventos en paralelo, o para determinar el comportamiento del proceso bajo ciertas circunstancias (condicionales). en la siguiente tabla los tipos:

el de XOR y COMPLEX no serán usados por los momentos, este tipo de condicionales están orientados a data. el tipo de condicional orientado a eventos, que sirve para modelar carreras es el siguiente:

 

Exclusiva Basada en Eventos.






Esto es solo una breve introducción. Ahora vamos a pasar a la parte práctica.

Haremos juntos un ejercicio y luego te dejaré dos ejemplos, para que intentes implementarlos por tu cuenta, y la solución para que compares con lo que hiciste.

Ejercicio.
Nuestros productos están listos para ser enviados.para determinar qué compañía de envío utilizar, enviamos 3 mensajes separados a cada una pidiéndole que despachen nuestros productos. la primera compañía que responda a esta solicitud, será la escogida.

Paso1.
Análisis del problema:
Primero que todo debemos identificar los participantes, que son todos aquellos que intervienen en el proceso de negocio de alguna forma. En este caso:
-Nuestra Empresa: Que es la que desea hacer el envío.
-Compañía de Envío: A la cual se le hace la solicitud para ver si puede o no hacer el envio. Hay 3.
En el proceso de modelado BPMN, los participantes se representan con carriles (pool). Existen dos tipos:
-Ejecutables: Se dice que es el sistema, el pool que realiza el proceso de negocio como tal.
-No Ejecutable: Todo aquel que colabora de manera indirecta en el proceso de negocio.
Lo siguiente que debemos hacer es identifcar el proceso de negocio. Este proceso de negocio es el de concretar envío, por decirlo de alguna forma. Es aquel que realiza la empresa para decidir por cual medio distribuir sus productos, noten que no se nos dice que se envían, solo se desea saber quién será el que realice el envío. Por todo esto, el pool ejecutable es la empresa, y los no ejecutables son las compañías de envío.

Paso2.
El modelado:
Una vez tenemos identificados nuestros participantes, lo que debemos hacer es identificar que eventos usaremos para modelar nuestra situación. Primeramente, tenemos el evento de que los productos están terminados, podemos representarlo con un evento o actividad de inicio (cualquiera de las dos funciona). luego prosigue el envío de mensaje el cual debemos realizar en paralelo, por esta razón usaremos la compuerta AND, pero para la recepción de mensajes, como es una carrera, debemos usar la compuerta exclusiva basada en eventos, que fue descrita con anterioridad, una vez hecho esto, finaliza el proceso. En el caso de las compañías, ellas solo deben recibir una solicitud, procesarla y dar respuesta.

Paso3.
Intalio:
Para poder realizar nuestro modelo, debemos usar el Intalio | Designer. Una vez abierto, Creas un nuevo proyecto












Coloca el nombre que quieras, yo le puse lab5, luego pulsa Finish.

Ahora, creemos un nuevo modelo.









NOTA IMPORTANTE: Es importante que durante todo lo que vamos a realizar a continuación no le des a "guardar" ni una sola vez, si lo haces no podrás exportar el modelo, puesto que Intalio es una herramienta que permite hacer modelos funcionales, es decir que puedan ejecutarse, y  como por ahora solo vamos a modelar, si lo guardas, te lo tomará como un proceso incompleto y te dará problemas.


En mi caso lo llame ejercicio. Ahora verás que te sale un carril por defecto, y una tarea inicial por defecto, para agregar cualquier cosa al modelo debemos hacerlo desde donde dice palette.

Ahora, procedemos a agregar los pool que habíamos acordado. podemos renombrar el existente, para que sea nuestro pool principal (Empresa), para ello hacemos doble clic sobre la palabra pool que está en el carril; bastaría entonces con crear 3 pool más (las compañías de envio). Para agregar un pool busca en la zona verde un dibujito azul que dice pool y después de darle clic sobre él, haces clic en el diagrama. el pool se agregará solo. En la parte baja a la izquierda puedes ver una miniatura de tu modelo (Circulo verde).

Agregados nuestros pool, arreglaremos que no sean ejecutables los de las compañías, para ello nos paramos sobre el pool, y con clic derecho, vemos que no sean ejecutables. verás que se oscurecen.

Ahora, procedemos a colocar cada elemento que modele la situación. La actividad que tenemos allí, puedes re nombrarla, dando clic en la palabra Task, le pondremos: "Productos listos". Ahora tienes dos opciones: Dejarla como una actividad de inicio, o convertirla en un evento de inicio. si optas por la segunda opción, dale clic con botón derecho->change activity type->start events->empty start event. Ahora, si dejas el ratón sobre el pool te saldrá una lista de eventos y compuertas que puedes colocar, busca la paralela y colócala.

Para colocar las flechitas que ves, debes posicionar el ratón en un evento y/o compuerta. Si lo colocas de lado derecho, te permite modelar flujo, si lo colocas arriba o abajo indican envío/recepción de mensajes, ten mucho cuidado con esto, es importante.Avanzando un poco más encontramos modelados los 3 eventos de envío de mensaje.
En el mundo de BPMN, el envío de mensajes se modela con un sobre negro y el de recepción con uno blanco, ten calma, Intalio oscurece o no el sobre dependiendo del sentido de la flecha (si sale del evento representa envío, si llega al evento representa recepción). dejemos un momento el carril del sistema y modelemos el carril de una de las compañías.

Este es el comportamiento de una carril compañía. Las compañías tienen un evento de inicio de recepción de mensaje, el cual se representa como ves en la imagen, luego tenemos una actividad, llamada procesar solicitud. En este paso, la compañía decide si se hace cargo o no del envío. luego colocamos una compuerta OR (exclusión) para ver cual es la siguiente acción a realizar. la flechita con la linea indica que es la acción que se hace por defecto, es decir, normalmente aceptan hacer los envíos. cómo puedes colocar la raya a la flecha? das clic derecho sobre ella y te vas a condition type, seleccionas default y es todo. Para colocar textos, recuerda que basta darle doble clic sobre el objeto; y las actividades (TASK) se consiguen en la zona verde ubicada a la izquierda. Este comportamiento es exactamente el mismo en las 3 compañías, así que este proceso se repite en los dos carriles faltantes.

Ahora procedemos a realizar la conexiones, recuerda lo importante del sentido de las flechas. Cuando te pares sobre el evento, por la parte posterior o superior, aparecerán tres flechas, debes usar la del circulo en la base. Coloca las que están en verde primero, y las que se ven en azul después. Para Intalio debes colocar dos flechas en cada envío y recepción puesto que debe haber una confirmación por cada mensaje, contrario a BPMN en papel, donde sólo se coloca una flecha.

Ahora realiza el mismo procedimiento con los carriles faltantes. Para finalizar toda compuerta que coloques debe tener su homóloga, esto es por notación y funcionamiento de las compuertas.Te queda entonces:

Una vez terminado tu modelo,puedes exportarlo. Recuerda que no debiste darle guardar ni una sola vez durante todo lo que hemos hecho, de lo contrario no podrás exportar. Para guardarlo como una imagen debes ir a:
File->Export->SOA Tools Plataform -> BPMN Diagram Image
Seleccionas la carpeta de tu proyecto, y dentro seleccionas la carpeta con el nombre de tu diagrama, y solo debes marcar la ultima opción de dentro de la carpeta (modeler.bmpn_diagram) selecciona la carpeta donde quieres guardar la imagen, el nombre que tendrá y pulsa finish.

Ejercicio Terminado.

Ahora te dejo los ejemplos, intenta aplicar lo hecho hasta ahora.

Ejemplo 1:
El siguiente ejercicio es para familiarizarnos un poco con la notación BPMN:
• Cree 6 tareas que se ejecuten secuencialmente, nómbrelas de la ‘A’ a la ‘F’.
• La tarea B, realmente es un subproceso, compuesto de dos tareas B1 y B2, las
cuales se ejecutan secuencialmente en el orden respectivo.
• La tarea C y el subproceso B se ejecutan paralelamente.
• Bajo ciertas condiciones no se ejecuta C.
• En circunstancias aún más especiales, en vez de ejecutarse C se debe detener el
proceso completo, incluso las actividades del subproceso B.
• Antes de ejecutar la tarea E se debe esperar un tiempo.
• La tarea A es realmente la recepción inicial de un mensaje de un participante
llamado ‘cajero’ y la tarea F es realmente un evento de fin vacio.
• La tarea E es realmente un envío de mensaje a un participante llamado ‘cliente’.

Solución.

Ejemplo2:

Después de un incendio, por un lado se necesita obtener información de nuestra compañía de seguro. Por otro lado, es posible que necesitemos información adicional del departamento de bomberos, pero solo si los bomberos participaron durante el apagado del incendio. Cuando se tenga toda la información, se necesita escribir un informe consolidado.

Solución.

Instalacion de Intalio en Win XP

Un saludo muy cordial a ti, que estás leyendo esto. Ya que por estos días estaré incursionando en el mundo de los BPMS, me pareció indicado usar una de las herramientas populares en este mundillo tan especial, asi es, me refiero a Intalio, y aquí  te dejo, de mi completa autoria un tutorial de instalación, esperando te sea útil para que me puedas seguir la pista en los siguientes días, en cuanto al cómo se realizan los ejercicios de modelado de procesos, usando esta herramienta. sin más por el momento, te dejo el enlace del tutorial:

https://docs.google.com/open?id=0B3JCh6S1jMcTUS14V3AzSURlUlk