No artigo anterior, iniciamos o estudo da notação BPMN apresentando os elementos task e sequence flow, utilizados para representar a sequência lógica de atividades a serem executadas para a realização do processo. Neste artigo estudaremos um novo elemento de fluxo.
Gateways são os elementos de BPMN responsáveis por controlar iterações do fluxo, criando caminhos alternativos ou paralelos no mapeamento do processo ou unificando fluxos para continuação em uma mesma sequência de atividades.
Gateways são elementos chave na modelagem de processos de negócio, pois permitem descrever não apenas o “dia feliz” do processo, em que as atividades acontecem sempre da mesma maneira ou na mesma sequência, mas prever possíveis exceções conhecidas do negócio, ou beneficiar a duração do processo através da paralelização de atividades.
O gateway é conectado ao fluxo através de setas de fluxo de sequência e é representado visualmente por um losango. O símbolo interno do losango identifica a interpretação lógica representada.
Gateway exclusivo (Databased Exclusive Gateway)
Representa uma condição de fluxo exclusiva, em que apenas um dos caminhos criados a partir do gateway será seguido, de acordo com uma informação a ser testada.
Este gateway pode ser representado visualmente como o losango vazio ou com um marcador de “x”.
Quando o processo em execução atingir este gateway, o processo deverá verificar a condição indicada, e apenas uma das saídas do gateway dará seguimento. Semanticamente, este gateway funciona como um “ou”, já que ou um ou outro caminho será seguido – nunca mais de um.
Os conectores de sequência de saída deste gateway podem apresentar descrições que ajudem a identificar qual a condição para que o fluxo siga por aquele caminho.
Além de realizar separação de fluxos, o gateway também pode unificar fluxos distintos em uma única sequência de atividades. Neste caso, o gateway exclusivo implica no entendimento que, dos caminhos que convergem a ele, o primeiro que chegar dará continuidade no fluxo do processo.
Gateway paralelo (Parallel Gateway)
A paralelização de trabalho em um diagrama BPMN é possível com a utilização do gateway paralelo. Este gateway representa a divisão de um fluxo em dois ou mais que serão executados paralelamente. Todos os caminhos que saem deste gateway são executados.
Este gateway é representado visualmente como o losango com um marcador de “+” dentro dele.
Semanticamente, este gateway funciona como um “e”, já que um e outro caminho serão executados.
Quando este gateway é utilizado para realizar a convergência de fluxos, ele garantirá que todos os fluxos paralelos sejam concluídos, chegando até ele antes de dar continuidade ao fluxo de saída.
Gateway inclusivo (Databased Inclusive Gateway)
Representa uma condição de fluxo inclusiva, em que pode haver uma combinação dos caminhos criados a partir do gateway, de acordo com uma informação a ser verificada. Este gateway é representado visualmente como o losango com um marcador de círculo dentro dele.
Quando o processo em execução atingir este gateway, o processo deverá avaliar a condição relacionada, e uma ou mais das saídas do gateway poderão dar seguimento.
Semanticamente, este gateway funciona como um “e/ou”, já que o caminho a ser seguido pode ser um e/ou outro, de acordo com as informações e a lógica do negócio.
Quando este gateway é utilizado para realizar a convergência de fluxos, ele garantirá que todos os fluxos que estiverem em execução sejam concluídos, chegando até ele antes de dar continuidade à sequência de atividades.
Algumas coisas importantes que devem ser observadas ao utilizar gateways:
- Diferente dos diamantes dos tradicionais fluxogramas, os gateways em BPMN não são apenas pontos de divisão binária do fluxo. É possível (e muito mais vantajoso!) utilizá-los para realizar testes mais complexos do que o tradicional “sim/não”. Isto vale para todos os tipos de gateway nesta notação.
- Nos gateways exclusivo e inclusivo, onde o fluxo é direcionado com base em uma condição, a informação a ser validada (para identificar que fluxo o gateway deve seguir) já deve ter sido obtida anteriormente no processo.
- Embora a notação não coloque isto como uma regra obrigatória, é sempre uma boa prática descrever, nos conectores de sequência que saem destes gateways com decisão, que valor resultante da condição deve ser verdadeiro para que o fluxo siga por aquele caminho. (Veja nos exemplos aplicados como os conectores de sequência que saem dos gateways exclusivo e inclusivo possuem descrições associadas às suas linhas.) Isto deixará o diagrama mais claro para a leitura dos que venham a consultá-lo futuramente!
BPMN 2.0 possui outros tipos de gateways, como os baseados em eventos, por exemplo. estes gateways, entretanto, são utilizados em casos mais especializados (a partir do nível 2 – analítico, de acordo com a classificação de Bruce Silver).
Em nosso próximo artigo:
um estudo sobre os eventos e os principais gatilhos para início e fim de processos.
Confira todos os artigos deste guia de BPMN Nível 1:
- Um guia para iniciar estudos em BPMN (I): Atividades e sequência
- Um guia para iniciar estudos em BPMN (II): Gateways (você está aqui)
- Um guia para iniciar estudos em BPMN (III): Eventos de Início e Fim
- Um guia para iniciar estudos em BPMN (IV): Eventos Intermediários
- Um guia para iniciar estudos em BPMN (V): Subprocessos
- Um guia para iniciar estudos em BPMN (VI): Swimlanes e Artefatos
72 Responses
Tenho uma dúvida, toda comporta de divergência vai precisar de uma de convergência?
Existirá casos em que não haverá a necessidade da convergência?
Olá Gabriel, embora convergir os fluxos divididos por um gateway seja considerada uma boa prática, ela não é uma exigência da notação, e podem haver situações de negócio no qual a convergência não é necessária ou não se aplica.
Por exemplo, neste diagrama (https://blog.iprocess.com.br/wp-content/uploads/2013/05/BPMN-pools-e-lanes-diagrama-horizontal1.png), note que o gateway “Resultado da avaliação” divide o fluxo em dois caminhos, mas não há um gateway de convergência, simplesmente porque para o processo de negócio mapeado não faz sentido unificar esses fluxos novamente. Do ponto de vista da notação, essa prática é perfeitamente aceitável.
Muito obrigado, Kelly!
Boa tarde,
Seguindo a pergunta do Gabriel, é possível dizer que os gateways paralelo e inclusivo necessitam de fechamento para convergência do fluxo, enquanto os gateways exclusivo e baseado em evento não necessita (embora seja boa prática convergir no caso de gateway exclusivo); correto?
Considerando tais premissas, como deveria proceder quando em um gateway paralelo eu não tenho como convergir o fluxo, pois as atividades são executadas em lanes diferentes e o fluxo seguinte é diferente?
Desde já agradeço.
Olá Felipe,
Esta premissa e que o gateway paralelo ou inclusivo necessita fechamento para convergência do fuxo é incorreta. Não há regra na notação que exija essa convergência. É plenamente possível para um processo em BPMN ter seus fluxos seguindo distintos até o fim, e mesmo que um dos fluxos criados em paralelo chegue ao fim antes, o processo continuará ativo até que todos os outros fluxos paralelos sejam concluídos. O que define se um processo deve ou não ter os seus fluxos convergidos para continuar em um fluxo único é a lógica do processo.
Existem, entretanto, algumas ferramentas de automação de processos que, para simplificar o controle sobre a execução do processo, exigem que ele tenha um único fim. Isso é uma regra imposta pelo produto, mas não é uma obrigatoriedade pela notação. Também conheço algumas organizações que adotaram como prática de modelagem esta regra, mas a notação em si não define esta obrigatoriedade.
Da mesma forma, não há problema algum na notação BPMN que fluxos paralelos executados em lanes diferentes sejam unificadas para, a partir de um determinado ponto, seguirem como um fluxo único, desde que estas lanes façam parte da mesma pool.
Entendi. Muito obrigado!
Comentei dessa premissa, pois ao inserir um gateway inclusivo ou paralelo na ferramenta Business Process Composer da Oracle, ela automaticamente adiciona outro com a indicação de fechamento e não permite que esse seja deletado.
Olá Felipe,
Sim, o Oracle BP Composer faz isso mesmo, mas essa é uma restrição imposta pelo próprio produto. Isso acontece porque na visão deste fornecedor, a modelagem feita no Composer é um primeiro passo rumo à automatização no Oracle BPM Suite, e o motor de processos desse produto precisa desse controle para gerenciar a execução.
Essa não é a única ferramenta que faz adequações do uso de BPMN na sua modelagem, percebemos no mercado muitas ferramentas que criam regras e restrições adicionais à notação para que a arquitetura interna dos seus sistemas consiga suportar a execução do processo baseada na interpretação do fluxo. Um caso típico são as ferramentas de modelagem que não tem todos os elementos de BPMN – apenas aqueles que a ferramenta consegue automatizar.
É por isso que em nosso curso Dominando o Mapeamento de Processos de Negócio com BPMN 2.0 nos preocupamos em ensinar toda a notação de forma independente das ferramentas – porque acreditamos que conhecendo a notação corretamente os profissionais podem evitar vícios impostos pelas ferramentas que usaram no passado. Além disso, as ferramentas evoluem e a tendência é que comecem a se tornar cada vez mais aderentes ao padrão definido na especifiação.
Olá pessoal, estou com uma duvida de conceito, posso ao fim de um Gateways inclusivo ou paralelo, encerrar o processo, o ou tenho que incluir uma atividade ou um subprocesso para finalizar?
Olá Raphael,
A notação BPMN serve para descrever a lógica do seu processo. Você só deve usar tarefas (ou subprocessos, que na verdade são conjuntos de tarefas em sequência) para representar algum trabalho a ser realizado. Se algum dos fins do seu gateway leva á conclusão do processo e nada mais precisa ser feito, então você pode sim fazer aquela sequência levar ao evento de fim.
Olá, bom dia!
Uma dúvida, se tenho uma condição com apenas um caminho, eu coloco uma segunda seta saindo e entrando do gateway?
Exemplo:
Se campo X= Sim, mostra uma msg.
Mas se campo X=Nao , não faz nada.
Obrigada!
Bia.
Olá Bia,
O cenário que você descreveu passa o entendimento de que esta não é uma condição do processo, e sim uma condição de tarefa. Ou seja, você está ainda executando a tarefa, mas há uma condição que poderá levar o sistema a mostrar uma mensagem. Quer dizer que se você está fazendo essa verificação, a tarefa ainda não acabou.
Talvez você esteja modelando o seu processo em um nível muito baixo da operação, usando tarefas para representar passos operacionais. A especificação não determina um nível mínimo de diagramação do processo, mas as melhores práticas recomendam que a tarefa seja usada para representar um trabalho (que gera uma entrega), evitando-se o hiperdetalhamento em diagramas.
Se mesmo assim você desejar representar esse nível de documentação com um diagrama de processo em BPMN, então sim, o seu gateway deveria prever uma saída “não” na qual ele retorna para a tarefa anterior no qual o campo X foi gerado.
Muito boa a explicação. Clara e objetiva. Obrigado!
Parabéns pelo conteúdo! Claro, objetivo e com qualidade!
Bom dia.
Tenho certa dificuldade em entender como devem ser utilizados os gateways de início baseados em evento, sejam exclusivos, sejam paralelos.
Estes gateways podem ser aplicados para iniciar um processo?
É possível exemplificar a aplicação?
Grato desde já,
Daniel.
Olá Daniel, sim esses gateways podem ser usados para iniciar processos. Eles são uma forma de explicitar a lógica que pode ser representada de foma mais objetiva com os eventos de início múltiplo (multiple) e múltiplo paralelo (parallel multiple). Em geral não recomendamos eles pois são muito específicos e costumam ser mais difíceis de interpretar por pessoas que não dominam a notação, já que as pessoas ao ler o diagrama geralmente buscam pelo elemento de evento de início para identificar onde inicia o processo (iniciá-lo com um gateway parece muito estranho).
Olá Kelly! Agradeço a resposta! Sou um grande admirador do trabalho de vocês e este blog tem me ajudado bastante nos mapeamentos e modelagens.
Forte abraço!
Boa tarde,
Quando vou salvar no bizagi aparece a mensagem: “A gateway shoud be used either to split apart the flow or to merge together, both behaviours in the same gateway are not supported”, como posso corrigir este erro?
De fato tenho gateways com duas entradas e duas saídas porém eles se fazem preciso devido a necessidade de negócio. Como solucionar diante deste impasse?
Nathalia, o ideal é separar a lógica em dois gateways, um que faça o join (união dos caminhos) e outro que faça o fork (nova divisão do fluxo). A especificação BPMN formal recomenda que estes comportamentos do processo sejam separados em dois elementos distintos, para que fique claro em cada caso qual a lógica do gateway – se é inclusivo, exclusivo, paralelo, complexo…
Bom dia,
Tenho uma dúvida em relação ao gateway paralelo e a sequência de atividades normal. Quando tenho uma atividade que dela saem outras duas (que necessitam ser realizadas), preciso botar um gateway paralelo? Ou posso botar duas atividades saindo de uma atividade?
Obrigada,
Olá Bianca. O uso de gateway nesta situação não é obrigatório, mas é bastante recomendável. Sem o gateway, quem lê o diagrama poderá se confundir e ficar em dúvida se os fluxos que saem da tarefa são alternativos ou paralelos. O uso de um gateway paralelo entre a tarefa de origem e as duas tarefas seguintes garantirá que a interpretação será sempre correta.
Obrigada pela resposta!
Tenho uma outra dúvida: O processo inicia com a divulgação de um cronograma. Diversas áreas devem enviar documentos para a sequência do processo. Todas essas informações serão conferidas, porém isto não precisa acontecer só quando todas as informações forem recebidas, o processo pode já começar a conferir a cada informação recebida. Como faço para utilizar um gateway nesse caso, ligando todas as atividades de “Enviar documento” para “Conferir documentos”?
Olá Bianca. A situação que você está descrevendo, em que não existe uma dependência de fim-início entre as tarefas, é muito complicado de representar com BPMN pois pode não ser interpretado corretamente. Esse tipo de cenário tem características de CASE MANAGEMENT. Existe uma notação chamada CMMN (Case Management Modeling Notation) ideal para representar este tipo de caso, mas ela ainda não está formalmente integrada ao BPMN.
Para representar isto em BPMN, ou você utiliza um recurso de Subprocesso AD HOC (em que as tarefas não possuem dependência, a definição de ordem é controlada pelos participantes) ou você desenha o fluxo BPMN normal no caso mais comum (que é uma tarefa para a área avaliar o cronograma e outra para a informação ser conferida. Mesmo que não tenha dependência de fim-início, as pessoas entenderão que existem estes dois passos. Outra sugestão: em vez de ter várias lanes para cada um responsável por enviar documento, considere isto como sendo uma única tarefa com loop múltiplo paralelo. (em vez de várias lanes para cada pessoa que envia esses documentos, uma unica lane de um grupo de participantes, por exemplo “Grupo de revisores”). Na descrição da lane você determina quem são, e na descrição da tarefa você determina que cada participante do grupo receberá esta atividade). Seu diagrama ficará bem mais limpo.
Olá, se eu tenho 4 possibilidades de caminho, após o gateway, como devo proceder? Adiciona-se um segundo gatway?
Olá Camila, se todos eles são resultados de uma mesma verificação para roteamento, pode fazer eles todos saírem do mesmo gateway. Não há limites de saídas de um gateway. Se você estiver usando o Bizagi para criar o modelo, que tem uma restrição de permitir o mapeamento de conectores no gateway apenas nas pontas, pode achar que está limitada a três (um seria usado para a entrada e os outros três para saídas). Mas essa limitação não existe na notação – e inclusive pode haver mais de um conector saindo da mesma ponta. Apenas lembre-se de nomear cada conector de saída com uma referência da lógica que leva por aquele caminho para que fique claro a quem lê.
Olá Kelly, boa tarde.
Tenho uma dúvida. É possível colocar quatro gateways ou mais, um após o outro? Ou não é certo? Obrigada!
OI Alessandra, não existe nenhuma regra que impeça isso, mas não é considerado uma boa prática, pois estende muito o diagrama e pode torná-lo difícil de interpretar. Se for possível simplificar esses gateways, nós recomendamos!
Embora a notação não exija o uso do gateway para junção dos fluxos numa mesma atividade, eu costumo utilizá-lo para facilitar a leitura. Minha pergunta é: ao utilizar o gateway para essa junção eu devo colocar como um gateway paralelo ou pode ser abstrato (sem simbologia dentro)?
Helder, o gateway sem o simbolo dentro não é “abstrato”, ele é um gateway exclusivo (equivalente ao gateway com o marcador de “X”).
Embora não seja realmente obrigatório, a utilização ou não de um gateway para unir fluxos antes de ir para uma próxima atividade em comum pode ser uma boa prática pois ajuda a deixar claro qual a lógica da chegada dos conectores. Isso tem um pouco a ver com o gateway que criou os fluxos que estão unificando, mas nem sempre. Se você colocar um gateway paralelo para separar digamos 3 fluxos e depois eles se juntam antes de uma determinada atividade, não colocar o gateway pode tornar dificil para quem lê o fluxo se a atividade pode começar quando qualquer um dos fluxos chegar naquela tarefa primeiro, ou se precisa esperar todos os fluxos paralelos finalizarem antes de ir para a atividade seguinte. O gateway torna a lógica do fluxo mais explícita, portanto pode ser uma boa prática.
Quanto a usar o marcador de X ou deixar em branco, no caso do gateway exclusivo, isso é totalmente a gosto do analista :)
Um gateway inclusivo (sim ou não), de uma das opções pode derivar duas ou mais? Ou existe algum gateway específico para isso?
Ex: a oficina esta para reparar um carro, é feito análise de diagnóstico, se o diagnóstico for fácil (SIM), repara o carro, se o diagnóstico for difícil (NÃO), pode enviar para um analista técnica OU também pode abrir diretamente um ticket via sistema.
Job, no seu caso, vejo o uso dois gateways exclusivos: um que verifica o diagnóstico (OU ele é fácil OU é difícil, portanto tem que ser um gateway exclusivo). E para o caso de ser difícil, teria que entender melhor a lógica proposta. Se for:
– OU envia para analista OU abre ticket (nunca os dois juntos), então deve ser outro gateway exclusivo
– OU envia para analista OU abre ticket (com possibilidade de seguir os dois juntos), então neste caso um gateway inclusivo
– envia para analista E abre ticket (sempre os dois juntos), então um gateway paralelo.
Entendo que devem ser dois gateways separados, pois as lógicas são distintas.
Em relação ao evento de fim, se durante o processo várias situações podem levar ao “Fim”, por exemplo um processo de analise de credito que serão analisados mais de uma condição do cliente, e várias dela podem levar a ‘crédito negado”, todos essas condições devem ser ligadas ao evento de fim?
Olá Sheila, isto depende do que acontece caso o crédito seja negado. Se há mais trabalho a fazer (outras tarefas como comunicar o cliente, cadastrar alguma coisa, passar para um segundo nível de revisão, etc) então o fluxo deve seguir para as próximas atividades. Mas se nada mais acontece com o crédito negado então sim, as saídas devem levar para o evento de fim. Ou, numa abordagem alternativa, você pode ter vários eventos de fim, um para cada situação de crédito negado.
Existe na BPML notação para mostrar que uma sequência, dentre outras, é obrigatória numa convergência? Ou seja, se a convergência possui 3 setas de entrada, uma delas é obrigatória e as demais são opcionais. Acho que o mesmo valeria também para as divergências paralelas.
Olá Paulo. Desconheço BPML, mas se você se refere a BPMN, posso dizer que não há na especificação uma regra para este nível de controle no gateway de convergência.
É possivel mesclar gateway paralelo com gateway exclusivo?
Sim, e esse gateway mesclado tem um nome: se chama gateway inclusivo =)
Kelly, poderia me esclarecer como proceder com a situação abaixo?
Tenho uma atividade de realizar auditoria em algumas atividades de um técnico operacional. Quando o auditor faz a avaliação do processo, sendo que o técnico não está presente nesse momento, há um gateway indicando se houve ou não desvio do procedimento. Caso ocorra o desvio, o auditor irá se deslocar até onde o técnico está, fará um feedback corretivo e o processo continua. Agora, se ele não encontrar desvios do procedimento, ele também terá que se deslocar até o técnico e realizar um feedback positivo. Minha dúvida é, como preciso colocar o gateway imediatamente após a inspeção da atividade pelo auditor, eu posso ter as duas próximas atividades (o deslocamento e o feedback) iguais após o decisor?
Olá Everton, as duas formas são válidas. O melhor para decidir é avaliar o quanto você quer demonstrar a diferença entre os dois tipos de feedback. A forma de fazê-los é diferente, procedimentos, documentos… ou é igual?
Minha sugestão apenas seria não usar uma tarefa para representar o deslocamento. No meu entendimento, isto é mais um meio de realizar o feedback do que trabalho em si (se ele pudesse ser feito por vídeo conferencia, por exemplo, o feedback ainda seria o mesmo, mas o deslocamento não precisaria acontecer, certo? e ainda assim, o processo estaria correto).
Bom dia!
Estou modelando um processo e fiquei com dúvida em que tipo de Gateway devo utilizar.
– TODAS as 3 Tarefas devem ser executadas (Task1 , Task2 e Task3);
– Após a realização de cada uma desses tarefas, a Task4 é realizada;
– Para dar andamento a Task4, não necessariamente preciso ter feito todas as Tasks (1,2 e 3), elas podem seguir o fluxo independente de alguma não estar concluída
Qual gateway de abertura e fechamento eu utilizo?
Desde já, muito obrigado!
Att,.
Olá Fernando, certamente um gateway paralelo para abrir o fluxo, já que sempre executará as 3 tarefas.
Quanto ao fechamento, você pode colocar um gateway exclusivo (assim sempre q chegar no gateway, bastará uma entrada para ele acionar a saída), ou então simplesmente não usar gateway, tornando o seu fluxo não-controlado. Isso quer dizer que as saídas das tarefas 1, 2 e 3 serão todas ligadas à tarefa 4, sem um gateway intermediando.
Boa Tarde!
Tem como um fluxo ter mais de três saídas?
Obrigada !
Sim, Priscilla, um gateway pode ter mais de três saídas. Não há problemas em usar um mesmo ponto de saída do gateway para mais de uma seta de saída.
muito interessante seus conteúdos gostei muito deles. Parabéns :)
Oi Kelly, bom dia!!!
Muito bom o conteúdo do blog, está me ajudando bastante.
Em relação ao geteway, me surgiu uma dúvida. Estou mapeando um processo onde ao ser tomada uma decisão (quarta etapa do processo), ou o meu processo segue, ou eu volto na atividade inicial, há a necessidade de um outro geteway para fechar o fluxo ou um geteway exclusivo me permite que esse fluxo volte e, após reavaliada a situação, ele possa seguir o processo?
Não sei se fui clara na minha explicação, mas desde já agradeço!!
Obrigada!
Oi Mariane, não existem muitas coisas obrigatórias no BPMN. O que deve definir se você deve ou não usar um gateway é a clareza que ele dará ao entendimento do seu fluxo. Se ele fizer sentido sem o uso do gateway, então beleza. Se não ficar claro, melhor usá-lo.
Olá Kelly, uma dúvida, posso ter gateways interligados entre si? sou nova no processo, e gostaria de entender se essa prática é possivel, obrigado!
Olá Juliana!
Sim é possível ter gateways interligados. Em alguns casos inclusive você pode precisar disso – por exemplo: quando quer juntar fluxos que foram separados por um gateway paralelo e então usar um gateway exclusivo para direcionar o caminho a ser seguido; ou mesmo quando após separar o fluxo com um gateway exclusivo um dos caminhos se desdobra em dois ou mais caminhos paralelos.
Apenas procure utilizá-los com inteligência – em vez de sempre colocar decisões binárias nos exclusivos (por exemplo “foi aprovado?” com respostas sim/não) gerando encadeamento de vários gateways, avalie se não há mais combinações que possam ser usadas no mesmo gateway (tipo “resultado” com respostas aprovado/reprovado/em revisão).
Oi Kelly, tudo bom? Tenho uma dúvida: Em relação ao Gateway Exclusivo, que é do tipo “OU”, só um caminho será seguido, quando que um caminho não é válido? É fácil identificar quando, na convergência de 2 ou mais caminhos, apenas um caminho é seguido. Quando ele volta também? seja por um fluxo de sequência voltando, ou por um link. A minha dúvida é: Posso, diante de 2,3 ou mais caminhos a serem seguidos, um segue, e os outros eu coloco um evento de fim, posso dizer que esse Gateway é exclusivo, em razão de ter colocado eventos de fim? Ou não posso dizer que, ao sinalizar com evento de fim, afirmar que esse caminho não é um caminho válido, já que um evento final, por definição, é responsável por “Propagação de resultados”. Nesse caso, não seria melhor colocar o Gateway inclusivo?
Olá João, sim, pode finalizar os fluxos sem necessariamente uní-los depois. O que importa nesse caso é o gateway exclusivo será usado se a lógica de sequência a partir daquele ponto é exclusiva (apenas um dos caminhos será seguido). Por exemplo: se você tem um gateway que verifica o resultado de uma aprovação que tem duas saídas: “aprovado” e “reprovado”, e no caso de reprovado o processo deve acabar (não tem mais nada a fazer), você pode desenhar esse fluxo saindo do gateway e indo para um evento de fim.
Observe apenas que algumas ferramentas de automação podem exigir que os caminhos sejam unificados (geralmente por alguma questão de arquitetura interna e controle do fluxo do processo). Mas no caso da notação BPMN com foco na descrição ou análise do processo, não há restrição quanto a esta modelagem.
quando um analista de negócio deve utilizar o tipo de gateway XOR e quando ele deve utilizar o gateway do tipo paralelo?
Olá Ana,
Os tipos de gateway são detemrinados pela lógica que o fluxo deve seguir.
Se o fluxo pode se dividir em três caminhos A, B e C, e pela lógica do seu processo apenas um desses caminhos será seguido, então o gateway é excluxivo (XOR). Isso é comum em fluxos que envolvem decisões em que os passos a seguir são diferentes para cada resultado.
Se o fluxo deve seguir todos os três caminhos, então o gateway a ser usado é o paralelo (AND). Isso é comum quando você tem atividades que precisam ser executadas a partir de um ponto mas que não existe uma ordem de sequência entre elas, o que indica que os fluxos podem ser paralelos. Por exemplo, ao elaborar um artigo para uma revista, posso escrever o texto e selecionar as fotos em paralelo, ou posso escrever o texto e depois selecionar as fotos, ou começar selecionando as fotos e depois escrever o texto sobre elas. Não existe ordem entre essas duas tarefas, logo elas podem estar em fluxos paralelos.
Olá Kelly,
Uma dúvida, quando utilizar cada um desses tipo de gateways?
Obrigado!
Olá Douglas, como podemos ver pelos exemplos do artigo, cada um tem uma aplicação relacionada à lógica que se dará no processo a partir do ponto em que o gateway foi aplicado.
O gateway exculsivo deve ser usado quando apenas um dos fluxos deve ser seguido. Por exemplo, em aprovações em que você pode ter os caminhos “aprovado” e “reprovado”, estes caminhos são excludentes, pois o processo nunca seguirá os dois ao mesmo tempo já que as tarefas a serem feitas em cada caso são diferentes. Então usa-se o gateway exclusivo.
O gateway paralelo deve ser usado quando as tarefas seguintes não têm uma ordem predefinida. Portanto, podemos colocá-las em fluxos paralelos, que podem ser sincronizados antes da atividade que depende que todas as anteriores tenham sido executadas.
O gateway inclusivo também é baseado em alguma informação, porém você pode ter combinações de caminhos. Veja no exemplo do artigo e creio que a ideia ficará mais clara.
Boa tarde!
Ao divergir um fluxo com um gateway específico, a convergência dos fluxos gerados deve ser realizada pelo mesmo tipo de gateway utilizado na divergência? Ou seja, se eu utilizar um gateway paralelo para divergir, necessariamente tenho que utilizar um gateway paralelo para unificar?
Obrigado!
Olá Bruno, embora não haja uma regra específica sobre isso, na maior parte dos casos é isso que acontecerá. O que importa é: se a lógica para sincronizar os fluxos é a mesma do gateway usado para dividí-los (geralmente é) e se os fluxos precisam ser unificados. Existem situações em que depois de divididos os fluxos as atividades seguintes seguem completamente distintas até o fim, e nesses casos não há por que unificá-los. Mas se a partir de uma determinada atividade os fluxos devem ser sincronizados novamente, então é recomendável utilizar um gateway para isso, e a lógica de unir provavelmente será a mesma da divisão dos fluxos.
Se eu inicio um gateway inclusivo, com duas opções de saída posso dar continuidade das tarefas e colocar um gateway exclusivo em uma delas antes de fechar o gateway inclusivo? Se sim, dentro desse desenvolvimento das atividades pode conter finalização de atividades?
Olá Larissa,
Quando aplicar essas combinações de gateway, é importante fazer uma leitura do fluxo para ver se a lógica não vai acabar travando o fluxo do processo.
Se você usou um gateway inclusivo ou paralelo para dividir fluxos, tecnicamente não precisa sincronizá-los depois. Se não for sincronizá-los, não tem problema adicionar outros componentes lógicos nos fluxos (outros gateways) porque não deverão gerar impacto no downstream do processo. Mas se você for fazer a sincronização dos processos com algum destes gateways, precisa garantir que haja entrada para os fluxos, caso contrário o processo ficará pendente de continuidade.
Oi Kelly,
Sobre o gateway inclusivo, ao fazer a convergência é necessário aguardar que todos os “caminhos” que foram ativados sejam executados e somente depois disto há continuidade ou o primeiro que chegar é suficiente para continuidade do processo ?
( Comparando com o fluxo paralelo que aguarda as ações para seguir… )
Sim Angelica, a leitura que se faz do gateway inclusivo quando está convergindo fluxos é essa mesma – ele implica em todos os fluxos de entrada que estão em andamento sincronizarem no gateway para seguir para a próxima atividade.
Se você deseja que o processo não espere todos, mas dê andamento assim que o primeiro fluxo atinja o gateway de convergência, poderá usar um gateway exclusivo para isso (embora seja bem incomum). Nesse caso, terá que ter uma preocupação adicional de que o executor da atividade seguinte entenda que há trabalhos ainda em andamento antes da tarefa poder ser finalizada e assim ele acabará sendo o responsável por garantir a sincronização. Caso contrário, você poderá ter um processo com fluxo dessincronizado e confuso.
Nota: se o processo for automatizado em um BPMS, é preciso verificar se a ferramenta permite usar gateway de divisão/convergência de tipos diferentes e como ele se comporta na convergência (as ferramentas podem responder a isso de formas diferentes ou terem restrições funcionais nesse cenário).
Boa noite.
Conforme o tipo de produto, tenho atividades no processo que não precisam ser realizadas.
Ex.: Contar substrato -> Imprimir offset -> Imprimir serigrafia -> Criticar impresso
Nem todos produtos possuem impressão serigráfica. Qual é a melhor forma de demonstrar essa situação?
Oi Rafael, se for só esse caso (alguns tem outros não) você pode colocar um gateway antes de “imprimir serigrafia” para verificar se aquele produto deve passar por aquela tarefa, senão segue para a próxima.
Mas se você tiver muitas tarefas que variam em um ponto do processo de acordo com o produto, talvez minha historinha a seguir possa ajudar.
Uns tempos atrás trabalhei na modelagem de um processo de produção que pode ser semelhante ao seu caso.
Naquele processo, depois da matéria prima ser processada (por exemplo metal entra na máquina e sai parafusos), os produtos (parafusos) passavam por tratamentos pós usinagem. Mas dependendo da linha do produto, os tratamentos eram diferentes e a ordem em que aconteciam também.
Por exemplo o parafuso tipo X passava por jateamento e impressão a laser, já o parafuso tipo Y passava por impressão a laser e retífica e depois pintura. Eram mais de 600 linhas de produtos diferentes, tentar mapear em um fluxo todas as possibilidades seria caótico.
Entretanto, a definição de quais tipos de tratamentos se aplicavam a cada linha de produto já estavam documentados no roteiro de ordem de produção, no qual cada OP que passava pela fábrica vinha com uma lista dos tratamentos a serem aplicados na sequência que deveriam acontecer para o produto daquela linha.
Como aproveitamos essa informação para modelar o processo?
No fluxo do processo de produção, o tratamento é uma atividade do tipo subprocesso que vem após a usinagem (processamento na máquina). Esse subprocesso era do tipo AD HOC (Tem um exemplinho de subprocesso ad hoc nesse artigo: https://blog.iprocess.com.br/2013/01/bpmn-modelando-processos-de-negocio-com-elementos-avancados-parte-ii/)
Subprocessos AD HOC tem essa particularidade de que podemos incluir nele várias tarefas que não estão ligadas por fluxos de sequência, simplesmente porque não há uma sequência padrão em que devem ser executadas. A tarefas dentro desse subprocesso não tem uma ordem específica e nem todas elas são executadas para todos os casos.
Para o nosso processo de fabricação de parafusos funcionou bem, porque nesse subprocesso incluímos todas as tarefas de tratamento. No diagrama há uma anotação informando que a definição de quais tarefas de tratamento e em que ordem serão executadas devem seguir o roteiro definido na ordem de produção.
Olá, bom dia.
Estou mapeamento um fluxo e preciso documentar que o processo pode iniciar com 3 tipos de entradas pelo cliente: E-mail, Azure DevOps e Chat no Teams. Como posso realizar essa modelagem, sem criar 3 eventos de início? Poderia conectar o evento de início em um gateway complexo, fechar com um gateway complexo e dar sequência?
Olá Patricia, você pode usar um evento de início do tipo “múltiplo”. Use um elemento de anotação ou a descrição do elemento para listar as possíveis fontes de entrada para iniciar o processo.
Olá Kelly
Situação: Uma empresa X e uma empresa Y entregam produtos para a empresa Z ao mesmo tempo.
Como posso representar o paralelo da empresa X e Y se elas estão em piscinas diferentes?
É necessário colocar o gatewary de paralelo nas duas piscinas ou só em uma?
Oi Kássia, existem formas diferentes com mais ou menos detalhamento para modelar isso, aqui vai uma sugestão: imagino que a piscina da empresa Z esteja no meio e que nela é que estará a sincronização dessas entregas. Considere que as entregas chegam no fluxo da empresa Z como mensagens, então nesse fluxo você precisará modelar um gateway paralelo em que cada fluxo de saída aponta para um evento de recebimento de mensagem (cada evento de mensagem recebe a entrega de uma das empresas). Quando os dois eventos ocorrerem eles devem sincronizar novamente em um gateway paralelo, de forma que a próxima atividade só seja realizada quando as duas entregas foram realizadas.
Será que esse cenário consegue representar a sua necessidade?
Olá, Kelly.
No primeiro fluxo, na atividade “Avaliar Artigo” existem dois elementos de fluxo e um saindo do elemento. Quando posso utilizar esse artificio sem utilizar gateways?
Olá Marlon.
O mais comum é que elementos do tipo atividades tenham um fluxo de sequência de entrada e um de saída, mas não existe uma regra que estabeleça ou restrinja a isso. No caso do exemplo há dois fluxos de entrada para a tarefa. Como eles são de caminhos exclusivos (nunca chegarão junto), não há problema em omitir o uso do gateway aqui pois a lógica funcionará tranquilamente. Chamamos isso de lógica exclusiva não controlada. Se houvesse um gateway exclusivo unificando as entradas, seria um fluxo exclusivo controlado.
Entretanto, se fosse necessário que os fluxos fossem sincronizados antes da tarefa iniciar (no sentido de que a tarefa só pode ser iniciada quando os dois caminhos de entrada chegarem à tarefa), então será necessário adicionar um gateway paralelo ou inclusivo (de acordo com a lógica usada na divisão dos fluxos).
Espero ter esclarecido sua dúvida :)
Estava procurando informação sobre processos BPMN para alguns trabalhos que faço e me deparei com esta página. E não é que vim lendo as perguntas e respostas desde 2014?! Muito interessante as perguntas e muito clara as respostas. Gostei muito e salvei a página para voltar várias vezes. Parabéns pela clareza, é um trabalho relevante para nós.
Que legal! Aproveite!
Olá Kelly !
Tenho uma dúvida, estou modelando um processo de Compras e uma das atividades é validar se o cadastro (fornecedor e produto) existe. Dai utilizei um gateway paralelo para que a validação seja feita tanto para fornecedor quanto para produto. Assim, preciso tomar duas ações diferentes na sequencia, pois, caso exista o cadastro do fornecedor será necessário solicitar os dados de cadastro apenas do produto ou caso exista o cadastro do produto será necessário solicitar os dados de cadastro apenas do fornecedor. Neste caso, eu poderia utilizar um gateway exclusivo para logo depois do gateway paralelo ?
Oi Emanoela!
Se as atividades necessárias para fazer o cadasdtro do fornecedor e o cadastro do produto puderem ser feitas em paralelo (digo, não importa a ordem), você pode usar um gateway inclusivo.
Agora, há casos que o cadastro do produto só poderá ser feito se já houver o cadastro do fornecedor. Se esse for o seu caso, seria melhor um gateway exclusivo para verificar se tem cadastro do fornecedor, levando a essa atividade caso ainda não tenha, e então outro depois para verificar se tem o cadastro do produto.
Espero ter ajudado!