Um guia para iniciar estudos em BPMN (II): Gateways

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.

No exemplo acima, o gateway “Resultado da avaliação” testará o resultado da atividade anterior. Se na execução da atividade “Avaliar artigo” o usuário aceitar o conteúdo, o fluxo seguirá pela saída superior “Conteúdo aceito”, e as atividades “Realizar revisão final do artigo” e “Publicar artigo” serão realizadas. Se o usuário rejeitar o conteúdo, o fluxo seguirá pela saída “Conteúdo rejeitado”, e apenas a atividade “Cancelar artigo” será realizada. Por fim, se o usuário optar por requerer ajustes, o fluxo seguirá a sequência “Requer ajustes”, iniciando a atividade “Ajustar artigo”. Ao terminá-la, note que o fluxo seguirá novamente para a atividade de “Avaliar artigo”. Ainda no exemplo acima, note a utilização do gateway exclusivo para convergir dois dos fluxos criados. Isto garante que a atividade “Comunicar partes interessadas” só aconteça depois que a tarefa “Publicar artigo” ou a tarefa “Cancelar artigo” for executada, de acordo com o fluxo iniciado pelo gateway anterior.

 

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.

No exemplo acima, o primeiro gateway paralelo produz dois fluxos que serão executados paralelamente. Enquanto a tarefa “Escrever artigo” é realizada, as atividades “Selecionar imagens” e “Tratar imagens” também podem ser executadas. Ainda no exemplo acima, o segundo gateway faz a convergência dos fluxos, garantindo que a tarefa “Realizar diagramação” só seja executada depois que “Escrever artigo” e “Tratar imagens” tenham sido finalizadas.

 

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.

No exemplo acima, o gateway “Documentos necessários” testará o resultado da atividade anterior. Se na execução da atividade “Identificar documentação necessária” o usuário identificar a necessidade de um, dois, ou três dos documentos requeridos, cada um dos fluxos será executado. Por exemplo, se para um processo em execução for identificada a necessidade da Negativa civil e Negativa criminal, mas não a de débitos, o processo seguirá pelas saídas “Negativa civil” e “Negativa criminal”, mas não pela “Certidão negativa de débitos”. Assim, as atividades “Anexar negativa civil” e “Anexar negativa criminal” deverão ser executadas. Em outro processo, pode ser possível que uma combinação diferente de documentos seja requerida. Ainda no exemplo acima, note a utilização do gateway inclusivo para convergir os fluxos criados. Isto garante que a atividade “Analisar validade dos documentos” só aconteça depois que todos os fluxos que forem iniciados pelo gateway anterior sejam executados, para então a atividade ser iniciada. No exemplo citado, a tarefa de analisar validade dos documentos só será iniciada depois que as tarefas “Anexar negativa civil” e “Anexar negativa criminal”, mas sem que ocorra a atividade “Anexar negativa de débitos”.

 

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:

.

29 ideias sobre “Um guia para iniciar estudos em BPMN (II): Gateways

  1. Pingback: BPMN: Modelando processos de negócio com elementos avançados | Blog da iProcess

  2. 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?

  3. 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 (http://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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

  8. 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?

  9. 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.

  10. 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.

  11. 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.

  12. 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.

  13. 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).

  14. 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!

  15. 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?

  16. 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…

  17. 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,

  18. 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.

  19. 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”?

  20. 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.

  21. 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ê.

  22. 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!

  23. 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!

  24. 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)?

  25. 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 :)

Deixe uma resposta

O seu endereço de email não será publicado Campos obrigatórios são marcados *

*

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>