2 Notações para Representação de Processos (1)

Prévia do material em texto

1 Modelagem BPMN - Business Process Model and Notation 
1.1 O que é BPMN e sua origem 
1.1.1 O que é BPMN 
BPMN é sigla de Business Process Model and Notation. Ou seja, é um conjunto de elementos e regras que 
compõem um modelo e é, ao mesmo tempo, uma notação para representar processos de negócio. 
É uma norma aberta no sentido de que: 
• foi criada por um grupo de profissionais de diversas empresas diferentes, de modo colaborativo; 
• é de acesso gratuito, sendo possível baixar pela Internet gratuitamente a norma completa oficial; 
• é mantida por uma organização sem fins lucrativos, a OMG – Object Management Group. 
Site de acesso para as informações sobre BPMN: www.bpmn.org. 
De modo mais objetivo, BPMN é uma notação gráfica para modelagem de processos de negócio. Hoje é aceita 
mundialmente e tem tido uma ampla e crescente aceitação pelas mais diversas empresas no planeta. Dessa 
forma, essa notação é considerada padrão mundial. Em sua origem, a notação BPMN foi criada com objetivo de 
facilitar a comunicação entre a área de negócio e a Tecnologia da Informação. 
Por outro lado, BPMN reduz a distância entre o mapeamento de processos das empresas e a implementação 
técnica de tais processos. A possibilidade de representar processos com foco no negócio faz uma real 
aproximação do uso dessa notação dentro das organizações, sem que o profissional precise ser da área de 
Tecnologia da Informação. 
É importante ressaltar que BPMN não foi criado para representar: 
• organogramas; 
• telas de sistemas; 
• mapas estratégicos; 
• arquitetura organizacional. 
O foco é representação dos processos em suas atividades, ao estilo de um fluxograma. 
 
1.1.2 Origem de BPMN 
BPMN teve sua origem no início dos anos 2.000. Nessa época não havia BPMS e o conceito de BPM ainda estava 
se formando. No campo de ferramentas, havia somente ferramentas de Workflow, bastante limitadas. E ainda 
havia um problema maior: não havia notação de modelagem de processos amplamente aceita no mercado pelos 
profissionais que atuavam com processos e sua representação. Existiam, portanto várias diferentes. E cada 
fornecedor de workflow implementava a sua notação particular, cada empresa criava a sua. 
Como resultado, existiam algumas dificuldades, tanto para os profissionais do mercado quanto para as empresas 
que queriam representar seus processos e utilizar também algum software para a representação e documentação 
de processos. 
Isso porque, para os profissionais, em cada empresa que um profissional fosse atuar, se houvesse utilização de 
algum software, e sendo software diferente daquele que o profissional conhecia, certamente tinha de aprender a 
nova notação. Assim, a cada empresa, era comum ter que aprender nova notação. 
Para as empresas, a cada profissional que entrasse na empresa para trabalhar com processos, era comum ter que 
realizar o treinamento da notação do software desde o início. E, caso a empresa comprasse um workflow e 
resolvesse trocar por outro workflow, o trabalho anterior de modelagem e da automação era prati-camente todo 
recomeçado do zero, desde a modelagem, pois não havia portabilidade entre os softwares workflow, ou seja, não 
havia como exportar a modelagem feita no workflow anterior, assim como a codificação da automação, e passar 
para outro software de marca ou fornecedor diferente. 
Isso era uma grande dificuldade na época. 
Assim, em agosto de 2.000, surgiu uma iniciativa chamada BPMI - Business Process Management Initiative, ou 
seja, uma iniciativa em Gerenciamento de processos de negócio. Essa iniciativa era sem fins lucrativos que reuniu 
inicialmente 16 empresas. O objetivo dessa iniciativa foi a de promover uma padronização relaci-onada a 
processos de negócio. 
Missão da iniciativa BPMI: “Promover e desenvolver o uso de BPM através do estabelecimento de padrões para 
desenho de processos, implantação, execução, manutenção e otimização” (FONTE: traduzido de 
http://searchcio.techtarget.com/definition/Business-Process-Management-Initiative-BPMI) 
Dentro do trabalho desenvolvido pela iniciativa BPMI, foram desenvolvidos inicialmente 3 padrões, sendo que o 
padrão BPMN foi o mais bem-sucedido. Os padrões criados de início foram: 
• BPMN (Business Process Modeling Notation): padrão para modelar processos do negócio. Depois este padrão 
passou a ser chamado de Business Process Model and Notation. Como citado, este foi o padrão mais bem-
sucedido dentro dos criados inicialmente pela iniciativa. 
E também foram criados estes 2 outros padrões, menos famosos: 
• BPML (Business Process Modeling Language): era uma linguagem padrão de desenvolvimento em processos de 
negócio 
• BPQL (Business Process Query Language): era uma interface padrão de manutenção para a dis-tribuição e a 
execução de processos e-Business 
 
1.2 Apresentação do Bizagi 
Bizagi é uma ferramenta de software da categoria que chamamos de BPMS - Business Process Management 
System (o S também pode aparecer como Software ou Suite, mas no final das contas é um software). As 
ferramentas BPMS têm adotado a notação BPMN como padrão para modelagem, que é representação de 
processos. Assim, Bizagi também utiliza a notação gráfica BPMN (Business Process Model and Notation) para 
modelagem. 
Além disso, Bizagi 
• é gratuita na parte de modelagem (Bizagi Modeler); 
• é uma das mais ferramentas populares para modelagem BPMN, tanto pela usabilidade (que é a faci-lidade de 
uso) para modelar e documentar processos, quanto para gerar documentações em HTML, Word e PDF, dentre 
outras opções. 
Para usá-la, deve-se fazer download do Bizagi Modeler 
• http://www.bizagi.com/pt/produtos/bpm-suite/modeler 
No site do Bizagi há uma área com inúmeros vídeos gratuitos que também ensinam sobre o software e como 
utilizá-lo. 
 
1.3 Visão geral de uma modelagem BPMN 
1.3.1 Processos em BPMN 
Em BPMN, um processo representa o que uma organização faz, o trabalho que é realizado através de ativi-dades 
e outros elementos para alcançar um propósito ou objetivo específico. 
BPMN usa um conjunto de elementos gráficos especializados para a representação de cada processo de negócio, 
demonstrando como cada processo é realizado. 
De modo mais didático, podemos dizer que os principais elementos gráficos de BPMN para representar um 
processo de negócio são: 
• Atividades, representados pelos retângulos com bordas arredondadas, que representam as ações (podendo ser 
tarefas ou subprocessos). 
• Eventos, representados pelos círculos. Um evento é algo que “Acontece” durante o andamento de um processo 
de negócio (por exemplo, o início, o término de um processo). 
• Gateways, que são losangos, utilizados para dividir ou juntar fluxos de processos. 
• Fluxo de sequência (Sequence Flow), que são as linhas com setas, fazendo as interconexões necessárias. 
Vamos detalhar e explicar nas próximas páginas um pouco mais cada um desses elementos. 
 
Do ponto de boas práticas, já podemos aproveitar a oportunidade para indicar que as atividades sempre devem 
ser nominadas com verbo no Infinitivo + Objeto. Deve-se ressaltar que isso não é uma regra, é uma boa prática 
bem aceita pelos profissionais de BPM. O verbo no infinitivo deixa mais clara a ação. E não adianta só colocar 
verbo no infinitivo sem um objeto, uma vez que o objeto direciona a ação. Por exemplo, deixar escrito “Imprimir” 
pode ser suficiente para que uma pessoa que não conhece o processo possa segui-lo adequadamente. A palavra 
“Imprimir” não é precisa, pode ser qualquer tipo de impressão. Imprimir pode ser um documento, um contrato, 
pode-se imprimir até um cartão de Natal. Justamente por isso é importante direcionar e deixar claro que a 
impressão é de, por exemplo, de um contrato novo. Assim, o correto é que a atividade tenha o nome “Imprimir 
contrato”. 
 
1.4 Sobre piscinas e raias em BPMN 
1.4.1 Piscinas e Raias 
Em BPMN existe um conjunto de símbolos que, agrupados, são denominados Swimlanes,e que contém as 
seguintes simbologias: 
• Piscinas (Pools) 
• Raias (Lanes) 
Este conjunto de elementos denominado Swimlanes apresenta uma importante representação em suas sim-
bologias de Piscinas (Pools) e Raias (Lanes). Veremos isso nas próximas páginas. 
 
1.4.2 Piscinas 
Piscinas são representadas por um retângulo maior e são utilizadas para representar processos. Assim, a 
representação de cada processo ocorre dentro de uma piscina. 
E um detalhe importante: cada piscina representa apenas 1 processo, não mais do que isso. Se precisar 
representar outro processo, será criada outra piscina durante a modelagem. 
 
 
FONTE: elaborado pela autora. 
A piscina sempre tem uma área (ou à direita ou superior) para se inserir o título (nome) da piscina, que, em geral, 
é o nome do processo – mas vamos ver que pode haver uma variação nessa denominação de acordo com a 
situação de representação da piscina (vamos ver isso mais à frente): 
Internamente, a piscina contém o espaço para a representação do processo modelado, mas podemos também ter 
situação em que a piscina fica vazia, ou seja, não representamos nada dentro. Isso é possível e também veremos 
mais adiante sobre essa situação. Em ambos os casos, cada piscina sempre estará representando, em cada 
piscina, apenas 1 processo. 
 
1.4.3 Raias 
De modo similar à piscina física, a simbologia de Piscina pode ter subdivisões ou subpartições internamente, que 
são as chamadas RAIAS. 
• Raias são utilizadas para organizar e categorizar atividades dentro do fluxo do processo, isso de acordo com 
papéis, áreas, funções, responsabilidades. 
Portanto, as raias podem representar papéis, áreas, funções de atores do processo. 
Nas piscinas, podemos: 
• não ter raias – neste caso não estamos distinguindo as responsabilidades sobre a execução das atividades 
dentro do processo; 
• e podemos ter inúmeras raias – não há limite de número de raias na representação e, neste caso, a necessidade 
das raias é derivada do processo e suas características (por exemplo: se são muitas áreas e diversos papéis 
envolvidos). 
 
FONTE: elaborado pela autora. 
Ainda em tempo, uma observação importante: a regra de BPMN não possui cor na descrição da notação, mas 
também não proíbe o uso de cores. Como somos muito visuais, muitos fabricantes utilizam cores e isso ajuda na 
visualização dos processos. 
 
1.4.4 Representação das Piscinas e Raias 
Pela norma BPMN, piscinas podem ser representadas na horizontal ou na vertical. 
 
1.4.5 Tipos de piscinas 
Temos 2 tipos de piscinas: 
• Piscinas Caixa-branca (White-box pool): contêm internamente a representação de processos. 
• No título da piscina vamos ter o nome do processo. 
• Internamente contém o fluxo do processo representado graficamente. 
• Importante, para relembramos: em cada piscina, representamos apenas 1 único processo! 
Um exemplo de Piscinas Caixa-branca: 
 
FONTE: elaborado pela autora. 
• Piscinas Caixa-preta (Black-box pool): contêm a representação de colaboradores ou de um processo que não 
queremos representar graficamente ou que não sabemos como funciona. 
• No título da piscina vamos ter o nome do colaborador (exemplos: cliente, governo, transportadora, fábrica), OU 
• O nome do processo (mesmo sem representar tal processo) 
Neste caso, em geral, quando a Piscina Caixa-preta está com o nome de um colaborador, este colaborador é 
externo à organização e não temos mesmo um domínio dos processos dele – por isso não os representamos. 
Porém, este colaborador interage com a empresa e dependemos de certos resultados e informações deles, daí a 
importância de representá-los. Por isso é comum termos nomes de colaboradores como: governo, fábrica, 
transportadora, parceiro, operadora de cartão. Sobre o cliente em piscinas caixa preta, também é devido à essa 
questão de ser externo à organização e não termos total controle sobre o que o cliente faz, mas temos contato 
com ele. Daí vem outras formas de representar essa interação da comunicação entre cliente e nosso processo da 
empresa (vamos ver também isso mais à frente). Porém, quando o cliente tem uma interação muito forte com o 
processo que estamos representando, pode não ser representado como Piscina Caixa-preta, mas, sim, como uma 
das raias, em que o cliente terá algumas atividades bem definidas a serem executadas durante o processo. Isso 
pode ocorrer em processos judiciais, em que o cliente (quem, por exemplo, entrou com um processo na justiça) 
precisa em momentos determinados executar precisamente algumas ações durante o andamento do processo 
judicial. 
 
FONTE: elaborado pela autora. 
 
 
1.5 Orquestração e Colaboração 
1.5.1 Orquestração 
Orquestração é uma terminologia que demonstra, em BPMN, a perspectiva de coordenação em um processo (o 
caminho que o processo segue), ou seja, a coordenação dentro de um processo. Dessa forma, 
• A orquestração é definida pelos fluxos de sequência (linhas contínuas e setas que interligam os elementos 
dentro de um processo). 
• A orquestração se limita ao processo em si. Ou seja, não ultrapassa o limite de um processo para outro. 
 
No domínio de TI, a palavra “orquestração” é associada com a efetiva automação ou automatização do processo 
de negócio, pois, na automatização, é necessário seguir o caminho do processo para se chegar ao resultado final 
do processo. 
 
1.5.2 Colaboração 
A terminologia Colaboração ilustra o comportamento esperado (interações) entre processos diferentes, que 
podem ser através de diferentes participantes que se relacionam com um determinado processo de ne-gócio. 
• Em BPMN, as interações representam a comunicação entre participantes distintos, na forma de troca de 
mensagens. São essas comunicações que representam colaborações entre processos. 
 
 
FONTE: elaborado pela autora. 
Para conectar duas piscinas, é necessário utilizar uma seta diferente da seta do fluxo de sequência. Dessa forma, 
somente é possível conectar duas piscinas através de um fluxo de mensagem (linha tracejada com seta). Elas 
ficam sempre na borda de uma piscina, na borda de um evento ou na borda de uma atividade. 
 
As colaborações podem ser representadas interligando diferentes elementos, e podem ser representadas, portanto, dentro 
das seguintes alternativas: 
 
FONTE: elaborado pela autora. 
Neste exemplo de Colaboração, são mostradas as interações entre diversas piscinas caixa-branca e uma piscina 
caixa preta. Nestes exemplos, entre piscinas caixa-branca é possível perceber que foram interligadas atividades e 
eventos. E entre piscina caixa-branca e caixa preta, a interligação ficou sempre entre a borda da piscina caixa 
preta e os elementos internos da piscina caixa-branca. 
 
 
FONTE: BPMN 2.0 by Example (OMG, 2010) 
 
1.6 Atividades 
1.6.1 Atividades 
Atividades, em processos, representam o trabalho realizado dentro de um processo de negócio. 
Toda atividade: 
• consome tempo para ser executada; 
• envolve um ou mais recursos da organização; 
• requer algum tipo de entrada; 
• produz uma ou mais saídas. 
Em BPMN, atividade é o nome de um conjunto, de uma família de simbologias. 
Dessa forma, existem 2 tipos de atividades em BPMN: 
• Tarefa: é uma algo mais atômico, mais pontual. É representada por um retângulo com borda arredondada. 
• Subprocesso: é uma simbologia que representa um conjunto de tarefas, sendo que este conjunto de tarefas 
recebe um nome único para identificação. É representado por um retângulo com borda arredondada e que 
contém, na parte inferior um símbolo “+”. 
• E um detalhe importante: um subprocesso pode ser reutilizável. Com isso há uma flexibilidade em seu uso, uma 
vez que podemos somente referenciar pelo nome em outros processos e ter centralizado o conteúdo de quais 
atividades daquele subprocesso. 
 
 
1.6.2 Conectando atividades 
Uma atividade pode ter uma, mais de uma entrada ou pode ter uma ou mais saídas. 
 
1.6.3 Tipos de Tarefas 
Dentrode BPMN, pode-se representar mais de um tipo da tarefa diferente a partir do uso de simbologias internas 
dentro do símbolo da tarefa. A indicação da simbologia do tipo permite representar os diferentes 
comportamentos possíveis para uma tarefa. 
Neste caso, a simbologia interna é posicionada no canto superior esquerdo da tarefa. A seguir está o conjunto das 
simbologias de tipos de tarefas mais comuns em BPMN. 
 
FONTE: elaborado pela autora. 
1.7 Eventos de início 
1.7.1 O que são Eventos 
• Evento é algo que acontece durante o curso de um processo 
• Eventos afetam o fluxo do processo, podendo, dentre outros: 
• Iniciar 
• Atrasar 
• Interromper 
• Finalizar um processo 
• Eventos são representados por círculos (e podem também ter simbologias dentro, mas o círculo é o que 
representa o Evento) 
 
1.7.2 Eventos de início 
• São simbolizados por círculos com um traço fino. 
• Definem e mostram o início do processo. 
• São vários tipos de início de processos em BPMN. 
• O que muda é o símbolo interno. 
 
 
 
FONTE: elaborado pela autora. 
Ao utilizar estes símbolos escreva o motivo do início do processo abaixo do símbolo. Assim, se é um evento 
condicional que diz que o processo inicia quando o estoque chegou a 10% da capacidade de estoque, então 
escreva abaixo do símbolo esse motivo “estoque a 10% da capacidade”. 
 
2 Modelagem BPMN - Business Process Model and Notation -Parte 2 
2.1 Eventos intermediários 
2.1.1 O que são eventos intermediários 
• Evento intermediário está relacionado a algo que acontece durante um processo 
• Indicam onde alguma coisa acontece depois do processo ser iniciado e antes de ser finalizado. 
• São vários tipos, vamos ver os principais/mais comuns de utilização. 
 
 
 
2.2 Eventos de término 
2.2.1 Sobre eventos de término 
Formato: círculo com borda mais espessa 
Eventos de término indicam onde um processo, ou mais especificamente, um caminho dentro de um processo 
finaliza. 
São vários tipos de eventos de término, sendo que os principais são os seguintes 
 
 
FONTE: elaborado pela autora. 
Ao utilizar estes símbolos escreva o motivo do fim do processo abaixo do símbolo. Assim, se é um término por um 
motivo positivo, por exemplo, venda bem-sucedida, escreva embaixo “Venda encerrada com sucesso”. 
Se for um término enviando mensagem para o cliente de cancelamento, escreva embaixo “Comunicado de 
cancelamento”. 
 
2.3 Gateway XOR 
2.3.1 O que são Gateways 
São elementos usados para controlar como o fluxo do processo diverge ou converge ao longo da sua execução. 
Se o fluxo não precisa ser controlado, não precisamos usar gateways. 
Os mais utilizados possuem o seguinte formato: 
 
 
2.3.2 Características dos Gateways 
O mesmo tipo de gateway pode ser usado tanto para divergir quanto para convergir o fluxo, possuindo 
características específicas em cada caso. 
 
FONTE: elaborado pela autora. 
É importante ressaltar que gateway não é atividade. Ou seja, gateway não realiza ação nenhuma diferente da 
ação de direcionamento sobre para onde o processo vai seguir. Ou seja, funciona como um roteador, um 
direcionador do fluxo do processo. 
Regras do gateway: 
• Em divergência (divisão) a partir do símbolo Gateway, sempre vamos ter 1 linha entrando e n linhas saindo do 
gateway. 
 
• Em junção (união) a partir do símbolo Gateway, sempre vamos ter n linhas entrando e 1 linha saindo do 
gateway. 
 
• Qualquer outra combinação está incorreta: n linhas entrando e n linhas saindo ou 1 linha entrando e 1 linha 
saindo. 
 
2.3.3 Gateway Exclusivo (XOR ou “OU Exclusivo”) 
Gateway Exclusivo (XOR ou “OU Exclusivo”) são elementos do processo necessários para trabalhar com caminhos 
alternativos em que só uma alternativa é válida ou possível, por isso o nome Exclusivo. Podem ser usados para 
DIVIDIR ou JUNTAR um determinado fluxo do processo. Ambos os símbolos abaixo são utiliza-dos para este 
gateway (o mais comum é utilizar o símbolo sem o X dentro). 
 
 
• Comportamento de DIVISÃO do gateway XOR 
• Gateway XOR, também denominado Gateway Exclusivo, divide o fluxo quando existirem dois ou mais caminhos 
de saída. Somente um caminho será válido e continuado, que dependerá do critério de avaliação. 
• Não há limitação sobre número de caminhos derivados ou divididos pelo gateway. 
 
FONTE: elaborado pela autora. 
Vale reforçar que gateway não é atividade e não obtém informação, não processa tarefas. Como já registrado 
antes, o gateway não realiza ação nenhuma diferente da ação de direcionamento sobre para onde o processo vai 
seguir. E, para realizar esse direcionamento pelo gateway XOR, é necessário que a informação já esteja disponível 
antes de se chegar ao gateway (e que será capturada em alguma atividade anterior). Assim, ao prosseguir na 
execução do processo, ao se chegar no gateway, a pergunta que será realizada ou a comparação de qual caminho 
o gateway XOR vai realizar, direcionando o caminho correto, já terá a resposta disponível antecipadamente. 
• Comportamento de JUNÇÃO do gateway XOR 
Após ter ocorrido a divisão de caminhos alternativos pelo gateway XOR, pode ocorrer de precisar juntar de novo 
mais à frente do processo. Nesse caso, será importante utilizar o mesmo gateway XOR para realizar essa junção 
do gateway. 
Na junção de diferentes linhas que foram divididas por um XOR anterior, Gateways XOR também são utilizados 
para juntar fluxos de sequência. Nesse caso, nenhuma avaliação de condição é realizada, apenas é realizada a 
união das diferentes linhas divididas do processo. 
Recomendações: 
• Deve-se fazer a junção com o mesmo símbolo anterior, que dividiu o processo. Ou seja, se a divisão ocorreu 
com gateway XOR, recomenda-se fechar com XOR. 
 
FONTE: elaborado pela autora. 
 
 
FONTE: elaborado pela autora. 
 
Observações: 
• Pode acontecer de ter fins diferentes após a divisão do gateway XOR, nesse caso, se não fizer sentido unir as 
linhas divididas antes, tal junção não deve ocorrer. 
• Uma observação importante, pode ter gateways XOR em sequência (entre si e com outros gateways também). 
Neste caso, para gateways XOR em sequência, deve-se garantir que previamente alguma atividade ou algumas 
atividades responda ou respondam a todas as necessidades de informações de todos os gateways seguintes que 
dividem o fluxo. 
 
FONTE: elaborado pela autora. 
 
 
2.4 Gateway OR 
2.4.1 Gateway Inclusivo (OR ou “OU”) 
• Gateway Inclusivo (OR ou “OU”) suporta decisões em que mais de uma saída é possível no ponto de decisão. Na 
realidade é possível qualquer combinação entre 1 alternativa e todas as alternativas existentes. 
• Assim como o gateway XOR, um gateway OR (INCLUSIVE) possui vários fluxos de saída e cria ca-minhos 
alternativos baseados na condição do fluxo. 
• Diferente do gateway XOR, o gateway inclusivo ATIVA um ou mais caminhos, podendo até ser todos os 
caminhos possíveis. 
• Não há limitação sobre número de caminhos derivados ou divididos pelo gateway. 
 
• Comportamento de DIVISÃO do gateway OR 
• Quando a execução do processo chega em um gateway OR (INCLUSIVE), a condição é avaliada e um ou mais 
caminhos podem ser seguidos, isso em paralelo. 
 
FONTE: elaborado pela autora. 
Vale reforçar novamente aqui que gateway não é atividade e não obtém informação, não processa tarefas. Assim, 
também no caso do OR, esse gateway não realiza ação nenhuma diferente da ação de direcionamento sobre para 
onde o processo vai seguir. E, para realizar esse direciona-mento pelo gateway OR, é necessário que a informação 
já esteja disponível antes de se chegar ao gateway (e que será capturada em alguma atividade anterior). Assim, ao 
prosseguir na execução do processo, ao se chegar no gateway, a pergunta que será realizada ou a comparação de 
qual caminho o gateway OR vai realizar, direcionando o caminho correto, já terá a resposta disponível 
antecipadamente. 
• Comportamento de JUNÇÃO do gateway OR 
GatewaysOR poderão juntar fluxos de sequência. No fechamento, o gateway Inclusivo realizará uma avaliação, 
com base na condição inicial, para saber quantas linhas deverão chegar (quantas aguardar para seguir o processo) 
Na junção de diferentes linhas que foram divididas por um OR anterior, Gateways OR também são utilizados para 
juntar fluxos de sequência. Nesse caso, nenhuma avaliação de condição é realizada, apenas é realizada a união 
das diferentes linhas divididas do processo. 
Recomendações: 
• Deve-se fazer a junção com o mesmo símbolo anterior, que dividiu o processo. Ou seja, se a divisão ocorreu 
com gateway OR, recomenda-se fechar com OR. 
 
FONTE: elaborado pela autora. 
 
Observações: 
• Pode acontecer de ter fins diferentes após a divisão do gateway OR, nesse caso, se não fizer sentido unir as 
linhas divididas antes, tal junção não deve ocorrer. 
• Uma observação importante, pode ter gateways OR em sequência (entre si e com outros gateways também). 
Neste caso, para gateways OR em sequência, deve-se garantir que previamente alguma atividade ou algumas 
atividades responda ou respondam a todas as necessidades de informações de todos os gateways seguintes que 
dividem o fluxo. 
 
2.4.2 Símbolo de padrão 
É possível inserir um pequeno corte em uma das linhas de saída do gateway. Esse é o símbolo de padrão, que 
quer dizer que, ao comparar as alternativas de saída possíveis em relação à pergunta ou direcionamento do 
gateway, se nenhuma alternativa coincidir, o padrão será a escolha a ser executada por padrão pré-definido. 
 
FONTE: elaborado pela autora. 
 
2.5 Gateway Paralelo 
2.5.1 Gateway Paralelo (Parallel Gateway) 
• Gateway Paralelo (Parallel Gateway) insere bifurcação (divisão de um caminho em vários caminhos paralelos). 
• Neste caso, todos os caminhos dessa bifurcação são executados obrigatoriamente em paralelo, ou seja, todas as 
atividades das linhas em paralelo devem ser executadas. 
 
• Possibilita a sincronização (junção ou combinação de vários caminhos em um único). 
• Comportamento de DIVISÃO do gateway Paralelo 
• Quando a execução do processo chega a um gateway Paralelo, não existe avaliação de quaisquer condições e o 
caminho é dividido por vários caminhos obrigatórios. 
• Não há limite superior de linhas em paralelo, podem ser 2 ou mais (Ex: 30) 
• Regras: 
1) Não há pergunta no gateway. 
2) Não há opções escritas nas linhas (tudo é obrigatório). 
3) Não é necessário ter atividade antes do Gateway Paralelo (pode começar direto de evento de início) 
 
FONTE: elaborado pela autora. 
• Comportamento de JUNÇÃO do Gateway Paralelo 
Gateways Paralelo poderão juntar fluxos de sequência. No fechamento, o gateway Paralelo ser-virá como uma 
barreira, aguardando que todas as linhas paralelas sejam executadas até que possa ser seguido o fluxo de 
sequência do processo que foi unificado após o gateway. 
• Usado para sincronizar caminhos paralelos antes que o processo possa continuar 
• Na junção, o gateway Paralelo espera a chegada de TODAS as setas (fluxos) que chegam ao gateway 
Recomendações: 
• Deve-se fazer a junção com o mesmo símbolo anterior, que dividiu o processo. Ou seja, se a divisão ocorreu 
com gateway Paralelo, recomenda-se fechar com gateway Paralelo. 
Observações: 
• Pode acontecer de ter fins diferentes após a divisão do gateway Paralelo, nesse caso, se não fizer sentido unir as 
linhas divididas antes, tal junção não deve ocorrer. 
• Uma observação importante, pode-se ter gateways Paralelo em sequência. 
 
2.6 Regras de negócio em BPMN 
2.6.1 Regras de Negócio (Business Rules) 
De acordo com o glossário do CBOK, Regra de Negócio é uma: 
“Lógica que guia o comportamento e define O QUE, ONDE, QUANDO, POR QUE e COMO será feito, além de como 
o negócio será gerenciado ou governado. As regras podem assumir muitas formas, de simples de-cisões 
booleanas a decisões que envolvem regras de lógica mais complexas. Regras são declarativas e não podem ser 
decompostas sem perder seus significados.” (ABPMP, 2013) 
Normalmente, a regra de negócio é registrada como expressão do tipo “Se xxx condição (> ou < ) valor, definição 
do resultado, senão, definição de outro resultado”. 
Exemplo: Regra de negócio de Cálculo de comissão de vendedor: “Se vendedor vender valor >= R$100.000,00, 
comissão de 10%; se for menor, 3% de comissão.”. 
Informações importantes: 
• Regras de negócio não são processos. Regras de negócio são utilizadas pelos processos, sendo referenciadas 
pelas atividades. 
• E Regras de negócios mudam mais frequentemente que processos. 
 
2.6.2 Regras de Negócio (Business Rules) em BPMN 
Não existia representação de Regras de Negócio antes da versão 2.0 da notação BPMN. Essa representação 
ocorre através da simbologia de Tarefa, acrescido de um elemento gráfico que representa o tipo Regra de 
Negócio. 
 
Em uma tarefa de Regra de negócio, uma ou mais regras são aplicadas para produzir um resultado ou realizar 
alguma decisão. 
Uma Regra de Negócio pode ser chamada por diferentes processos. Neste caso, o nome é sempre o mesmo para 
a mesma regra. 
Além disso, o detalhamento dessa tarefa de regra de negócio traz as informações da regra 
 
2.6.3 Representação de Regras de Negócio (Business Rules) no BIZAGI 
Bizagi possui a simbologia BPMN específica implementada para representação de Regras de Negócio. A 
recomendação é inserir a simbologia e descrever o conteúdo (a expressão de definição da Regra de Negócio) 
usando o campo de descrição que é acionado pela tecla F4. O nome da atividade segue as boas regras de 
nomenclatura de atividades: verbo no infinitivo + complemento (Exemplo: Calcular desconto de compra). 
 
 
 
2.6.4 Repositório de Regras de Negócio 
Pode-se ter na empresa uma lista centralizada ou um software que gerencia regras de negócio, essa é uma 
estratégia interessante para se criar um repositório centralizado de regras de negócio, facilitando, portanto, a 
gestão e manutenção das mesmas. 
Na representação de processos, mesmo se tendo um repositório centralizado de regras de negócio: 
• os processos só referenciam o nome da regra nas atividades; 
• se a regra mudar em seu conteúdo (expressão), não há necessidade de alterar os processos, só o conteúdo da 
regra dentro do repositório de regras. 
Exemplo de Repositório simples de Regras de Negócio (lista). 
 
FONTE: elaborado pela autora. 
 
2.7 Dados e Subprocessos Ad hoc 
2.7.1 Dados (Data) 
Dados (Data) são utilizados na representação de documentos ou informações: 
• que entram (são consumidas, entradas, inputs) 
• ou que saem (são produzidas, saídas, outputs) das atividades no processo. 
Ou seja, Dados (Data) permitem que informações de entradas e saídas das atividades sejam representadas. 
Vamos ver aqui os seguintes tipos de Dados: 
 
2.7.2 Objetos de dados (Data Objects) 
Objetos de dados fornecem informações sobre o que atividades utilizam (consomem) e/ou o que elas produzem, 
são as entradas e saídas. 
Por exemplo, podem representar um documento de contrato, uma nota fiscal, um relatório, dentre outras 
opções. 
 
São considerados artefatos porque não têm efeito direto no fluxo de sequência ou no fluxo de mensagem do 
processo. O estado do objeto de dados também deve ser definido. 
Objetos de dados pode representar um objeto simples ou uma coleção de objetos. 
 
2.7.3 Repositório de dados (Data Store) 
Repositório de dados é utilizado para representar dados que ficam persistentes em alguma base de dados ou em 
algum sistema. 
 
2.7.4 Exemplo de uso de Dados na modelagem 
Para interligação dos Dados, é utilizada a conexão chamada Associação, que é uma seta com traço pontilhado: 
 
• Quando a seta sai da atividade em direção ao Dado, significa que tal dado está sendo produzido pela atividade 
• Quando a seta sai do elemento Dado em direção à atividade, então o Dado em questão será utilizado 
(consumido) pela atividade. 
 
FONTE: elaborado pela autora.2.7.5 Subprocessos Ad hoc 
• Subprocesso Ad hoc contém tarefas que não possuem um fluxo específico (ou ordem específica de ocorrência) 
e, assim, não podem ser conectadas com os fluxos de sequência quando estes são representados. 
• A utilização dos subprocessos Ad hoc permite representar processos conhecidos como Processos Dinâmicos, 
que são processos em que não se consegue definir antecipadamente um caminho fixo, único. O caminho é 
definido no momento em que o processo é executado. 
• Normalmente são processos ligados ou relacionados a conhecimento (negociação, projetos, por exemplo). 
 
• Estão relacionadas à representação do que chamamos de processos dinâmicos. 
• Nunca se aplica o símbolo Ad hoc (~) a tarefas isoladas. 
 
Um exemplo de modelagem de um subprocesso Ad hoc, em um processo de escrita de um artigo ou livro está 
representado a seguir. 
 
3 Referências 
ABPMP. Guide to the Business Process Management Common Body of Knowledge. 3ª Versão. São Paulo, 2013. 
OMG. Business Process Model and Notation (BPMN) version 2.0.1, 2013. 
OMG. BPMN 2.0 by Example. Jun. 2010. <http://www.omg.org/cgi-bin/doc?dtc/10-06-02.pdf>