BPMN (Business Process Model and Notation) é uma das notações mais completas e utilizadas para a modelagem de processos de negócio. Todavia, com a sua popularidade, tornou-se um desafio manter a qualidade dos modelos devido à subjetividade na interpretação de algumas regras. Além disso, pode ocorrer erros de qualidade sintática (conformidade do modelo desenvolvido com as regras de sintaxe da notação), qualidade pragmática (compressão do modelo pelo leitor) e qualidade semântica (o modelo de processo representa corretamente a execução do processo atual).
A presença de anti-padrões influencia diretamente na compreensão do processo, pois essas más práticas repetidas (roadblocks) acabam não refletindo o negócio com precisão. Isso leva a uma diminuição da utilidade para tomada de decisão, alguns diagramas confundem seus leitores com notações gráficas ambíguas e incongruentes. Além disso, erros de notação podem causar consequências inesperadas quando o fluxo é executado em ferramentas de BPMS.
Assim, separamos alguns anti-padrões mais comuns com recomendações sobre como podemos evitá-los, a partir dos estudos Analysis of Most Common Process Modelling Mistakes in BPMN Process Models de Tomislav Rozman e Anti-patterns for Process Modeling Problems: An Analysis of BPMN 2.0-Based Tools Behavior de Clemilson Brito Dias.
Anti-padrão 1: Processo não possui um evento de início e fim
Problema: Segundo a notação BPMN, os eventos de início e fim não são obrigatórios. No entanto, caso o evento de início seja utilizado, obrigatoriamente devemos utilizar o de fim e vice-versa. Em casos de processos mais complexos, a falta do uso de eventos pode ocasionar ambiguidade no entendimento do modelo. Analisando a figura abaixo, podemos ver que os usuários poderão não saber quando deverão iniciar o processo ou o que fazer quando atingirem o término das Tarefas 2 e 3, passando uma percepção de que o processo pode estar incompleto.
Anti-padrão : Processo não possui um evento de início e fim
Tipo de erro: Erro de qualidade pragmática.
Boa prática recomendada: Ao modelar processos, especifique explicitamente onde o fluxo inicia e termina independente da complexidade do processo.
Padrão correto
Anti-padrão 2: Atividades na piscina (pool) não estão conectadas
Problema: Não possui um fluxo de sequência conectando as atividades inseridas dentro de uma mesma piscina. Observando a figura abaixo, percebe-se que não é possível visualizar a dependência da Tarefa 3 com as demais atividades, portanto o disparo da mesma é desconhecido, comprometendo a execução do processo.
Anti-padrão: Atividades na piscina não estão conectadas
Tipo de erro: Erro de qualidade sintática e semântica.
Boa prática recomendada: Conforme a especificação BPMN, todos os elementos do processo inseridos dentro de uma piscina devem estar totalmente conectados por fluxos de sequência. A figura abaixo ilustra uma solução para esse anti-padrão.
Padrão correto
Anti-padrão 3: Uso incorreto de fluxo de sequência e mensagem
Problema: Fluxos de sequência utilizados para conectar atividades localizadas em piscinas diferentes ou fluxo de mensagem utilizado para conectar atividades localizadas na mesma piscina. Esses tipos de erros podem ocasionar erros de interpretação do processo, pois o fluxo de sequência determina a ordem de precedência entre as atividades de um processo, enquanto o fluxo de mensagem representa uma comunicação acontecendo entre dois processos (cada um em sua respectiva piscina).
Anti-padrão: Uso incorreto do fluxo de sequência
Anti-padrão: Uso incorreto do fluxo de mensagem
Tipo de erro: Erro de qualidade sintática, semântica e pragmática.
Boa prática recomendada: Para conectar dois participantes dentro de uma mesma piscina deve-se utilizar o fluxo de sequência. Quando mais de uma piscina é utilizada na modelagem de um processo, a interação entre piscinas devem ser conectadas por fluxo de mensagens. Além disso, cada piscina deve ter o seu fluxo próprio.
Padrão correto de uso de fluxo de sequência
Padrão correto de uso de fluxo de mensagem
Veja mais exemplos no artigo: BPMN: Modelando corretamente o fluxo de sequência de atividades.
Anti-padrão 4: Gateway produz, recebe e avalia dados
Problema: Gateway realizando ações dentro do processo. A causa mais comum para esse tipo de problema é uma da interpretação equivocada de que o gateway pode ser utilizado como uma atividade dentro de um processo. Analisando a figura abaixo, percebe-se que a atividade “Solicitar férias” dispara uma tomada de decisão diretamente no gateway, o que é incorreto.
.
Anti-padrão: Gateway produz, recebe e avalia dados
Tipo de erro: Erro de qualidade sintática e semântica.
Boa prática recomendada: Segundo as especificações BPMN, os gateway são elementos de controle de divisão e unificação do fluxo, logo, um gateway não pode ser usado para representar trabalho como produzir, receber ou avaliar dados. Ao modelar processos, adicione tarefas para que estas recebam e/ou produzam as ações necessárias, como mostra a figura abaixo.
Padrão correto
Para compreender melhor sobre o uso de gateway, veja também estes artigos: (Diferenças entre os gateways de BPMN (com animações!) e (Estudo de caso: Boas práticas no uso de gateways em BPMN)
Anti-padrão 5: Cada raia na piscina contém um evento de início
Problema: Inserir um evento de início em cada raia da piscina de um modelo de processo. Embora a notação BPMN permita essa prática, os especialistas da área não recomendam, pois pode causar uma ambiguidade no entendimento do processo (por exemplo: precisam iniciar ao mesmo tempo? Ou, se um tiver iniciado e o outro iniciar posteriormente, será o mesmo caso de processo em andamento ou um novo processo?). Além disso, pode fazer com que o executor entenda que os trechos em cada raia são independentes e isso nem sempre pode ser verdade.
Anti-padrão: Cada raia na piscina contém um evento de início
Tipo de erro: Erro de qualidade pragmática.
Boa prática recomendada: Em cada piscina inclua apenas um evento de início seguido de uma sequência de atividades, conforme a figura abaixo. Existem outras soluções para esse problema, mas suas aplicabilidades dependerão do objetivo do processo em questão.
Padrão correto
Anti-padrão 6: Evento intermediário de borda não estar conectado a exceção
Problema: Utiliza evento intermediário de borda, porém sem modelar o fluxo a ser executado no caso do gatilho do evento da borda ser acionado, como mostra a figura abaixo. Pela notação BPMN temos um erro sintático, pois ao adicionar um evento intermediário de borda devemos criar um fluxo paralelo caso a exceção seja acionada, todavia, se o objetivo é representar uma exceção, temos um problema semântico na modelagem, pois se a tarefa atual for interrompida, nenhuma outra ação será executada devido a forma incorreta com que foram implementadas as conexões.
Anti-padrão: Evento intermediário de borda não estar conectado a exceção
Tipo de erro: Erro de qualidade sintática e semântica.
Boa prática recomendada: Primeiro procure compreender o que pretende representar com o evento intermediário de borda. Se o objetivo é representar um fluxo de exceção, então o fluxo de sequência deve ser conectado ao evento intermediário de borda conforme mostra abaixo.
Padrão correto
Anti-padrão 7: Uso de eventos de mensagens para comunicação dentro do processo
Problema: Evento de mensagem utilizado para comunicação entre raias dentro de um mesmo processo. Analisando a figura abaixo, podemos ver que foram utilizados dois eventos do tipo messagem, um de envio (throw message) na raia do “Analista de RH” e outro de recebimento (catch message) na raia do “Colaborador”. Entretanto o evento do tipo mensagem não serve para comunicação entre participantes do mesmo processo.
Anti-padrão: Uso de eventos de mensagens para comunicação dentro do processo
Tipo de erro: Erro de qualidade sintática e semântica.
Boa prática recomendada: Segundo as especificações da BPMN, eventos de mensagem deverão ser utilizados para demonstrar um ponto do processo onde ocorre uma comunicação com um outro processo ou agente externo. O evento de throw message tem como símbolo um envelope preto e sinaliza o envio da comunicação, enquanto o evento do tipo catch message tem como símbolo um envelope branco e sinaliza o recebimento da mesma. A abaixo apresenta uma solução para esse anti-padrão.
Padrão correto
Para entender mais como utilizar eventos intermediários, veja também estes artigos: Um guia para iniciar estudos em BPMN (IV): Eventos Intermediários e Diferenças entre eventos de Link, Message e Signal.
Aproveite as recomendações e boa modelagem!
4 respostas
Excelente!
Olá!
Parabéns pelo ótimo artigo!
Vocês abordaram um tema bastante pertinente, visto que esses anti-padrões são realmente bem comuns e causam muita confusão entre Analistas de Negócios, de Processos, de Requisitos e de Sistemas, pois abrem margem para interpretações subjetivas nas especificações dos processos, o que é contraproducente na nossa prática profissional como Analistas/Consultores.
Apesar de bem escrito e pertinente, há algumas ressalvas ao texto do artigo. Por exemplo:
i) Na seção “Anti-padrão 3: Uso incorreto de fluxo de sequência e mensagem”, a segunda figura “Anti-padrão: Uso incorreto do fluxo de mensagem” e a quarta figura “Padrão correto de uso de fluxo de sequência” são exatamente a mesma imagem, logo é impossível, inferir qual o padrão errado no fluxo de mensagem.
ii) Na seção “Anti-padrão 5: Cada raia na piscina contém um evento de início”, embora o texto esteja correto e a figura “Padrão correto”, seja realmente uma das soluções possíveis para esse Anti-padrão, diria até que a mais simples das soluções. Porém, mesmo que haja a interconexão das atividades em um único fluxo, ainda existem processos nos quais há a real necessidade de se modar mais de um evento de início, em geral, nesses processos, os eventos de início apresentam as diferentes situações/condições que podem iniciar do processo.
Por exemplo: o processo para produção de um relatório, que fará parte do planejamento mensal da gerência. Esse relatório deve realizado, todos os meses, até a última semana do mês. O processo de elaboração e envio ao gerente pode ser iniciado em qualquer ponto do mês pelo funcionário responsável por elaborar o relatório, porém, se o processo não for iniciado pelo funcionário até o início da última semana do mês, o sistema irá iniciar o processo automaticamente e enviar uma mensagem avisando que a tarefa se iniciou e o prazo limite de entrega, tanto para o executor, quanto para o gerente.
Nesse exemplo, há umas formas possíveis de início para o processo, e apesar de existirem formas de usar eventos intermediários para se modelar essa situação como tendo apenas um início, seguido de eventos intermediários, e o evento que se realizar primeiro dá seguimento ao processo.
Porém, solução mais simples são dois inícios ligados à um gateway do tipo XOR e a uma tarefa analisando qual dos eventos de início foi acionado. Nesse caso há dois eventos de início, porém apenas o evento que acontecer primeiro dará seguimento ao processo.
Assim, apesar de, nessa situação, existirem múltiplos eventos de início, podendo ou não ser um em cada raia, pela especificação do BPMN, esse é um modelo sintaticamente correto. Visto que apenas um dos eventos pode dar início àquela instância específica do processo. Não há ambiguidade a respeito de qual evento se início se aplica a cada situação.
Fora isso, ótimo artigo!
Vocês estão de Parabéns!
Olá, Nicholas! Muito obrigada pelos seus comentários e contribuições, muito ricas para a discussão de BPMN!
i) Corrigido.
ii) Excelente exemplo e de fato não é errado usar dois eventos de início na mesma piscina, mas segundo a literatura analisada não é uma prática recomendada. No caso em que você citou e pensando em um modelo mais objetivo para a compressão do leitor, o ideal seria usar um evento intermediário de borda tipo timer.
Parabéns pelo Artigo.!!