Como já comentamos em diversos artigos deste blog, é possível representar uma mesma situação de negócio de formas diferentes com BPMN.
A seguinte questão foi levantada esta semana por um de nossos leitores, que acompanhou o diagrama logo abaixo:
“Qual a maneira correta de representar uma decisão binária (sim ou não)?
É correto utilizar o evento de erro na atividade para representar o ‘não’?
Para os 3 casos, as notificações acontecem caso o ‘caminho feliz’ não seja satisfeito. O que você me diz disso sobre a notação?
Tenho que utilizar 3 gateways?”
No livro “BPMN Method & Style” 2a ed, Bruce SIlver fala o seguinte (pág 104):
“Um evento de Erro na borda de uma tarefa simplesmente representa o estado final de exceção da tarefa. O fluxo normal, a sequência de saída da tarefa, representa o seu término quando a tarefa é concluída com sucesso, e o fluxo de exceção, a sequência de saída através do evento de Erro, representa o término quando o resultado não é bem sucedido. Ele representa exatamente a mesma coisa que um gateway XOR (Exclusive data based) seguido do resultado da tarefa com fluxos de sucesso e exceção.”
De fato, ao analisarmos a especificação da notação (https://www.omg.org/spec/BPMN/2.0/), não há nenhuma restrição que indique que não seja correto utilizar este evento com esta conotação. Alguns profissionais preferem utilizar outro evento, o de Escallation, que possui semântica semelhante à do evento de Error, porém mais relacionada a uma percepção de falha relacionada ao negócio (e permite tratamento non-interrupting), reservando para o evento de erro as falhas relacionadas a exceções técnicas.
Em geral, nas modelagens que realizamos em nossos projetos, damos preferência pelo uso de gateways para verificar o resultado da tarefa (que pode ser mais do que simplesmente uma decisão binária de sim ou não). Deixamos o evento de erro na borda para tratar casos que representem efetivamente uma exceção. Um dos argumentos para esta escolha está no fato de que muitas vezes estes processos serão posteriormente automatizados em um BPMS, e para os motores de execução de processos é mais fácil realizar a validação de resultados da tarefa através desta composição.
Do ponto de vista estritamente relacionado ao uso da notação BPMN, todas as abordagens acima são permitidas.
A segunda parte da dúvida do leitor é “Tenho que utilizar 3 gateways?”
Bem, talvez não para este caso. Quem sabe podemos propor uma outra perspectiva? Uma análise do diagrama um pouco mais observadora nos faz pensar que talvez nesta modelagem as operações estejam sendo representadas em um nível de granularidade muito baixo. Será que podemos considerar que “Verificar se há período sem lançamento”, “Verificar se há RATs abertos” e “Analisar despesas” poderiam na verdade ser procedimentos de uma única tarefa? É como se a tarefa fosse “Analisar pendências e despesas” na qual a ferramenta do usuário fosse uma checklist com estas três questões.
Não seria melhor que todas as análises fossem realizadas e o colaborador recebesse como resultado não uma notificação relatando resultado apenas da primeira divergência identificada, mas uma única que já contivesse tudo o que ele precisa resolver para que sua requisição possa ser atendida? Com essa consolidação de procedimentos em uma única tarefa, não haveria mais a necessidade de três gateways, mas um. E ele poderia resolver mais do que o resultado “sim” e “não”. Que tal se os resultados fossem “aceito”, “aceito com restrições” (em que as divergências não bloqueiam a continuidade do processo) e “rejeitado”? Vale a reflexão :)
De qualquer forma, independente da opção, recomendamos sempre que a organização defina um estilo de modelagem com diretrizes de utilização da notação, que guiarão os modeladores a representarem os processos de uma forma padronizada.
Aprenda a utilizar todo o potencial da notação BPMN em exercícios práticos e avançados com nossos instrutores!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br
