Um guia BPMN (IV): Eventos Intermediários | Blog da iProcess
Kelly Sganderla - 10 de dezembro de 2012
No artigo anterior iniciamos o estudo dos eventos, detalhando os principais tipos de gatilhos para eventos de início e fim de processo.
O evento intermediário (Intermediate event) sinaliza um ponto no decorrer do processo no qual é previsto que um fato irá ocorrer.
Eventos intermediários podem ser tanto do tipo catch (aguardam a ocorrência do fato para que o processo continue) quando do tipo throw (geram a ocorrência do fato e dão continuidade ao processo).
Em geral os eventos intermediários são conectados ao processo através de conectores de fluxo de sequência, dando o contexto de que ocorrem durante o processo. Entretanto, um evento intermediário também pode ser definido para ocorrer durante uma tarefa tarefa específica. Neste caso, o evento intermediário é anexado à borda da atividade, como mostrado em alguns exemplos abaixo.
Os tipos de evento intermediário mais comuns são:
Tempo ou Prazo (Timer)
Utilizado para representar um fato relacionado a uma condição temporal, como uma data específica (ex. 01 de janeiro), uma data relativa (próxima terça-feira), um intervalo de tempo (em sete dias) ou uma situação de espera de tempo.
O evento de timer é simbolizado por um relógio.
Quando utilizado no fluxo do processo, o evento intermediário de timer representa que o processo deverá parar naquele ponto do processo e aguardar que a condição de tempo se torne verdadeira.
Neste exemplo, quando a tarefa "Preparar viagem" for finalizada, o processo realizará uma pausa aguardando a data de início da viagem. Só então o processo continuará, iniciando a tarefa "Realizar viagem".
Quando utilizado na borda de uma atividade, o evento intermediário de timer representa que que, enquanto a atividade estiver em execução, o evento poderá acontecer, e neste caso, o fluxo desenhado a partir do evento será executado. Neste caso, o evento intermediário poderá ser de dois tipos:
Timer interrupting
Se o evento ocorrer enquanto a atividade estava sendo executada, ela será interrompida, e o fluxo seguirá pelo conector que se origina no evento.
A borda do evento é dupla e lisa.
No exemplo ao lado, se a atividade "Confirmar recebimento de mercadorias" for concluída antes da data de entrega prevista, o processo seguirá sua execução pelo fluxo normal do processo. Entretanto, se a data de entrega prevista for atingida e o recebimento das mercadorias não tiver sido confirmado, a tarefa é automaticamente cancelada e o fluxo que sai do evento de timer é disparado, dando início à atividade "Cancelar o pedido". A atividade de "Confirmar recebimento de mercadorias" não poderá mais ser realizada pois foi interrompida.
Timer non-interrupting
Se o evento ocorrer enquanto a atividade estava sendo executada, um fluxo paralelo será iniciado a partir do conector que se origina no evento, mas a tarefa permanece aguardando a sua execução.
A borda do evento é dupla e tracejada.
No exemplo ao lado, se o após dois dias úteis a tarefa "Avaliar pedido" ainda não tiver sido finalizada, o fluxo iniciado no evento é disparado, iniciando a tarefa "Receber aviso de atraso na avaliação". A atividade de avaliar pedido, entretanto, poderá ser realizada normalmente, dando sequência ao fluxo normal do processo. Se a tarefa "Avaliar pedido" for finalizada antes da ocorrência dos dois dias úteis, então a atividade "Receber aviso de atraso na avaliação" não acontecerá.
Utilizado para representar um fato relacionado a uma condição de negócio, pausando o processo até que ela se torne verdadeira.
No exemplo ao lado, ações são compradas e então o processo aguarda até que a condição "Valor de venda atingido" se torne verdadeira, dando continuidade ao processo e iniciando a tarefa "Vender ações".
O evento do tipo conditional também pode ser conectado à borda de atividades como demonstrado anteriormente no tipo timer, podendo ser interrupting ou non-interrupting. Neste caso, o evento será acionado quando a condição de negócio associada se torne verdadeira.
Eventos intermediários de tipo message são 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.
No exemplo acima, o Processo de Logística de Treinamentos prevê uma atividade para "Alugar sala de treinamento". Após alugar a sala, o processo aguarda uma "Comunicação do número de Participantes". Quando esta comunicação for recebida, a próxima atividade poderá ser iniciada, providenciando cadeiras e mesas para os participantes do treinamento cujas inscrições foram confirmadas.
Este exemplo apresenta o Processo de Inscrições de Treinamento, no qual há uma tarefa para receber as fichas de inscrição e então uma atividade para "Verificar inscrições pagas". Quando as inscrições pagas forem verificadas, o processo poderá comunicar o número de participantes que estão inscritos, enviando uma mensagem (que será recebida no processo demonstrado anteriormente, no evento com o mesmo nome). Após, o processo segue, iniciando a tarefa de "Providenciar impressão dos certificados".
A identificação de que a mensagem enviada por um processo é a mesma recebida em outro processo deve ser explicitada utilizando-se a mesma descrição para o elemento.
É possível ainda demonstrar visualmente esta comunicação, colocando-se os dois processos em um mesmo diagrama BPMN e apresentando como esta mensagem flui de um processo para o outro. Neste caso, utiliza-se um conector especial para demonstrar essa ligação entre processos através da troca de mensagens (envio e recebimento): o conector de fluxo de mensagem (message flow).
O conector de fluxo de mensagem pode ser usado apenas para conectar elementos de envio e recebimento de mensagem, e caracteriza-se por uma linha tracejada com uma seta vazada apontando para o destino da mensagem.
É importante ressaltar que para o BPMN, uma comunicação é realizada sempre para fora do processo, nunca entre eventos de mensagem de um mesmo processo.
O evento do tipo mensagem também pode ser utilizado à borda de atividades como demonstrado anteriormente no tipo timer, podendo ser interrupting ou non-interrupting. Neste caso, o evento será sempre "catch", aguardando a chegada de uma mensagem, e será acionado se a mensagem for recebida enquanto a atividade estiver sendo executada.
Ligação (Link)
Eventos intermediários de link representam uma ligação entre pontos distantes de um mesmo do processo.
Este elemento é utilizado frequentemente em processos cujo número de atividades é muito grande e há pontos do processo que estão visualmente distantes ou bloqueados. Assim, para evitar a sobreposição de conectores de fluxo de sequência, pode-se utilizar este evento, criando uma "ponte virtual" entre pontas do fluxo do processo.
O evento de "throw" link tem como símbolo uma seta preta e sinaliza a ponta de origem da ligação, enquando o evento do tipo "catch" tem como símbolo uma seta branca e sinaliza o destino da mesma.
O exemplo acima apresenta um exemplo de uso de eventos de ligação (link). Observe que há dois eventos de ligação com o mesmo nome: "Continuar negociação". O primeiro tem a seta preta, indicando a origem da ligação, e o segundo a seta branca, indicando o destino da ligação. Com isso, a leitura que se faz deste diagrama é de que após a realização da atividade "Verificar condições de férias" o processo dá sequência ao fluxo iniciando a tarefa "Avaliar solicitação de férias".
Para entender melhor o uso de eventos de mensagem e link, leia também estes artigos:
BPMN: Diferenças entre eventos de Link, Message e Signal
BPMN: Modelando corretamente o fluxo de sequência de atividades
No próximo artigo, um elemento fundamental para a abstação de conjuntos de tarefas na estruturação de diagramas de processos com níveis de profundidade e granularidade diferentes: os subprocessos.
Um guia para iniciar estudos em BPMN (IV): Eventos Intermediários (você está aqui)
Tags: análise de processos, BPMN, mapeamento de processos, modelagem de processos
39 ideias sobre "Um guia para iniciar estudos em BPMN (IV): Eventos Intermediários"
Ulisses Sampaio em 14 de dezembro de 2012 às 2:30 pm disse:
Parabéns Kelly pela série de artigos relacionados a BPMN. Bem didático…
Kelly Sganderla em 17 de dezembro de 2012 às 5:12 pm disse:
Obrigada Ulisses! Amanhã lançamos mais um artigo sobre os subprocessos em BPMN :)
Pingback: BPMN: Modelando processos de negócio com elementos avançados (Parte IV) | Blog da iProcess
Lindalice em 24 de abril de 2013 às 5:07 pm disse:
Parabéns pela iniciativa. Acabei de fazer um treinamento BPMN na Trainning Education e este blog está complementando com dicas e muita informação interessante principalmente pra quem está dando os primeiros passos. Gostei muito !
Bruno Lira em 29 de maio de 2013 às 3:15 pm disse:
Parabéns. Seu site tem sido bastante útil para mim, tendo em vista que tomei conhecimento do BPM há apenas alguns meses atrás e sempre o consulto para tirar algumas dúvidas.
Augusto Cesar em 11 de junho de 2014 às 8:55 am disse:
Sei que o a matéria é antiga mas os problemas continuam nos dias atuais, me deparei com uma dúvida na hora de modelar um processo, tenho uma atividade e preciso usar um evento intermediário condicional para ir para outra atividade. A dúvida é a seguinte: Ao usar um evento condicional na borda de uma atividade, essa atividade é executada primeiro e depois se verifica a condição, ou primeiro se verifica a condição e caso não seja satisfeita a atividade onde está o evento é executada?
Parabéns pelo blog e por tudo que há nele, tem me ajudado muito!
Kelly Sganderla em 11 de junho de 2014 às 2:23 pm disse:
Olá Augusto, agradecemos sua visita ao nosso blog! Para nós da iProcess é uma grande satisfação saber que o conhecimento que compartilhamos está contribuindo para o crescimento de outros profissionais envolvidos em iniciativas de processos de negócio.
A resposta à sua pergunta "ao usar um evento condicional na borda da atividade, essa atividade é executada primeiro e depois se verifica a condição, ou primeiro se verifica a condição e caso não seja satisfeita a atividade onde está o evento e caso não esteja satisfeita a atividade onde está o evento é executada", é:
O evento de borda é usado para controlar eventos que podem ocorrer enquanto a atividade está sendo executada.
Veja no artigo que temos exemplo de um evento de timer na borda. No caso do interrupting: se o evento ocorrer enquanto a atividade estava sendo executada, ela (a atividade) será interrompida, e o fluxo seguirá pelo conector que se origina no evento.
Já no caso do evento de borda ser non-interrupting: se o evento ocorrer enquanto a atividade estava sendo executada, um fluxo paralelo será iniciado a partir do conector que se origina no evento, mas a tarefa permanece aguardando a sua execução.
Se, durante a execução da atividade, o evento não acontecer (no caso do exemplo, se a tarefa "Confirmar recebimento de mercadorias" for concluída antes que a data de prazo da entrega seja atingido), a atividade é executada e concluída normalmente, seguindo por seu caminho normal modelado no fluxo.
Esse comportamento vale para qualquer tipo de evento conectado à borda de um atividade seja ele uma mensagem, condição, escalamento, erro… (você pode conferir que tipos de eventos podem ser usados em bordas de atividades em nosso Guia de referência rápida BPMN 2.0, disponível em http://blog.iprocess.com.br/2013/11/novidade-guia-de-referencia-bpmn-2-0-da-iprocess/).
Paulo Luciano Vieira em 5 de dezembro de 2014 às 8:59 am disse:
Uma atividade pode conter mais do que um evento intermediário na borda? Como por exemplo, em uma imobiliária, a tarefa de "divulgar imóvel" pode ser interrompida, caso: 1. o cliente solicite; 2. o imóvel seja alugado. Portanto, ao meu ver, tal tarefa deveria receber dois eventos intermediários na borda, que seriam, "Condicional" (no caso de imóvel alugado) e "Mensagem" (no caso da solicitação do cliente).
Posso representar através dos conectores de borda, na respectiva quantidade?
Kelly Sganderla em 5 de dezembro de 2014 às 9:11 am disse:
Sim, uma atividade pode ter tantos eventos de borda quantos forem necessários pelo processo de negócio.
Seu exemplo está bem especificado e esta modelagem seria correta.
Alexandre em 16 de março de 2015 às 5:10 pm disse:
Parabéns pelo blog! É muito instrutivo.
Caso tenhamos um processo para gestão de incidentes que possui várias atividades a serem executadas e um tratamento de exceção por tempo limite para atendimento. Repare que este tempo limite não é de uma atividade específica, mas do processo como um todo, isto é, após a chegada de um incidente, se ele não for atendido em 1h (por exemplo), o processo deve ser interrompido e certa atividade deve ser executada. Como representar isto em BPMN já que não seria correto por um evento intermediário de borda em cada atividade do processo?
Kelly Sganderla em 17 de março de 2015 às 10:17 am disse:
Você pode modelar isso de duas formas:
Uma delas é colocando o conjunto de tarefas que precisam ter seu tempo monitorado dentro de um subprocesso e colocar o evento de controle de tempo na borda do subprocesso. Assim, se o timeout ocorrer durante a execução das tarefas que estão dentro do subprocesso, todas são interrompidas e o fluxo seguirá pelo conector de sequência que sai da borda do subbprocesso.
A outra forma de modelar isso seria, no caso de *todo* o subprocesso estar condicionado a este prazo, usar um event subprocess com evento de início disparado pelo prazo determinado. Assim, se o timeout ocorrer, o processo é interrompido onde quer que esteja, e o fluxo modelado dentro do event subprocess passa a ser executado.
Alexandre em 18 de março de 2015 às 11:41 am disse:
Kelly, fui testar o event subprocess (subprocesso eventual) no Bizage, e percebi que o subprocesso criado impede a criação de raias como ocorre com um subprocesso incorporado. Isso está correto?
Se for assim, todas as atividades contidas num subprocesso eventual só poderão ser executadas por um mesmo responsável e desta forma tal subprocesso deverá ser criado dentro da raia correta no processo "pai" para poder explicitar quem é esse responsável.
Thiago Martins em 24 de março de 2016 às 2:26 pm disse:
Boa tarde, primeiramente parabéns pelo blog pois é muito show, pra min que estou iniciando essa semana estudos com bpmn esse blog é super completo. Como sou iniciante fiquei com uma duvida.Qual a diferencia de eu usar um gateways exclusivo e um evento intermediário do tipo conditional. Não sei se teria alguma relação entre os dois!
Kelly Sganderla em 7 de abril de 2016 às 3:01 am disse:
Olá Thiago, em nome da equipe de autores do Blog da iProcess agradeço sua mensagem Ficamos muito motivados em compartilhar nosso expertise e conhecimento com novos profissionais na área.
Existe uma diferença de natureza dos dois componentes da sua dúvida.
Os gateways tem função de roteamento. Eles são como placas na estrada que apontam o caminho para onde o fluxo deve seguir de acordo com uma decisão (informação) que já existe. Por exemplo: um gateway exclusivo pode rotear um processo com base no tipo de uma solicitação. Se for uma solicitação simples, levar para a atividade "A"; se for uma solicitação média vai para a atividade "B" e se for uma solicitação complexa vai para a atividade "C". O valor que caracteriza o tipo de solicitação é uma informação que já existe e foi obtida em algum momento anterior do processo – seja como entrada para o processo iniciar ou em alguma tarefa anterior ao gateway em que alguem definiu que, para aquele processo em andamento, o tipo de solicitação é uma dessas opções.
Já os eventos intermediários, independente do gatilho, são uma representação de que o processo precisa aguardar que um evento externo ao processo ocorra. Se for um gatilho de tempo (evento de timer) em que precisamos esperar uma semana, por exemplo, o processo chega no evento, espera passar o prazo e quando ele ocorrer (quando a data do prazo se tornar verdadeira) ele libera o processo e vai para a próxima atividade. Não existe variação de roteamento, como no caso do gateway. O mesmo vale para o evento condicional, que é usado para representar uma condição lógica (booleana) em que em um determinado momento é falso mas quando se tornar verdadeiro o processo seguirá. Como a maior parte das situações de condição estão atreladas a tempo ou comunicação (mensagem ou sinal) é difícil encontrar um exemplo de uso deste elemento que não seja muito particular de um processo, por isso vou usar um exemplo lúdico. Pense no preparo de uma pizza congelada. Você recebe como entrada para o processo a pizza congelada, faz uma atividade de ligar o forno, mas só pode fazer a próxima atividade de colocar a pizza no forno quando o forno tiver atingido a temperatura adequada (180º). Assim, antes desta tarefa, coloca o evento condicional de que o forno tem que estar na temperatura adequada. Quando o processo for exeutado, você terá feito a primeira tarefa, e chegando ao evento o forno ainda não estará na temperatura (ou seja, a condição ainda não é verdadeira). O processo terá que esperar até que a temperatura seja atingida e a condição do evento se torne verdadeira, fazendo com que o processo siga para as próximas atividades. Espero que os exemplos tenham ajudado!
Thiago Campos Leonel em 11 de maio de 2016 às 4:23 pm disse:
Parabens pela série de artigos sobre BPMN. Acho que você ja deve ter percebido que produziu um material atemporal e que quase quatro anos após a publicação ainda continua ajudando muita gente.
Henrique Santana em 21 de junho de 2016 às 11:40 am disse:
Bom, tem cerca de um ano que utilizo o blog do Iprocess como forme de complemento a documentação e seus exemplos e explicações são sensacionais.
Gostaria de retirar uma dúvida, qual a diferença entre uma tarefa de envio e um evento de envio (mensagens)? Sempre confundo.
Kelly Sganderla em 4 de julho de 2016 às 6:23 pm disse:
Em nome do time da iProcess gostaria de agradecer seu comentário, ele nos deixa bastante empolgados em seguir compartilhando nossa experiência através do blog para apoiar os profissionais de BPM brasileiros.
Sobre sua dúvida, sugiro que leia este artigo, onde falamos justamente sobre as tarefas de envio e recebimento e suas diferenças em relação aos eventos de mensagem: http://blog.iprocess.com.br/2014/04/desmistificando-tipos-de-tarefas-em-bpmn-tarefas-de-envio-e-recebimento/
Mariana em 8 de agosto de 2016 às 5:02 pm disse:
O blog é show! Parabéns!
Gostaria de saber se posso utilizar link saindo uma setinha dele?
Tenho uma atividade, coloco o simbolo do link, e coloco uma outra atividade em seguida, saindo a seta dele?
Kelly Sganderla em 8 de agosto de 2016 às 6:17 pm disse:
O evento de link throw (lançamento do link, o evento com icone preto) não pode ter fluxo sequência saindo dele, pois este fluxo de sequência está justamente implícito pelo link. No seu processo (na mesma pool) você deverá ter um outro link do tipo catch (captura do link, o evento com icone branco) que será o ponto de onde seu fluxo de processo continua. A partir deste, sim, você deverá ter um fluxo de sequência que dá andamento ao processo.
Joseane em 5 de setembro de 2016 às 5:59 pm disse:
Estou em dúvida sobre qual a forma correta de indicar o início de um processo, que pode ser iniciado por três entradas distintas, cada uma em uma área (lane) diferente.
Há um início principal (o mais comum) que indiquei como início do processo (star event), e as duas outras entradas indiquei como evento intermediário/multiplo (intermediate event/event multiplo). Está correto?
Kelly Sganderla em 3 de novembro de 2016 às 9:07 pm disse:
Ola Joseane! Existe mais de uma forma de representar isso, embora geralmente envolvem utilização de elementos complexos que muitas vezes mais dificultam do que facilitam a interpretação do processo.
Mas para ajudá-la nesta questão, acho importante comentar que o evento não tem uma "lane" proprietária. Você pode colocá-lo em qualquer lane do processo, pois ele não diz em que area o processo começa, apenas que começou. As lanes representam quem faz o trabalho (atividades). Assim geralmente o evento de início é colocado junto da primeira tarefa.
No seu caso, se a primeira tarefa pode ser diferente de acordo com a área no qual o processo "inicia" então sugiro colocar um evento de início na lane onde é mais comum, seguido de um gateway que verifique qual a origem do processo e então de acordo com o resultado, apontar para a tarefa na respectiva lane.
Mas se a tarefa de início é única, então pode ser interessante utilizar um evento de início simples na mesma lane, e adicionar à descrição do evento as possíveis origens para a informação que faz com que o processo comece.
Ricardo em 20 de outubro de 2016 às 10:52 am disse:
Antes de tudo, parabéns pelo material. Conceitualmente, para o BPMN podemos ter 2 tasks com o mesmo nome em uma raia ? Ex: "Enviar mensagem"
Não seria mais apropriado sempre uma distinção entre as tarefas de forma que sejam absolutamente únicas em escopo e aplicação ? Como por exemplo: "Comunicar gerentes" e "Comunicar equipe" ao invés de "Enviar Mensagem" para ambos os casos ?
Levanto esta questão pois, apesar de me policiar quanto a isto, não cheguei a encontrar um artigo que descreva isto como sendo uma boa prática.
Kelly Sganderla em 3 de novembro de 2016 às 8:57 pm disse:
Olá Ricardo, obrigada por seu feedback e contribuição.
Há uma situação sim em que duas tarefas podem constar no processo com o mesmo nome: é quando elas representam, em pontos diferentes do fluxo, a realização de um mesmo trabalho (tem o mesmo tipo de entrada, fazem o mesmo tipo de processamento e geram o mesmo tipo de saida). Por exemplo, considere em um processo automatizado uma sequência de tarefas em que, sempre que alguém adiciona um documento em alguma tarefa humana, a tarefa seguinte aciona um serviço para arquivar digitalmente o documento. É a mesma tarefa (arquivar o documento), que tem o mesmo tipo de entrada, realiza o mesmo procedimento e gera o mesmo resultado (o documento arquivado) em momentos distintos do processo. Como é a mesma tarefa, pode ter o mesmo nome. Há, inclusive uma categoria de atividade chamada "call activity" para representar o reuso da tarefa. Basicamente a primeira ocorrência dela seria uma global task, em que é feita a definição da tarefa. E então, a cada reuso ela seria apenas referenciada (não precisaria detalhar novamente pois seria apenas uma "cópia"), através da call activity.
Entretanto, se a entrada, o seu processamento e o resultado forem diferentes, usar o mesmo nome para a tarefa pode gerar confusão. Neste caso, embora não haja nenhuma regra que impeça uma modelagem desta forma, uma prática adequada seria usar nomes mais específicos que realize a distinção deste trabalho, como você bem exemplificou em sua questão :)
André O. Silva em 20 de junho de 2017 às 12:03 pm disse:
Explicação do fluxo do processo:
Estou modelando um fluxo de aquisição e optei por um modelo orquestrado, o fluxo está dividido em 5 fases: 1) Fase: preparação para aquisição, 2) Fase: formalização de aquisição: Nesta fase subdivide em dois subprocessos: Executar modalidade de contratação e conseguinte Celebrar contratos ou ata de registro de preço. 3) Fase: Executar objeto contratado é composto pelo processo: Receber produto/serviço. 4) Fase: Gerenciar contratos: Nesta fase subdivide em dois processos: Fiscalizar a execução dos contratos e Acompanhar a vigencia e aditivos dos contratos. 5) Fase: Executar despesa: Nesta fase subdivide em três processos: Empenhar despesas, Liquidar despesas e Pagar despesas.
1°Dúvida: Como diferenciar no mesmo fluxo de processo, o que é Processo e o que é Subprocesso?
2° Qual a melhor maneira de definir o que vai ser processo e o que será um sbprocesso?
3° Dúvida: Na 3° Fase, o processo "Receber produto" tem duas saídas, sendo a primeira: produto adquirido e atestado (representei com um evento final de sinal) com a intenção de ligar e iniciar o segundo processo da 5° Fase, que é "Liquidar despesas". Então, um evento final de sinal pode iniciar um evento intermediário de sinal? Optei representar dessa forma, pois quis dizer que o processo de aquisição se encerra no devido recebimento do produto/serviço (produto adquirido e atestado). Porém ele se comunica com outros processos. A segunda saída: Produto/serviço irregular (representei com um evento intermediário de Link) com a intenção de ligar no processo "Fiscalizar a execução dos contratos" que é feito após celebrar contratos e também quando é acionado por um produto/serviço irregular. Está correto, ou deveria representar de outra forma?
Da mesma Forma o processo "Receber produto/serviço" só pode iniciar quando, o empenho da despesa for realizado. Então antes do processo "Receber produto/serviço" coloquei um evento intermediário de sinal, de recebimento, (Empenho realizado), que recebe de um evento final de sinal, de envio, do processo "Empenhar despesas" (saída: Empenho realizado).
Kelly Sganderla em 28 de junho de 2017 às 11:41 pm disse:
Oi André, você chegou a assistir o webinar que realizamos uns tempos atrás, em que tratamos especificamente dessa questão do encadeamento de processos?
Dá uma conferida, acho que diversas das suas questões são respondidas nesse vídeo: http://blog.iprocess.com.br/2015/09/webinares-iprocess-2015-bpmn-modelando-a-comunicacao-entre-processos/
Dave Noleto em 20 de dezembro de 2017 às 1:46 pm disse:
Olá boa tarde Kelly! Não sei se você ainda responde por aqui, mas queria te dizer que o blog é muito bacana e estou gostando bastante, estou até querendo fazer um curso de vocês ano que vem, sou iniciante em BPMN mas estou me aventurando em fazer alguma coisa, diante disso me surgiu uma duvida, Oi Professor, boa tarde.
Gostaria de esclarecer uma duvida de BPMN .. me aventurei em aplicar isto em um projeto que estou participando, e me deparei com uma questão, se puder ajudar eu agradeço:
A empresa tem um processo de venda de um produto, este processo envolve n áreas, cada área cumpri um papel neste processo (venda), dai surge a duvida, como o processo tem várias áreas como eu classifico cada uma? Tipo .. melhor colocar cada área como um processo e usar o evento Message ou coloco cada área como uma lane numa unica pool? Caso eu aplique a segunda opção, como realizo a comunicação entre as lanes?
Kelly Sganderla em 22 de janeiro de 2018 às 4:29 pm disse:
Oi Dave,
Se você vai representar as áreas, minha sugestão é que utilize uma pool para representar o processo de vendas, e subdivida ele pelas áreas usando lanes.
Se você usar pools separadas para cada área, estará segregando e verticalizando o seu processo – algo que na disciplina de gestão por processos tem sido muito debatido.
A visão do processo de negócio integrado em um único fluxo deve ser a forma mais clara de visualizar toda a orquestração das áreas sendo envolvidas para produzir o resultado do processo.
Parabéns por abraçar esse desafio; esperamos encontrá-lo em breve em um de nossos cursos!
Janaina em 19 de fevereiro de 2018 às 5:10 pm disse:
Olá tudo bem? Gostaria de saber se posso usar um evento conector link como fim e depois início, ou precisam ser ambos intermediários? Minha dúvida também é em relação aos eventos de mensagem, se preciso utilizar o evento intermediário ou se dependendo do processo posso utilizar o Fim e depois o Início.
Kelly Sganderla em 19 de fevereiro de 2018 às 7:37 pm disse:
Os eventos de link são sempre intermediários pois conectam pontas de um mesmo fluxo.
Já os eventos de mensagem dependem do contexto do processo, podendo implicar em um processo que ao terminar (evento de fim) começa outro (evento de inicio) ou representar que no meio de um processo ele se comunica com outro processo (podendo iniciá-lo ou realizar outra ação de comunicação intermediária).
Adriano Santiago de Freitas em 26 de fevereiro de 2018 às 10:31 am disse:
Da forma como está colocado o uso do evento intermediário de mensagem, conforme reproduzido abaixo: "Eventos intermediários de tipo message são utilizados para demonstrar um ponto do processo onde ocorre uma comunicação com um outro processo ou agente externo.", nos leva a entender que o mesmo só deve ocorrer quando há comunicação externa ao processo. É isso mesmo? É incorreto utilizá-los, tanto pra envio quanto para recebimento entre participantes do mesmo processo? Nesse caso, para representar troca de mensagens entre participantes de um mesmo processo, devo utilizar apenas os elementos "Tarefa envio mensagem" e "Tarefa recebimento de mensagem"?
Kelly Sganderla em 28 de fevereiro de 2018 às 4:08 pm disse:
Olá Adriano. É isso mesmo: na notação BPMN, a mensagem é uma comunicação entre processos (transferência de informação) e por isso deve ser usada para enviar ou receber informações de outros processos (ou outros Participantes da colaboração, que em BPMN são representados como pools). Usar tarefas de envio e recebimento de mensagem teriam a mesma conotação, pois estaria transferindo uma mensagem. Na prática, a notação BPMN entende que não é preciso transferir a mensagem a outro participante pois isso é implícito no fluxo de sequência. Quando uma atividade termina, o fluxo de saída é seguido indo para a próxima tarefa, e com ele todas as informações geradas nas atividades anteriores.
Mas se você quer representar algo como um envio de email ou SMS, pode usar uma tarefa de serviço, que aciona o serviço SMTP passando as informações e dados de destinatário, e esse tipo de tarefa independe de quem está recebendo a informação. Portanto, o email pode ser mandado a qualquer pessoa – seja ele um papel do processo ou não.
Do ponto de vista prático, entretanto, temos visto muitas pessoas e organizações optarem por usar os elementos de evento ou tarefa de envio de mensagem para demonstrar momentos em que são enviados emails ou SMS para papéis envolvidos do próprio processo.
Edson Toshio em 19 de abril de 2018 às 10:09 pm disse:
Excelente explicação com ótimos exemplos! Parabéns!
Rodrigo Silva em 6 de julho de 2018 às 11:16 am disse:
Ola, excelentes explicações, estão me ajudando muito.
Uma dúvida, no Timer interrupting, como eu configuro um horário especifico para que o fluxo faça um disparo de e-mail (no caso do meu fluxo), e aguarde o usuário finalizar a tarefa.
Kelly Sganderla em 9 de julho de 2018 às 2:05 pm disse:
Olá Rodrigo, bem vindo ao blog da iProcess!
O evento de borda do tipo interrupting sempre _interrompe_ a atividade no momento em que o seu prazo for atingido. Isso quer dizer que se o tempo definido for atingido e a atividade ainda estiver aberta, ela será encerrada à força para continuar pelo fluxo definido a partir do evento. No caso do comportamento desejado, acredito que será necessário utilizar um evento de borda do tipo non_interrupting. Ele permitirá começar um outro fluxo (por exemplo, enviar um e-mail) enquanto a atividade permanece aberta aguardando encerramento pelo seu responsável.
Em relação à configuração de tempo, isso dependerá da ferramenta que você está usando para automatizar este processo.
A notação BPMN fornece a linguagem, mas deixa que cada produto defina os detalhes sobre como será a configuração de cada elemento no processo.
Neste caso, sugiro verificar na documentação do produto que você está utilizando se: a) a ferramenta implementa esse tipo de evento (nem todas implementam, ou implementam com variações) e b) como realizar a configuração.
Flávio Augusto Marques Faria em 30 de abril de 2019 às 7:15 pm disse:
Olá, tenho acompanhado o Blog e várias dicas dele, porém possuo uma dúvida:
Tenho modelado vários processos com interfaces do tipo:
Área 1: Criar documento X -> Enviar documento para aprovação da área 2.
Área 2: Aprovar documento -> Enviar documento aprovado para área 1.
Eu tenho mapeado esses exemplos como atividades, porém, seria mais fácil utilizar eventos intermediários na linha da área 1? Ou uma tarefa de envio de mensagem?Qual o mais indicado?
Kelly Sganderla em 7 de maio de 2019 às 1:59 pm disse:
Se as duas áreas fazem parte da mesma pool, você não precisa modelar nem com atividade nem com evento a transição do fluxo do trabalho de uma para a outra área. Não é necessário representar com elementos situação como "enviar" ou "receber" trabalho entre participantes do mesmo fluxo, pois o conector de fluxo de sequência já passa este entendimento de que a saída da tarefa anterior é entrada para a próxima atividade. Experimente fazer assim e seu processo ficará muito mais simples, enxuto e claro, representando apenas as atividades que de fato contribuem para a geração do valor produzido pelo processo.
Tiago Magalhães Alves em 14 de agosto de 2019 às 11:33 am disse:
Olá Kelly! Parabéns pelo Blog!
Tenho uma dúvida sobre a utilização de evento de borda (de mensagem) em subprocessos. Talvez você possa me ajudar. É correto utilizar um evento de mensagem (catch message) na borda de um subprocesso para capturar um fim de mensagem (throw message) emitido dentro do próprio subprocesso?
Kelly Sganderla em 17 de setembro de 2019 às 10:37 am disse:
Para o subprocesso enviar uma informação para o processo que o chamou, o elemento mais apropriado é o de escalação (escalation).
O evento de mensagem na borda do subprocesso serve para tratar situações em que, durante a execução do subprocesso, uma mensagem chega e precisa ser tratada (interrompendo o subprocesso ou acionando atividades em paralelo).
Tiago Magalhães Alves em 17 de setembro de 2019 às 5:13 pm disse:
Deixe uma resposta para Ulisses Sampaio Cancelar resposta
← Caso de Sucesso – Aumento da produtividade e efetividade nos negócios do SICREDI com a adoção de SOA e BPM Quando usar o OSB, Oracle BPEL ou Oracle BPM →