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.
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.
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 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.
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.
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).
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.
Você se interessou pelo assunto?
Este tema é explorado com mais profundidade em nosso curso “Dominando o Mapeamento de Processos utilizando BPMN2.0 Prático e Avançado” oferecido pela iProcess Education, onde abordamos de forma mais abrangente o tema.
15 respostas
Vi alguns desenhos de processos em que as pessoas associam o evento de início “Chegada de uma mensagem” à raia onde o evento de início foi desenhado, indicando que o papel informado na raia foi responsável por enviar a “mensagem”, como poderia sugerir o desenho de processo usado no exemplo do item (6) acima para a raia “Solicitante”. Isto procede?
Gostaria de saber se um sistema de informação poderia ser representado como ator dentro de um processo. Poderia compor as raias de um processo como ator?
Olá Ana, De acordo com a especificação BPMN 2.0, um sistema de informação pode ser representado tanto como um ator (raia) do processo como um participante externo (pool). Ambas as formas podem ser utilizadas, cabendo mais ao modelador definir por padrão da organização ou por estilo de modelagem como utilizará.
Modelagem m BPMN o tema que escolhi pra desenvolver minha TCC gostaria de receber material e vídeo sobre o assunto tou tendo dificuldade pra fazer modelagem de um sistema sobre Reclamação no Transporte Coletivo.
alguém pode me ajudar?
obrigada.
Oi Rosario, que tal participar da nossa próxima turma EAD de Mapeamento de Processos com BPMN 2.0?
Certamente suas principais dúvidas serão esclarecidas nesse curso que equilibra conhecimentos teóricos e práticos.
A próxima turma está prevista para agosto – confere lá na nossa agenda: iprocesseducation.com.br/agenda
Quanto a evento de início múltiplo como ficaria se um dos eventos de início fosse de outro agente ?
Olá Leonardo, se quem dá o início do processo é um outro processo (na visão de BPMN, tudo é processos – o Agente no caso também tem o seu processo, em que em um determinado momento identifica que precisa iniciar o processo em questão), o início poderia ser através de um recebimento de mensagem ou de sinal.
Isso não fica explícito no desenho do processo se você usar um evento múltiplo; precisará ser detalhado através da documentação/descrição do elemento.
Eeu montei um processo de Desligamento de funcionário, onde existem dois eventos de inicio: “Demissão por parte do funcionário” na raia do “Funcionário” e “Demissão por parte da Coordenação” que fica na raia “Coordenação”.
Minha dúvida é, como eu posso utilizar o evento de inicio múltiplo para evitar ter mais de um processo de inicio, sendo que ao meu ver não tem uma maneira de “centralizar” o evento múltiplo entre as raias “Funcionário” e “Coordenação”.
Olá Paulo,
os eventos não são personificados no BPMN, ou seja, a raia que você colocar tem relação puramente visual com o fluxo do processo, pois o evento acontece independente de quem o acioná-lo. Assim, por exemplo, se você só tivesse um dos eventos, na lane do coordenador, mas um funcionário pedisse demissão, o processo iria acontecer da mesma forma. Ao mesmo tempo, existem outras origens para o seu processo, como por exemplo: se a diretoria da empresa resolver fechar uma área inteira; não seriam iniciados vários processos para cada um dos funcionários a serem desligados?
Assim, nossa recomendação é: se o gatilho do processo é o mesmo (um funcionário precisa ser desligado), o processo deve começar, independente da origem. Com isso, bastaria apenas um evento de início, que pode estar em qualquer raia (como boa prática, recomendamos posicioná-lo na mesma lane onde está a primeira atividade do processo).
Utilize o evento de início múltiplo quando os gatilhos de disparo do processo são de naturezas diferentes (por exemplo uma condição de tempo ou uma solicitação em forma de mensagem).
Quanto ao gateway de início baseado em evento exclusivo…
No exemplo apresentado o processo é iniciado com o referido gateway e fechado com gateway exclusivo. Teoricamente não deveria abrir e fechar com o mesmo?
Grata.
Olá Camila, obrigada por visitar e contribuir para nosso blog.
Primeiramente, é importante esclarecer que não há regra sobre utilizar o mesmo gateway para abrir e fechar fluxos. O que determina qual gateway de combinação de fluxos (join) que deve ser usado é a lógica do processo, e quase sempre é a mesma lógica do gateway que iniciou a abertura dos fluxos. Geralmente, se usamos um gateway exclusivo para abrir os fluxos, não faz sentido usar um paralelo para fechar antes de seguir o processo, já que nunca teremos braços paralelos chegando a ele; da mesma forma pode se dizer de outras combinações de gateways.
Aqui neste diagrama que você questionou, o processo é iniciado por um “gateway exclusivo iniciado por eventos”, ou seja, a lógica é exclusiva. Não existe um gateway desse tipo para fechar o processo, e como a lógica do gateway é exclusiva, usa-se um gateway exclusivo para a combinação dos fluxos.
Espero que a explicação tenha ficado mais clara :)
Após esse exemplo de Gateway de início, os eventos subsequentes são intermediários? Ou serão de início? Pela cor da imagem não ficou claro pra mim.
Olá Bruno!
Neste caso, sempre eventos intermediários (você pode identificá-los pela borda dupla, os eventos de início teriam borda simples).
Cuidado ao guiar-se na identificação dos elementos por cores, pois cada ferramenta pode usar cores diferentes para os elementos. Pela notação formal de BPMN, os elementos são preto e branco.
Olá, um evento de término pode conter mais de uma informação? Por exemplo, senha gerada e cidadão orientado
Oi Mariana,
Você pode colocar essa dupla informação sim, sem problema. Mas procure evitar nomes muito longos.
Uma alternativa é você dar um nome que englobe tudo (por exemplo “conta do cidadão liberada”) e na descrição do evento colocar estes detalhes.
Mas se você faz questão de deixar explícito no diagrama, não tem problema, não há nenhuma regra contra isso :)
OBS: Um detalhe: você disse “evento de término”. Cuidado para não confundir “evento de fim” e “evento de término” porque são tipos diferentes. O “término” é um sub-tipo de evento de fim que só deve ser usado quando o processo é forçado a terminar (“Terminate” em inglês refere-se a “exterminar”. Lembra do filme “Terminator: O Exterminador do Futuro”? Então, é isso!).
Não me parece o seu caso, portanto um evento de fim comum seria suficiente.