Este é o terceiro artigo de uma série dedicada ao estudo da notação BPMN básica, ou nível descritivo. No artigo anterior, descrevemos um importante elemento na representação de processos nesta notação, os gateways.
Este artigo é dedicado ao esclarecimento de outro importante componente de fluxo em BPMN: os eventos.
Eventos (Events) são elementos utilizados para representar a ocorrência de fatos em um processo.
Eventos podem representar a espera de que um fato aconteça para iniciar/prosseguir a execução o processo ou então sinalizar que o processo produzirá a ocorrência de um fato durante ou ao término de sua execução.
Os eventos são sinalizados no processo através de um círculo, e dependendo do ponto do processo onde ocorrem podem ser sinalizados de forma diferente:
- Eventos de início (Start events) marcam o ponto onde o processo inicia e são representados por um círculo de linha simples.
- Eventos intermediários (Intermediate events) marcam ocorrência de eventos no decorrer do processo e são representados por um círculo de linha dupla.
- Eventos de fim (End events) marcam o ponto onde o processo termina e são representados por um círculo de linha grossa.
Eventos que aguardam fatos e possuem uma causa são chamados “catch”.
Eventos que produzem fatos e possuem um resultado são chamados “throw”.
A causa ou resultado do evento é chamado “trigger” (gatilho) e sinalizado através de um símbolo dentro do elemento. Os tipos de gatilho variam de acordo com cada tipo de evento.
Evento de início (Start Event)
O evento de início marca o ponto onde deve-se iniciar a leitura ou a execução de um processo.
O evento de início será sempre do tipo catch, pois deve aguardar a ocorrência de um evento para realizar o disparo (início da execução) do processo.
É recomendável que todo o processo tenha um evento de início para facilitar a leitura do diagrama, possibilitando a quem lê identificar por onde começa o fluxo de atividades.
Os tipos de evento de início mais comuns são:
None
O processo é iniciado sem a definição de um fato específico que gere o seu início.
Não possui símbolo.
Timer
O processo é iniciado pela ocorrência de um fato temporal, como a chegada de uma data específica (ex. 01 de janeiro) ou relativa (ex. primeira terça-feira do mês).
É simbolizado por um relógio.
Message
O processo é iniciado com a chegada de uma comunicação de qualquer tipo (um documento, uma mensagem, um telefonema, etc).
É simbolizado por um envelope branco (catch).
Conditional
O processo é iniciado quando uma determinada condição torna-se verdadeira. É simbolizado por um desenho de página com linhas representando as condições.
Evento de fim (End event)
O evento de fim marca o término onde deve-se iniciar a execução de um processo.
O evento de fim será sempre do tipo throw, marcando que o processo termina com a geração de um fato.
É recomendável que todo o processo tenha ao menos um evento de fim. É possível entretanto simbolizar términos diferentes para o processo usando mais de um evento de fim.
Os tipos de evento de fim mais comuns são:
None
O processo termina sem gerar nenhum fato específico.
Não possui símbolo.
Message
O processo é finalizado com o envio de uma comunicação de qualquer tipo (um documento, uma mensagem, um telefonema, etc). É usado para iniciar um outro processo ou fornecer um resultado a uma comunicação começada no início ou decorrer do processo.
É simbolizado por um envelope preto (throw).
Terminate
O processo é terminado finalizando por completo, mesmo que existam atividades em fluxos paralelos em execução. Caso existam atividades em execução quando um dos fluxos existentes atinja o evento de fim terminate, as tarefas pendentes são canceladas e o processo é dado como completamente finalizado.
É simbolizado por um círculo preto preenchido.
No exemplo acima, o evento de fim “Processo arquivado” é do tipo terminate. Se a tarefa “Arquivar processo” for concluída antes das atividades do fluxo paralelo, o processo chegará ao evento terminate e as tarefas que ainda estavam em execução serão interrompidas. Mas se a tarefa “Anexar documentos pendentes” terminar antes de “Arquivar processo”, o processo finalizará com todas as atividades executadas, pois diferente do evento terminate o evento do tipo none não interrompe a execução de atividades no fluxo paralelo.
Embora o uso de eventos de início e fim não sejam obrigatórios, são considerados uma boa prática, fundamental para a obtenção de um processo bem mapeado, claro e legível a todos os participantes do processo.
Há porém uma regra na especificação que deve ser observada: se for utilizado um evento de início no processo, deve obrigatoriamente haver ao menos um evento de fim. Da mesma forma, se for adicionado ao mapeamento do processo um evento de fim, então o processo deve obrigatoriamente possuir ao menos um evento de início.
Existem outros gatilhos para eventos de início e de fim do processo. Estes apresentados, porém, são os mais comumente utilizados e que compõem o nível de componentes do nível descritivo da notação BPMN.
No próximo artigo:
o tema Eventos continua! Estudaremos os principais usos e tipos de eventos intermediários, usados para prever ocorrência de eventos no decorrer da execução dos processos.
Confira todos os artigos deste guia de BPMN Nível 1:
- Um guia para iniciar estudos em BPMN (I): Atividades e sequência
- Um guia para iniciar estudos em BPMN (II): Gateways
- Um guia para iniciar estudos em BPMN (III): Eventos de Início e Fim (você está aqui)
- Um guia para iniciar estudos em BPMN (IV): Eventos Intermediários
- Um guia para iniciar estudos em BPMN (V): Subprocessos
- Um guia para iniciar estudos em BPMN (VI): Swimlanes e Artefatos
31 Responses
Boa tarde, antes de mais nada, parabéns pela iniciativa de compartilhar seus conhecimentos, principalmente pelo fato do conteúdo de BPM e BPMN ser ainda muito pobre para quem está iniciando. Os artigos são bem didáticos!!!
Tenho uma dúvida acerca de Evento de fim (End event): fiz um mapeamento de processos que engloba 4 departamentos (dentro de uma pool) da empresa onde trabalho.
Em uma lane, coloquei um evento TERMINATE para, justamente, representar o término por completo de todo processo; nas outras 3 lanes, coloquei em cada uma um evento NONE para justamente mostrar que os processos terminam sem gerar um fato específico.
Por causa disso, estou sendo muito criticado, pois meus colegas e superiores afirmam que todo mapeamento de processo deve ter SOMENTE UM EVENTO DE INÍCIO E UM EVENTO DE FIM.
Porém, segundo o que você explicou em seu artigo, e um processo “É recomendável quhe se tenha ao menos um evento de fim. É possível entretanto simbolizar términos diferentes para o processo usando mais de um evento de fim.”.
Logo, fica claro que existe a possibilidade de se colocar pelo menos um evento de fim em um processo. Não é verdade?
Aproveitando a oportunidade, gostaria de saber se é possível (co)existir em um processo mais de um evento TERMINATE ou mais de um evento NONE.
Desde já, agradeço a atenção dispensada.
Att.,
Marcos Mello.
Olá Marcos, em nome da equipe de blogueiros da iProcess agradeço sua mensagem!
Em relação aos múltiplos eventos de fim: É uma boa prática ter apenas um evento de início, mas um processo pode sim ter diferentes eventos de fim. É inclusive considerado uma boa prática. Por exemplo, se tenho um processo que pode terminar como aprovado, mas há um fluxo alternativo cujo resultado do processo é reprovado, é bastante recomendado ter eventos de fim diferentes para especificar o fim do processo em cada situação.
Em um caso de paralelismo, múltipos fins não farão muita diferença. Isto porque, mesmo que um dos fluxos paralelos chegue ao evento de fim, os outros continuarão em execução. O processo só será considerado “concluído” quando não haja mais nenhuma atividade em execução – ou seja, quando todos os fluxos alternativos forem concluídos. Portanto, ter os fluxos paralelos cada um com seu fim, ou ter um gateway ao fim das atividades para reunir estes fluxos em um único evento de fim, na prática da interpretação do processo em BPMN, não fará diferença. Uma idéia interessante, se você optar por manter estes eventos de fim separados no diagrama, seria atribuir ao label de fim o estado em que o processo acabou para cada fluxo. Assim, o leitor do processo entenderá facilmente que o processo acaba quando todos estes estados forem atingidos :) O melhor teste, ao meu ver, para se definir se ter o término dos processos separados ou não, é o de legibilidade. Experimente apresentar o diagrama a uma pessoa que não conheça o processo mas que consiga ler um fluxograma simples e peça que ela tente interpretá-lo (sozinha, mas você pode apoiar na interpretação de gateways, etc).
Mais importante que o modelador achar que fez uma boa documentação do processo é ter certeza que outras pessoas possam interpretá-lo sem precisar de muita ajuda (preferencialmente de nenhuma!).
Em relação ao evento de fim com trigger “terminate”, acho importante esclarecer que ela só fará diferença em relação a um evento none se houverem fluxos paralelos. O “terminate” implica no entendimento que, quando o processo atingir este evento de fim, *se* houver alguma atividade ainda em execução em outro fluxo do mesmo processo, ela é cancelada, e todo o processo é dado como “concluído”.
Espero ter ajudado!
Bom dia!
Estou com uma dúvida sobre o início.
É uma boa prática existir apenas um tipo de início no processo?
Por exemplo:
Tenho um processo que pode ser iniciado por 3 gatilhos, sendo:
1 – Por recebimento de um e-mail (um serviço fica lendo uma caixa de e-mail e quando reconhece o e-mail, o processo é iniciado).
2 – Este mesmo processo pode ser iniciado quando um documento específico é incluído no sistema pelo operador.
3 – Este mesmo processo pode ser iniciado quando um documento específico é incluído no sistema pelo fornecedor.
Tudo isso ocorre em momentos diferentes e distintos e iniciam o processo.
Olá Ricardo, estava avaliando as informações que você passou com a sua dúvida.
Mesmo que tenha três origens, entendo que o gatilho de início do processo é o mesmo: a chegada de uma informação (que pode ser recebida no formato de um documento específico ou no conteúdo de um email).
É claro, precisaria conhecer um pouco mais do processo de negócio para entender as implicações e particularidades do processo para tratar as diferenças da origem dessa informação (talvez no caso do email tenha alguma atividade distinta? mas isso poderia ser tratado através de um gateway), mas creio que no cenário que você descreveu, poderia considerar o início do processo um mesmo gatilho: um evento de recebimento de mensagem.
Espero ter ajudado! Continue enviando suas dúvidas, para nós é um prazer ajudar a esclarecê-las!
Boa noite,
Tenho uma dúvida e não encontrei nenhum material que me auxiliasse. É necessário inserir um evento de início em cada lane ou o correto é utilizar apenas um evento de início por pool?
Atenciosamente,
Felipe
Olá Felipe.
Uma pool deve conter apenas um processo, e é ele quem deve ter o marcador de evento de início e fim. As lanes representam apenas os participantes por onde o fluxo passa. Assim, todas as atividades das lanes devem estar conectadas em um mesmo fluxo.
Pela especificação BPMN, não é correto colocar eventos de início para cada lane.
Veja neste artigo BPMN: demonstrando a continuidade de processos que os exemplos mostram processos com pools contendo duas ou mais lanes – mas há apenas um evento de início, marcando onde o processo inicia. No diagrama em que há duas pools, cada um tem um evento de início, porque cada pool representa um processo.
Olá,
Este blog é ótimo! Gostaria de esclarecer duas dúvidas sobre eventos de início:
1) É errado modelar com mais de um evento de início em uma pool?
Por exemplo, um subprocesso inicia com um único evento de início, mas podem ocorrer situações que fazem com que este subprocesso também possa ser executado a partir de uma outra tarefa que não a primeira (digamos, a terceira tarefa do fluxo, pulando as duas primeiras). Isso pode ocorrer quando, por exemplo, lá na frente no processo é necessário refazer um conjunto de tarefas do subprocesso (neste caso, lançando um evento, que é capturado no subprocesso para iniciá-lo a partir da 3a tarefa).
2) Supondo que existem várias condições para iniciar um subprocesso, é correto usar vários eventos de início ligados a um gateway exclusivo para indicar que o processo inicia somente por algum deles? Ou seria mais indicado usar um único evento múltiplo de início, nomeado por todas as condições separadas por “ou”?
Agradeço muito!!
OI Nilton,
A notação é flexível ao permitir que um processo tenha mais de um evento de início, mas há um consenso comum entre profissionais de processos de que esse tipo de prática deve ser evitado pois pode causar confusão sobre como é iniciado o processo. Portanto não é errado, mas também não é uma prática recomendada.
Quando você tem um processo que pode iniciar por gatilhos diferentes, existem alguns elementos especiais para esse tipo de representação.
No artigo Desmistificando o uso de eventos em BPMN, demonstramos com bons exemplos os eventos de ‘Início Múltiplo’, ‘Início múltiplo paralelo e também o ‘Gateway de Início Baseado em Evento Exclusivo’, que são formas de representar o início de um processo com mais de um tipo de evento.
Muito obrigado, Kelly.
Bom dia,
Gostaria de agradecer pelo Blog que tem me ajudado muito nos estudos de BPMN..
No entanto me surgiu uma dúvida, como poderia representar um processo onde o cliente ao fazer sua requisição ele precisa entregar alguns documentos porém essa entrega poderá ser feita em diversos locais como um posto avançado,, direto na unidade,,, numa recepcao nesses locais cada um tratará de formas distintas. No posto avançado ao verificar o que está sendo pedido alguns casos ele poderá resolver ali mesmo e em outros encaminhará pra unidade central, a recepção só verificará a pendências de documentos e encaminhará pra unidade e a unidade resolve tudo. Terei que usar o início múltiplo? Como? Será que vocês podem esclarecer minha dúvida?
Obrigada!
Eunice, agradecemos seu feedback e ficamos felizes que nosso blog tem contribuído para seus estudos na área.
Precisaríamos entender um pouco mais o processo para propor a melhor solução já que existem diferentes formas de representar este cenário, mas a forma ideal realmente precisaria de um entendimento mais detalhado. Uma pena que só identificamos sua mensagem agora (havia caído no filtro antispam da ferramenta do blog).
Se ainda houver interesse, entre em contato com a gente e podemos agendar um mentoring.
Olá!
Um evento TERMINATE interrompe quaisquer atividades de todo o processo que está contido ou somente as que estão sendo executadas em paralelo ao fluxo que chegou ao “terminate”?
Olá Paulo,
O evento terminador (terminate) finaliza o processo inteiro. Ou seja, qualquer atividade ou evento que esteja ativo esperando resposta será cancelado, independente de quais/quantos sejam e de estarem ou não conectados ao fluxo que leva ao evento de terminate.
Ele serve justamente para possibilitar que o processo seja completamente finalizado.
Muito Bom o artigo.
Estou com uma dúvida:
Eu tenho um finalzinho de processo que estão sequenciados da seguinte forma:
Atividades – event end NONE – gateway paralelo – 3 subprocessos
É correto essa estrutura?
Ex.
O processo é afastamento de funcionário:
Com isso o final ficou:
Atividade: atualizar cadastro do funcionário – event end none: funcionário afastado – gateway paralelo – subprocessos: Gerir Benefícios, Processar folha de pagamento e Controlar frequência periodicamente
Obrigada
Olá Graciele, sua modelagem está boa mas precisa de um pequeno ajuste: após o evento de fim (event end) não pode haver nenhum outro elemento, pois ele justamente marca o fim do processo.
Assim, você pode removê-lo do ponto onde está, fazendo com que logo após a atividade venha o gateway paralelo para acionar os tres subprocessos. A partir de cada subprocesso, conecte-os novamente usando um gateway paralelo para então levar ao evento de fim. Com isso você garante que seu processo só chegará ao final quando todos os subprocessos forem concluídos.
Não esqueça de colocar também um evento de início antes da primeira atividade!
Excelente Blog, gracias por compartirlo !!!
Espero puedan leer y responder mi consulta.
Estoy haciendo el flujo de un proceso cuyo inicio principal depende de un Plan de mantenimiento, sucede que durante el proceso si se detecta una anomalía , se comunica el incidente y se continúa con el flujo, pero si no hay incidentes el flujo no se afecta. Estoy considerando iniciar el proceso con dos inicios:
La primera de tipo Señal (plan de mantenimiento) , y la segunda de tipo condicional ( si es que se detecta anomalías) , esto sería correcto y recomendable ?
Muchas gracias … Saludos desde Perú.
Lissi, para el escenario que propones, lo mejor es utilizarse el Event Subprocess. Con ese tipo de subproceso podrá demonstrar en el diagrama que las actividades del flujo en ese subproceso solo ocorrerán caso el trigger del evento inicial se ocurra.
NO es recomendable tener dos eventos iniciales en su fluxo principal. Eso puede llevar los que lo leen a comprender que los procesos se principian de dos diferentes formas (lo que no es lo que está buscando).
Busca más en: https://blog.iprocess.com.br/?p=1226
Excelente blog! Parabéns e obrigada por compartilhar conosco seus conhecimentos. Fantástico. Continuem!
Olá!
Primeiramente gostaria de parabenizar a equipe da iProcess pelo excelente trabalho, o blog de vocês é sempre uma boa referência!
Gostaria de saber como posso representar uma atividade que ocorre antes de um evento que realmente dá inicio ao processo.
Meu processo é de compra de livros, então o processo tem inicio quando ocorre a chegada de verba para compra. Entretanto, antes mesmo da liberação da verba uma lista com os livros que ainda não foram comprados no ano anterior é gerada. Como posso representar essa atividade antes do evento que dá inicio ao processo?
Olá Maria,
Pelo cenário que você especificou, esta atividade de gerar a lista consiste em um outro processo, cujo resultado é uma entrada para o seu processo de compra de livros. Ou seja, para o processo de compra de livros começar, uma das entradas é a verba aprovada, e a outra é a lista gerada no processo anterior (mesmo que seja extremamente simples). Considere esta opção :)
Sou um iniciante no BPM e gostaria de saber de possíveis materiais e soft para começar a estudar e praticar em processos de minha própria empresa? Obrigado
Olá Márcio, conheça os cursos da iProcess Education (www.iprocesseducation.com.br).
Recomendamos que participe do programa Ciclo BPM: da estratégia à automação, no qual discutimos todo o ciclo de melhoria de processos dentro da organização – da visão estratégica à modelagem, análise, transformação e automação dos processos, inclusive sobre o que é possível fazer com as ferramentas de software para processos disponiveis no mercado. Confira na agenda a turma mais próxima de você!
Olá,
Sempre acompanho o blog de vocês. É muito útil e didático. Estou com uma dúvida com relação ao evento de fim de mensagem.
Suponhamos que eu tenho um processo em que há um gateway com duas possibilidades:
a) ocorreu um erro no preenchimento no início do processo e eu preciso informar a outra empresa que o preenchimento foi errado. Após essa atividade o processo acaba.
b) o formulário está correto e eu preciso informar que o formulário está correto e o processo acaba.
Qual a melhor forma de representar essas situações?
1) Atividade informar xxx – evento de fim de mensagem
2) Atividade informar xxx – evento de fim none
3) evento de fim de mensagem (informar xxx)
Grato de Antemão.
Olá Diego,
O lance com BPMN é que a notação é bastante flexível e deixa a cargo do modelador avaliar cada caso e identificar a melhor forma de representar o negócio no diagrama – e às vezes pode haver mais de uma forma.
No exemplo que você citou:
– a opção (1) apresentaria uma redundância da ação de realizar a comunicação, considerando que há uma atividade que faz o papel de informar xxx antes do fim, então o evento de fim por mensagem não seria neecssária. Neste caso, o término mais apropriado seria mesmo o evento none, conoforme você descreveu na opção (2).
– a opção (3) também pode ser uma possibilidade, se a mensagem for automática. A diferença entre ter uma tarefa ou um evento realizando a comunicação está no fato de que a tarefa considera que há um tempo para realizar o trabalho, enquanto o evento é simplesmente disparado. Assim, se há um esforço de redigir a mensagem que será enviada, há um trabalho, e portanto deve ser uma tarefa. Se a mensagem é padrão e não há nenhum esforço para produzir a comunicação, então pode-se usar o evento. Confira este artigo: Desmistificando tipos de tarefas em BPMN: tarefas de envio e recebimento onde falamos mais a respeito da comunicação por tarefas ou eventos.
Boa tarde,
Gostaria de saber se há um manual, diretriz, etc, que estabelece regras para utilização da notação BPMN. Qual a fonte que vocês utilizam para estabelecer essas regras? Obrigado!
Olá André! Toda a notação BPMN, com sua semântica e gramática dos elementos é especificada pela OMG (Object Management Group). Nós sempre nos baseamos nesta especificação, que é a oficial, quando escrevemos sobre a notação BPMN.
Para saber mais: http://www.omg.org/bpmn
Bom dia Kelly,
Primeiramente parabéns pelo blog. Gostaria de tirar uma dúvida.
Preciso modelar um processo de gerenciamento de configuração e para esse processo quero mapear as atividades de planejamento, controle e auditoria. Cada uma delas tem um inicio diferente, o planejamento começa com a necessidade de implementar esta gerência, o controle começa com a necessidade de manutenção de um item de configuração(é iniciado por outro processo) e a auditoria que é executada de tempos em tempos para verificar se a gerência de configuração está sendo executada corretamente.
Sei que não é correto termos mais de um inicio no processo, como poderia representar isso em um único processo? Ou não posso e devo considerar e representar como processos separados? Pensei colocar um evento unico de inicio ligado a um gateway e desse gateway saindo as tres possibilidades de caminho.
Obrigado
Olá Fred, uma coisa importante a considear na questão apontada: são origens diferentes, que iniciam o processo da mesma forma, ou são formas diferentes de iniciar o processo (ex: um é por evento de tempo, outro é por evento de mensagem)?
Se forem apenas origens, não há porque ter mais de um evento de inicio: o evento pode ser a chegada da mensagem que inicia o processo, que pode ser acionada por diferentes origens e isso não é um problema.
Se forem formas diferentes, avalie se talvez o gerenciamento de configuração não seja, na verdade, um subprocesso dentro de outros processos. Neste caso, recomendo tratá-lo como um subprocesso reusável.
Gostei muito deste blog. Poderiam atualizado com mais notações de eventos ?
Ex. Não encontrei o ícone SINAL (roda com um triangulo).
Parabéns pelo material.
Olá, tudo bem? Ficamos muito felizes com seu feedback positivo.
No final da página de cada post tem a opção: Inscreva-se na nossa Newsletter
Através do seu cadastro, é possível ser avisado em cada novidade em nosso blog. :)