As regras da especificação são relativamente fáceis de aplicar já que são bastante claras. Elas definem como são os símbolos, como podem se conectar e o que significam. As dúvidas mais frequentes geralmente estão relacionadas a como aplicá-las para representar as particularidades da lógica do processo de negócio que estamos mapeando.
Recentemente recebemos algumas dúvidas de um leitor do nosso blog sobre a aplicação de gateways, cujas respostas compartilharemos aqui, guiados por esses dois aspectos e mais alguns cuidados de boas práticas.
1) Existe alguma restrição em começar um processo com um evento de inicio e logo depois um gateway?
Pela especificação não. O uso do gateway paralelo após o evento de início neste processo de exemplo enviado pelo leitor é perfeitamente aplicável. Qual seria a razão de se criar um impedimento a tarefas realizadas em paralelo quando um processo inicie – o que na verdade pode representar um excelente ganho de desempenho no processo ao se reduzir a sua duração?
Entretanto, pode haver restrição no caso do uso de gateway baseado em dados, como o Inclusivo ou o Exclusivo. Mas é uma restrição lógica: como esses gateways testam um dado para determinar o roteamento do processo, a informação precisa ter sido gerada antes. Assim, na maior parte das vezes, antes do gateway será necessário uma atividade que forneça essa informação. Mas nem sempre. Por exemplo: se o processo começar com um evento de mensagem, pode-se presumir que a informação seja obtida da mensagem recebida ao iniciar o processo. Quando estamos modelando, precisamos pensar nisso.
Portanto, a restrição não é de regra de uso do elemento, mas está associada à lógica do processo mapeado.
Também não há nenhuma regra restringindo o encadeamento de gateways, mas fazer isso pode tornar a leitura do diagrama mais complexa, além de serem mais elementos agregados no diagrama (quando ele começar a ficar grande, qualquer elemento a menos pode significar uma bela economia !)
A única observação que faço sobre este tipo de diagrama é lembrar que gateways não precisam ser binários (com apenas duas saídas). As melhores práticas de uso da notação recomendam inclusive que se evite utilizar perguntas na definição de gateways porque elas tendem a gerar resultados do tipo “Sim”/”Não”. Em vez disso, recomendamos usar uma regra avaliativa.
Por exemplo: digamos que uma tarefa de avaliação possa resultar em: aprovação, aprovação com restrições ou reprovação, e que cada resultado leve a uma sequência de ações diferentes no fluxo.
26 Responses
Estou com uma situação semelhante a do exemplo 2 acima, porém tenho as saídas “Aprovado”, “Aprovado com restrição A” e “Aprovado com restrição B”, sendo que cada tipo de restrição direciona a um fluxo diferente, e podem ocorrer as duas simultaneamente.
Pensei em usar um gateway inclusivo, mas vi que não daria certo pois a saída “Aprovado” não acontece simultaneamente com as outras. Nesse caso, a melhor forma é usar mesmo gateways encadeados?
Olá Ana,
Esta é uma particularidade de uso do gateway no qual a especificação não se posiciona claramente.
Pensando no comportamento do gateway, se a sua atividade anterior garante que não ocorra a combinação de “Aprovado” com as demais saídas, isto não seria um problema, já que a lógica do gateway depende da informação que chega nele.
Entretanto, se você quer garantir que o uso da notação elimine o risco deste tipo de interpretação, há duas opções: usar o gateway complexo (embora eu evite usá-lo pois ele pode causar mais confusão do que esclarecimento) ou como você disse, a combinação de dois gateways, sendo o primeiro para verificar se está aprovado ou se tem restrições e o segundo inclusivo verificando o tipo de restrição.
Espero ter ajudado!
Obrigada! Fiz dessa forma mesmo, com dois gateways. Acho que ficou mais claro.
Obrigada pela atenção.
Considerando que as melhores práticas não recomendariam o uso de pergunta, quando um modelo tem saída com resposta obrigatória do tipo “sim” ou “não”, ainda assim não se recomenda pergunta no gateway?
Olá Elton,
As boas práticas recomendam evitá-las justamente para instigar o analista e a equipe a considerarem que o gateway pode fazer mais do que tratar respostas binárias (sim/não). Ele testa valores, e até mesmo combinações de valores, que podem ir além de apenas duas saídas. Entretanto, não é uma restrição. Se o cenário do processo de negócio demanda que o fluxo seja roteado desta forma, não há problema em usar perguntas.
Qual é o gateway que possui semântica equivalente ao gateway inclusivo (e/ou), mas que é baseado em eventos. Ou seja, se um evento for disparado, o token presente nos demais eventos não é consumido e, sim, poderá ser acionado a qualquer momento no decorrer do processo.
Olá Paulo. Não há na notação BPMN um gateway intermediário que possibilite a combinação de lógica inclusiva baseado na ocorrência de um ou mais eventos. Isto porque o processo não saberá se, ao ocorrer um dos eventos conectados ao gateway, ele deve ou não esperar os outros ocorrerem para então identificar qual a combinação e fazer a variação do processo. Se você tem um cenário assim, precisará lançar mão de outros elementos para configurar o processo de forma a atendê-lo. Isso depende muito da própria lógica do processo. Se quiser nos enviar um cenário de negócio em que isto é requerido, podemos tentar ajudá-lo a representar esta situação com a notação.
Alguns gestores, comentaram ao utilizar os gatway não os utiliza com uma pergunta, porém eu vi nós exemplos que é possível sim fazer perguntas, qual é o correto?
Olá Carol,
Não existe uma regra específica para o uso de gateways. A notação BPMN é bastante permissiva, ela não detemina o que, que forma ou termos devem ser usados, por isso muitos profissionais da área ajudaram a consolidar algumas boas práticas.
Em geral, perguntas que levem a um roteamento simplificado, como aqueles com resposta “sim” e “não” costumam ser evitadas nessas práticas. Não porque seja proibido/errado, mas porque muitas vezes ele esconde uma oportunidade de deixar o processo mais claro.
Por exemplo, um gateway com a pergunta
"Aprovado?"e respostas"Sim"e"Não"à primeira vista parece usual, mas o que significa realmente “não ser aprovado“? Significa que alguém formalmente rejeitou completamente aquela avaliação e nada mais pode ser feito, terminando o processo? Ou rejeitou apenas por algum detalhe que se for corrigido poderá ser novamente avaliado? Ou talvez porque passou o tempo e ninguém fez nada, e portanto não foi de fato aprovado? Ou foi aprovado, mas com algumas restrições? Esses casos deveriam seguir o mesmo fluxo de “não aprovado“?Caso os caminhos a serem seguidos pelo processo precisem ser explicitados pois levam a sequências de atividades diferentes, a recomendação é que o gateway leve o nome da informação que ele verifica para fazer o roteamento. O que o gateway verifica, neste caso? Ele verifica o
"Resultado da avaliação". Usando este nome para o gateway, podemos explicitar saídas para cada resultado, por exemplo:"Aprovado","Reprovado","Aprovado com restrições"“,"Requer revisão".Portanto, não é errado usar perguntas, mas é uma prática que se recomenda que seja evitada. Em alguns casos, elas fazem sentido, em outras podem estar camuflando lógicas de processo como esta.
Bom dia
Todo Gateway precisa de convergir???
Olá Fábio. A princípio, pelas regras da notação, não precisa, embora tenha se tornado uma prática muito usual. O que determina a necessidade de adicionar um gateway para convergência não é se teve uma gateway de divergência antes, e sim se a partir de um determinado ponto do processo as atividades seguintes possuem dependência em relação ao término das atividades dos fluxos anteriores.
Entretanto, algumas ferramentas de automação, por questões de controle sobre o fluxo, exigem que toda divergência feche de alguma forma em uma convergência, de forma que o processo tenha apenas um evento de fim. Isso é uma restrição imposta pela ferramenta, não pela notação.
Olá, Kelly
Primeiramente adorei seu blog e suas explicações são bem claras. Parabéns!
Indo ao assunto, eu preciso de uma ajuda num caso. No projeto que estou desenvolvendo, o funcionário vai até a casa do cliente, daí ele encontra 5 distintas: ele negocia a divida, ele não negocia a divida, casa abandonada, conta duplicada e “outros”. Utilizando os gateways, eu fico me perguntando como que eu faço desse processo gerar essas 5 condições. Obrigado!
Olá Francisco, se entendi bem, sua dúvida se dá pelo fato do gateway ser um elemento de quatro pontas, e se de cada ponta sair um fluxo para uma condição, então teríamos um limite de três condições… é esta a sua questão?
Bom, na notação BPMN não existe limitação sobre o número de saídas em cada ponta. De uma mesma ponta do gateway podem sair tantos conectores quantos forem os casos. Então não haveria problema se, por exemplo, a ponta da esquerda fosse usada para o conector de entrada no gateway, e todas as saídas saíssem de apenas uma ponta. Do ponto de vista de design, é interessante apenas cuidar para que as linhas não se sobreponham muito e que o desenho fique tão claro quanto possível.
Outra possibilidade é usar uma combinação de dois gateways: um verificando se a dívida foi ou não negociada, e se não foi, o segundo gateway verificaria o motivo – se for aplicável à sua necessidade, claro. Espero ter ajudado!
Estou aprendendo muito com vocês. Parabéns pelo ótimo trabalho!
Tenho uma duvida, se por acaso o fluxo que eu estiver desenhando tenha bastante “tarefas”, ou seja, uma longa lista de itens a ser colocados no fluxo, como a leitura do fluxo deve ser da direita para esquerda, como posso otimizar o espaço dentro da piscina para que não fique muito “longo” o desenho?
Olá Sheila, o processo pode ser descrito na direção em que você quiser: da direita para a esquerda, para cima, para baixo, como for mais conveniente. O mais natural é que façamos o fluxo seguir uma sequência da esquerda para a direita pois é assim que lemos as coisas no ocidente =) mas não é uma regra rígida. É o sentido da seta (para onde ela aponta) que determina o que será feito a seguir, e não o fato dela estar à esquerda, à direita, acima ou abaixo.
Portanto, não há problema se você verticalizar o desenho do fluxo fazendo algumas atividades irem para baixo ocupando espaço da página.
Entretanto, se o fluxo está muito longo, talvez seja interessante considerar se algumas tarefas não poderiam ser reunidas em um subprocesso, de forma a abstrair o detalhamento de algumas etapas do processo.
boa noite, veja se podem me ajudar. Tenho um fluxo onde preciso distribuir documentos para os postos I, II, III e IV. O posto I executa duas atividades (abrir e ler por exemplo), o posto II uma atividade (imprimir), o posto III uma atividade (organizar) e o posto IV uma atividade (arquivar). Como posso representar da melhor forma?
Considerando que o fluxo de uma atividade “distibuir documentos” segue para quaisquer uma das atividades (abrir e ler (são duas atividades), imprimir, organizar e guardar).
Sds,
Antonio
Olá Antonio, para melhor orientá-lo é necessário entender um pouco mais a lógica da distribuição dessas atividades. Assim, seguem duas alternativas – veja qual melhor se aplica ao seu caso:
1) Se todas as atividades são realizadas, mas não tem uma ordem predefinida (um posto pode fazer uma atividade de imprimir antes do outro ler, por exemplo), então você pode usar um gateway paralelo para dividir esse fluxo.
2) Se nem sempre todas as atividades são realizadas (dependendo do documento, por exemplo, não precisa imprimir) então você deve dividir esse fluxo usando um gateway inclusivo.
Boa tarde, Kelly.
Vamos supor que eu configure uma aprovação de ponto de funcionário para um gestor e caso esse gestor não a realize em 3 dias, a tarefa passará um outro gestor e mas ficaria também com o anterior. Com esses 2 gestores podendo aprovar, qual seria o Gateway? Imagino que seja inclusivo, pois o paralelo obrigaria os dois aprovarem (e só precisa de 1), correto? Utilizo o Bonitasoft.
Acho que terá que ser um gateway exclusivo, já que apenas um fará a aprovação. Um inclusivo aguardará o outro fluxo também, se ele tiver sito ativado, mesmo que nunca venha a ser concluído. Além disso, provavelmente será necessário criar algum script para fazer o cancelamento automático da outra tarefa.
Como alternativa, sugiro que em vez de criar uma nova tarefa para o segundo gestor, acione um script para incluir o segundo gestor como co-responsável da mesma tarefa. Assim, o primeiro que responder à tarefa a encerrará, e você não terá dois fluxos para controlar.
Olá Kelly,
Qual gateway utilizar quando tenho 11 tipos diferentes de situações após a verificação da condição?
Agradeço demais a ajuda.
Obrigada
Olá Francisca,
o número de resultados não muda o tipo de gateaway, o que determina o tipo de gateway é a lógica do fluxo. Se os caminhos que saem do gateway forem excludentes, então o gateway é exclusivo; se forem combinatórios, então é inclusivo; e se forem paralelos, então o gateway deve ser deste tipo.
Recomendo considerar duas coisas:
1) O que determina o número de saídas do gateway não é o número de situações diferentes e sim o número de diferentes fluxos. Se das 11 situações de “resposta” que você tiver para o gateway, seis levam para a mesma próxima atividade, então é apenas uma transição que deve ser desenhada.
2) Se são realmente 11 caminhos diferentes, avalie se realmente são todas relativas à mesma unidade de informação. Se forem diferentes, talvez ter gateways em sequência tratando o subnível da informação possa tornar o diagrama mais fácil de ler.
Por exemplo: tenho caminhos diferentes para os casos de aprovado para cliente vip, aprovado para cliente normal, aprovado para prospect, reprovado ou cancelado. Neste caso, um gateway para avaliar o resutlado da aprovação (aprovado/reproado/cancelado) e outro para tratar, no caso de aprovação, o tipo de cliente (vip, normal, prospect) pode deixar a lógica do processo mais clara.
Avalie se há situações assim no seu processo.
Oi, Kelly!
Um gateway de junção, para unir atividades, pode ser conectado à um evento final?
Obrigada desde já.
Olá Camila, pode sim! Você pode sincronizar fluxos alternativos ou paralelos antes de encerrar o fluxo do processo :) Manda ver!
Bom dia!
Estou trabalhando em um projeto onde em determinada tarefa se o resultado for aprovado existem 5 possíveis caminhos (ex: depto 1, depto 2, etc…), e se for rejeitado podem ser seguidos dois possíveis caminhos.
A princípio pensei em colocar dois gateways saindo desta tarefa, um complexo para a aprovação e um exclusivo para a rejeição, mas gostaria de saber se seria correto saírem dois gateways da mesma tarefa, ou teria uma forma de demonstrar melhor no fluxo.
Desde já, agradeço.
Oi Andreza, o seu cenário é bem interessante! Eu evitaria o uso do gateway complexo. Em vez disso, dado o cenário que você descreveu, faria um gateway após a atividade para verificar o resultado (aprovado ou reprovado) e para cada saída dessas um outro gateway para verificar a condição que determina para onde o processo deve seguir (aí depende se a lógica para seguir para os departamentos 1, 2 ou 3 é paralela, exclusiva ou inclusiva). O importante é entender que cada gateway vai verificar uma regra diferente – um verifica o resultado da aprovação, o outro verifica o tipo de situação que leva para o respectivo departamento. Portanto, faz sentido você separar em dois gateways. Espero que a sugestão tenha esclarecido a sua dúvida :)