A boa modelagem de processos de negócio em BPMN é resultado do domínio da notação, fruto de estudo e compreensão dos elementos. Esse aprendizado se faz de diversas formas, principalmente através da aplicação prática e também com exemplos (bons e ruins). Coletamos algumas dúvidas comuns de iniciantes na notação BPMN, participantes dos nossos cursos e leitores do blog da iProcess, sobre a aplicação dos eventos, cujas respostas compartilhamos aqui.
1) É típico das ferramentas de modelagem de processos representarem elementos BPMN por cores, estas cores muitas vezes variam de ferramenta para ferramenta. Oficialmente que cor possui cada evento (Início, intermediário e fim)?
Os elementos BPMN não são representados por cores, mesmo que muitas vezes ferramentas de modelagem representem estes e outros elementos com cores, a especificação não define uma cor para o elemento, pelo contrário, representa na forma preto e branco. Ferramentas de modelagem como Bizagi, por exemplo, costumam diferenciar os elementos BPMN por cores.
O objeto evento é representado graficamente, na sua especificação, por um círculo. Eventos que marcam o início do processo são representados por uma borda de linha simples, já eventos intermediários são representados por duas linhas circulares concêntricas e eventos de fim são representados por uma linha simples com uma borda mais espessa.
A notação deixa o uso de cores livre e podem ser usados tanto para identificar visualmente os tipos de elementos quanto com outros propósitos, como por exemplo: sinalizar com uma cor os elementos que estão mudando de uma versão para outra em uma revisão do processo, ou destacar eventos críticos para o processo.
Na grande maioria, estas ferramentas de modelagem possuem em suas configurações a opção para apresentar o desenho do processo em preto e branco.
2) O uso do evento de início e evento de fim são obrigatórios?
Não são obrigatórios, porém seu uso é altamente recomendado por se tratar de uma boa prática, pois com estes elementos definimos e identificamos visualmente o ponto inicial e final do processo.
Regra: se um evento de início é definido, obrigatoriamente, um evento de fim também deve ser (e vice-versa).
3) Se o evento de início e evento de fim não são obrigatórios, como identificamos o início e fim do processo quando estes eventos não estão definidos?
Quando o processo segue um fluxo definido pelo fluxo de sequência (sequence flow), identificamos o início (ponto de partida) e fim do processo (ponto final) pelo primeiro e último elemento do fluxo.
No exemplo acima, a tarefa “Escolher produtos” é o primeiro elemento do fluxo, portanto o processo inicia-se por ele. O fluxo segue até a tarefa “Realizar entrega da mercadoria”, que por não apresentar um fluxo definido após sua ocorrência, é considerada o ponto final do processo.
4) Caso seja necessário, posso voltar ao início do processo ligando o fluxo de sequência ao evento de Início?
De forma alguma! A especificação deixa claro que o evento de início não pode ter nenhum fluxo de sequência apontando para ele. Além disto, o evento de início só pode ser executado/inicializado uma única vez para cada instância de processo.
No exemplo, o fluxo retornou de forma correta a tarefa “Solicitar Férias”.
Emprego indevido da notação BPMN! A saída do gateway está retornando ao evento de início!
Se realmente for necessário que o processo volte ao seu início, o fluxo de sequência deverá ser ligado ao elemento que vem logo após o evento de início.
5) É obrigatório o uso de rótulo (nomenclatura) nos eventos? Como devo utilizar?
Não é obrigatório, porém o uso é considerado uma boa prática pois impacta diretamente na clareza e compreensão do processo. O rótulo deve apontar o motivo daquele processo ocorrer (evento de início), motivo para dar andamento (evento intermediário) ou motivo de chegar ao fim (evento de fim).
Exemplo de rótulo nos eventos do processo, seu uso é altamente indicado para compreensão correta do processo!
6) Um processo que conter mais de um evento de início é considerado sintaticamente incorreto (emprego indevido da notação)?
Pela especificação não! Porém a própria especificação deixa claro que a compreensão do processo pode ser prejudicada se houver vários eventos de início e que o modelador deve estar ciente que os leitores do processo podem ter dificuldades na interpretação do diagrama, por isto recomenda-se usar este recurso com moderação.
A boa prática nos indica o uso de tipos de eventos que abstraem a ocorrência de mais de um evento em um único objeto. É o caso do Evento Múltiplo e o Evento Paralelo.
No exemplo acima, o processo pode iniciar com uma ligação do 0800 ou por envio de SMS ou ainda por um e-mail. Basta que um destes gatilhos seja disparado para que o processo inicie. Importante destacar que o gatilho acionado cancela os demais.
Diferente do evento de início múltiplo, o evento de início paralelo requer que todos os tipos de eventos, abstraídos no objeto, sejam realizados para que o processo inicie.
Para que o processo acima inicie, contendo o evento de início paralelo, deverá ser aprovado o investimento e confirmado o orçamento pelo financeiro. Necessariamente todas as condições devem ocorrer para que o processo inicie. Este é mais um motivo para abstrair diversos eventos em um único objeto (possibilidade de aplicar condições para o processo iniciar).
Existe ainda uma terceira forma de modelarmos o cenário de múltiplos eventos de início. É utilizando o Gateway de Início Baseado em Evento Exclusivo, outra indicação de boa prática para substituirmos pelos diversos eventos iniciais.
O gateway de início baseado em evento exclusivo depende do resultado dos eventos imediatamente posteriores a ele. O primeiro evento que for disparado cancela os demais.
7 ) Vários eventos de fim (sempre que necessário) é considerado uma boa prática de modelagem?
Sem dúvida, sim! Utilizar eventos de fim dá maior visibilidade e clareza das situações em que o processo pode terminar.
Em alguns casos, deixam de ser apenas boas práticas e se tornam vitais para o perfeito funcionamento do fluxo. É o caso do exemplo abaixo, em que as saídas do subprocesso de aprovação de compras são replicadas no processo de compras para informar o caminho que o fluxo deverá seguir.
O gateway que vem logo a seguir do subprocesso de aprovação de compras replica exatamente as mesmas saídas apresentadas dentro do subprocesso.
Encerramos mais um artigo 🙁
Mas não fique triste, confira outros conteúdos do blog! 🙂 🙂 🙂
Entre para nossa lista e receba conteúdos exclusivos GRATUITOS com prioridade
Não durma no ponto! Não perca nenhum conteúdo da BPM ACADEMY!
E não se preocupe, assim como você, não suportamos SPAM.
Espero que tenha gostado deste artigo!
Deixe seu comentário abaixo, sua opinião neste blog é muito importante!
Se estiver procurando por um assunto que não encontrou, comente!
Se este artigo te surpreendeu, compartilha!
Aproveita e siga a BPM ACADEMY nas redes sociais…
isso seria ótimo para a disseminação do conhecimento e a cultura da Gestão por Processos!
Nos vemos no próximo artigo!
Até mais!!!