Bpmn 2.o manual de referencia y guía practica.pdf

Gua de Referencia y

Modelado

BPMN

Published by Future Strategies Inc. www.futstrat.com

Este libro ha sido traducido desde su versin original en Ingls por un un equipo de profesionales con ms de 10 aos de experiencia en la implantacin de soluciones de BPM en organizaciones hispanoparlantes, vinculados a la Universidad Catlica

del Uruguay y a la empresa INTEGRADOC.

En la Universidad Catlica del Uruguay (www.ucu.edu.uy) funciona el Grupo de Trabajo en Gestin de Procesos de Negocios (BPM & Workflow), en el marco de la

Facultad de Ingeniera y Tecnologas.

La empresa INTEGRADOC (www.integradoc.com) se especializa en soluciones de BPM optimizadas para procesos de negocios que involucran un tratamiento

intensivo de documentos con soporte digital o en papels.

Dr. Ing. Juan J. Moreno. Lder del Grupo de Gestin de Procesos de Negocios - Universidad Catlica del Uruguay.

Director - INTEGRADOC.

Ing. Erik Koleszar. Universidad Catlica del Uruguay.

Arquitecto de Software - INTEGRADOC.

Ing. Martn Sorondo. Universidad Catlica del Uruguay.

Lic. Martn Palatnik. Universidad Catlica del Uruguay.

Lic. Cristian Mastrantono. Universidad Catlica del Uruguay.

A/I. Martn Fros. Universidad Catlica del Uruguay.

Desarrollador de Software Senior - INTEGRADOC.


Gua de Referencia y

Modelado BPMN

COMPRENDIENDO Y UTILIZANDO BPMN

Desarrolle representaciones grficas de procesos de negocios, que sean rigurosas pero al mismo tiempo de fcil

comprensin.

STEPHEN A. WHITE, PHD DEREK MIERS

Future Strategies Inc. Lighthouse Point, Florida, USA


Gua de Referencia y Modelado BPMN Comprendiendo y utilizando BPMN Derechos Reservados 2009 por Future Strategies Inc. ISBN13: 978-0-9819870-3-3 Edicin digital de espaol

Publicado por Future Strategies Inc., Book Division 3640 B3 North Federal Highway, #421, Lighthouse Point, FL 33064 USA 954.782.3376 / 954.719 3746 fax www.FutStrat.com [email protected] Tapa: Hara Allison www.smallagencybigideas.com Todas las marcas y nombres de productos mencionados en este libro son marcas registrados o marcas de servicio de sus respectivas compaas. Cualquier omisin o mal uso no debe ser interpretado como un intento de infringir la propiedad de otros. El publicador reconoce y respeta todas las marcas usadas por las compaas, productores y desarrolladores como una herramienta para distinguirsus productos. Ni los autores, editores, traductores o Future Strategies Inc., aceptan ninguna responsabilidad o implicancia por prdidas o daos ocasionados a cualquier persona o propiedad mediante el uso de este material, instrucciones, mtodos o ideas contenidas, o actuando o como consecuancia de actos como resultado de su uso. Los autores y el publicador expresamente rechazan cualquier garanta implcita, incluyendo comerciabilidad o adecuacin para cualquier propsito particular. No habr responsabilidad del autor o publicador de corregir cualquier error o defectos en el software. Todos los derechos reservados. Manofacturado en los Estados Unidos de Amrica. Ninguna parte de este trabajo cubierta por los derechos de autor puede ser reproducida o usada en ninguna forma grfica, electrnica o mecnica, incluyendo fotocopiado, grabacin o almacenamiento en sistemas de de informacin y recuperacin sin el permiso expreso y escrito del publicador, excepto en los caso de breves reseas incorporadas en artculos crticos y revistas.

Datos del Publicador ISBN: 978-0-9819870-3-3

Gua de Referencia y Modelado BPMN. Comprendiendo y utilizando BPMN /Stephen A. White, PhD., Derek Miers p. cm. Incluye referencias bibliogrficas y apndices. 1. Gestin de Procesos de Negocios. 2. Modelado de Procesos. 3. Arquitectura Empresarial. 4. Estndar de Notacin. 5. Flujos de Trabajo (Workflow). 6. Anlisis de Procesos White, Stephen A.; Miers, Derek


Future Strategies Inc. Este libro es publicado en formato digital. El contenido completo de este libro est protegido por derechos de autor y no debe ser distribuido o sus datos extrados sin autorizacin por escrito del publicador Future Strategies Inc. Contacto [email protected]. www.FutStrat.com. Tel: +1 954 782 3376.

Usted est autorizado a imprimir una copia para uso personal.

Future Strategies Inc. This book is published in digital format. The content of this book is fully copyrighted and may not be distributed or data extracted therefrom without written permission by the publisher, Future Strategies Inc. Contact [email protected]. www.FutStrat.com. Tel: +1 954 782 3376.

You are licensed to print one copy for your own use.


5 Guia de Referencia y Modelado BPMN

Tabla de Contenidos

TABLA DE CONTENIDOS 5 PRLOGO 9 ACERCA DE ESTA TRADUCCIN. 13 PARTEI.COMPRENDIENDO BPMN 14 CAPTULO1.INTRODUCCIN 16

ESTRUCTURA DEL LIBRO 16 CONVENCIN TIPOGRFICA 18

CAPTULO 2. LA IMPORTANCIA DE MODELAR 20

LOS PROCESOS AYUDAN A LA COMUNICACIN 20 MODELOS DE PROCESO QUE ORIENTAN AL TRABAJO 22 MODELADO DE PROCESOS EN BPMN 23 HISTORIA Y OBJETIVOS DE BPMN 24

CAPTULO 3.PROCESOS 27 CATEGORAS DE PROCESOS 29

Orquestacin...................................................................................... 29 Coreografa ........................................................................................ 30 Colaboracin ...................................................................................... 31

CAPTULO 4.ASPECTOS DEL MODELADO 33 TODOS LOS MODELOS SON ERRNEOS, ALGUNOS SON TILES 33 CUNTOS PROCESOS, EN DNDE ENCAJAN? 35 ENFRENTANDO LA COMPLEJIDAD EN BPMN 36

CAPTULO5.INTRODUCCIN A BPMN BASADA EN ESCENARIOS 38 CONSTRUYENDO UN PROCESO CON BPMN 38 ESTABLECIENDO TEMPORIZADORES 39 BUCLES 42 DECISIONES BASADAS EN EVENTOS 44 ALCANZANDO SLAS 45 REPRESENTANDO ROLES EN LOS PROCESOS 46 MODELANDO DATOS Y DOCUMENTOS 48 COORDINANDO HILOS DE ACTIVIDAD PARALELOS 50 OTRO ENFOQUE PARA LA ESCALADA 55 MS DE UNA RESPUESTA CORRECTA 57

PARTE II.SECCIN DE REFERENCIA DE BPMN 60 CAPTULO 6.INTRODUCCIN A LA REFERENCIA DE BPMN 62 CAPTULO 7.ACTIVIDADES 64


TAREAS 65 SUB-PROCESOS 66

Tipos de Sub-Procesos ....................................................................... 67 CONECTANDO ACTIVIDADES 70 COMPORTAMIENTO DE LA ACTIVIDAD 70

Con Flujos de Secuencia de Entrada Mltiples ................................. 71 Con Flujos de Secuencia de Salida Mltiples .................................... 73 Bucles ................................................................................................ 73 Actividades Multi-Instancia ............................................................... 75

NIVELES DE PROCESO 75 Proceso de Alto Nivel ......................................................................... 76 Comportamiento Entre Niveles de Proceso ........................................ 76 Conectando Sub-Procesos ................................................................. 79

CAPTULO 8.EVENTOS 82 EVENTOS DE INICIO 82

Conectando Eventos de Inicio ............................................................ 83 Comportamiento del Evento de Inicio ................................................ 85 El Evento de Inicio Bsico.................................................................. 85 Evento de Inicio Temporizador .......................................................... 86 Evento de Inicio Mensaje ................................................................... 86 Eventos de Inicio Seal...................................................................... 87 Eventos de Inicio Condicional ............................................................ 88 Eventos de Inicio Mltiple .................................................................. 89 Modelando con Ms de un Evento de Inicio ...................................... 89 Eventos de Inicio y Sub-Procesos ...................................................... 90 Los Eventos de Inicio Son Opcionales ............................................... 90

EVENTOS INTERMEDIOS 92 Comportamiento de un Evento Intermedio ........................................ 94 Conexin de Eventos Intermedios ..................................................... 95 Interrupcin de Actividades mediante Eventos ................................. 96 Eventos Intermedios Bsicos ............................................................. 99 Eventos Intermedios Temporizador ................................................... 99 Eventos Intermedios Mensaje .......................................................... 103 Eventos Intermedios Seal .............................................................. 105 Eventos Intermedios de Error .......................................................... 112 Eventos Intermedios de Cancelacin ............................................... 113 Eventos Intermedios de Compensacin ........................................... 114 Eventos Intermedios Condicionales ................................................. 114 Eventos Intermedios de Vnculo ...................................................... 115 Eventos Intermedios Mltiples ......................................................... 118

EVENTOS DE FIN 119 Conectando Eventos de Fin ............................................................. 121 Comportamiento de Eventos de Fin ................................................. 121 Eventos de Fin Bsicos ................................................................... 122 Eventos de Fin Mensaje................................................................... 122 Evento de Fin Seal ......................................................................... 123 Evento de Fin Terminador ............................................................... 123 Evento de Fin de Error ..................................................................... 124 Evento de Fin de Cancelacin ......................................................... 125

Guia de Referencia y Modelado BPMN 7

Evento de Fin de Compensacin ..................................................... 125 Evento de Fin Mltiple ..................................................................... 126

CAPTULO 9.GATEWAYS 128 GATEWAYS EXCLUSIVOS 130

Comportamiento Divisor de un Gateway Exclusivo ......................... 131 Comportamiento Unificador de un Gateway Exclusivo ................... 133

GATEWAYS EXCLUSIVOS BASADOS EN EVENTOS 134 Comportamiento Divisor de un Gateway Evento ............................. 135 Comportamiento Unificador de un Gateway Evento........................ 137

GATEWAYS PARALELOS 137 Gateway Paralelo Dividiendo .......................................................... 138 Gateway Paralelo Unificando .......................................................... 139

GATEWAYS INCLUSIVOS 142 Comportamiento Divisor de un Gateway Inclusivo .......................... 142 Comportamiento Unificador de un Gateway Inclusivo .................... 143

GATEWAYS COMPLEJOS 146 Comportamiento Divisor de un Gateway Complejo ......................... 147 Comportamiento Unificador de un Gateway Complejo .................... 147

CAPTULO 10.SWIMLANES 150 POOLS 150 CARRILES 152

CAPTULO 11.ARTEFACTOS 155 OBJETOS DE DATOS 155 GRUPOS 156 ANOTACIONES DE TEXTO 159 LOS ARTEFACTOS SON EXTENSIBLES 159

CAPTULO 12.CONECTORES 161 FLUJO DE SECUENCIA 161

Flujo de Secuencia Condicional ....................................................... 162 Flujo de Secuencia Predeterminado ................................................ 164

FLUJO DE MENSAJES 165 ASOCIACIN 166 FLUJO NORMAL 167 FLUJO DE DATOS 168

Entradas y Salidas de Actividades ms complejas ........................ 170 CAPTULO 13.CONCEPTOS AVANZADOS 173

REALIZANDO UNA ACTIVIDAD 173 El Ciclo de Vida de una Actividad ................................................... 173

TRANSACCIONES Y COMPENSACIN 174 Riesgos en un Sub-Proceso de Transaccin ..................................... 177 Cancelacin en un Sub-Proceso de Transaccin.............................. 178 Compensacin sin un Sub-Proceso de Transaccin ......................... 181

PROCESOS AD HOC 182 APNDICES 184


AMBIENTES DE EJECUCIN DE PROCESOS 184 TCNICAS PARA LA ARQUITECTURA DE PROCESOS 186

Descomposicin Funcional ............................................................... 186 Composicin de Procesos ................................................................. 187 Arquitectura Orientada a Servicios de Negocio ............................... 187 Del Contexto de Negocio a la Arquitectura de Procesos ................... 188 Para leer ms .................................................................................. 189

CUESTIONES Y DIRECCIONES BPMN 190 Coreografa versus Orquestacin .................................................... 190 Decisiones de Colaboracin y Reuniones ........................................ 190 Futuro de BPMN .............................................................................. 190

BUENAS PRCTICAS DE BPMN 192 EPLOGO 194 BIOGRAFA DE LOS AUTORES 198

STEPHEN A. WHITE, PH.D. 198 DEREK MIERS 198 PRLOGO 199

Richard Mark Soley, Ph.D. ............................................................... 199 Angel Luis Diaz, Ph.D. ..................................................................... 200

EPLOGO 200 Michael zur Muehlen Ph.D. .............................................................. 200

GLOSARIO 202 TRADUCCIN DE TRMINOS DE BPMN AL ESPAOL. 212


Prlogo

Richard Mark Soley, Ph.D. Presidente y CEO Object Management Group, Inc. Julio de 2008

Ms barato por docena! Qu clase de alocada pareja planificara cuida-dosamente que su familia tuviera una docena de nios, solamente por-que su estudio detallado de la crianza ha calculado que una familia con doce nios es optima? Slo un hombre y una mujer tan profundamente inmersos en estudios de productividad, que su vida entera haya girado en torno a la optimizacin. Si bien la familia de Frank y Lillian Gilbreth se ha inmortalizado en la pantalla gigante, los efectos deshumanizantes del enfoque de personas como engranajes de la mquina tambin ha en-contrado su lugar bajo las luces de Klieg, principalmente representados en la comedia negra de Charlie Chaplin "Tiempos modernos".

Evidentemente la optimizacin de los procesos de negocio no es una idea particularmente nueva. La Revolucin Industrial, especialmente a fines del siglo XIX, centr su atencin en la sistematizacin del negocio para incrementar los ingresos y beneficios, resultando no solo en la estandari-zacin de las lneas de ensamblaje de Colt y Ford, sino tambin en estu-dios de productividad como el de los Gilbreth y el de Frederick Winslow Taylor. Bajo el nombre de ergonoma y diseo de factores humanos, estos estudios continuaron optimizando departamentos de envo, organi-zaciones manufactureras, asistencia sanitaria, hasta el diseo automo-triz.

Qu hay en cuanto a la optimizacin de las prcticas de gestin? Cier-tamente la revolucin liderada al estilo de gestin del oeste a comienzos del siglo XX instaur una estructura que parece ser bastante rgida desde el exterior, sin embargo, desde el interior esa rigidez es raramente visible. La gestin se considera generalmente como una ciencia social, aunque sin duda la eficiencia y eficacia de la toma de decisiones puede ser medi-da (en algunas empresas).

En la base de la optimizacin del proceso de negocio debe haber un enfo-que hacia la sistematizacin de la prctica empresarial, ya sea que dicha prctica sea el funcionamiento diario de un operador de telemercadeo en un call center, un empleado de despachos en el muelle de carga, un ges-tor de citas en una oficina mdica, o un Vicepresidente finalizando una decisin de inversin. Incluso los procesos de toma de decisin que no pueden ser totalmente automatizados, pueden an as ser mapeados, se-guidos, optimizados y editados. La disciplina para hacerlo no es particu-larmente nueva; ni siquiera los sistemas para soportar la gestin de pro-cesos de negocios son nuevos. Lo que s es nuevo es el inters centrado en la utilizacin de una prctica de gestin para dar apoyo a la agilidad empresarial y una norma mundial para especificar los procesos de ne-


gocio, ya sean totalmente automatizables, completamente manuales o alguna combinacin entre ellos.

La notacin de modelado de procesos de negocio (BPMN) es la culmina-cin de dos corrientes de trabajo de finales de la dcada de 1990 y co-mienzos de este siglo. Una de las corrientes se centr en la planificacin y gestin del flujo de trabajo y tareas asociadas, mientras que la otra se ocup del modelado y la arquitectura. Es sorprendente constatar que, despus de cientos de aos de xito en el cuidadoso diseo de ingeniera de puentes, barcos y edificios del siglo XVI en adelante, las llamadas dis-ciplinas modernas de la ingeniera como el desarrollo de software han resistido satisfactoriamente a las antiguas e importantes disciplinas de la ingeniera por dcadas. Esto est cambiando; el reconocimiento de que el modelado es necesario para el xito de sistemas de software de gran complejidad es ahora comn, al igual que se hizo un reconocimiento comn a los astilleros y la construccin en los siglos XVI y XVII, y a la industria de construccin de puentes en el siglo XIX. El modelado es tan relevante para el software como lo son para los diseos de construccin.

Desde un punto de vista abstracto, el software diseado para aplicarse en el mbito empresarial (como los sistemas de planificacin de recursos, sistemas de gestin de envos, sistemas de facturacin y similares) son de hecho descripciones de procesos de negocio a un nivel sorprendentemen-te bajo. Usted no sabra slo con observar el rebuscado cdigo de C++ y Java que estos sistemas describen procesos de negocio, pero sin duda lo hacen. De hecho, incluso las descripciones de procesos de negocio de BPMN son una generalizacin de lo que el software se tratala automati-zacin de procesos. Pero los procesos reales en organizaciones reales no son totalmente automatizables. Lo cual significa que no se puede utilizar el mismo lenguaje para definir, no se pueden usar los mismos procesos para medir, o para optimizar. La combinacin de la capacidad de los len-guajes modernos de programacin para ocultar la intencin de la fun-cin, con su incapacidad para integrar claramente los procesos manuales y ejecutivos, hacen que la mayora de los lenguajes de programacin se-an, como mnimo, ineficientes y ms probablemente intiles como len-guajes de descripcin de procesos. Esta corriente tcnica de descripcin de la prctica, junto con las ten-dencias de la gestin de flujo de trabajo y re-ingeniera de los procesos de negocio de finales de siglo XX, provoc la aparicin de un lenguaje expl-cito y detallado para describir procesos de negocio, centrndose en dejar clara la intencin de una descripcin de proceso y reconocer completa-mente que todo proceso de negocio interesante involucra un toque humano. La fusin de la Iniciativa de Gestin de Procesos de Negocio (BPMI) con el Grupo de Gestin de Objetos (OMG) uni dos grupos especializados en una organizacin ms fuerte. BPMI se centr en procesos de negocio; OMG se centr en el problema de modelado genrico con su Arquitectura Orientada a Modelos, y especialmente en el modelado de sistemas de


software. El nuevo OMG, que surgi en el 2005, cre exitosamente una sola organizacin que se centr en el modelado de sistemas, incluyendo los procesos de negocio, en dos docenas de mercados verticales desde la asistencia sanitaria hasta las finanzas, desde la fabricacin hasta las ciencias de la vida, y desde sistemas de gobierno hasta sistemas militares. No solamente hizo que el lenguaje BPMN se estableciera, sino que tam-bin logr un sustento tcnicamente detallado, con MDA (integrndolo con lenguajes para expresar el diseo de software, diseo de sistemas de ingeniera e incluso diseo de hardware). Ms importante an, la expe-riencia se qued con el lenguajevaliosa experiencia en modelado de ne-gocios, escasa en el OMG antes de la fusin, es ahora el centro del xito del OMG.

Este libro representa, en trminos claros y ciertos, la experiencia de dos de los expertos con una referencia no slo en el dnde y porqu de BPMN, sino que ms importante en el cmo. Cmo se deben representar las di-ferentes clases de procesos? Cmo saber si se ha hecho correctamente? Cmo obtener valores de las descripciones de los procesos, y medir y optimizar los procesos resultantes? Nadie sabe cmo responder estas preguntas mejor que Stephen White y Derek Miers, de modo que si lo que usted est buscando es un negocio optimizado, usted tiene el libro indi-cado en sus manos.

Angel Luis Diaz, Ph.D. Director, Websphere Business Process Management IBM Software Group Agosto de 2008

El paisaje empresarial se encuentra lleno de retos, incertidumbres y oportunidades. Para muchas empresas e industrias, estos cambios se estn volviendo ms significativosincluso transformativosen su natu-raleza. La Gestin de Procesos de Negocio (BPM) ayuda a que los proce-sos de una organizacin sean ms flexibles y receptivos a cambios. BPM es una disciplina, que combina las capacidades del software y la expe-riencia de negocio para acelerar la mejora de procesos y facilitar la inno-vacin del negocio.

Los estndares para BPM ayudan a la organizacin a aprovechar el po-der del cambio a travs de sus procesos de negocio, utilizando una Arqui-tectura Orientada a Servicios (SOA) para acomodarse rpidamente a las cambiantes condiciones y oportunidades del negocio.

En un clima de negocios en rpida evolucin, el desarrollo pro- activo y el uso de estndares son la clave para permanecer competitivo para los proveedores de BPM y sus clientes. Los procesos orientados a estndares permiten a las organizaciones conectar las funciones empresariales en conjunto, tanto internamente como externamente con sus clientes, socios y proveedores. No se trata de la tecnologa en aras de la tecnologase trata de permitir nuevas formas de hacer negocio. Se trata de ayudar a las organizaciones a alcanzar nuevos niveles de innovacin mientras se


continan ofreciendo aumentos en la productividad, los cuales son nece-sarios para mejorar el balance final. Los estndares abiertos permiten a las empresas reducir los costos, incrementar los ingresos y responder rpidamente a las presiones de la industria. Lo nuevo es que los estndares abiertos estn acercndose a los objetivos de las empresas, y el ritmo al que estn surgiendo es impulsado acelera-damente por la estratificacin que se produce. Cuando un conjunto de mejores prcticas es acordado, se abre la puerta a la prxima oportuni-dad para la innovacin mientras que se aprovecha el creciente apoyo a los estndares abiertos de integracin, conectividad e interoperabilidad. Con la amplia adopcin de los estndares de Arquitectura Orientada a Servicios (por ejemplo, XML, Servicios Web) se tiene una base slida para construir estndares para la Gestin de Procesos de Negocio.

Esto conduce a la Notacin de Modelado de Procesos de Negocio (BPMN), uno de los estndares clave que han surgido en el mbito de BPM. BPMN mejora los esfuerzos organizacionales de BPM proporcionando un lengua-je grfico comn, facilitando la comunicacin y mejor comprensin de los procesos de negocio en ambos, negocio y TI.

El futuro de BPMN es brillante a medida que se aumente el rigor aso-ciado a la definicin del negocio. Este rigor asegurar que las inversiones que realizan los empresarios en definir sus procesos sean rpidamente traducidas a la realidad. Adems, a travs de puntos de agilidad embebi-dos en el proceso de ejecucin, los sistemas se optimizan fcilmente.

La Gestin de Procesos de Negocio pone a los requerimientos de negocio al volante; asegurando la claridad del concepto a todos los operadores, desde los lderes de la empresa, analistas y usuarios, hasta los lderes de tecnologas de la informacin y desarrolladores. Los autores se encuen-tran personalmente entusiasmados por la publicacin de este libro ya que sin duda ayudar a llevar el poder de BPM a las masas y proveer un recurso valioso para todos los que estn desarrollando modelos e imple-mentaciones BPMN.


Acerca de esta traduccin.

Este libro fue originalmente escrito en ingls y BPMN est definido com-pletamente tambin en esa lengua. Dado que BPMN es una notacin, in-corpora una gran cantidad de trminos, utilizados en la descripcin y modelado de los procesos y que por ende son de gran relevancia. Lo ideal sera que este conjunto de trminos (claves y secundarios), fuera univer-sal y no se tradujera a cada lengua. Sin embargo, la cantidad de trmi-nos sin traducir hara ininteligible el libro, el estndar y en general cual-quier redaccin referida a BPMN, pues sera una mezcla sin sentido de palabras en diferentes idiomas.

Con este desafo por delante, el equipo de traduccin fij como principal objetivo que el libro sea lo ms comprensible posible a los hispano-parlantes, no modificando su estructura ni contenidos. Para lograr esto, se defini que se traduciran todos los trminos de BPMN, fueran claves o secundarios, que tuvieran una traduccin adecuada a nuestro idioma. En orden de facilitar la comprensin, referencia y mapeo con los trminos originales en ingls, al final de este libro, se incluye una tabla que mapea como fueron traducidos cada uno de stos trminos.

Como segundo objetivo se busc que la traduccin fuera lo ms desloca-lizada posible, es decir, que fuera comprensible en la mayor cantidad de regiones de habla hispana. Existen innumerables trminos en ingls que no cuentan con una traduccin adecuada al espaol, y que en diferentes regiones son utilizados en forma divergente. Para todos estos trminos, se han dejado en ingls, adjuntando en el texto una breve traduccin de su significado en espaol.

Dr. Ing. Juan J. Moreno. INTEGRADOC, Universidad Catlica del Uruguay.

Ing. Erik Koleszar. INTEGRADOC, Universidad Catlica del Uruguay.

Ing. Martn Sorondo. Universidad Catlica del Uruguay.

Lic. Martn Palatnik. Universidad Catlica del Uruguay.

Lic. Cristian Mastrantono. Universidad Catlica del Uruguay.

A/I. Martn Fros. INTEGRADOC, Universidad Catlica del Uruguay.


Parte I. Comprendiendo BPMN


Captulo 1. Introduccin

Este libro proporciona una gua y referencia de modelado para las carac-tersticas de la versin 1.1 de BPMN.

En la parte I, se describirn levemente los impulsores de negocio asocia-dos al modelado de procesos, alinendolos con la historia de la No-tacin de Modelado de Procesos de Negocio (BPMN),1 desarrollos estn-dar y controvertidos esperados en el futuro. Se continuar hablando acerca de procesos y modelado en general para establecer y posicionar algunas de las cuestiones y desafos para los modeladores de BPMN.

Luego se presentar el enfoque de modelado BPMN utilizando un escena-rio progresivo que se despliega al lector. Mientras se detalla cada nuevo aspecto del escenario, se describir la funcionalidad de BPMN que permi-te el comportamiento deseado. En lugar de intentar explicar cada con-cepto detalladamente, esta parte del libro se atiene a los principios fun-damentales, haciendo referencia al lector a la seccin para obtener mayor detalle (por ejemplo, la parte II de este libro).

La intencin es permitir al lector entender cmo aplicar BPMN en un es-cenario del mundo real. Adems el enfoque tomado introduce cada conjunto de funcionalidades de un modo no amenazante, permitiendo al lector comprender a su propio ritmo. A lo largo de esta parte del libro, se introducirn ejercicios para que el lector complete, ayudndolo a fijar su aprendizaje y establecer un nivel fundamental de experiencia. Las res-puestas a estos ejercicios estarn disponibles en lnea (como parte del entrenamiento en lnea que complementa a este libro).

La parte II presenta una detallada seccin de referencia que cubre la semntica precisa del estndar BPMN, explicndola y explicando el com-portamiento del proceso que resulta.2

Para modeladores ocasionales, la Parte I proporcionar lo suficiente co-mo para comenzar. Con el tiempo, se espera que usted se inmersa en la Parte II (la referencia detallada) para familiarizarse con las funciones pre-cisas de la notacin.

Estructura del Libro El libro est organizado en 13 captulos principales, seguidos por Apn-dices, un Prlogo, Glosario e ndice.

<

1 BPMN es una marca registrada de Object Management Group.

2 La especificacin BPMN y una lista de proveedores que la soportan estn disponibles en http://www.bpmn.org/. Se decidi no incluir una lista de proveedores en este libro ya que podr-a perder vigencia rpidamente.


Parte I Captulo 1 Introduccin

Captulo 2El Modelado de Procesos es Importante introduce el modelado de procesos en general, destacando la forma en que ayuda a la comunicacin y comprensin entre las personas. Des-cribe brevemente cmo los Modelos de Procesos pueden ayudar a la comunicacin y guiar el trabajo dentro de la organizacin.

Captulo 3Procesos proporciona una rpida introduccin a los conceptos de Procesos de BPMN, que abarca conceptos de Or-questacin, Coreografa y Colaboracin.

Captulo 4Enfoques de Modelado & Arquitectura introduce al-gunos de los posibles enfoques para modelar con BPMN.

Captulo 5Introduccin a BPMN basada en un escenario pro-porciona una introduccin al modelado BPMN fcil de seguir. Co-mienza con una situacin simple y fcil de reconocer y luego se construye sobre esa base, introduciendo lentamente y explicando las funcionalidades de BPMN para respaldar la evolucin de la complejidad del comportamiento.

Parte II Captulo 6Introduccin a la Seccin de Referencia BPMN pro-porciona una breve introduccin, explicando los tokens que se uti-lizan para mostrar el comportamiento asociado a cada elemento de BPMN.

Captulo 7Actividades explora Tareas, Sub-Procesos y Niveles de Proceso en general. Luego se discuten las cuestiones especiales que afectan los Sub-Procesos

Captulo 8Eventos proporciona explicaciones detalladas de to-dos los eventos inciales, intermedios y finales. Recorre cada uno de ellos, describiendo el comportamiento de cada uno de sus ele-mentos.

Captulo 9Gateways investiga el rol de las Gateways en el mode-lado BPMN (puntos donde el control es necesario para dividir y unir caminos), pasando por el comportamiento asociado a cada ti-po.

Captulo 10Swimlanes establece la semntica apropiada y las reglas de asociadas a los Pools y Carriles.

Captulo 11Artefactos explica cmo representar Datos, Docu-mentos y otras cosas que no estn directamente cubiertas con los objetos centrales del diagrama de flujo de procesos.

Captulo 12Conectores explora el significado asociado al Flujo de Secuencia, Flujo de Mensajes y Anotaciones.

Captulo 13 Conceptos Avanzados proporciona explicaciones so-bre el Ciclo de Vida de una Actividad, Compensacin y Transac-ciones, y procesos Ad-Hoc.


Los apndices proporcionan un anlisis ms detallado de:

o Entornos de Ejecucin de Procesos (Suites BPM y Workflow) o Tcnicas de Arquitectura de Procesosun breve anlisis de los

enfoques disponibles.

o Una coleccin de buenas prcticas en BPMN. o Orientacin de BPMNanaliza la direccin a seguir por la es-

pecificacin de BPMN, explorando algunas de las funcionali-dades esperadas en la versin 2.0 de BPMN y posteriores ver-siones.

El eplogo proporcionado por el Prof. Michael zur Muehlin, analiza algunos de los usos de los Modelos de Proceso, y a travs del uso de BPMN, cmo evitar los errores cometidos en el pasado.

Glosario e ndice.

Convencin Tipogrfica En este libro, se utilizan los siguientes estilos para distinguir los elemen-tos de BPMN del espaol. Sin embargo, estas convenciones no son utili-zadas en tablas o ttulos de seccin donde no es necesaria la distincin.

Bookman Old Style - 10.5 pt.: Texto estndar

Cursiva con Sangra: Escenarios

Inciales en Mayscula Elementos BPMN

Cursiva minscula: Conceptos Importantes de BPMN

Subrayado: nfasis general

Calibri10.5pt.CursivaconSangra: PuntoClave/MejorPrctica

Calibri10.5pt.Sangra(Nocursiva): Ejercicios


Captulo 2. La Importancia de Modelar

Resumen: Este captulo describe la funcin del Modelado de Procesos en generaltantocomoayudaparalacomunicacincomoparaguiarlaformaenquese trabajaen lasorganizacionesmodernas.LuegoseanalizarbrevementelahistoriadeBPMN.

Todas las organizaciones se encuentran en un recorridoun viaje sin fin donde la atencin se centra en mejorar la manera en que las cosas se hacen (como quiera que sea medido) para el beneficio de los accionistas, las partes interesadas y/o ganancias. Este concepto se encuentra en el corazn de las Gestin de Procesos de Negocio (BPM); una manera de pensar, una filosofa de gestin centrada en mejorar los procesos opera-cionales de la organizacin.

Cuanto ms tiempo una organizacin haya estado recorriendo este cami-no, ms maduros son sus procesos, ms repetibles y escalables son sus operaciones y es mejor su desempeo en general. De hecho, la literatura acerca de la gestin est llena de ejemplos de Empresas que han estado en este recorrido desde hace un tiempoDell, General Electric, Toyota, Nokia, Cisco, Federal Express son algunos de los ejemplos.

Donde sea que se mire, es fcil encontrar cualquier nmero de artculos o libros que recomiendan a las empresas a incurrir en la innovacin ope-racional (con el objetivo de abrumar a la competencia). Y sin embargo, todos estos ejemplos tienen algo en comnun remarcado nfasis en la comprensin de los procesos de negocio de la empresa para poder mejo-rarlos. Se podra argumentar que este es un principio fundamental de la disciplina de la gestin.

En todo el mundo, prcticamente en todas las empresas y organizaciones, las personas estn luchando para comunicarse entre ellas para ver cmo organizar el trabajo de la mejor manera. Se estn cuestionando cosas como:

Cules pasos son realmente necesarios? Quin debera realizarlos? Deben quedarse en la empresa o en el subcontratado? Cmo deben ser realizados? Qu funcionalidades se necesitan? Qu resultados se esperan y como sern monitoreados?

Mientras que las respuestas a estas preguntas son siempre para una si-tuacin en particular, sin el sustento de una descripcin comnmente aceptada del proceso de negocio en cuestin, esas respuestas son a me-nudo imprecisas y confusas.

Los Procesos Ayudan a la Comunicacin Los competidores sacan al mercado nuevos productos, los clientes de-mandan cambios ms rpidos y precios ms bajos, las reglamentaciones cambian. Cada vez que un programa organizacional pone en marcha este


tipo de desafos, las personas se encuentran construyendo modelos de procesos de negocio para mostrar el flujo de trabajo y las actividades asociadas (vase figura 2-1).

Figura 2-1Ejemplo de Proceso BPMN

Las personas generalmente usan estos modelos para respaldar sus con-versaciones, ayudando a la comunicacin y comprensin, actuando como respaldo para prcticamente todos los programas de mejora. Tales mode-los forman la base de una referencia global del negocio, detallando cmo la operacin se integra. Forman parte del material de capacitacin y act-an como base para compartir las buenas prcticas dentro de la Empre-sa.

Como se representa en la figura 2-2, los modelos de proceso son nor-malmente creados (descubiertos o capturados) observando las operacio-nes de la empresa en marcha. Son importantes entradas los objetivos, estrategias y reglas (o reglamentaciones) de la organizacin. Se realiza una especie de Anlisis previo al Rediseo.

Las organizaciones pueden elegir entre muchas metodologas sofisticadas para la captura y el diseo de modelos para adecuarse a su propsito. Este libro no tiene como objeto proporcionar dichas metodologas, pero si proporcionar las bases para entender los modelos resultantes.

Hasta este punto, se asume que los humanos sern los principales con-sumidores de estos modelos. Como se ver luego, estos procesos pueden ser las principales entradas para un entorno de soporte para negocios.


Figura 2-2Los Modelos de Proceso son importantes en todas las etapas del cambio organizacional.

Inicialmente, estos modelos impulsan la comunicacin entre los compa-eros de trabajo dentro de la organizacin, ayudndolos a lograr un en-tendimiento compartido. En una organizacin pequea, esto es relativa-mente sencillo de lograr, pues los empleados tienden a compartir una cultura y un conjunto de valores en comn. Pero en una organizacin ms grande, especialmente en las que los empleados estn distribuidos en distintos lugares fsicos, lograr una interpretacin comn acerca de lo que quieren decir realmente las palabras es frecuentemente difcil.

Pero al compartir modelos de proceso con proveedores, clientes y/o so-cios por ejemplo, de un extremo al otro de la cadena de valor este pro-blema de interpretacin empeora. Los participantes ya no tienen las refe-rencias culturales que ayudan a fijar el significado del diagrama.

PuntoClave: Sinunaformarigurosadedescribirlosprocesosdenegocio,lainterpretacindeunmodelodadosiemprequedaenmanosdel lector (nodelmodelador),locualpuedefrustrarelpropsito.

Los modelos de proceso tambin proporcionan el marco de trabajo dentro del cual las mtricas tienen significado. Por ejemplo, sin alguna nocin de procesos de negocio, conceptos como ciclo de completo y costos de ac-tividad no tendran puntos de referencia.

Modelos de Proceso Que Orientan al Trabajo Habiendo construido estos modelos, algunos se dan cuenta de que es po-sible usarlos para orientar el trabajo en s mismo. Ntese que en la figura 2-2 se muestra cmo el rediseo del proceso alimenta la entrada del so-porte del proceso. Junto con los Datos, Documentos y Reglas, el Modelo de Proceso es ahora el apoyo de las operaciones de la empresa.


Interpretados por sofisticados sistemas de software (suites BPM y pro-ductos de Workflow), los modelos de procesos ejecutables llevan las ins-trucciones de cmo el trabajo debe realizarse, quin debe realizarlo, con-diciones de intensificacin en el caso de que no haya sido realizada a tiempo, conexiones a otros sistemas, etc. El resultado agiliza el trabajo en la organizacin, asegurando el rendimiento correcto de los pasos crticos y que los elementos de trabajo no caigan en quiebres.

Si el trabajo debe cambiar entoncesen lugar de escribir nuevos pro-gramas de computacin (enfoque antiguo)slo se debe cambiar los mo-delos base y el comportamiento de la organizacin se adaptar de forma correspondiente.

Estos ambientes de software orientados a procesos se estn volviendo cada vez ms populares, pues proporcionan un mtodo directo para tra-ducir ideas estratgicas y tcticas a procesos operacionales. De muchas maneras distintas, permiten a toda la organizacin volverse ms gil de lo que podra hacerse de otras maneras. Para un anlisis ms detallado de Soporte de Procesos y Ejecucin de Procesos en general ver la seccin del Apndice Ambientes de Ejecucin de Procesos en la pgina 184. 3

El factor esencial es que los modelos de proceso requieren mayor rigor deben soportar este comportamiento de ejecucin (en lugar de confiar en la interpretacin humana). El problema es que, sin precisin y estructura, cuanto ms se mira diagramas simples basados en cajas y conectores, menos significan. Para lograr que un modelo comunique la esencia real (para el lector o para un sistema) las cajas y conectores deben represen-tar algo.

PuntoClave: La realidadesque, cuando se tratademodelarelpolifacticomundodeltrabajo,todoslosprocesosdenegocionecesitanunciertogradoderigor. De otra forma, no tienen sentido. Esto es especialmente ciertocuandoelmodeloestdiseadoparaserinterpretadoporcomputadoras.

Y de eso es lo que la Notacin de Modelado de Procesos de Negocio (BPMN) se trata. Proporciona una forma estndar de representar proce-sos de negocio tanto para propsitos descriptivos de alto nivel y para de-tallados y rigurosos entornos de software orientados a procesos.

Modelado de Procesos en BPMN En BPMN, los Procesos de Negocio involucran la captura de una se-cuencia ordenada de las actividades e informacin de apoyo. Modelar un Proceso de Negocio implica representar cmo una empresa realiza sus objetivos centrales; los objetivos por si mismos son importantes, pero por

<

3 Vase tambin Mastering BPM--The Practitioners Guide de Derek Miers. Este libro proporciona un anlisis mucho ms profundo en cuestiones asociadas a la ejecucin de Modelos de Procesos en una Suite BPM.


el momento no son capturados por la notacin. Con BPMN, slo los pro-cesos son modelados.

En el modelado de BPMN, se pueden percibir distintos niveles de mode-lado de procesos:

Mapas de ProcesosSimples diagramas de flujo de las activida-des; un diagrama de flujo sin ms detalle que el nombre de las ac-tividades y tal vez la condiciones de decisin ms generales.

Descripcin de ProcesosProporcionan informacin ms exten-sa acerca del proceso, como las personas involucradas en llevarlo a cabo (roles), los datos, informacin, etc.

Modelos de ProcesoDiagramas de flujo detallados, con suficien-te informacin como para poder analizar el proceso y simularlo. Adems, esta clase de modelo ms detallado permite ejecutar di-rectamente el modelo o bien importarlo a herramientas que pue-dan ejecutar ese proceso (con trabajo adicional).

BPMN cubre todas estas clases de modelos y soporta cada nivel de deta-lle. Como tal, BPMN es una notacin basada en diagramas de flujo para definir procesos de negocio, desde los ms simples (por ejemplo vase la Figura 2-1) hasta los ms complejos y sofisticados para dar soporte a la ejecucin de procesos.

PuntoClave: BPMNescapazderepresentarunagrancantidaddenivelesdedetalleydiferentestiposdediagramasparadiferentespropsitos.

Historia y Objetivos de BPMN En el 2001, BPMI.org4 comenz a desarrollar BPML (Lenguaje de Modela-do de Procesos de Negocio, un lenguaje XML de ejecucin de procesos) y surgi la necesidad de una representacin grfica. Las personas y los proveedores involucrados en ese momento decidieron que una notacin orientada hacia las necesidades del usuario era necesaria, es decir, no una notacin que represente directamente el lenguaje de ejecucin en desarrollo. Esto significa que sera necesaria una traduccin de la nota-cin orientada al negocio al lenguaje tcnico de ejecucin.

El Notation Working Group (quien originalmente creo BPMN junto con BPMI.org) fundado en agosto del 2001. Estaba compuesto por 35 com-paas de modelado, organizaciones y personas, que entre todos aporta-ron una cantidad de perspectivas diferentes. Este grupo desarroll BPMN 1.0.

Cuando se comenz el desarrollo de BPMN habany todava hayuna amplia gama de notaciones de modelado de procesos, distribuidas utili-zando diferentes herramientas, y utilizadas dentro de una gran variedad de metodologas.

<

4 Iniciativa de Gestin de Procesos de Negocio


Lo interesante de BPMN era la gran cantidad de proveedores que se re-unieron con el objetivo comn de consolidar los principios subyacentes del modelado de procesos. Su meta era llegar a un acuerdo sobre una nica notacin (en cuanto a la representacin) la cual pueda ser adopta-da por otras herramientas y personas. Por lo tanto, BPMN no era un gran ejercicio acadmico, sino ms bien una solucin prctica tanto para los proveedores de herramientas de modelado como para los usuarios de herramientas de modelado.

El razonamiento fue que este enfoque ayudara a los usuarios finales dndoles una notacin simple y acordada. Esto permitira capacitacin consistente, utilizando cualquier nmero de herramientas. Las compa-as no deberan re capacitar cada vez que se compre una nueva herra-mienta o se contrate nuevo personal que haya sido capacitado en otras herramientas y notaciones. En resumen, hizo que el aprendizaje sea transferible.

Otro objetivo de BPMN era que proporcionara un mecanismo para gene-rar procesos ejecutablesinicialmente BPML (posteriormente substituido por BPEL). Por lo tanto, BPMN provee un mapeo vlido entre los dia-gramas BPMN a BPEL, de manera que un motor pueda ejecutar el proce-so. Esto no significa que todo modelo de proceso BPMN es ejecutable, pe-ro para aquellos procesos destinados a la ejecucin, BPMN proporciona los mecanismos para pasar del diseo original hasta la ejecucin. Esta trazabilidad fue parte de la meta original para el desarrollo de BPMN.

PuntoClave: BPMN tena dos objetivos contradictorios proporcionar una manerafcil de utilizar la notacin de modelado de procesos, accesible a losusuarios empresariales; y proporcionar facilidades para traducir losmodelosaunaformaejecutabletalcomoBPEL.

En mayo de 2004, fue publicada la especificacin 1.0 de BPMN. Desde entonces, ms de 50 compaas han desarrollado implementaciones del estndar. En febrero de 2006 la especificacin 1.0 fue adoptada como un estndar OMG (luego de que BPMI.org se incorpor al OMG).

Ntese que el Notation Working Group no estableci que se especificara un mecanismo de almacenamiento (serializacin) acordado para BPMN. Esto es a la vez una bendicin y una maldicinpermiti a los proveedo-res que adoptaran la notacin sin tener cambiar sus formatos internos de almacenamiento (un factor contribuyente a la expansin de la adopcin del estndar). Pero tambin signific que los archivos de diagramas no fueran portables entre herramientas de modelado.

PuntoClave: OriginalmenteBPMNnoespecificabaun formatodealmacenamiento,permitiendo que una franja ms amplia de proveedores adoptaran elestndar,apesardelimitarlaportabilidaddelosmodelos.

En febrero de 2008, la OMG public la versin final de BPMN 1.1, la cual se encuentra disponible para descargar pblicamente (vase www.bpmn.org). La mayora de los cambios en la versin 1.1, esclarecie-


ron el documento de especificacin en s, haciendo su significado ms explcito.

Sin embargo, pocos cambios grficos fueron realizados a BPMN en la ver-sin 1.1 (cubierta totalmente en este libro). Se ha resaltado en donde ocurrieron los cambios.

El OMG pronto publicar la versin 1.2. Esta versin no incluir cambios significativos en el aspecto grfico; los cambios son solamente en la re-daccin (por ejemplo, aclarando el lenguaje de la especificacin en s).

Actualmente BPMN 2.0 se encuentra en desarrollo y dar un gran paso adelante en las capacidades de BPMN. Es muy poco probable que esta nueva versin salga a luz hasta mediados de 2009, como muy temprano. Para un anlisis ms extenso acerca del futuro de BPMN y las posibles facilidades de BPMN 2.0 vase el Apndice Futuro de BPMN en la pgi-na 190.


Captulo 3. Procesos

Resumen: El propsito de este captulo es explorar las diversas definiciones deltrmino Proceso antes de incurrir en la introduccin de un diagramaBPMN, apuntando a los elementos clave que se presenten. Luego secontina con el anlisis de las diferentes categoras de Procesos queBPMNestcomenzandoadarsoporte(Orquestacin,CoreografayColaboracin).

Existe una gran cantidad de definiciones de Proceso de Negocio. De hecho, la nocin de un Proceso de Negocio es una nocin abstracta en el mejor de los casos. En los talleres realizados, frecuentemente se les pide a las personas que escriban sus propias definiciones y es sorprendente la variedad de respuestas que se reciben. Ejemplos extrados incluyen:

Una secuencia de actividades realizadas sobre una o ms entra-das para entregar una salida.

Un conjunto de actividades sistemticas que llevan un evento de negocio a un resultado exitoso.

Una coleccin de actividades de negocio que crean valor para un cliente.

Una determinada cantidad de roles colaborando e interactuando para lograr una meta.

Una coleccin organizada de comportamientos de negocio que sa-tisfacen un propsito empresarial definido, actuando de acuerdo a objetivos especficos.

Simplemente cmo las cosas se hacen aqu. La actual definicin de Wikipedia es, Un proceso de negocio o mtodo de negocio es una coleccin de tareas interrelacionadas, que persiguen una meta en particular.

El problema en llegar a una definicin para el trmino Proceso, es que existen muchas (definiciones) todos tienen una interpretacin sutil-mente diferente. Adems, siempre se utiliza la misma palabra, sin tener en cuenta de que se pueden querer decir cosas diferentes.

Entonces aunque todas estas definiciones son vlidas, es necesario asen-tarse en una para el propsito de este libro. En BPMN un Proceso repre-senta lo que una organizacin realiza su trabajo para lograr cumplir su propsito u objetivo. En la lista anterior, la segunda y tercera defini-cin son las que probablemente ms se acerquen.

Dentro de una organizacin, hay muchos tipos de Procesos en trminos de cul es su propsito y cmo son realizados. La mayora de los Proce-sos requieren algn tipo de entrada (ya sea electrnica o fsica), utilizar y/o consumir recursos, y producir algn tipo de salida (ya sea electrnica o fsica). La mayora de las organizaciones realizan cientos de miles de procesos en el transcurso de proporcionar valor a los clientes, personal, o satisfacer reglamentos.


Algunos procesos son formales, repetibles, bien estructurados, y hasta pueden estar automatizados. Usualmente se refiere a estos procesos co-mo Procedimientos. Los ejemplos Incluyen:

Procesamiento de reclamos sanitarios Creacin de una nueva cuenta. Transacciones bancarias. Procesamiento de reclamos de gastos.

Otros procesos son informales, muy flexibles, impredecibles (altamente variables), y difciles de definir o repetir. Usualmente se refiere a estos procesos como Prcticas. Los ejemplos Incluyen:

Escribir un manual de usuario. Desarrollar una estrategia de venta. Preparar un programa de conferencia. Ejecucin de una reunin de consultora.

BPMN utiliza un conjunto de elementos grficos especializados para des-cribir un Proceso y de qu manera es realizado (vase figura 3.1). Los elementos principales de un Proceso en BPMN son los Objetos de Flujo (Actividadesvase pgina 64; Eventosvase pgina 82; y Gatewaysvase pgina 128), y Flujo de Secuencia (vase pgina 161).

Figura 3-1Proceso

PuntoClave: Losobjetosdeflujo(Actividades,Eventos,GatewaysyFlujosdeSecuencia)son loselementosprincipalesquedefinen laestructurafundamentalyelcomportamientodelProceso.

Habitualmente los modeladores agregan ms elementos grficos para ex-plicar la estructura del Proceso y proporcionar mayor detalle. Por ejem-plo, los Objetos de Datos (vase la pgina 155) muestran cmo los datos son utilizados en el Proceso. Otros Artefactos tales como los Grupos (va-se pgina 156) o Anotaciones de Texto (vase pgina 159) ayudan a orga-nizar o documentar detalles del Proceso. Los Carriles pueden separar los elementos por rol (u otro criteriovase pagina 152).

PuntoClave: LosObjetosdeDato,ArtefactosyCarriles,proporcionanmayordetalle,describiendoeldesempeoocomportamientodelProceso,peronomodifican significativamente la estructura bsica (como fue definido porlosobjetosdeflujoyflujodesecuencia).


Categoras de Procesos Desde su descripcin, BPMN ha tratado de dar soporte a tres categoras principales de Procesos:

Orquestacin Coreografa Colaboracin

Estos trminos han variado, usualmente con conflictivos significados en los distintos contextos de negocio en los que son aplicados. Se ha tratado de definirlos para los propsitos de BPMN, y luego aplicarlos consisten-temente en este libro. Versiones futuras de BPMN harn distinciones ms claras entre estos tipos de procesos, incluyendo un robusto soporte de diagramas para cada aspecto.

Orquestacin En BPMN, los modelos de orquestacin tienden a implicar una perspecti-va nica de coordinacinpor ejemplo, representan una vista especfica del negocio u organizacin del Proceso. Como tal, un Proceso de orques-tacin describe cmo una nica entidad de negocio lleva a cabo las cosas. Utilizada principalmente en la comunidad tcnica, la Orquestacin del Proceso est habitualmente alineada con lenguajes de Servicios Web tal como BPEL.

La mayor parte de este libro explora los modelos de procesos orientados a la orquestacin. Tanto es as, que se referir a las orquestaciones simple-mente como Procesos. La figura 3-2 muestra un simple modelo de or-questacin.

Figura 3-2Una Orquestacin tpica de BPMN

Sin embargo, un diagrama BPMN puede contener ms de una orquesta-cin. En tal caso, cada orquestacin aparece dentro su propio contenedor llamado Pool (vase pagina 161). De esta manera, las orquestaciones (por ejemplo, los Procesos) estn siempre contenidos dentro de un Pool. Esta es una importante distincin al comprender la diferencia entre orquesta-cin y coreografa.

Adems, el hecho que los modelos de orquestacin estn contenidos en un Pool indica que consisten de elementos de procesos que coexisten de-


ntro de un contexto bien definido, o centro de control. Un modelo de or-questacin ejecutado por una Suite BPM cumple exactamente esta des-cripcin, pero tambin aplica a situaciones que no son parte de un sis-tema semiautomtico. Una consecuencia del contexto bien definido en una orquestacin, es que cualquier dato est disponible para todos los elementos del modelo.

Coreografa Un modelo de proceso de coreografa es una definicin del comportamien-to esperado (una clase de contrato procedimientos o protocolo) entre los participantes que interactan. Estos participantes pueden ser roles de negocio generales (por ejemplo, un despachador) o una entidad especfica de negocio (por ejemplo, FedEx como empresa de transporte).

Como en la definicin de un ballet, en BPMN una coreografa describe las interacciones de los participantes. En BPMN, una coreografa define la se-cuencia de interacciones entre dos o ms participantes. En BPMN, las in-teracciones son la comunicacin, a travs de la cual se intercambia un mensaje entre dos participantes.

Un modelo de coreografa BPMN comparte muchas de las caractersticas de un modelo de orquestacin en cuanto a que tienen un diagrama de flujo. Incluye tanto caminos alternativos y paralelos, as como Sub Proce-sos. De esta manera, los objetos de flujo (Actividades, Eventos, y Gate-ways) de los modelos de orquestacin tambin aplican a los modelos de coreografa.

Sin embargo, hay grandes diferencias entre los modelos de orquestacin y coreografa:

Una orquestacin est contenida por un Pool y normalmente en un contexto bien definido.

Una coreografa no existe dentro de un contexto bien definido o centro de control. No hay mecanismo central que gue o mantenga trazo de una coreografa. Por lo cual no hay datos compartidos disponibles para todos los elementos de la coreografa.

Para ubicar una coreografa dentro de diagramas BPMN, la forma es hacerlo entre los Pools.

La primera versin de BPMN (ahora 1.1) inclua algunos de los conceptos que dan soporte a los modelos de coreografa. Y si bien es posible obtener el comportamiento esperado de la coreografa, los elementos que se nece-sitan para una definicin completa todava no se han definido. BPMN 2.0 incluir soporte completo para diagramas de coreografa (distinto a los diagramas de orquestacin).


Figura 3-3Coreografa en BPMN (como se modela actualmente)

La figura 3-3 muestra la capacidad actual para la definicin de coreograf-a en BPMN 1.1. El diagrama muestra dos Pools, cada una contiene una orquestacin. Los conectores entre los Pools son el Flujo de Mensajes (vase pgina 165). La combinacin de Actividades y otros elementos de-ntro de los Pools y el Flujo de Mensajes entre los Pools definen una co-reografa implcita.

Se espera que BPMN 2.0 incluya un diagrama especfico de coreografa. En lugar de tener que obtener la coreografa a partir del intercambio de mensajes, ser posible modelarlo por si solo o ubicarlo entre los Pools.

Colaboracin La colaboracin tiene un significado especfico en BPMN. Mientras que la coreografa muestra el conjunto ordenado (protocolo) de interacciones en-tre los participantes. Una colaboracin puede contener tambin una co-reografa (cuando est disponible en BPMN) y una o ms orquestaciones.

Para ser ms especfico, una colaboracin es cualquier diagrama BPMN que contenga dos o ms participantes como se muestra con los Pools. Los Pools tienen Flujo de Mensajes entre ellos. Cualquiera de los Pools puede llegar a contener una orquestacin (un Proceso), pero no est requerido.

La figura 3-4 muestra un ejemplo de diagrama de colaboracin. Contiene dos Pools y Flujo de Mensajes entre ellos. Otros diagramas de colabora-cin pueden mostrar orquestaciones dentro de los Pools (como en la figu-ra 3-3).


Figura 3-4Ejemplo de colaboracin en BPMN


Captulo 4. Aspectos del Modelado

Resumen: Elpropsitodeestecaptuloesanalizaralgunasde lascuestionesasociadasalmodeladodeProcesosengeneral,eidentificaralgunosdelosdesafos que se presentan al tratar con estas cuestiones. El Apndiceasociado(TcnicasparalaArquitecturadeProcesos"enlapgina186)analizavariosdelosenfoquesdisponiblesquepuedenayudaralmodeladoraidentificarlaarquitecturaapropiadadeProceso. 5

Todos los Modelos son Errneos, Algunos son tiles Esta cita, muchas veces atribuida a Edwards Deming, pero en realidad originaria del menos conocido Charles Box, 5 describe la difcil situacin en la que se encuentran los modeladores. Existen una gran cantidad de maneras de modelar el comportamiento deseado, con cualquier nivel de precisin.

PuntoClave: Muchagenteasumequehaysiempreunmodelocorrecto(ydealgunamaneraelrestosonerrneos),sinembargo,raravezhayunnicomodelo correcto. Por otra parte, los modelos pueden ser invlidos (en elsentidodeunmalusodelanotacin).

Adems, usualmente hay muchos ms potenciales detalles que capturar que los que son necesarios. Si se tuviese que modelar cmo se prepara una taza de t, una sola Actividad podra ser suficiente. Alternativamente, se podra describir la necesidad de primero hacer hervir el agua, poner una bolsa de t en una taza y opcionalmente agregar leche. Pero si se quisiera preparar t para varias personas utilizando una tetera y hojas de t, o se debiera incluir los pasos para llenar la caldera, o agregar azcar. El modelador siempre debe tomar decisiones sobre qu incluir y qu no. Por lo que es necesario mantener una perspectiva sobre los usos del mo-delo y por quin ser interpretado.

Si el pblico (aquellos que leern e interpretaran el modelo) no estn in-teresados en los detalles, entonces no se incluirn en los modelos. En otras situaciones, como cuando el modelo soportar la ejecucin en una Suite BPM o cuando el objetivo es la simulacin, entonces un alto nivel de detalle es requerido.

<

5 A pesar de que esto se encuentra fuera del alcance del estndar BPMN, es de inters para los modeladores pues tienden a asumir que de algn modo BPMN los ayudar a decidir cuales pro-cesos existen en un dominio dado.

6 Charles Box lo utilize por primera vez como ttulo en un captulo de un libro en 1979 Cita: Box, G.E.P., Robustness in the Strategy of Scientific Model Building, in Robustness in Statistics, R.L. Launer y G.N. Wilkinson, Editors. 1979, Academic Press: New York.


Al comienzo de uno de los talleres se realiza un sencillo ejercicio. Se pide a los participantes que sugieran todas las ideas que quisieran represen-tar en los modelos de proceso. No transcurre mucho antes de completar un par de pizarrasactividades, flujos, entradas, salidas, responsabili-dades, costos, locaciones, calidad, reglas, interacciones, escalabilidad. Al preguntar a los delegados si quisieran que todas estas dimensiones apa-rezcan en un solo proceso, inmediatamente se dieron cuenta de que es cuestin de remover elementos de los modelos para hacerlos tiles.

PuntoClave: El modelador est constantemente tomando decisiones de modeladoacercadelpropsitodelmodeloydelpblicoalqueestdirigido. 6

Una historia anecdtica lo dejar en claro. Durante los das de Reinge-niera de Procesos de Negocio (BPR a veces referenciado a Reducciones de Personas Mayores), uno de los principales gigantes de la industria qumi-ca contrat a una de las firmas lderes en consultora para que los ayu-dara con la reingeniera de sus procesos de venta en Norteamrica. Lue-go de varios meses de trabajo, se realiz una presentacin para la reu-nin de directorio (pues este era un proyecto de gran importancia). Uno de los costados del saln de reuniones estaba cubierto por un diagrama de flujo de ochenta pies (el modelo tal cual ocurre). En la otra pared, un diagrama de flujo del proceso a ser. El entonces Presidente permiti a los Socios de Consultora culminar su presentacin antes de realizar una simple pregunta. Es ese un buen proceso? Y de ser as, por favor, explqueme porqu. Y es ah que surge la base del problema. El detalle dado era totalmente inapropiado para el pblico al que se estaba apun-tando.

Aqu hay algunos aspectos de un buen modelo:8

Selectivoningn modelo puede representar todo, debe repre-sentar selectivamente los aspectos que son ms relevantes de la tarea en cuestin.

ExactoEl modelo debe codificar exactamente el estado actual del negocio y no una nocin parcial o errnea.

Cuidadosamente completoEl modelo debe ser lo ms simple posible, pero no ms simple que eso.9

ComprensibleUna vez que se percibe el modelo se debera estar en condiciones de encontrarle sentido, no debera ser muy compli-cado o resultar poco familiar para comprender.

<

7 Algunos modeladores parecen sentir que la notacin debera proporcionar solo una forma de representar cualquier problema particular. Esto va en contra de la realidad y esperar que un nico modelo posible para un escenario dado es irrealista. Todos los modelos son un compromi-so. Habitualmente BPMN proporciona un grupo de funcionalidades para facilitar los diferentes propsitos y estilos de modelado.


Clemens contina haciendo referencia a algunos de los inconvenientes de la evolucin y adaptabilidad entorno al modelo. Como todos los modelos son, en algn punto, imprecisos, irrelevantes, errneos, sensibles al paso del tiempo, etc., deben estar abiertos a revisiones recursivas para reflejar nuevos datos, el creciente nivel de comprensin, o la evolucin de nues-tras necesidades.

Al final, los modelos deben ser tiles. Clemens contina diciendo, La utilidad es la suma de las propiedades descriptas antes y el grado en que estas se combinan para promover la comprensin y una accin efectiva. Es Importante notar que cuanto ms preciso, o ms completo, o ms ele-gante sea el modelo no significa que sea ms til. Todos los modelos son incompletos. Todos los modelos tiene compromisos. El arte de los que realizan los modelos radica en hacer esa compensacin de manera astuta, de forma tal que haga el modelo ms til para el problema en cuestin.

PuntoClave: Conelpropsitodesertiles, losmodelosrepresentanselectivamentealgunoselementosdelmundoreal.Elmodeladorexcluyediferentesdimensionesdeldominio(paralograrlasmetasdemodelado).

8 Marshal Clemens de la empresa de consultora, Idiagram, ofrece una excelente gua sobre las caractersticas que los modelos deben exhibir. No analiza BPMN, pero muchos de los puntos son an relevantes. http://www.idiagram.com/ideas/models.html

9 Aqu est parafraseando a Einstein.

Cuntos procesos, en dnde encajan? La tentacin siempre es comenzar directamente a modelar. Sin embargo, un enfoque ms detenido normalmente paga importantes dividendos.

El problema real es que as como las personas comienzan a describir la manera en que suceden las cosas en un rea de su organizacin, asumen que es todo un gran y nico proceso. Lo vemos usualmente en los talle-res. Los estudiantes intentan conectar todo en una descripcin de proce-so amorfa que captura toda posible alternativa.

PuntoClave: Habitualmente,esdifcilmodelarunprocesodeextremoaextremoparaunproblemadenegocioenparticular.Yaunqueesto fueseposible,seraundesafohaceresemodeloflexibleyadaptable.

Por lo general, es mucho mejor partir el dominio del problema en un nmero discreto de partes, que al trabajar juntas resuelven el problema. Por lo tanto la cuestin se reduce a cmo elegir las partes apropiadas. Al buscar tcnicas, se encuentran muy pocas.

Para una discusin ms amplia sobre los diferentes enfoques para orga-nizar, definir modelos, vase el Apndice Tcnicas para la Arquitectura de Procesos" en la pgina 186. All se plantean un conjunto de enfoques que, entre ellos, proporcionan una traduccin desde el nivel de estrategia del negocio directo a una arquitectura de procesos robusta (independien-temente de la estructura de reportes de la organizacin). Estas tcnicas


podran extenderse potencialmente a una pila de servicios de TI (como parte de una Arquitectura Orientada a Servicios).

El punto es que BPMN es agnstico a metodologas. Las organizaciones suelen tener una metodologa preferida para capturar y desarrollar sus procesos de negocio. No es el papel de BPMN dictar cmo la informacin de procesos de negocio es recolectada o cmo son llevados a cabo los proyectos. Por lo cual, BPMN soporta mltiples metodologas (siendo tan simples o tan complejas como se necesite que sean). No se especifica el nivel de detalle para los modelosel modelador, la herramienta de mode-lado, u la organizacin toman esta decisin. De hecho, como se ver ge-neralmente en el modelado de procesos; habitualmente existen diferentes maneras de modelar la misma situacin, con cualquier nmero de dife-rentes niveles de detalle.

PuntoClave: BPMNnoproporcionaconsejosacercadecmoestructurarundominioo lograr unaarquitecturaapropiadaparaunreadada.Sinembargo,proporciona funciones quepuedensoportarmuchosmtodosdiferentes.

Enfrentando la Complejidad en BPMN Como se puede ver con lo anterior, los modelos de proceso pueden vol-verse complejosmuy complejos (cubierto ms profundamente en el Apndice). Sin embargo, la mayora de los desarrolladores y lectores de los modelos de proceso desean un lenguaje sencillo y grfico para repre-sentar los procesos de negocio. De hecho, la mayora de los modelos de proceso son sencillos diagramas de flujo (cajas de actividad, puntos de decisin y conectores entre ellos). A la vez, los modeladores necesitan la flexibilidad suficiente para representar mayores niveles de complejidad de ser necesario.

El objetivo de la mayora de los proyectos de modelado de proceso es do-cumentar (comprender) y analizar los procesos clave de una organizacin. Sin embargo, estos mismos procesos pueden luego convertirse en las ba-ses para un conjunto ms detallado de descripciones de procesos para otros usos. Elaborados y construidos en base a mayor detalle, pueden llegar a convertirse en ejecutables (en una Suite BPM o herramienta de workflow).

Por ejemplo, un modelo ms bien simplista (originalmente desarrollado para una discusin de proceso de negocio), puede llegar a terminar sien-do adaptado para ser utilizado en establecer relaciones apropiadas con los socios (definiendo las interfaces), el cual luego es enriquecido y adap-tado por ambas partes para apoyar sus respectivos ambientes de ejecu-cin de procesos.

Dado que cada compaa o modelador podra querer mostrar diferentes niveles o reas de complejidad, la notacin debe ser lo suficientemente flexible para manejar prcticamente todos los posibles requerimientos de


las situaciones de negocio o de modelado. Pero el problema es que tal no-tacin de negocios, que fuese capaz de representar todas las situaciones de negocio, dejara de ser simple, sera compleja.

Este problema resalta la tensin que existe entre las dos principales me-tas de BPMN:

Por una parte, facilidad de uso para los usuarios y analistas del negocio.

Y por la otra, los procesos ejecutables. Para cumplir con los requerimientos de la primer meta, BPMN est con-formado por un pequeo conjunto de elementos (por ejemplo, Actividades, Eventos, y Gateways) que tienen formas que los distinguen (por ejemplo, rectngulo, crculo y diamante). El pequeo conjunto de elementos prin-cipales ayudan a la sencillez y legibilidad de los modelos.

Para cumplir con los requerimientos de la segunda meta, los elementos principales son especializados para propsitos particulares, cada uno de ellos contiene informacin y/o es apoyado por ms elementos que permi-ten lograr el modelado del comportamiento deseado. Adems, la estruc-tura semntica subyacente de BPMN debe ser rigurosa, contener infor-macin que permita la generacin de BPEL vlido; o al menos sentar las bases para que otras herramientas puedan completar el desarrollo y des-pliegue. 7

La especificacin BPMN incluye una gran cantidad de informacin y fun-ciones que lo hacen parecer complicado. Sin embargo, es muy poco pro-bable que una analista de negocio o un usuario final necesiten la mayor-a de estas funciones (pues se relacionan a la semntica de ejecucin). En este libro, se apuntar a los elementos de BPMN que incumben al Analista de Negocio, mientras que tambin se proporcionaran descripcio-nes de los elementos ms avanzados de BPMN.

PuntoClave: MientrasquelatcnicademodeladodeBPMNpuedeparecerunpocointimidanteparaalguienquerecincomienza,estancomplejacomosenecesitaqueseaconelfindeayudaralafacilidaddeusoparaelAnalistadeNegocioyparaelusuario;ya lavez,permitirconstruirmodelosquesoportenlaejecucindeprocesos.

<

10 Con una rigurosa definicin de la semntica de un modelo BPMN, algunas Suites BPM son capaces de ejecutar modelos de Procesos directamente, sin tener que traducirlo a un lenguaje intermedio como BPEL. Con la aparicin de BPMN 2.0 esta capacidad ser reforzada mientras que la semntica ser an ms rigurosa


Captulo 5. Introduccin a BPMN basada en es-cenarios

Resumen: EstecaptuloproveeallectorconunaintroduccingradualalaespecificacinBPMN,empezandoporunescenariodecompresinsencillaparaluego irconstruyendo lentamentesobrel, introduciendo lafuncionalidaddeBPMNenelcontextodescrito.

DiseadoparaaquellosquearribanaBPMNporprimeravez,este lespermite familiarizarse con los aspectos fundamentales de la Notacinsin abrumarlos con la complejidad de alguno de sus aspectos msesotricos.

Lamayorpartede lafuncionalidadest limitadaalconjunto ncleodeelementosdeBPMNconelcualunAnalistadelNegociodebeestarfamiliarizado.Esteconceptodelconjuntoncleoseexpandeen laseccinreferencias.

Construyendo un Proceso con BPMN El escenario central utilizado en este captulo gira en torno a una orga-nizacin ficticia Mortgage Co. Ellos toman solicitudes de potenciales clientes, realizan una evaluacin de si ofrecer o no la hipoteca, y final-mente rechazan la solicitud o realizan una oferta (ver Figura 5-1).8

Figura 5-1El escenario subyacente de oferta de hipotecas

Claramente, esta es una imagen bastante simplista de cmo dicho proce-so puede operar. Pero ser suficiente para proporcionar un marco que nos permita introducir la funcionalidad de BPMN. En el resto de esta parte del libro, vamos a construir sistemticamente sobre este escenario,

<

8 Todos los pargrafos sobre el escenario subyacente compartirn este estilo en la fuente (lige-ramente indentado y en cursiva).


embelleciendo la historia e introduciendo las caractersticas apropiadas de modelado con BPMN para representar el comportamiento deseado.9

El Proceso empieza a la izquierda con un Evento de Inicio (crculo de borde fino), con dos Actividades (rectngulos redondeados) conectadas al Evento de Inicio. La primer Actividad es una Tarea y la segunda repre-senta un Sub-Proceso. Siguiendo una decisin, representada por el rom-bo (llamado Gateway Exclusivo), el Proceso se ramifica en Ofrecer Hipo-teca o Enviar Rechazo (ambas representadas como Tareas simples). Ambas ramas conducen a un Evento de Fin (crculo de borde grueso).

Los Eventos de Inicio representan los lugares en los que un Proceso pue-de iniciar, los Eventos de Fin representan diferentes resultados, algunos que pueden ser deseados y otros que no. Un Gateway Exclusivo repre-senta una decisin binariasolo una secuencia de flujo de salida puede evaluarse como verdadera. A los efectos de este modelo, las tres Tareas representan pasos simples atmicos, mientras que el Sub-Proceso co-lapsado tiene un nivel superior de detalle.

Mas detalles sobre los elementos introducidos estn disponibles en la Seccin de Referencia de BPMN:

Eventos de Inicio en la pgina 82 Tareas en la pgina 65. Sub-Procesos en la pgina 66. Gateways Exclusivos en la pgina 130. Eventos de Fin en la pgina 119. Flujo de Secuencia en la pgina 161.

Estableciendo Temporizadores Ahora, asumamos que queremos representar el hecho de que nuestro cliente potencial contact a Mortgage Co para pedir un formulario de so-licitud de hipoteca. Por el momento no nos preocuparemos en la forma en cmo contactaron a la compaa, asumamos que es un mensaje de algn tipo. Adicionalmente, queremos establecer un temporizador para enviarles un recordatorio si Mortgage Co no recibi la solicitud luego de siete das (ver Figura 5-2).

<

9 Nos referimos a los elementos grficos de BPMN con las letras inciales en mayscula. Cuando un concepto importante de BPMN es referenciado (que no es un elemento grfico), utilizamos cursiva en la frase.


Figura 5-2Se introduce un Evento de Inicio de tipo Mensaje y un Evento Intermedio de tipo Temporizador.

El Proceso ahora empieza con un Evento de Inicio de tipo Mensaje que representa el mensaje recibido por Mortgage Co quien luego enva el for-mulario de solicitud; un temporizador se sita en la tarea de espera para interrumpirla y enviar un recordatorio y luego volver a esperar al formu-lario de solicitud nuevamente.

Hay varios tipos de Eventos de Inicio en BPMN; aqu utilizamos un Even-to de Inicio de tipo Mensaje para indicar como empieza este Proceso. Los Eventos Intermedios situados en los lmites de una Tarea significan que si el Evento se dispara, este interrumpir a la Tarea y enviar el Proceso a su Flujo de Secuencia de salida. Si la Tarea finaliza antes de que se dispare el Evento Intermedio, entonces el Proceso se mueve normalmente (siguiendo el flujo normal del Proceso). El bucle es creado explcitamente con un Flujo de Secuencia aunque, como descubriremos luego, existen alternativas (por ejemplo, utilizar una Tarea de tipo Bucle).


Evento de Inicio Mensaje en la pgina 86. Interrupcin de Actividades mediante Eventos en la pgina 96. Eventos Intermedios Temporizador en la pgina 99. Bucle en la pgina 73.

Hay otra manera de modelar este escenario utilizando un Sub-Proceso para enviar el formulario de solicitud y esperar por la respuesta. Figura 5-3.


Enviar Formulario de Solicitud & Recordatorios

EnviarFormulario de

Solicitud

EnviarRecordatorio

RecibirFormulario de

Solicitud

7 Das

Pedido deSolicitud

Figura 5-3Utilizando un Sub-Proceso para representar el formulario de solicitud y los recordatorios

El Evento Intermedio de Tipo Temporizador que se muestra en lnea con el Flujo de Secuencia se dispara ni bien comienza el Sub-Proceso (el Sub-Proceso se muestra en su forma expandida). Espera siete das antes que de ese hilo de actividad se mueva a la tarea Enviar Recordatorio antes de volver a esperar siete das. Cuando un Evento Intermedio de Tipo Temporizador se utiliza en lnea (como en este caso), este puede tener slo un Flujo de Secuencia de entrada y de salida. Por lo tanto, para unir el Flujo de Secuencia de entrada antes del Evento Intermedio de tipo Temporizador se requiere un Gateway Exclusivo. Cuando se une un Flujo de Secuencia con un Gateway Exclusivo, los tokens entrantes pasan in-mediatamente por cualquier Flujo de Secuencia de entrada, por lo que en este caso este Gateway no representa ningn tipo de retraso.

Por supuesto, hay otros objetos de flujos (Actividades o Gateways) que pueden tener normalmente varios Flujos de Secuencia de entrada y de salida. Si bien el Sub-Proceso podra haber incluido un Gateway Paralelo para crear la divisin (ver Figura 5-4), es innecesario porque el Flujo de Secuencia no requiere control. La Figura 5-3 y la Figura 5-4 describen exactamente el mismo comportamiento. Una regla general es que se re-quiere Gateways nicamente cuando los Flujos de Secuencia requieren control.


EnviarFormulario de

Solicitud

EnviarRecordatorio

RecibirFormulario de

Solicitud

El GatewayParalelo es

innecesario porqueel Flujo de

Secuencia no requiere control en

este punto

7 Das

Figura 5-4Utilizar un Gateway Paralelo es innecesario


El Sub-Proceso termina con un Evento de Fin de tipo Terminacin. El Evento de Fin de tipo Terminacin causa la inmediata finalizacin del Proceso en su nivel actual (y niveles infereriores) incluso si an existen actividades realizndose. Efectivamente, termina el bucle de recordatorios.


Eventos Intermedios de Tipo Temporizador en la pgina 99. Eventos De Fin de tipo Terminacin en la pgina 119. Gateways Paralelos en la pgina 137. Anotaciones de Texto en la pgina 159.

Ejercicio Uno Intente modelar este proceso; ayudar a asegurar que las tcnicas discu-tidas hasta el momento sean asimiladas:

Cadamaana laborable, labasededatosserespalday luegoseverificasi latablaCuentasMorosastienenuevosregistros.Sinoseencuentrannuevosregistros,entonceselprocesodebeverificarelsistemadeAtencinalCliente(CRM)paraversisearchivaronnuevasdevoluciones.Siexistennuevasdevolucionesentoncessedebenregistrartodaslascuentasyclientesmorosos.Siloscdigosdelosclientesmorososnofueronpreviamenteadvertidos,entoncessedebeproducirotratablaconlascuentasmorosasyenviarlaalaadministracindecuentas.Todoestodebecompletarseparalas2:30pm,sinoesas,entoncessedebeenviarunaalertaalsupervisor.Unavezquesehayacompletadoelnuevoreportedecuentasmorosas,sedebeverificar el CRM para ver si las nuevas devoluciones fueron archivados. Si nuevasdevolucionesfueronarchivadas,sedebevolveraconciliarconlatablaexistentedecuentasmorosas.Estodebecompletarseparalas4:00pm,encasocontrariosedebeenviarunmensajeaunsupervisor.

Bucles Hasta ahora, el bucle se expres utilizando Flujos de Secuencia explcitos volviendo a una parte anterior del Proceso. BPMN provee otro mecanismo para representar este tipo de comportamientoLa Tarea Bucle (ver Figura 5-5). Una Tarea Bucle tiene una pequea flecha semicircular que se dobla hacia s misma.

EnviarFormulario de

SolicitudPedido deSolicitud

RealizarEvaluacin

Esperar alFormulario de

Solicitud

Figura 5-5Una Tarea Bucle sencilla


Es posible establecer atributos BPMN para mantener comportamientos de iteracin sofisticados.10 Esto es necesario para apoyar la complejidad necesaria que se requiere en simulaciones y en ambientes de ejecucin de procesos. Estos aspectos son discutidos en detalle en la Seccin de Referencia de BPMN.

Claramente no tiene mucho sentido iterar indefinidamente esperando un formulario de solicitud que puede no llegar nunca. Entonces, des-pus de dos recordatorios, Mortgage Co decide cancelar la solicitud y archivar los detalles.

En la Figura 5-6 existe otra manera de establecer el contador de iteracio-nes. En lugar de utilizar una tarea modelada grficamente como Esta-blecer Contador de Iteraciones, la Tarea Enviar Recordatorio podra establecer una asignacin al nivel de los atributos. Aunque sea invisible, una anotacin podra destacar su existencia.

Vale la pena destacar que la iteracin con Flujos de Secuencia explcitos no puede volver al Evento de Inicio. De hecho, los Eventos de Inicio no pueden tener Flujos de Secuencia de entrada. El bucle solo puede iterar hasta la primer Tarea.

Esperar alFormulario de

Solicitud

EnviarRecordatorio

7 Days

EstablecerContador

Iteraciones

ConteoIteraciones

=3?

Si

No

NotificacinFinal

EnviarFormulario de

SolicitudPedido deSolicitud

ArchivarDetalles

RealizarEvaluacin

DetallesArchivados

Figura 5-6Se establece un contador de iteraciones y luego de dos iteraciones se archivan los detalles y el Proceso finaliza

<

10 Bucles y otros atributos de elementos almacenan informacin sobre el Proceso que no se muestra grficamente.



Bucle en la pgina 73.

Decisiones Basadas En Eventos Por supuesto que si el cliente no devuelve el formulario de solicitud, el proceso nunca llegar a la fase de evaluacin. Pero qu pasara si el cliente deja saber a Mortgage Co que no quiere proceder con la hipo-teca. El modelo en la Figura 5-6 no representa adecuadamente este es-cenario que es ligeramente diferente.

Ahora, luego de enviada la solicitud, Mortgage Co espera que una de tres diferentes cosas suceda. O bien reciben la solicitud (se mueve a la Tarea Realizar Evaluacin), o se les notifica que el cliente no desea continuar (en cuyo caso Archivar Detalles), o despus de 7 das se les enva un recordatorio (dos veces antes de enviar un aviso final y archi-var los detalles).

Si bien es posible modelar tal escenario utilizando Actividades, Flujos de Secuencia y Gateways Exclusivos, el modelo se volvera muy desordenado y complejo. Hay otra manera de modelar esta situacin, utilizando un Gateway Exclusivo Basado en Eventos (ver Figura 5-7).

Figura 5-7Utilizando un Gateway Exclusivo Basado en Eventos

El Gateway Exclusivo Basado en Eventos (o informalmente, el Gateway de Eventos) y los Eventos Intermedios que lo siguen son vistos como un


todo (la lnea punteada alrededor de ellos es un grupo de BPMN utilizado para enfatizar nicamente). Para diferenciarlo de otros Gateways, El Ga-teway de Eventos reutiliza el marcador de Eventos Intermedios Mltiples en el centro del diamante. El Gateway espera que uno de los eventos pos-teriores ocurra. O bien se recibe un mensaje (Evento Intermedio de tipo Mensaje) indicando que el cliente est No Interesado o ocurre el Evento Intermedio de tipo Mensaje Solicitud Recibida (y el Proceso puede pro-gresar), o el temporizador finaliza y el resto del bucle se inicia. Otro Sub-Proceso podra representar el resto del bucle.

Observar que el Sub-Proceso colapsado Archivar Detalles aparece dos veces en el diagrama. Este Sub-Proceso se diseo como un Sub-Proceso reutilizable. Puede aparecer en otros Procesos fuera del alcance de este. De hecho, representa un proceso independiente referenciado por ste. Por supuesto, se podra reorganizar el diagrama para utilizar solo una actividad en este modelo.


Gateways Exclusivos Basados en Eventos en la pgina 134. Eventos Intermedios Mensaje en la pgina 103 Grupos en la pgina 156. Eventos Intermedios Mltiples en la pgina 118.

Alcanzando SLAs Ahora asumamos que Mortgage Co recibe el formulario de solicitud y decide promover un Acuerdo de Nivel de Servicio con el cliente. Ahora se compromete a responder con una oferta o un rechazo dentro de los 14 das desde la fecha de recepcin del formulario de solicitud. En apoyo de esto, el Proceso debe alertar al gerente luego de 10 das si no ha terminado an, y luego todos los das. Asimismo, es necesario ar-chivar los detalles si la decisin fue de rechazar la solicitud (antes del fin del Proceso).

Pensando en la alerta, la primer tentacin es probablemente la de utilizar un Sub-Proceso y luego adjuntarle un Evento Intermedio de tipo Tempo-rizador en el borde para crear la alerta (similar a la Figura 5-2 en la pgina 40). El problema de este enfoque es que interrumpir el trabajo del Sub-Proceso, y una iteracin hacia el principio causar que el trabajo empiece nuevamente (no es el comportamiento deseado). El trabajo no debe parar solo para dar aviso de la alerta al gerente. La Figura 5-8 muestra un enfoque para resolver este problema.


Figura 5-8Un enfoque para el problema de la alerta sin interrup-cin

Un camino (o hilo) independiente con un Evento Intermedio de tipo Tem-porizador vinculado al Evento de Inicio del Sub-Proceso es un enfoque posible para crear la alerta sin interrupcin. El temporizador se inicia luego de 10 das si el trabajo del otro hilo no terminen caso de que se complete el trabajo, uno de los Eventos de Fin de tipo Terminacin aca-bar con el temporizador. De hecho, se produce una condicin de carrera entre estas dos vertientes del proceso. Una vez que se produjo la Tarea Alertar al Gerente espera un da antes de iterar nuevamente.

Representando Roles en los Procesos La Tarea Alertar al Gerente, arriba en la Figura 5-8, parece indicar que el gerente recibe un mensaje. Sin embargo, los mensajes tienen una im-portancia especial en BPMN. Los Flujos de Mensajes pueden moverse so-lo entre distintos participantes en una situacin negocio-a-negocio. Cada participante opera un Proceso separado representado por Pools. Los Flu-jos de Mensajes coordinan los Procesos de cada participante.

Esencialmente, un Proceso existe dentro de un nico Pool. Cuadros eti-quetados presentan al Pool; tambin tienen esquinas cuadradas contra-riamente a las Tareas y los Sub-Procesos que tienen esquinas redondea-das. BPMN utiliza Pools para representar la interaccin entre una organi-zacin y participantes fuera de su control. Dentro de una empresa, un nico Pool cubre sus operaciones internas es solo cuando se interacta con participantes externos que se requieren Pools adicionales.11

<

11 Pools separados pueden utilizarse cuando una organizacin tiene varias unidades de negocio independientes que se encuentran colaborando. En tal situacin, cada unidad de negocio no necesariamente conoce el funcionamiento interno de las otras, teniendo que identificar las inter-faces entre ellas.


Por ejemplo, en el caso de la Mortgage Co, la Agencia Crediticia (y el Cliente) tendra un Pool separado (suponiendo se que se intentaba re-presentar las interacciones entre las partes).


EnviarFormulario de

Solicitud

Enviar Recordatorio

Bpmn 2.o manual de referencia y guía practica.pdf

Documents

Transcript of Bpmn 2.o manual de referencia y guía practica.pdf