modeling

Pools e Lanes em BPMN: Definindo Claramente as Responsabilidades

Peter Carter
Pools e Lanes em BPMN: Definindo Claramente as Responsabilidades

Em um diagrama BPMN, Pools e Lanes são elementos visuais essenciais usados para definir quem faz o quê. Mais do que simples ferramentas de layout, eles ajudam a estruturar processos de forma clara, mostrando papéis, departamentos, organizações ou sistemas envolvidos na execução.

Um pool sempre representa um participante no processo — alguém ou algo que executa ou colabora no processo, como uma empresa, um departamento ou um sistema. Essa separação visual ajuda a esclarecer como os participantes interagem por meio de trocas de mensagens e responsabilidades claramente definidas.

O que é um Pool?

Para começar a estruturar um processo BPMN, primeiro é necessário identificar quem está envolvido. Um pool é o elemento que representa cada participante — seja uma empresa, departamento ou sistema — que desempenha um papel no processo.

Um pool pode representar:

  • Uma organização (por exemplo, "Fornecedor")
  • Um departamento (para processos internos colaborativos)
  • Um sistema (como “ERP” ou “CRM”)

Nos modelos de processo colaborativo, cada pool mostra qual participante executa qual parte do processo e como eles trocam informações via fluxos de mensagens.

💡
Exemplo: Um pool pode representar o “Cliente” e outro a “Empresa”. O cliente envia um pedido, e a empresa o processa. Cada um é um participante distinto.

O que são Lanes?

Após identificar os participantes, o próximo passo é entender como as responsabilidades são divididas dentro de cada um. É aí que entram as lanes: elas são subdivisões internas dentro de um pool que mostram quem é responsável por cada tarefa.

Lanes dividem um pool em papéis, departamentos ou funções dentro do participante.

  • Elas ajudam a atribuir responsabilidade a cada tarefa.
  • Elas mostram colaboração entre áreas.
  • Elas não contêm lógica — são simplesmente organizadores visuais.
💡
Exemplo: Dentro do pool "Empresa", você pode ter lanes como "Vendas", "Finanças" e "Logística".

Fluxo de Sequência vs. Fluxo de Mensagem

Ao modelar processos de negócio com múltiplos participantes (representados por piscinas), é essencial entender como as tarefas estão conectadas. Nem toda conexão é igual — há uma diferença clara entre fluxos internos, que mostram a ordem das atividades dentro de um participante, e fluxos de mensagem, que mostram comunicação entre diferentes participantes.

  • Fluxo de Sequência (setas sólidas): conecta atividades dentro da mesma piscina, mostrando a ordem de execução.
  • Fluxo de Mensagem (linhas tracejadas): conecta atividades entre diferentes piscinas, indicando troca de informações ou coordenação.
💡
Exemplo: Dentro da piscina "Empresa", você pode ter raias como "Vendas", "Finanças" e "Logística".

Como Lidar com Mensagens Entre Pools

⚠️
Tópico Avançado: Para leitores que já entendem pools e fluxos de sequência, esta seção aprofunda-se em como a comunicação baseada em mensagens funciona entre participantes no BPMN.

No BPMN, a comunicação entre diferentes participantes (representados por pools separados) deve sempre ser feita usando fluxos de mensagem — não fluxos de sequência. Para representar isso corretamente, você pode usar tipos de tarefas específicos e eventos de mensagem projetados para esse propósito.

Aqui estão os principais elementos que você pode usar:

Tarefa de Envio

Uma Tarefa de Envio é usada quando o processo precisa enviar uma mensagem para outro pool. Ela mostra visualmente que o principal objetivo da tarefa é despachar uma mensagem para um participante.

💡 Exemplo: Após validar uma solicitação de rescisão, uma Tarefa de Envio pode ser usada para notificar o departamento de TI.

Tarefa de Recebimento

Uma Tarefa de Recebimento é usada quando o processo está esperando para receber uma mensagem específica de outro pool antes de continuar. Ela representa um ponto de espera explícito para a comunicação recebida.

💡 Exemplo: A equipe de TI pode usar uma Tarefa de Recebimento para esperar por uma solicitação formal para revogar acesso.

Eventos de Mensagem Intermediários

Você também pode usar Eventos de Mensagem Intermediários para modelar pontos de comunicação mais flexíveis.

  • Evento de Mensagem de Lançamento (Envio): usado para enviar uma mensagem no meio do processo.
  • Evento de Mensagem de Captura (Recebimento): usado para esperar por uma mensagem antes de continuar o fluxo.

Estes são úteis quando a mensagem não é o objetivo principal da tarefa, mas parte de uma atividade maior.

💡 Exemplo: Um evento de mensagem de captura pode ser colocado antes de uma tarefa de aprovação que deve começar apenas quando uma confirmação externa for recebida.

Evento de Início de Mensagem

Se um processo é acionado por uma mensagem de outro participante, você pode usar um Evento de Início de Mensagem no início desse processo.

💡 Exemplo: O processo de “Gestão de Acesso ao Sistema de TI” pode começar com um Evento de Início de Mensagem quando recebe uma solicitação do processo de RH.

Usar a combinação correta de tarefas de mensagem e eventos ajuda a tornar o fluxo do processo mais preciso, sustentável e pronto para automação — especialmente quando sistemas ou parceiros externos estão envolvidos.

Evento de Fim de Mensagem

Um Evento de Fim de Mensagem é usado quando um processo termina enviando uma mensagem para outro participante. Ele representa o ponto final do processo, onde uma mensagem é despachada — muitas vezes para notificar outra equipe ou acionar um processo de acompanhamento.

  • É visualmente semelhante a outros eventos de fim, mas marcado com um símbolo de envelope.
  • Comumente usado em subprocessos ou processos de apoio que devem relatar de volta ao fluxo principal.
💡 Exemplo: Após completar a verificação de dívida, o processo financeiro termina com um Evento de Fim de Mensagem que notifica a equipe de RH, permitindo que eles prossigam com as etapas finais.

Exemplo Prático: Término do Contrato de Trabalho

Vamos agora explorar um exemplo de BPMN para reforçar o que aprendemos — desta vez usando o processo de Término do Contrato de Trabalho.

Este é um cenário comum no mundo real que requer coordenação entre várias equipes — como RH, gerentes diretos e o departamento de TI — para garantir que todas as etapas sejam concluídas de forma segura, consistente e na ordem correta.

Neste exemplo, focamos em como usar fluxos de mensagens entre pools para:

  • Iniciar processos em outras equipes
  • Manter o processo principal fracamente acoplado enquanto mantém a coordenação
  • Transitar tarefas entre raias para refletir mudanças de responsabilidade baseadas em funções

Vamos começar analisando os fluxos destacados na imagem abaixo.

A seta A mostra um fluxo de sequência conectando duas tarefas dentro do mesmo pool. À medida que o processo de Rescisão de Emprego avança de "Completar Documentação de Rescisão" para "Validar a Solicitação de Rescisão", a responsabilidade muda entre as raias, representando diferentes papéis dentro da organização.

Além disso, a seta B ilustra um fluxo de mensagem. Aqui, o processo principal envia uma mensagem para a equipe de Gestão de Acesso ao Sistema de TI, iniciando um processo separado para revogar o acesso ao sistema. Este subprocesso é executado de forma independente — o processo principal de rescisão não espera por sua conclusão.

Agora, vamos examinar como o processo interage com o terceiro pool.

A seta C representa uma mensagem acionada pelo evento intermediário “Notificação de Dívidas Pendentes” e recebida pelo evento de início “Processo de Rescisão de Empregado Processado” no terceiro pool. Este pool contém uma única tarefa e, ao ser concluída, atinge o evento final “Verificação de Dívida Concluída,” que por sua vez envia outra mensagem — representada pela Seta D.

Enquanto isso, no pool de chamada, o usuário de RH pode executar a tarefa “Cancelar Benefícios e Deduções” em paralelo com o processo do terceiro pool. No entanto, o fluxo deve pausar em “Receber Mensagem de Verificação Financeira” para aguardar a confirmação da equipe financeira.

Esse comportamento de bloqueio garante que nenhum processo de rescisão possa ser finalizado sem a verificação de dívidas da equipe financeira.

Este processo completo faz parte do nosso banco de dados de exemplos e está disponível gratuitamente para todos os usuários do HEFLO. 👉 Clique no botão abaixo para criar uma conta gratuita no HEFLO e explorar este diagrama BPMN na íntegra, diretamente no modelador.

Tipos de Pool: Caixa Preta e Caixa Branca

Às vezes, você não precisa ou não quer mostrar o que acontece dentro de cada participante. É por isso que o BPMN permite representar um pool de duas maneiras, dependendo de quanto detalhe interno você deseja exibir.

1. Pool de Caixa Preta

Um pool de caixa preta é usado quando você não mostra o processo interno do participante. Ele aparece no diagrama, mas não contém tarefas visíveis.

  • Representa uma parte externa para quem você envia ou de quem recebe mensagens.
  • Comum para clientes, fornecedores, parceiros ou sistemas de terceiros.
  • Ajuda a manter o foco no que é relevante para o processo de negócio sendo modelado.

A imagem abaixo ilustra um bom exemplo de um pool de Caixa Preta. O evento "Aquisição de Bens Acionada" envia uma mensagem e aguarda uma resposta. Como o "Processo de Compras" representa um processo externo, o que acontece dentro dele não é mostrado — e do ponto de vista do processo principal, isso não importa.

2. Pool de Caixa Branca

Um pool de caixa branca mostra as atividades internas do participante.

  • Usado quando você deseja modelar o processo dentro do participante.
  • Pode ser subdividido em raias para mostrar papéis ou departamentos.
  • Permite rastrear o fluxo de sequência completo dentro da organização.

O exemplo "Rescisão de Emprego" acima é um caso claro de um pool de Caixa Branca, pois exibe todas as tarefas internas e seu fluxo de execução.

✅ Melhores Práticas

Agora que você entende pools, lanes e tipos de fluxo, aqui estão algumas melhores práticas para ajudá-lo a usar esses elementos de forma eficaz e manter seu diagrama claro, preciso e pronto para execução ou documentação.

  • Use pools separados para participantes distintos.
  • Use lanes para definir claramente as responsabilidades dentro de um pool.
  • Nunca conecte pools com Fluxo de Sequência — sempre use Fluxo de Mensagem.
  • Nomeie pools e lanes claramente usando termos que sua organização entende.
  • Evite nomear lanes com nomes de indivíduos. Use papéis ou funções (por exemplo, “Analista de Compras” ou “Gerente Financeiro”) para que o processo de negócio permaneça válido mesmo que a equipe mude.
💡 Bons exemplos de nomes de lanes: “RH,” “Financeiro,” “Gerente do Solicitante”
❌ Evite: “João Silva,” “Ana Pereira”

🎥 Aula em Vídeo Gratuita: Modelando uma Piscina com Duas Raias

Quer ver tudo isso em ação?

Gravamos uma aula em vídeo gratuita que o guia passo a passo na construção de um processo BPMN usando um único pool com duas raias. É a maneira perfeita de entender como modelar responsabilidades internas dentro de um participante.

Neste vídeo, você aprenderá:

  • Como criar um pool e adicionar raias para diferentes papéis ou departamentos
  • Como posicionar corretamente as tarefas em cada raia
  • Como conectar tarefas usando Fluxos de Sequência dentro do mesmo pool
  • E as melhores práticas de layout para manter seu diagrama limpo e profissional

Perguntas Frequentes

Mesmo com os conceitos claramente explicados, algumas perguntas são comuns — especialmente para aqueles que são novos no BPMN. Aqui estão as respostas para as dúvidas mais frequentes:

Posso usar raias em diferentes piscinas?

Sim. Cada piscina pode ter seu próprio conjunto de raias para representar papéis ou departamentos internos. No entanto, os fluxos de mensagem devem apenas conectar elementos entre piscinas, nunca entre raias em diferentes piscinas.

Posso conectar tarefas entre piscinas usando fluxos de sequência?

Não. Os fluxos de sequência devem permanecer dentro da mesma piscina. Para conectar diferentes piscinas, sempre use fluxos de mensagem — eles representam a comunicação entre participantes.

As raias podem ser aninhadas ou hierárquicas?

Não. Todas as raias dentro de uma piscina estão no mesmo nível. O BPMN não suporta raias aninhadas ou indentadas.

Devo nomear as raias com nomes de pessoas?

Não é recomendado. Sempre use papéis, departamentos ou títulos de trabalho. Evite nomes pessoais para que seu diagrama permaneça válido ao longo do tempo, mesmo que os membros da equipe mudem.

Quando devo usar uma Tarefa de Envio vs. um Evento de Fim de Mensagem?

Use uma Tarefa de Envio quando o envio de uma mensagem faz parte de um processo, geralmente seguido por mais tarefas. Use um Evento de Fim de Mensagem quando o processo termina com o envio de uma mensagem — por exemplo, notificando outra equipe de que uma tarefa está completa.

Qual é a diferença entre uma Tarefa de Recebimento e um Evento de Captura de Mensagem?

Ambos esperam por uma mensagem, mas uma Tarefa de Recebimento é tratada como uma tarefa completa (pode ser atribuída, rastreada, etc.), enquanto um Evento de Captura de Mensagem é mais leve e frequentemente usado para pontos de controle ou decisão.

Como inicio um processo quando uma mensagem é recebida?

Use um Evento de Início de Mensagem. Ele aciona o início de um processo quando uma mensagem específica chega — comum em processos que dependem de solicitações externas.

E se eu tiver várias equipes trabalhando em paralelo?

Use portas de entrada paralelas dentro de uma piscina, ou dispare múltiplos fluxos de mensagem para diferentes piscinas. Sincronize-os com um evento de recebimento de mensagem ou porta de entrada de junção posteriormente, dependendo da sua lógica.

Conclusão

Compreender como definir participantes e responsabilidades usando pools e raias é fundamental para criar diagramas BPMN que sejam claros, colaborativos e prontos para melhoria ou automação. Pools e raias tornam seu processo de negócio fácil de ler e alinhado com o funcionamento real da sua organização.


Curtiu? Compartilhe com amigos!

Artigos relacionados