BPMN Business Process Modeling Notation

BPMN Business Process Modeling Notation Por: Márcio Balduino Leitão marcio@gnofi.com.br mbalduinol@gmail.com Business Process Modeling Notation Página 1

É proibida a reprodução total ou parcial desta obra, de qualquer forma ou meio eletrônico, mecânico, fotográfico e gravação ou qualquer outro, sem a permissão expressa da GNOFI TECNOLOGIA Business Process Modeling Notation Página 2

Sumário 1. Tipos de Diagramas de Processo de Negócio 5 1.1. Privative (internal) business process 5 1.2. Abstrat (Public) Process 5 1.3. Colaboration (Global) Process 6 1.4. Elementos de um BPD 7 1.5. Elementos essenciais 7 2. Modelando Eventos de Negócio 12 2.1. Notação básica de tipo de eventos 12 2.2. Eventos mais complexos 12 3. Processo de Negócio, Subprocessos e Tarefas 15 3.1. Decompondo seu processo dentro de hierarquias 15 4. Token 20 5. Ciclo de Vida da Atividade 22 6. Modulando Pontos de Decisões com Gateways 22 7. Pools e Lanes Quem faz o quê? 39 7.1. Um POOL pode representar muitas coisas 40 Aprendendo BPMN por meio de um Exemplo 41 Referências 50 Business Process Modeling Notation Página 3

Objetivo O objetivo deste curso é apresentar os elementos da notação de modelagem de processos de negócio BPMN 1.1 (Business Process Modeling Notation) mostrando-os por meio de exemplos práticos. O que é processo Processo é qualquer atividade ou conjunto de atividades que toma uma entrada, adicionando a esta um valor, e fornece uma saída gerando um produto valorado. Então, em um processo são conhecidos os passos a serem seguidos, as sequências em que eles acontecerão, as pessoas (ou perfil) envolvidas em todas as atividades e o produto final a ser produzido. "Os processos utilizam os recursos da organização para oferecer resultados objetivos aos seus clientes" (Harrington, 1991). "Um processo é um grupo de atividades realizadas numa sequência lógica com o objetivo de produzir um bem ou um serviço que tem valor para um grupo específico de clientes" (Hammer e Champy, 1994). Business Process Modeling Notation A especificação da notação de modelagem de processos de negócio (BPMN) fornece uma notação gráfica para expressar os processos de negócio em forma de diagrama de processo de negócio (BPD). O objetivo do BPMN é dar suporte ao gerenciamento de processo de negócio, tanto para os usuários técnicos quanto para os usuários de negócio, fornecendo uma notação intuitiva para os usuários, tornando-os capazes de representarem semânticas de processos complexos. Business Process Modeling Notation (BPMN) é uma notação gráfica que descreve a lógica dos passos de um processo de negócio. Essa notação tem sido especialmente desenhada para coordenar a sequência dos processos e as mensagens que fluem entre os participantes das diferentes atividades. Business Process Modeling Notation Página 4

Por que é importante Modelar com BPMN? BPMN é um padrão internacional de modelador de processos aceito pela comunidade. BPMN é independente de qualquer metodologia de modelador de processos. BPMN cria uma ponte padronizada para diminuir a lacuna entre os processos de negócio e sua implementação. BPMN permite modelar o processo de uma maneira unificada e padronizada. 1. Tipos de diagramas de processo de negócio (BPD) A modelagem de processo de negócio é usada para comunicar uma ampla variedade de informações para uma ampla variedade de público. O BPMN está projetado para cobrir muitos tipos de modelagens e permite a criação de um processo de negócios de ponta a ponta. Os elementos estruturais do BPMN permitirão ao observador ser capaz de facilmente identificar as seções de um diagrama de BPMN. Existem três tipos básicos de diagrama de processo de negócio (BPD): 1.1 - Private (internal) business process ou diagramas de processo de negócios privados. Nós o utilizamos quando não é do nosso interesse a interação desse processo com outros com os quais ele possa interagir. Estamos preocupados com o teor deste fluxo em si. 1.1. 1.2 - Abstract (Public) Process ou processos abstratos, representam uma interação entre um processo de negócio privativo e outro processo ou participante. Não estamos preocupados com o conteúdo do fluxo em si, mas sim como ele colabora com os outros fluxos dentro de um sistema Business Process Modeling Notation Página 5

1.3 - Colaboration (Global) Process O processo colaborativo descreve a interação entre dois ou mais entidades do negócio. Estas interações são definidas como uma sequência de atividades que representa o padrão de trocas de mensagens entre as atividades envolvidas. O processo colaborativo pode ser entendido como sendo dois ou mais processos abstratos comunicando entre si. E no processo abstrato, as atividades que são as participantes na colaboração podem ser consideradas como sendo os pontos de contato entre os participantes. Business Process Modeling Notation Página 6

1.4 - Elementos de um BPD O principal objetivo para o desenvolvimento do BPMN é que fosse uma notação simples e adaptável para os analistas de negócio. Para ajudar a entender como o BPMN pode gerenciar as necessidades da organização, a lista de elementos gráficos do BPMN é apresentada em dois grupos. Primeiro, existe a lista de elementos essenciais (CORE ELEMENTS) que irá suportar os requerimentos necessários para uma notação simples. Estes são os elementos que definem o layout básico do BPMN. Muitos processos de negócios poderão ser modelados adequadamente com estes elementos. Segundo, existe uma lista completa de elementos, os quais ajudarão a suportar requerimentos de uma poderosa notação para gerenciar situações de modelagem mais avançadas. 1.5 - Elementos essenciais Enfatizando, novamente, que o objetivo do desenvolvimento do BPMN foi o de permitir por meio de um mecanismo simples a criação de modelos de processos de negócio, enquanto que ao mesmo tempo seja capaz de manipular a complexidade inerente de um processo de negócio. A abordagem empregada para manipular estes dois requerimentos conflitantes foi organizar as figuras gráficas para anotação dentro de categorias específicas. O BPMN fornece um pequeno conjunto de categorias para que o usuário (leitor) possa facilmente identificar os tipos básicos dos elementos e entender o diagrama. Dentro dessas categorias básicas de elementos, informações e modificações adicionais podem ser adicionadas para apoiar as necessidades da complexidade sem alterar drasticamente a aparência do diagrama. As quatros categorias dos elementos são: Objetos de Fluxo (Flow Objects) Objetos de Conexão (Connecting Objects) Raia de piscina (Swimlanes) Artefatos (Artifacts) 1.5.1 - Objetos de Fluxos (Flow Objects) Os objetos de fluxos são os principais elementos gráficos para definir o comportamento do processo de negócio. Existem três tipos de objetos de fluxos: Eventos (events) Atividades (Activities) Decisões (Gateways) 1.5.2 - Objetos de Conexão (Connecting Objects) A conexão dos objetos de fluxos com outra informação é realizada por meio de três objetos: Fluxo de sequência (sequence Flow) Fluxo de mensagem (Message Fluxo) Business Process Modeling Notation Página 7

Associação (Association) 1.5.3 - Raia de piscina (Swimlanes): Existem duas maneiras de agrupar os elementos de modelagem básica por meio dos Swimlanes: Pool (piscina) Lane (raia) 1.5.4 - Artefatos (Artifacts) Os artefatos são usados para fornecer informações adicionais sobre o processo. Existem quatro artefatos padronizados, mas os fabricantes de software de modelagem estão livres para adicionar outros artefatos. O conjunto corrente de artefatos inclui: Objeto de Dados (Data Object) Grupos (Group) Anotação (Annotation) Business Process Modeling Notation Página 8

Lista dos elementos essenciais de modelagem que são descritas na notação: Objetos de Fluxos (Flow Objects) Elemento Descrição Notação Eventos (events) Atividades (Activities) Decisões (Gateways) Um evento é alguma coisa que acontece durante o curso de um processo de negócio. Esses eventos afetam o fluxo do processo e usualmente tem uma causa (Gatilho) ou um impacto (resultado). Eventos são representados por círculos vazados para permitir sinalização que identificarão os Gatilhos ou resultados. Existem três tipos eventos: Inicio Intermediário Final Atividade é um termo genérico para o trabalho que a empresa realiza. Uma atividade pode ser atômica ou não atômica (composta). Os tipos de atividades que fazem parte de um processo de negócio são: Processos, Subprocessos e Tarefas. Tarefas e Sub-Processos são representados por um retângulo arredondado. Os processos podem ser representados ou por um retângulo arredondado ou incluído dentro de um POOL. Uma Decisão é usada para controlar as ramificações e os encontros dos Fluxos de sequência (sequence Flow). Desta forma, ele irá determinar as ramificações, consolidações e união dos caminhos. A sinalização gráfica interna ao desenho irá indicar o tipo de comportamento da decisão. Objetos de Conexão Fluxo de sequência (sequence Flow) O Fluxo de seqüência é usado para mostrar a ordem em que as atividades serão processadas. Business Process Modeling Notation Página 9

Raia de piscina (Swimlanes) Artefatos (Artifacts) Fluxo de mensagem (Message Fluxo) Associação (Association) Pool (piscina) Lane (raia) Objeto de Dados (Data Object) Grupo (Group) Uma caixa que circunda um grupo de objetos para propósito de documentação Um Fluxo de mensagem é usado para mostrar o fluxo de uma mensagem entre dois participantes que estão preparados para mandar ou recebê-las. No BPMN, dois Pools (piscinas) no diagrama representam os dois participantes. Uma Associação é usada para relacionar informações com os objetos de fluxo. Textos e gráficos que não fazem parte do fluxo podem ser associados com os objetos de fluxo. Um Pool (piscina) representa um participante dentro do processo. Ele também atua como uma Swimlane e um recipiente gráfico para separar um conjunto de atividades de outro Pool, geralmente em um contexto de situação de B2B. Uma Lane (raia) é uma subpartição dentro de um Pool (piscina) e irá ampliar o tamanho de um Pool (piscina) horizontalmente ou verticalmente. Lane (raia) são usadas para organizar e categorizar as atividades. Objetos de Dados (Data Object) são considerados artefatos porque eles não têm nenhum efeito direto sobre o fluxo de sequência ou fluxo de mensagem do processo, mais eles podem fornecer informações sobre o que a atividade necessita para ser executada ou/e o que elas produzem. É um agrupamento de atividades que não afeta a sequência do fluxo. O agrupamento pode ser usado para o propósito de documentação ou análise. Os Grupos (Group) podem também ser usados para identificar as atividades de uma transação distribuída através de várias Pools. Business Process Modeling Notation Página 10

Anotação (Annotation) Ligada com uma associação Uma Anotação (Annotation) de texto é um mecanismo para que o modelador forneça informações adicionais para facilitar a leitura do diagrama por parte do usuário. Business Process Modeling Notation Página 11

2. Modelando Eventos de negócio Durante a modelagem de negócio, você modela eventos que acontecem no seu negócio e mostra como eles interferem no fluxo do processo. Um evento pode ser o ponta-pé inicial de um processo, pode acontecer durante o fluxo do processo e finalizar o processo. O BPMN fornece uma notação diferente para cada um desses tipos de eventos como mostrado na tabela abaixo: 2.1 Notação básica de tipos de eventos Evento de Início Evento Intermediário (Start Events) (Intermedate Events) Inicia um processo Acontece durante o curso de um processo Evento de Fim (End Events) Finaliza o fluxo do processo 2.2 Eventos mais complexos Quando você modela fluxos de processos mais complexos, você necessita modelar eventos de processos mais complexos também, tais como mensagens, cronômetros ou temporizadores, regras de negócios e condições de erro. O BPMN permite que você especifique o tipo de Gatilho (start) do evento e o simbolize com um ícone representativo, como especificado na tabela abaixo. Especificar um tipo de gatilho para um evento coloca certas restrições no fluxo de processo que você está modelando, conforme especificado na tabela. Por exemplo, um temporizador não pode ser usado para finalizar um fluxo do processo. Evento de Início Mensagem de início Temporizador de início Regra de início Evento Intermediário Mensagem Temporizador Regra Evento de Fim Mensagem de fim O temporizador não pode ser um evento de fim A regra não pode ser um evento de fim Descrição Uma mensagem de início chega de um participante ou gatilho de início do processo, ou continua o processo, neste caso um evento intermediário. Uma mensagem de fim denota a mensagem que será gerada ao fim do processo. Um tempo específico ou ciclo (por exemplo, a cada segunda-feira às 9:00AM) pode ser ajustado para realizar o início de um processo, ou a continuação do processo, no caso de evento intermediário. O evento é iniciado quando a condição da regra for verdadeira, tal como faça novo pedido quando a quantidade do estoque for menor de 10%. Business Process Modeling Notation Página 12

A Ligação não pode ser um evento de Início Ligação A Ligação não pode ser um evento de fim É usado para conectar atividade de um mesmo processo com a finalidade de deixar o diagrama mais limpo. Múltiplo Início Múltiplo Múltiplo Fim Para um evento de múltiplo início, existem múltiplas maneiras de desencadear o processo, ou de continuar o processo, no caso do evento intermediário. Somente uma delas é necessária. O atributo do evento define qual gatilho é acionado. Para Múltiplo Fim, existe múltiplas consequências na finalização do processo, todos os quais irão ocorrer, como por exemplos, múltiplas mensagens enviadas. Um evento de exceção no fim informa ao mecanismo do processo que um erro deverá ser criado. Este erro deverá ser um evento e exceção intermediária. No evento de exceção intermediária ele só poderá ser usado conectado na borda de uma atividade. A exceção não pode ser um evento de Início Exceção Exceção no fim Uma Compensação não pode ser um evento de Início Compensação Compensação no fim Um evento de compensação de fim informa ao mecanismo do processo que uma compensação é necessária. Assim o identificador da compensação é usado pelo evento intermediário quando o processo está sofrendo um roll back. Um cancelamento não pode ser um evento de Início Não se aplica Sinal de Inicio Cancelamento Cancelar no fim O evento de fim significa que o usuário decidiu cancelar o processo. O processo é finalizado com um tratamento de evento normal. Este tipo de fim indica que todas as Terminar atividades dentro do processo deverão ser Não se aplica imediatamente finalizadas. Isto inclui todas as instâncias das múltiplas instâncias. O processo é finalizado sem compensação ou tratamento de evento. Sinal Sinal no fim Um sinal é usado para gerar comunicação dentro ou por meio de níveis de processos, Pools e entre diagramas de processos. Business Process Modeling Notation Página 13

3. Processo de Negócio, Subprocessos e Tarefas Um dos pontos-chave da modelagem de processos de negócios é o próprio processo. Existem três tipos de processos O processo, o Sub-Processo e a Tarefa. Todas elas são desenhadas graficamente pelo mesmo símbolo retangular de bordas arredondadas; o uso de diferentes nomes simplesmente reflete a hierarquia do relacionamento entre eles 3.1. Decompondo seu processo dentro de hierarquias Um processo é uma rede de ações acontecendo. No BPMN você o desenha com um retângulo arredondado como sendo seu nível mais alto no diagrama de processo de negócio. Você pode especificar os detalhes internos do processo criando ou ligando-o a outro diagrama de processo de negócio. Um processo que tem um diagrama filho recebe um sinal de + no seu desenho. Graficamente mostramos os detalhes de um processo como outro diagrama de processo de negócio que é considerado como decomposição do processo. Você pode continuar a decompor processo sem nenhuma restrição. Processos que você desenha como sendo diagrama filho são considerados Subprocessos. O menor nível do processo, o qual não pode ser mais decomposto, é considerado como sendo uma tarefa. Uma atividade representa o trabalho realizado dentro de um processo. Uma atividade normalmente levará algum tempo para ser realizada, envolverá pessoas e recursos (sistema de informática - Aplicação) e normalmente irá produzir algum tipo de saída. Atividades Tarefa Genérico ou Indefinido, Frequentemente usado durante o estágio inicial do desenvolvimento do processo. Manual, é uma Tarefa não-automática realizada por humano fora do controle do WorkFlow ou da solução BPM. Business Process Modeling Notation Página 14

Receber Mensagem, espera uma mensagem chegar de um participante externo (relacionado com o processo de negócio). Uma vez recebida a tarefa é completada. Seu comportamento é similar ao evento de chegada de mensagem. Script, realiza um Script. Envia Mensagem, dispara uma mensagem a um participante externo. Uma vez enviada a mensagem a tarefa é completada. Seu comportamento é similar ao evento de envio de mensagem. Serviço, ligado a algum serviço, o qual pode ser um web service ou uma aplicação automática. Usuário, típica tarefa realizada por um humano com auxílio de uma aplicação. Atividades Subprocesso Business Process Modeling Notation Página 15

Estado Contraído Estado Expandido LOOP PADRÃO Uma atividade de loop padrão terá uma expressão booleana que é avaliada para cada ciclo do loop. Se a expressão for VERDADEIRA, então o loop irá continuar. Existem duas variações do loop, as quais refletem no construtor de programação WHILE(enquanto) e UNTIL(até). O loop WHILE avalia a expressão antes que a atividade seja realizada, isto significa que a atividade talvez não seja realizada. O loop UNTIL irá avaliar a expressão após a realização da atividade, isto significa que atividade vai ser realizada pelo menos uma vez. O exemplo a seguir mostra uma situação típica de loop em processo, Aplicando uma atividade de loop (neste caso um subprocesso) o fluxo ficaria: Business Process Modeling Notation Página 16

A expressão booleana seria O produto não passou no teste? se a resposta for verdade então a atividade será realizada novamente e se for Falsa o processo seguirá seu fluxo. Loop Multi-Instance Loop Multi-Instance reflete o construtor de programação de cada uma. A expressão de avaliação para um loop Multi-Instance é uma expressão numérica avaliada somente antes que a atividade seja realizada. O resultado da avaliação da expressão será um número inteiro que especificará o número de vezes que a atividade se repetirá. Existem também duas variações para o loop Multi- Instance onde a estância será realizada sequencialmente ou paralelamente. Graficamente é representado por três linhas verticais A quantidade de vezes que a atividade vai ser realizada é conhecida antes de ativá-la. Cada atividade realizada é distinta das outras. É usado quando desejamos realizar uma atividade várias vezes com um conjunto de dados diferentes. As Instâncias podem ocorrer sequencialmente ou em paralelo. Atributos devem definir estas características. Exemplo: Quando uma matriz de uma empresa está verificando os resultados financeiros de todas suas filiais. A condição de loop seria a quantidade de filiais que serão analisadas. Business Process Modeling Notation Página 17

AD HOC Uma atividade Ad HOC é identificada por um ~. Mas atividades (tarefas) em seu interior são soltas, ou seja, elas não são conectadas, isto significa que estas atividades podem ocorrer em qualquer ordem e várias vezes e não existe a obrigatoriedade de executar todas as tarefas. Geralmente este tipo de atividade está relacionado com atividades humanas, onde a ordem, a quantidade de vezes e quais atividades serão realizadas, são decididas por quem as realiza. No próximo exemplo temos um subprocesso que é realizado por um estagiário de um escrito de advocacia, ele terá que montar uma pasta com todos os documentos pertinentes ao processo que o referido escritório irá trabalhar. Para realizar este trabalho ele precisará tirar fotocópias dos documentos originais, tem que levá-los para reconhecimento de firma em cartórios, pode passar fax, etc e não existe uma sequência definida. Cada tarefa pode ser realizada quantas vezes forem necessárias, para o cumprimento da atividade Montagem de Processos Jurídicos. Business Process Modeling Notation Página 18

4. Token Para ajudar-nos na compreensão do comportamento fundamental do modelo do BPMN usaremos o conceito de TOKEN. Token pode ser concebido como o objeto Teórico que nós usamos para criar um comportamento descritivo do comportamento simulação dos elementos de fluxo da notação BPMN. Utilizando este artifício podemos descrever como este teórico componente viaja por meio do fluxo de sequência e dos objetos de fluxos. O Token atravessa do início até o fim do fluxo de sequência (Flecha), instantaneamente; não existe um tempo associado com o Token enquanto percorre o fluxo de sequência. Podemos pensar no Token como um pulso elétrico que percorre os elementos de fluxo do BPMN. Token Token Business Process Modeling Notation Página 19

Sendo assim podemos imaginar como seria uma possível trajetória do token no seguinte fluxo de processo se os documentos estiverem Ok. Business Process Modeling Notation Página 20

5. Ciclo de Vida da atividade Quando se inicia uma atividade, isto é, quando o Token chega a esta Atividade, ela muda o Status para "Pronta" isso não significa que a atividade começou imediatamente. Outros fatores podem também afetar a realização desta atividade. Tokenn Neste exemplo a atividade (tarefa) Rever Projeto tem duas entradas separadas (Projeto lógico e Projeto Físico) se essas entradas não estão disponíveis quando o Token chega à atividade, então essa atividade não pode começar. Para o tipo de tarefa (Usuário) é necessário o uso de uma aplicação e de um operador, se ambos não tiverem disponíveis a atividade também não pode começar. Quando todas as restrições estiverem resolvidas então a atividade pode ser iniciada. Neste momento ela muda o status para "Em execução e quando a atividade é finalizada ela muda o Status para "Completada". Enquanto a atividade está no Status "Em Execução" ela pode mudar para o status de "Pausada", "Reiniciada" e "Interrompida", modelando pontos de decisões com Gateways ou Comporta de decisão. 6. Modelando pontos de decisões com Gateways (Comporta de decisão) Gateways são elementos de modelagem que controlam como os fluxos de processo divergem (Split) ou convergem (merge) representando pontos de controle para os caminhos dentro do processo. Se um processo não requer controle, então não há necessidade do uso do elemento Gateway. Decisões, uniões, bifurcação e as combinações no fluxo do processo são modeladas com o símbolo de gateway. Podemos pensar no gateway como sendo as questões que são feitas em um ponto do fluxo do processo. A questão tem definido um conjunto de respostas alternativas, o qual afeta uma das portas do Gateway (ou Comporta). Os símbolos representando os tipos de Gateways estão descritos na tabela abaixo: Business Process Modeling Notation Página 21

Gateways ou Comportas Exclusive Gateway Decision No Gateway Exclusive Baseado em Dados, as condições para as alternativas devem ser avaliadas na ordem especificada. A primeira das alternativas que for avaliada como VERDADEIRA irá determinar o fluxo que será seguido. Visto que o comportamento do Gateway é exclusivo, qualquer outra condição que realmente possa ser VERDADEIRA irá ser ignorada. Somente um caminho pode ser escolhido. Um dos caminhos deve ser o padrão (DEFAULT) e é o ultimo caminho a ser considerado. Isto significa que se nenhum dos outros caminhos for escolhido, então o caminho padrão irá ser o escolhido. Supondo que na execução deste fluxo a resposta do Gateway seja Sim então o Token teria o seguinte comportamento. Business Process Modeling Notation Página 22

Exclusive Gateway Merge (XOR) Exclusive Gateway também pode ser usado como convergentes de Fluxos (Merge). Isto é, ele pode ter múltiplas entradas de fluxo de sequência. Entretanto, quando um Token chega a um Exclusive Gateway, não há validação de condição. Nem há necessidade de sincronização de TOKENS que possam vir de qualquer dos outros fluxos de sequência. O Token, quando chega ao Exclusive Gateway, imediatamente move-se para o fluxo de saída. Geralmente se utiliza este Gateway quando a atividade que vem após este Gateway Exclusive é comum a todas as ramificações que o antecedem. No exemplo abaixo a Atividade Preparar Compras do Cliente será realizada independente da forma de pagamento. Então, supondo que o pagamento tenha sido realizado em dinheiro o fluxo do Token Seria: Business Process Modeling Notation Página 23

Event-Based Exclusive Gateway Decision O Exclusive Gateway Baseados em eventos representa uma alternativa de pontos de ramificações onde a decisão é baseada sobre dois ou mais eventos que possam ocorrer. Ele tem o mesmo comportamento do Exclusive Gateway Baseado em dados, isto é, somente uma das ramificações será escolhida. Processos que envolvem comunicação com parceiro de negócio ou alguma entidade externa necessita deste comportamento. No exemplo acima a atividade Enviar Proposta de Crédito é usada para enviar uma proposta a um cliente (entidade Externa), seguindo o Fluxo temos um Exclusive Gateway Baseados em eventos, neste ponto o processo fica esperando que um dos três possíveis eventos aconteça: ou chega até ele uma mensagem SIM, uma mensagem NÃO ou o Temporizador de 5 dias finaliza a contagem. O comportamento é que quando o Token chega neste Gateway ele é replicado para cada um dos eventos. Business Process Modeling Notation Página 24

Assim o primeiro evento que venha ocorrer disparará seu Token e eliminará os demais. Partindo do exemplo acima, suponhamos que o cliente enviou a mensagem SIM, neste caso o Token que está no Evento que receberá a mensagem SIM irá seguir o seu caminho e os demais serão eliminados. Business Process Modeling Notation Página 25

Parallel Gateway Decision Um Gateway paralelo é também chamado de AND. Não há processo de decisão, todos os caminhos são seguidos. Quando um token chega a um Parallel Gateway não existe avaliação de condição sobre o fluxo de sequência (Diferentemente do Exclusive Gateway), por definição este gateway irá criar caminhos paralelos, isto significa que o Gateway irá criar o número de Tokens iguais ao número de fluxo de sequência de saídas. No exemplo acima após a Atividade Preparar Documentos para Assinatura, tanto a Atividade Preparar Contrato quanto Preparar Procuração serão executadas. Business Process Modeling Notation Página 26

Parallel Gateway Merge Utilize o Gateway Parallel Gateway Merge quando os caminhos paralelos necessitam ser sincronizados antes de o processo continuar. Para sincronizar o fluxo, o Parallel Gateway irá esperar que todos os Tokens cheguem de cada Fluxo de sequência de entrada. No exemplo acima, suponhamos que a atividade Preparar Contrato termine primeiro do que a atividade Preparar Procuração o Token T1 desta atividade chegará primeiro no Parallel Gateway. Este então esperará que o Token T2 da atividade Preparar Procuração chegue para sincronizar ambos os toquens e dar continuidade ao fluxo do processo. Business Process Modeling Notation Página 27

Business Process Modeling Notation Página 28

Inclusive Gateway Decision Tal como o Exclusive Gateway (decision), um Inclusive Gateway (decision) tem várias sequências de saída, cria vários caminhos (ramificações) alternativos baseados sobre as condições destes fluxos de sequência. A diferença é que o Inclusive Gateway pode ativar uma ou mais ramificações, isto significa que, uma ou mais das saídas do fluxo de sequência pode ser seguida. Cada condição que for avaliada como verdadeira irá resultar em um Token movendo sobre este fluxo de sequência. Não pode acontecer de não ter saída. Caso nenhuma condição seja satisfeita você deve especificar uma saída padrão (default). No exemplo acima o fluxo Cartão de Débito? é a saída padrão, identificada com um corte transversal ( / ) no seu fluxo de sequência. Partindo do exemplo acima, suponhamos que na atividade Definir Serviço foram escolhidos os seguintes serviços: 1. Cheque Especial 2. Cartão de Crédito Internacional 3. Cartão de Débito O comportamento do Token seria, Business Process Modeling Notation Página 29

Caso na atividade Definir Serviços não fosse escolhida nenhum serviço, o caminho padrão seria então ativado, assegurando que o processo não fique emperrado. Inclusive Gateway Merge Business Process Modeling Notation Página 30

O Inclusive Gateway Merge irá sincronizar cada um dos Tokens que estejam nos fluxos de sequência, isto que disser que enquanto tiver um Token em qualquer um dos fluxos de sequência que cheguem ao inclusive Gateway o processo não tem andamento. Partindo do exemplo acima, suponha que a atividade confeccionar cheque Especial termine primeiro que as atividades Confeccionar Cartão Internacional e Confeccionar Cartão de Débito então o Token T1 desta atividade chega ao Inclusive Gateway. Este percebe que tem mais dois Token T2 e T3 que faltam chegar. Business Process Modeling Notation Página 31

. Agora a atividade Confeccionar Cartão de Débito é completada, então o Token T3 sai desta atividade e chega ao Inclusive Gateway, que fica esperando pelo o ultimo Token T2. Por último a Atividade Confeccionar Cartão Internacional é completada, neste momento o Token T2 sai desta atividade e chega ao Inclusive Gateway. Agora todos os Tokens serão sincronizados e deste Gateway sairá um único Token dando continuidade ao fluxo do Processo. Business Process Modeling Notation Página 32

Token Sicronizado Business Process Modeling Notation Página 33

Complex Gateway Decision A expressão foi colocada em um elemento de notação, para uma melhor clareza Quando o Gateway é usado como uma decisão, então a expressão determina a saída que o fluxo de sequência irá escolher para continuar o processo. A expressão talvez se refira ao dado do processo e ao status para fluxo de sequência de saída. Por exemplo, uma expressão talvez avalie o dado do processo e então selecione um conjunto de saída do fluxo de sequência, baseados sobre os resultados da avaliação. Porém, a expressão deverá ser projetada para que ao menos uma das saídas do fluxo de sequência seja escolhida. No Exemplo acima a expressão avalia se o pagamento foi realizado a vista ou Cartão de Débito, no caso de acontecer uma destas atividades então a atividade Entregar Brinde ocorrerá também. Business Process Modeling Notation Página 34

Complex Gateway Merge Quando o Gateway é usado como merge, então nele deverá ter uma expressão que determinará qual das expressões do fluxo de seqüência irá ser obrigatória para o processo continuar. A expressão talvez se refira ao dado do processo. Por exemplo, uma expressão pode especificar que qualquer uma dos 2, dentre os 3 fluxos de seqüência de entrada, irá continuar o processo. Outro exemplo poderia ser uma expressão que especifique que o Token da atividade Realizar Teste A é requerido para fluxo de sequência e que um Token da sequência de fluxo Realizar Teste B ou Realizar Teste C é aceitável. Porém, a expressão deve ser projetada de tal forma que processo não crie um impasse. No exemplo acima estamos especificando que o teste A é obrigatório e que qualquer uma das outras duas atividades é opcional. Isto é, o Token da atividade A deve ser sincronizado com um ou os dois outros Tokens. Suponha que o Token T1 da atividade Realizar Teste A chegue ao Complex Gateway Merge este irá esperar por mais um Token para dar sequência ao Fluxo do processo. Business Process Modeling Notation Página 35

Agora a atividade Realizar Teste C finaliza. Neste momento o seu Token T3 chega ao Complex Gateway Merge e este é sincronizado com o Token T1 e o fluxo do processo tem continuidade. TOKEN Sincronizado 7. Pools e Lanes Quem faz o quê? À medida que você progride na modelagem de fluxo de processo, você pega os processos, eventos e gateways do diagrama de processo de negócio e os colocam dentro de Pools ou Lanes. Um Pool é um desenho com uma região retangular desenhada horizontalmente através do diagrama. Uma Lane é uma subpartição dentro do Pool e estende-se por todo comprimento do Pool. Tipicamente, um Pool representa uma organização e a Lane representa os departamentos dentro desta organização. Pegando os processos e colocando-os dentro de um Pool ou Lanes, você está Business Process Modeling Notation Página 36

especificando QUEM faz O QUÊ, especificando, para eventos, ONDE eles ocorrem e para os gateways ONDE AS DECISÕES são tomadas, ou QUEM as toma. Poderíamos fazer uma analogia entre estas representações e uma piscina, é bem interessante. Você pode imaginar um processo como sendo uma piscina com raias dentro dela, e a troca de raias como a necessidade de realizar uma atividade dentro dela. Então um Pool pode ser considerado como uma piscina de recursos. Existe ocasião em que o processo necessita saltar para outro Pool, porque este tem diferentes recursos necessários para completar a atividade. 7.1. Um POOL pode representar muitas coisas Um Pool pode representar outras coisas além de uma organização, tais como uma Função (Algo que a organização realiza, tal como Vendas, Treinamentos ou Compras), uma Aplicação (ou programa de computador), uma Localização (Uma localização física na companhia), uma Classe (Um módulo de um software em um programa orientado a objeto), ou uma entidade (representação lógica de uma tabela de um banco de dados). Ele pode somente representar uma coisa. Mais esta coisa pode ser de diferentes tipos. Concluindo, BPMN está destinado a ser o novo padrão de modelagem de processos de negócio e Web Services. Ele é projetado para lhe permitir facilmente modelar típicos processos de negócios, e oferecem a capacidade de modelar processos de negócios complexos, incluindo a passagem de mensagens via Web Services. Business Process Modeling Notation Página 37

Aprendendo BPMN por meio de um exemplo Business Process Modeling Notation BPMN proporciona uma linguagem comum para que as partes envolvidas possam comunicar os processos de forma clara, completa e eficiente. Desta forma BPMN define a notação e semântica de um diagrama de Processos de Negócio (Business Process Diagram, BPD). BPD é um Diagrama desenhado para representar graficamente a sequência de todas as atividades que ocorrem durante um processo baseado na técnica de Flow Chart, incluindo todas as informações necessárias para análises. BPD é um diagrama desenhado para ser usado pelos analistas de processos os quais desenham, controlam e fazem gestão dos processos. Dentro de um Diagrama de Processo de Negócio BPD se utilizam um conjunto de elementos gráficos, que se encontram agrupados em categorias. Para introduzir o tema de BPMN, no decorrer deste documento o leitor se encontrará com uma série de exemplos desenvolvidos em torno de um processo de Solicitação de crédito de Consumo Um processo de crédito consta basicamente de um registro de solicitação, em que o cliente irá manifestar seu interesse de adquirir um crédito. Nesta etapa se inclui a apresentação da solicitação e documentação requerida pela entidade de Crédito, na sequência se realiza uma verificação das informações, posteriormente segue a etapa de análise da solicitação de crédito e por ultimo encontramos as atividades referentes à realização efetiva do crédito ou comunicação da recusa ao cliente. Business Process Modeling Notation Página 38

Como pode observar no exemplo acima, dentro de um diagrama de processos de negócio existe um conjunto de elementos gráficos que nos permitem representar um processo de negócio. No exemplo anterior se pode visualizar diferentes tipos de elementos que descrevem o comportamento do processo, dentre estes elementos encontramos as ATIVIDADES que representam o trabalho realizado, os EVENTOS de início e de fim do processo que indicam o início e o fim do processo e os elementos de decisão conhecidos em BPMN como Gateways (comportas) que indicam uma divisão no caminho. Estes elementos se encontram conectados por linhas de sequência que mostram como flui o processo. O princípio do processo de solicitação de crédito está evidenciado na figura Evento de início indicando o começo do processo. Os processos podem iniciar de diferentes formas, BPMN fornece diferentes tipos de eventos de início (Simples, mensagem, sinal entre outras). O Gateway ou Comporta utilizada dentro do exemplo anterior é a comporta EXCLUSIVE, esta comporta como elemento de decisão se comporta como um XOR, que dizer, das varias alternativas apresentadas só uma delas pode ser tomada. Dentro do processo de solicitação de crédito podemos observar dois exemplos do uso da comporta EXCLUSIVA, no primeiro dependendo do resultado da verificação da informação do solicitante o fluxo tomaria um caminho; o outro, se o resultado for Recusado o processo terminaria e se o solicitante for aceito o processo continua. Na segunda comporta a decisão será tomada com base no resultado do estudo do pedido do crédito, uma vez que se a solicitação for recusada o cliente é informado e se for aprovada se procede com a realização do desembolso. Se analisarmos o processo de solicitação de crédito, podemos ver que existem atividades que podem ser analisadas com mais detalhes, uma destas atividades é a Verificação da Informação fornecida pelo solicitante, uma vez que normalmente as entidades que concedem créditos realizam várias análises do solicitante, por exemplo se verifica se o solicitante já é um cliente da entidade, se é um cliente que o banco tem interesse, ou por outro lado, se este se encontra em uma lista de clientes negativados e posteriormente, consulta sua situação financeira. As atividades podem ser compostas ou Atômica, dentro do BPMN as atividades compostas são conhecidas como Sub-Processos e as atividades atômicas como tarefas. Tarefas (task): Uma tarefa é utilizada quando o trabalho no processo não é mais decomposta em mais detalhes. É executada por uma pessoa e/ou uma aplicação. Subprocesso: É uma atividade composta que é incluída dentro de um processo. Esta atividade por sua vez é composta de um conjunto de atividades e uma sequência lógica (processo) que indica que a referida atividade pode ser analisada em mais detalhes, visualmente pode aparecer em modo contraído ou expandido. O diagrama de fluxo do processo de solicitação de Crédito ficaria da seguinte maneira ao transformar a atividade de Verificar Informação do Solicitante como um subprocesso. Business Process Modeling Notation Página 39

O Subprocesso Verificar Informação do Solicitante pode ser: Business Process Modeling Notation Página 40

Também é possível visualizar o processo de solicitação de crédito com o subprocesso Verificar Informação do Solicitante expandido: Adicionalmente, dentro do Subprocesso Verificar Informação do Solicitante encontramos as atividades Verificar a Existência do Cliente, Verificar Lista de Negativados e Verificar Perfil de Crédito que são tarefas automáticas, em que a realização ocorre por meio de um sistema sem a intervenção humana, podendo ser uma aplicação automática ou um serviço WEB. Para diagramar este tipo de atividades BPMN propõe um tipo de tarefa chamada Tarefa Automática (Service). O Subprocesso Verificar Informação do Solicitante teria agora o seguinte aspecto: Business Process Modeling Notation Página 41

Outra das atividades do processo de Solicitação de Crédito que pode ser mais detalhada é a atividade é a Desembolsar Crédito. Se visualizarmos o Subprocesso Desembolsar Crédito representado no diagrama abaixo, podemos observar que existem várias formas de desembolsar um crédito; Desembolsar em Conta, abono em outro crédito ou Cheques. Estas formas não necessariamente têm que ser excludentes, quer dizer, um crédito pode ser desembolsado usando só uma das formas disponíveis, ou usando diferentes combinações, por exemplo, uma parte com abono em uma conta e outra parte em cheque. Para diagramar esta situação de negócio se utiliza o Gateway (Comporta) INCLUSIVE como elemento de decisão, esta comporta permitirá ativar um ou vários caminhos dependendo dos dados do processo. Business Process Modeling Notation Página 42

Uma vez desembolsado o crédito deve-se informar ao cliente o resultado, mas é necessário que todas as ramificações que foram ativadas sejam finalizadas para realizar a atividade de Informar Resultado ao Cliente, para isto se utiliza a Comporta (Gateway) Inclusive como elemento de convergência (Sincronizador) o que significa que esta esperará por todas as ramificações ativadas antes de continuar o fluxo. No exemplo anterior visualizamos uma ANOTAÇÔES dentro do diagrama do processo, BPMN provêem diferentes artefatos que permitem incluir informações adicionais sobre o diagrama e desta forma fornece ao leitor maiores detalhes do processo. No BPMN também é possível detalhar quais atividades são automáticas (Tarefas Automáticas),quais são realizadas com ajuda de um sistema (Tarefa de Usuário), quais são realizadas manualmente (Tarefas Manuais), dentre outras. Dentro do Subprocesso Desembolsar Crédito, as tarefas de Desembolsar com abono em Conta, Desembolsar em Cheque e Desembolsar com abono a Outro Crédito são Tarefas Automáticas, quer dizer, são realizadas por sistemas sem a intervenção humana, adicionalmente poderíamos especificar que a atividade Entregar Cheque é uma tarefa completamente Manual e que a atividade Completar Informações Desembolso é realizada com ajuda de uma aplicação, indicada como uma Tarefa de Usuário. Suponhamos que uma vez aprovado o crédito é necessário coordenar uma data de desembolso com o cliente, para tanto o desembolso efetivo só deveria ser feito unicamente no dia acordado com o cliente. Para isto, é necessário realizar uma espera antes das tarefas de desembolso. O BPMN oferece o Evento Intermediário Temporizador, o qual é um tipo de evento intermediário que representa uma espera dentro do Fluxo. Business Process Modeling Notation Página 43

Retornando ao processo de Solicitação de Crédito, é possível que em um determinado momento da solicitação, o cliente não apresente todos os documentos requeridos, mas não é possível continuar com o processo até que toda a documentação esteja completa. Por isso faz-se necessário incluir uma atividade de recepção de documentação de documentos, mas o cumprimento desta atividade depende do cliente e não do funcionário da entidade. Para esta situação é possível utilizar um Evento Intermediário Simples. Business Process Modeling Notation Página 44

No caso anterior o evento Intermediário Simples Receber Docs representa algo que pode ocorrer dentro do fluxo do processo e não depende do usuário e sim de um cliente externo. Temos mais um detalhe que devemos prestar atenção. A entrega de documentos é algo que pode ou não ocorrer dentro do processo, isto é, o cliente pode não apresentar os documentos ou levar muito tempo para fazê-lo, por isso é necessário controlar o tempo que é dado ao cliente para a entrega dos documentos e desta forma poder cobrá-lo caso não o faça ou demore muito tempo para fazê-lo. Para isto é necessário diagrama dentro do processo de Solicitação de Crédito as seguintes situações: o cliente tem um tempo para entregar os documentos, se isto não ocorre dentro deste tempo, se desabilita o evento simples de Receber Docs e se procede à atividade de Contactar o Cliente para que este traga os documentos. Porém se os documentos são entregues pelo cliente dentro do tempo esperado, se revisão os documentos e o tempo que controla a entrega dos documentos deve deixar de correr, isto é, se desabilita o Evento intermediário Temporizador. Para diagramar esta situação vamos utilizar a Comporta (Gateway) Exclusiva Baseada em Eventos, esta comporta permite habilitar vários caminhos alternativos e somente um deles será executado, O primeiro Ganha já que este ganhador desabilita todos os outros caminhos. O processo se visualizaria da seguinte forma: Business Process Modeling Notation Página 45

Por ultimo, os diagramas de processos de negócio normalmente utilizam separadores visuais indicando papeis ou diferentes responsabilidades das atividades de um processo BPMN permite diagramar as diferentes áreas ou participantes que interagem dentro do processo, para isto vamos utilizar Lanes e o processo ficaria da seguinte forma. Business Process Modeling Notation Página 46

Referencias: 1. Business Process Modeling Notation, V1.1 OMG Available Specification OMG Document Number: formal/2008-01-17 Standard document URL: http://www.omg.org/spec/bpmn/1.1/pdf 2. BPMN and Business Process Management,Introduction to the New Business Process Modeling Standard By Martin Owen and Jog Raj, Popkin Software 3. BPMN Modeling and Reference Guide, Stephen A. White, Derek Miers. 4. Business Process Model and Notation (BPMN) 2.0 Request For Proposal OMG Document: BMI/2007-06-05 5. Introduction to BPMN Stephen A. White, BPM Architect, IBM 6. Modelagem de Processos de negócios com BPMN, Gluco S. Reis. Editora PortalBMP, www.portalbpm.com.br. 7. Documentação Bizagi, www.bizagi.com 8. The MicroGuide Process Modeling in BPMN, Tom Debevoise, Rick Geneva. Business Process Modeling Notation Página 47