Blog da iProcess - Compartilhando conhecimento em BPM e RPA

Webinares iProcess 2015 – BPMN: Modelando a comunicação entre processos

O webinar de “BPMN: Modelando a comunicação entre processos” foi apresentado ao vivo pela internet em 10/09/2015 pela Kelly Sganderla com uma centena de participantes! Nesta postagem, publicamos o vídeo gravado, a apresentação e as perguntas enviadas durante o evento.

A comunicação entre participantes internos, externos e entre processos na modelagem BPMN, apesar de simples, pode gerar muitas dúvidas nas modelagens iniciais. Como represento que um participante passa o processo para o próximo? Como modelo a situação em que um fluxo quando termina deve dar início a outro? Neste webinar, apresentamos como cada situação deve ser modelada de acordo com o uso padrão da notação, as diferentes abordagens possíveis e vantagens em cada uma.

Os slides da apresentação também estão disponíveis no slideshare:
https://pt.slideshare.net/iProcessBPMeSOA/bpmn-modelando-a-comunicao-entre-processos-webinares-iprocess-2015

Confira abaixo as respostas para as perguntas enviada durante o evento:

I. Perguntas sobre a transferência do processo entre participantes do mesmo fluxo:

Pergunta: “Se vc não representa o “encaminhar/receber” e houver um leadtime enorme entre essas tarefas? Ao suprimir essa passada de bastão vc não corre o risco de não observar oportunidades de melhorias?”
Resposta: Em BPMN, a passagem do processo de um participante para outro está implícita no fluxo de sequência (sequence flow). “Encaminhar” faz parte da condição de término da tarefa que foi concluída, assim como o recebimento é uma premissa para a tarefa seguinte. Entretanto, há casos em que o transporte do processo em si é uma tarefa a ser medida. Por exemplo: se houver uma situação em que o processo é entregue a uma assistente de protocolo, que dará registro de entrada e então passará para um analista realizar a avaliação – bom, estas duas são de fato tarefas diferentes. Mas então, o trabalho é “Receber” ou é “Protocolar o recebimento”? Cada caso precisa ser avaliado frente ao modelo que estamos criando, mas por definição a passagem do processo para a próxima atividade (independente de quem a realize seja a mesma pessoa ou uma pessoa diferente) está implícita na transição de fluxo de sequência (sequence flow) (veja mais no vídeo em 36’00).

Pergunta: “No caso das atividades ‘Enviar’ e ‘Receber’ existe o COMO é enviado e o COMO é recebido. Neste caso, não é necessário informar o COMO? Ex.: e-mail, via workflow, formulário, etc… A pergunta serve também para no caso de gatilhos se é necessário registrar o COMO?”
Resposta: O propósito da notação BPMN é possibilitar a criação de diagramas que representem a lógica do processo. Informações complementares como ferramentas, meios de compartilhamento da informação, etc fazem parte da modelagem física, que contempla uma documentação complementar, e que em geral não fica explícita no diagrama. É claro, pode-se utilizar elementos como data object (objeto de dados) para representar o fluxo de documentos, formulários de apoio entre outros, mas essa representação não é obrigatória em BPMN, e deve ser usada com cuidado. Afinal, o que é o mais importante no seu diagrama: colocar toda a informação em uma visão única porém de difícil leitura, ou facilitar o entendimento de o quê é realizado pelo processo até o seu resultado final? (Veja mais no vídeo, em 42’35”).

II. Perguntas sobre as abordagens de Orquestração x Comunicação:

Pergunta: “Podemos unir, em um fluxograma, a comunicação com a orquestração?”
Resposta: Sim, você pode ter a combinação de elementos usados nas duas abordagens, mas nossa recomendação é que, na estruturação de modelos de processo complexos, defina-se uma abordagem preferencial da organização, visando uma padronização nos diagramas (veja mais no vídeo, em 41’27”).

Pergunta: “Qual abordagem é mais utilizada? Comunicação ou Orquestração?”
Resposta: Não temos uma medição de qual a abordagem mais usada pelas organizações. Temos visto modelos usando os dois casos. Para esta opção recomendamos considerar: eventuais limitações da ferramenta, a maturidade e a cultura de processos da organização e que essa seja uma definição organizacional, propiciando uma modelagem padronizada em toda a arquitetura de processos da empresa.

Pergunta: “Alguma destas duas abordagens é mais ou menos recomendável ao usar uma ferramenta BPMS para a automação de processos ao usar BPMN?”
Resposta: Esta questão está intimamente relacionada à aderência do BPMS à notação. Algumas soluções, por exemplo, não permitem representar pools black box externas ao processo modelado, o que inviabiliza a adoção da abordagem por comunicação. Outras não contemplam elementos de subprocesso reusável, dificultando a escolha pela abordagem de orquestração.

Pergunta: “No diagrama geral de orquestração não há partes envolvidas (lanes) e não há atividades. Esta forma de modelagem é intencional? Se sim, qual é o nível de granularidade mais adequado para separar processos em subprocessos?”
Resposta: BPMN considera o uso de pools e lanes como representação meramente visual na modelagem dos processos. Você pode ter processos modelados sem representar pools e lanes e ainda assim ter um modelo de processo válido.
A estruturação de um processo em subprocessos varia de caso para caso, e pode ter múltiplos níveis também. Não há uma regra para isso.

Pergunta: “Eu utilizo a visão de orquestração para dar uma visão macro do processo e depois desenho todo o processo com o miles para representar os subprocessos e facilitar a visão do todo, está correto?”
Resposta: “Miles” (acredito que seja uma referência a milestones) não é um elemento da notação BPMN. Ela é uma extensão visual agregada por algumas ferramentas (como o Bizagi, por exemplo). Se no seu segundo desenho todo o fluxo é parte de um único diagrama de processo, então o que você tem é uma representação mais detalhada do mesmo processo, que é o caso do exemplo inicial – em que todo o fluxo é um único processo.

III. Apesar do foco do webinar ser sobre o encadeamento de processos para formar o processo de negócio de ponta-a-ponta, diversas dúvidas sobre outros elementos de BPMN foram enviadas pelos participantes, com base no exemplo usado no webinar, e que não podemos deixar de responder:

Pergunta: “Recebemos a informação que é necessário sempre colocar na sequência da direita, mas a seta pode retornar as atividades anteriores, e não repetir a mesma atividade seguindo a sequência.”
Resposta: Não há restrições sobre a direção da seta de entrada nem de saída em nenhum elemento de fluxo em BPMN. As boas práticas recomendam desenhar o processo da esquerda para a direita já que é a forma como naturalmente lemos as informações, mas um processo pode ter fluxos desenhados em qualquer direção. (Veja mais no vídeo em 44’14”).

Perguntas:
– “Na apresentação da modelagem as atividades não estavam identificadas como ‘Manual’ de ‘Usuários’, etc… algum motivo especial ou não é relevante para este tipo de processo?”

– “As tarefas não deveriam pertencer e ser representadas com um tipo de tarefa ou independe disso no exemplo?”
– “Qual a diferença de tarefa manual e de usuário?”
Resposta: A definição dos tipos de tarefas não é uma obrigatoriedade na modelagem de BPMN. Em um processo manual (que será disponibilizado como um guia e interpretado pelas pessoas) essa classificação realmente não faz muita diferença. Já na modelagem de um processo automatizado em um BPMS, cujas atividades serão interpretadas pelo sistema, definir o tipo de tarefa é fundamental (veja no vídeo em 38’25”).
Se você ainda tem dúvidas sobre os tipos de tarefas, confira essa série de três artigos que explicam bem as diferenças entre eles:
Desmistificando tipos de tarefas em BPMN: Tarefa Abstrata, Tarefa de Usuário e Tarefa Manual
Desmistificando tipos de tarefas em BPMN: Tarefas automáticas
Desmistificando tipos de tarefas em BPMN: Tarefas de envio e recebimento.

Perguntas:
– “Não teria q ter um gateway no primeiro loop do processo?”

– “Antes da primeira tarefa do Assistente de viagem não deveria conter um gateway, em função de várias outras tarefas estarem conectadas a ela?”
Resposta: É possível sim que qualquer elemento de fluxo tenha mais de uma entrada. O gateway antes poderá deixar mais explícita a lógica da chegada dos fluxos na atividade, mas se não há gateway controlando esses fluxos de sequência, o comportamento é como de um gateway exclusivo (veja mais no vídeo em 33’48”).

Pergunta: “Posso ter gateways seguidos (um após o outro)? Após a tarefa ‘Providenciar inscrição em evento’?”
Resposta: A especificação de BPMN não impõe nenhuma limitação sobre isso. Especialmente se a lógica dos gateways for diferente, então pode fazer sentido ter gateways em sequência. Sabemos que a melhor documentação é aquela que consegue ser mais objetiva, e assim se temos uma situação com vários gateways encadeados, é importante se questionar: se eu pensar além das respostas “Sim/Não”, posso resolver o problema de roteamento do meu processo com apenas um gateway? Se sim, então esta com certeza será a melhor opção, já que simplifica o diagrama.
Veja mais sobre uso de gateways neste artigo:
Estudo de caso: Boas práticas no uso de gateways em BPMN

Pergunta: “Você poderia explicar melhor esse P1 e P2 na atividade ‘Realizar prestação de contas’?”
Resposta: Esta pergunta refere-se aos dois eventos de borda de tempo (timer intermediate border event) não interruptivos conectados à tarefa de Realizar Prestação de Contas (veja no vídeo, em 10’38). Estes eventos de borda controlam prazos que se ocorrerem, dão início a outras atividades, no caso, de acompanhamento do processo.

Pergunta: “Quando estamos desenhando AS-IS, como representamos a forma como a comunicação é feita (e-mail, serviços em um barramento (SOA), em mãos) se usarmos a abordagem de orquestração? A forma como os subprocessos são acionados é importante para o entendimento do mesmo. Concorda?”
Resposta: Esta pergunta tocou em um ponto chave! O que determina como os subprocessos são acionados é o processo orquestrador. Ele é o responsável por determinar quando um subprocesso deve ser iniciado e garantir que as informações “desçam” e “subam” a cada execução desses subprocessos, de forma que o processo orquestrador tem sempre toda a informação que foi sendo acumulada durante seus subprocessos. Quais informações, e o meio como isso ocorre, não é detalhado no fluxo, mas na especificação detalhada de cada uma das tarefas.

Pergunta: “Qual é o meio de comunicação utilizado pelos participantes do processo?”
Resposta: Isto é independente da lógica do processo. Se os participantes se comunicarem através da troca de e-mails, ou se for um formulário de papel que passa de mão em mão, a lógica, ou seja, a sequência de atividades, as dependências e as responsabilidades sobre elas permanecerá a mesma.

Pergunta: “Os objetos de sistema e doc não podem ser utilizados para representar a comunicação via email ou sistema assim como era utilizado no EPC?”
Resposta: A notação BPMN não contempla estes elementos citados (sistema, doc), mas eles podem ser criados como extensão pela ferramenta de modelagem. Utilizá-los, neste caso, deve ser uma definição da própria organização.

IV. Outras questões enviadas, indiretamente relacionadas ao tema:

Pergunta: “Quais os BPMS mais consagrados de mercado?”
Resposta: Esta é uma questão na qual não encontraremos consenso no mercado. O que definirá um BPMS como “consagrado”? O número de cases? A variedade de cases? O volume de processos? A complexidade dos processos? A presença no Brasil? Ou no mundo?
Se for a presença no Brasil, uma boa fonte de informação pode ser a Pesquisa Nacional em Gerenciamento de processos de Negócio da ABPMP Brasil, publicada na 10ª edição da revista BPM Global Trends.
Outra fonte pode ser o relatório do Gartner Group e seu Quadrante Mágico de iBPMS (mas esse relatório não avalia nem 10% das soluções que existem ao redor do globo, apenas grandes players).
Para entender a complexidade na definição de critérios para comparação e avaliação de BPMS/iBPMS, assista ao Webinares iProcess 2014 – Etapas e Desafios da Seleção de uma Plataforma de BPM.

Quer participar dos próximos?

9 respostas

  1. Ótima explicação sobre concatenação entre processos.

    Dúvida : Eu posso ter em um mesmo diagrama mais de um evento de início padrão? Vejo que seu diagrama foi separado em 3 processos distintos.
    Vejo q existe 1 iniciador padrão e dois de mensagem. Até aí ok.

    Mas é possível existir em um mesmo diagrama com vários processos , mais de um iniciador padrão? Ou realmente , em um diagrama só pode haver 1 iniciador padrão?

  2. Mais uma dúvida importante sobre conectando processos dentro de um mesmo diagrama:

    Eu vejo q para conectar os processos dentro do mesmo diagrama vc está usando eventos de envio de mensagem ao final.

    1) Mas eu posso ter “Tarefas de Envio” de mensagem para se comunicar com o outro processo do diagrama?

    2) qual a diferença então entre usar uma tarefa de envio ou usar um evento de envio? Qdo eu sei qual devo usar para se comunicar com o outro processo?

    3) todo o processo necessariamente em algum momento deverá ter um iniciador, ainda que nao o genérico, mas deverá ter algo que acione o processo correto?

    1. Olá Manuel,

      Em nome do time da iProcess, gostaria de agradecê-lo pela visita ao nosso blog!
      Fiquei um pouco em dúvida de qual caso você está falando, já que no webinar apresentei duas formas de dividir um processo: por comunicação (um processo avisa o outro quando terminou) ou por orquestração (tem um processo macro que vai acionando cada etapa à medida que a etapa anterior terminou).

      O webinar foi baseado neste artigo, onde tem alguns exemplos:
      https://blog.iprocess.com.br/2013/04/bpmn-demonstrando-a-continuidade-de-processos/

      De qualquer forma, toda vez que tenho uma pool, eu tenho um processo (e apenas um processo por pool). Embora pela regra de BPMN o elemento de início não seja obrigatório, é um consenso geral de melhores práticas que todo fluxo de processo tenha eventos marcando o seu início e o seu vim.

      No caso do processo em que as etapas são acionadas no método de comunicação, é necessário que o evento de fim de um processo seja de mensagem, que dará início a outro processo. Eles não precisam estar na mesma página/diagrama em que está modelando o processo, mas devem usar o mesmo nome para facilitar a identificação do fluxo. E embora em alguns exemplos eu mostre a conexão do fim do processo com a entrada em uma pool black box (aquela pequena) isso não precisa ser modelado visualmente.

      Quanto ao método de orquestração, os eventos de início não precisam ter os tipos definidos, pois quem determina quando ele vai começar não é a chegada de uma mensagem, e sim o processo macro. Ele vai acionar a próxima etapa quando identificar que a etapa anterior foi concluída.

      Sobre sua outra dúvida, a respeito das tarefas de envio/recebimento, recomendo conferir este artigo que explica como essas tarefas funcionam e um paralelo com os eventos de mensagem:
      https://blog.iprocess.com.br/2014/04/desmistificando-tipos-de-tarefas-em-bpmn-tarefas-de-envio-e-recebimento/

  3. Boa tarde!
    Tenho um processo de nível 1 em orquestração sequenciada, posso no nível operacional em uma das saídas do processo representar o próximo subprocesso?

    Obrigado!

    1. Olá Glaucimar,
      Vou usar aqui os termos “processo orquestrador” para o seu nível 1, e “subprocesso” para o seu nível operacional, ok?
      Bom, falando puramente da notação, esta não seria uma abordagem apropriada.
      Na modelagem orquestrada, você tem que pensar que cada subprocesso é uma atividade. Quando ele chega ao evento de fim, a atividade no nível da orquestração acabou, e o processo orquestrador indicará qual a próxima atividade (subprocesso). Portanto, quem guia o fluxo, é o processo orquestrador.
      Ao usar um evento no nível de detalhe do subprocesso – o seu processo de nível operacional, você estaria tornando redundante o acionamento do próximo processo.
      Além disso, uma das vantagens da abordagem de orquestração é que como cada subprocesso é um componente reutilizável, você pode usá-lo em fluxos diferentes, de forma que os processos que acontecem antes ou depois de um subrocesso específico podem ser diferentes de acordo com a configuração de cada processo orquestrador onde ele seja usado.
      Ao definir o fim do subprocesso como gatilho para iniciar um próximo subprocesso, você estaria amarrando estes dois fluxos e tornando menos flexível a reutilização dos componentes.
      Algumas organizações não se importam muito com a pureza da notação e estão dispostas a fazer algumas flexibilizações de uso dos elementos na expectativa de facilitar o entendimento do processo or quem lê, e isso é aceitável. Mas nesse caso acho uma abordagem um pouco arriscada, já que poderia acabar referenciando um próximo subprocesso diferente do mostrado no nível da orquestação – o que poderia confundir a interpretação do processo de negócio. Sem contar que uma mudança do processo poderia ser mais trabalhosa com dois pontos a atualizar (em vez de um só).

  4. Olá, parabéns pelo conteúdo! Tenho um comentário complementar sobre os vídeos, que pode auxiliar algum designer.
    O BPMN indica como boas práticas não retornar para a esquerda… sempre para baixo, para cima ou para a direita. Se é uma boa prática o ideal é que seja seguida. Entendo que os casos que você mostrou são simples, e não resulta em grandes problemas retornar para trás.
    Acho interessante ressaltar como complemento o evento intermediário de link (envia e recebe). Em casos de diagramações grandes, muitas vezes aparece determinado fator acontecer(representado por um gateway na maioria das vezes) que precisaremos retornar para uma atividade no início ou meio do fluxo. Além de ficar visualmente feio voltar para trás pois ultrapassa muitas linhas, também não é uma prática saudável. Portanto, utiliza-se o evento de link para lançar e para receber na outra atividade, atualmente utilizo com a ordem alfabética.

    1. Obrigada pelas sugestões, Fernanda!
      De acordo com Bruce Silver, essa questão de desenhar apenas para direita e para baixo é uma questão de estilo de modelagem. Mais importante do que seguir uma prática recomendada por uma ferramenta, eu recomendo que sempre se julgue a capacidade de interpretação do modelo. Quanto mais limpo e claro, melhor, e é isso que importa :)
      Em relação ao uso de links, antes de usá-los, recomendaria avaliar se o modelo do fluxo já não está muito grande. Vejo diferentes autores recomendando número máximo de elementos de diagramas diferentes. A IBM recomenda até 7 atividades, alguns autores recomendam que o diagrama todo seja legível em apenas uma página e outros sugerem máximo de 20 ou 30 elementos. Então antes de usar o link, talvez seja bom refletir se o diagrama não está muito grande e se não seria melhor subdividí-lo em subprocessos.
      De qualquer forma, suas recomendações são bem interessantes, obrigada por contribuir para a reflexão!

Deixe um comentário para Glaucimar Souza Cancelar resposta

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