Blog da iProcess - Compartilhando conhecimento em BPM e RPA

Um guia para iniciar estudos em BPMN (IV): Eventos Intermediários

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á.   Condicional (Conditional) 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: 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.
Confira todos os artigos deste guia de BPMN Nível 1:  

53 respostas

  1. 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 !

  2. 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.

  3. 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!

    Obrigado!

    1. 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”, é:
      nem um, nem outro.

      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 https://blog.iprocess.com.br/2013/11/novidade-guia-de-referencia-bpmn-2-0-da-iprocess/).

  4. Olá!
    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?

    Att.

    1. Olá Paulo,
      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.

  5. 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?

    1. Olá Alexandre,
      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.

  6. 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.

  7. 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!

    Muito obrigado!

    1. 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!

  8. Olá,

    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.

    Obrigado!

  9. 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.
    Parabéns.

    Gostaria de retirar uma dúvida, qual a diferença entre uma tarefa de envio e um evento de envio (mensagens)? Sempre confundo.

    1. Olá Henrique!
      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: https://blog.iprocess.com.br/2014/04/desmistificando-tipos-de-tarefas-em-bpmn-tarefas-de-envio-e-recebimento/

  10. 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?

    Obrigada!

    1. Olá Mariana!
      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.

  11. Olá, boa tarde!

    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?

    1. 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.

  12. 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.

    1. 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 :)

  13. Bom dia,
    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).

  14. 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?

    1. 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!

  15. 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.

    1. 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).

  16. Bom dia!

    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”?

    1. 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.

  17. 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.

    1. 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.

  18. 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?

    Desde já, agradeço.

    1. Olá Flávio,
      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.

  19. 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?

    1. Olá Tiago,
      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).

    1. Oi Loyce, os processos To Run são os fluxos que serão executados e controlados pelo BPMS.
      Mesmo que o BPMS seja baseado em BPMN, nem todos tem no seu kit a notação completa – geralmente são usados apenas aqueles que a arquitetura do produto consegue tratar na automação. Por isso, o melhor caminho é você estudar a arquitetura e linguagem da própria plataforma.

  20. Eu tenho uma atividade que tem que acontecer até o dia 30 de cada mês, mas não identifiquei uma forma de representar essa condição no processo. Poderiam me ajudar?

    1. Olá Paulo, a modelagem dependerá de uma questão muito clara: o que acontece se a atividade não for feita até o dia 30?
      Parece meio óbvio mas há três possíveis respostas aqui:
      A) “nada, apenas o processo fica atrasado” – então nada deve ser modelado. Se essa informação for importante e precisa aparecer no diagrama, você pode colocar uma anotação ou adicionar essa informação no campo “Descrição” nas propriedades da tarefa.
      B) “a atividade fica em atraso e alguém precisa ser avisado (por exemplo o chefe da equipe)” – neste caso, você pode usar um evento de borda nesta tarefa, do tipo timer, e non-interrupting, indicando que um fluxo paralelo será iniciado. Nele, adicione a atividade de avisar a pessoa responsável e outras atividades que precisem ser feitas.
      C) “a atividade é interrompida e outras atividades são feitas para mitigar o problema” – neste caso, você pode usar um evento de borda nesta tarefa, do tipo timer, que inicia a sequência de atividades da mitigação.

      Para entender melhor o elemento de evento de borda, confira este artigo:
      Como representar exceções no fluxo do processo em BPMN?

  21. Olá Kelly, tudo bem?

    Neste artigo vocês explicam que “o conector de fluxo de mensagem pode ser usado apenas para conectar elementos de envio e recebimento de mensagem”, o que, a princípio, me leva a interpretar que ele poderia conectar apenas eventos de mensagem ou tarefas de envio e recebimento. Na literatura, porém, e no próprio blog de vocês (por exemplo, no artigo “Modelando corretamente o fluxo de sequência de atividades”) existem exemplos de situações onde o conector é usado “partindo de” ou “chegando em” atividades que não são de envio ou recebimento. Sei que estes exemplos estão corretos, pois o próprio guia BPMN 2.0 prevê que o conector de fluxo de mensagem pode ser utilizado também para conectar piscinas, atividades e subprocessos, certo? Portanto, gostaria de entender qual seria a melhor interpretação para a definição posta neste artigo em relação a conectar apenas elementos de envio e recebimento de mensagem. No caso de conectar piscinas e subprocessos não tenho muitas dúvidas, me parece tranquilo. A minha dúvida é em relação às atividades conectadas diretamente por fluxo de mensagem, sem serem precedidas ou sucedidas por eventos de mensagem (catch/throw). Nas minhas modelagens tenho sempre usado os eventos intermediários de mensagem e nunca conectado diretamente as atividades por fluxo de mensagem. Vocês possuem algum artigo que esclareça esta situação? Obrigado!

    1. Olá Tiago, você está certo.
      As palavras teriam sido melhor colocadas dessa forma: “o conector de fluxo de mensagem pode ser usado apenas para conectar elementos onde ocorre envio e recebimento de mensagem” (já vou ajustar isso no artigo – obrigada pela dica!).
      Com isso, queremos dizer que o conector pode ser usado em eventos de envio/recebimento de mensagens e tarefas de envio/recebimento, mas também em tarefas sejam elas sem tipo , tarefas de usuário, tarefas manuais e tarefas de serviço – desde que naquela atividade aconteça uma comunicação com um processo externo (que pode ser uma conversa com o cliente ou a requisição de um webservice).
      veja neste artigo outros exemplos em que o fluxo de mensagem é usado tanto em eventos de mensagem quanto em tarefas – inclusive com um exemplo proposto pela própria OMG (Pizza Delivery):
      BPMN: Modelando corretamente o fluxo de sequência de atividades.

  22. Olá Kelly, tudo bem?

    Se anexarmos um evento de borda do tipo non-interrupting a uma atividade ou subprocesso que esteja no fluxo principal de um processo e este evento de borda dê início a um fluxo paralelo com uma sequência de atividades e fim próprios:

    1. Este evento de borda pode ser disparado mais de uma vez numa mesma instância do processo enquanto a atividade ou subprocesso ao qual ele está anexado estiver ativa(o)?

    2. Caso ele possa ser disparado mais de uma vez, é correto interpretar que será iniciada uma nova instância do fluxo paralelo disparado por ele para cada ocorrência do evento naquela mesma instância do processo principal?

    Para exemplificar: imagine uma situação onde temos um subprocesso denominado “Gerenciar fornecimento de bens e serviços” e que durante a execução deste subprocesso podem ocorrer várias entregas (parciais) de bens e serviços contratados; neste caso, para cada entrega preciso disparar um processo de liquidação e pagamento de fornecedor, mas o subprocesso de gerenciamento do fornecimento continua ativo aguardando as novas entregas. Eu posso utilizar um evento de borda non-interrupting anexado ao subprocesso citado para disparar o fluxo de liquidação e pagamento? Obrigado!

    1. Olá Tiago, vamos às suas respostas:
      1) Sim, mas cada acionamento criará uma nova instância do subprocesso, ou seja, você disparará vários subprocessos em paralelo (pelo menos pela notação BPMN seria assim; se você estiver automatizando o processo precisa avaliar como a plataforma BPMS funciona nesse caso)
      2) Sim, como comentei na resposta anterior :)
      Me parece uma modelagem adequada para o cenário que você descreveu. Bom trabalho!

  23. Kelly, mais uma vez muito obrigado pela disponibilidade e pela clareza das respostas. Parabéns pelo trabalho de vocês! Nos ajuda muito.

    1. Olá Delley!
      Poderia esclarecer melhor a sua dúvida, talvez enviando um exemplo?
      Que tipo de anotação, e que método de publicação você está se referindo?
      Está falando sobre a funcionalidade de uma ferramenta de BPMN específica, como o bizagi ou camunda?

  24. Olá, Kelly. Tenho uma dúvida que não estou conseguindo resolver: se no meu fluxo, ao receber uma solicitação, o responsável tem o prazo de 20 dias para realizar o processo, mas caso ele atinja o prazo o processo apenas fica atrasado aguardando a finalização, como demonstro no fluxo?
    E se a depender do tipo de solicitação o prazo para realizar a atividade for diferente?

    Desde já agradeço.

    1. Olá Victória! Então, não existe elemento gráfico na notação BPMN para apresentar essa informação no diagrama. É que o objetivo da BPMN é explicitar a lógica executada em um processo para entregar seu resultado, não os controles.
      Então o prazo para execução de uma tarefa pode ser modelado como um atributo estendido (complementar), mas nesse caso ele não é visual, apenas documentado. Se for muito importante explicitar essa informação visualmente no diagrama, você pode usar o elemento de anotação associado à tarefa, mas fazer isso para cada atividade pode acabar deixando o diagrama meio poluído, então eu recomendaria usar isso só para aquelas onde ter essa informação visual seja crítica.
      Em relação à variação tempo conforme o tipo de solicitação, se existe uma regra que determina isso, você pode ter uma tarefa no início do processo do tipo Regra de Negócio, indicando que regra é usada para determinar o prazo das atividades do processo.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

MAIS VISTOS

Como transformar as ideias de mudança para um processo TO BE em ações efetivas, controladas... (continuar lendo)
Veja agora as ações que foram realizadas através das doações de todos os participantes deste... (continuar lendo)
Participe deste evento exclusive e gratuIto e se prepare para as transformações que IA irá... (continuar lendo)

Inscreva-se na nossa Newsletter

seers cmp badge