BPMN: guia de símbolos e como ler um diagrama de processo

Alguém manda um arquivo .bpmn ou um PDF cheio de losangos, círculos e retângulos arredondados ligados por setas, e pede para você validar o desenho. A reação mais comum é achar que entender aquilo exige curso de certificação e semanas de vocabulário técnico. Não exige. A notação BPMN (Business Process Model and Notation) tem mais de cem elementos no padrão completo, mas a maioria dos diagramas que uma área de RH, financeiro ou operações desenha no dia a dia usa entre oito e doze símbolos, sempre os mesmos.

Este guia é sobre ler, não sobre certificar. Ele lista os símbolos que cobrem cerca de 90% dos processos reais, descreve a forma de cada um — círculo de borda fina, losango com um X dentro, retângulo de cantos arredondados — porque este texto não tem imagem e você precisa reconhecer a forma no diagrama à sua frente, e fecha com o erro de leitura mais comum: confundir um gateway exclusivo com um paralelo, o que muda por completo o que o processo faz.

Os quatro grupos de elementos do BPMN

O padrão organiza os símbolos em quatro categorias. Saber a categoria já ajuda a adivinhar o que um símbolo desconhecido faz, mesmo sem memorizar o desenho exato. Se falta o porquê de modelar processos antes dos símbolos, o guia completo de BPM cobre a disciplina que a notação serve — este texto vai direto ao “como ler”.

• Objetos de fluxo são o que acontece: eventos, tarefas, subprocessos e gateways — a categoria com mais variação, detalhada símbolo a símbolo a seguir.
• Objetos de conexão são as linhas que ligam os objetos de fluxo entre si: fluxo de sequência, fluxo de mensagem e associação — onde mais gente erra a leitura, com seção própria mais adiante.
• Raias (pools e lanes) organizam o diagrama por quem faz o quê.
• Artefatos acrescentam contexto sem alterar o que o processo faz: um documento referenciado, uma nota explicativa, um agrupamento visual. Apagar um artefato do diagrama não muda o comportamento do processo. Apagar um objeto de fluxo, muda.

Artefatos: contexto que não mexe no fluxo

Os três artefatos mais comuns aparecem em quase todo diagrama real, e nenhum tem seta de sequência entrando ou saindo — é assim que você os distingue de um objeto de fluxo à primeira vista.

Símbolo	Forma	O que representa
Objeto de dados	Retângulo estreito com o canto superior direito dobrado, como uma folha de papel	Um documento ou informação que uma tarefa produz ou consome — não é uma etapa
Anotação	Um colchete aberto ligado ao elemento por uma linha pontilhada, com texto ao lado	Uma explicação para quem lê, sem efeito nenhum na execução
Grupo	Retângulo grande, borda tracejada, cantos arredondados, sem preenchimento	Uma faixa visual que reúne vários elementos para leitura — por exemplo, “etapa de aprovação”

Eventos: início, intermediário e fim

Os três eventos compartilham a mesma forma — um círculo — e se diferenciam só pela espessura da borda, o detalhe que mais gente ignora numa leitura rápida e que muda o significado.

• Evento de início é um círculo de borda fina, geralmente vazio por dentro. Marca onde o processo começa: chegada de um pedido, uma data agendada, uma mensagem recebida. Todo processo tem pelo menos um.
• Evento intermediário é um círculo de borda dupla — duas linhas finas, uma dentro da outra. Marca algo que acontece no meio do fluxo sem ser uma tarefa: uma espera por prazo, o recebimento de uma mensagem, um timer que dispara depois de um número de dias.
• Evento de fim é um círculo de borda única, mas grossa — bem mais pesada que a do evento de início. Marca onde aquele ramo do processo termina. Um processo pode ter mais de um evento de fim, um para cada desfecho possível: aprovado, reprovado, cancelado.

Dentro do círculo pode aparecer um ícone indicando o gatilho — um envelope para mensagem, um relógio para timer. Quando esse timer está amarrado a um prazo de atendimento, SLA, lead time e gargalo explica como medir esse tipo de prazo. Para 90% da leitura, porém, a borda — fina, dupla, grossa — já basta; o ícone interno é detalhe.

Tarefa vs subprocesso

Ambos usam a mesma forma: um retângulo de cantos arredondados. A diferença que importa para a leitura:

• Tarefa é um retângulo de cantos arredondados liso, sem nada além do texto que descreve a ação (“Aprovar solicitação”, “Enviar contrato”). Representa um trabalho atômico — não se abre em mais nada dentro do próprio diagrama.
• Subprocesso é o mesmo retângulo, mas com um pequeno quadrado contendo um sinal de mais (+) centralizado na borda inferior. Esse marcador diz “isto esconde um diagrama inteiro lá dentro”. Um subprocesso “Processar reembolso” pode conter, expandido, dez outras tarefas e dois gateways.

Regra prática: se o bloco passa de cinco ou seis passos, ou se repete idêntico em outros processos, ele merece virar subprocesso — mantém o diagrama principal legível, assunto da seção sobre espaguete mais à frente.

Gateways: os três que importam (e o erro clássico)

Todo gateway é um losango. A diferença entre os três que valem memorizar está no símbolo desenhado dentro dele, e não é estética — muda o comportamento do processo.

• Gateway exclusivo (XOR) — losango vazio ou com um X dentro. Só um caminho é seguido, por condição. “Valor da compra acima de R$ 5.000?” tem duas saídas, sim ou não, e o processo segue só por uma.
• Gateway paralelo (AND) — losango com um sinal de mais dentro. Todos os caminhos que saem dele seguem ao mesmo tempo, sem condição nenhuma. “Notificar o financeiro” e “notificar o solicitante” acontecem os dois, sempre que o gateway é alcançado.
• Gateway inclusivo (OR) — losango com um círculo dentro. Um ou mais caminhos seguem, cada um avaliado pela própria condição. Diferente do exclusivo (no máximo um) e do paralelo (todos), pode liberar só dois de três caminhos, por exemplo.

O erro clássico é desenhar — ou ler — um XOR onde deveria haver um AND. Acontece quando duas ações deveriam ocorrer juntas, como “aprovar E notificar o fiscal”, mas o diagrama trata como alternativas, “aprovar OU notificar”. O sintoma é sutil: uma das ações nunca acontece, porque o desenho nunca abre os dois caminhos ao mesmo tempo — e ninguém percebe até alguém perguntar por que o fiscal nunca foi avisado. Antes de aceitar um losango, pergunte: as saídas são alternativas (XOR), obrigatórias (AND), ou dependem de condições independentes (OR)? Se a resposta não vier na hora, o gateway está mal modelado, não mal lido.

Fluxo de sequência vs fluxo de mensagem

As duas são setas, e é fácil ler uma pela outra — mas respondem perguntas diferentes.

• Fluxo de sequência é uma linha sólida com ponta de seta cheia. Conecta objetos de fluxo dentro do mesmo pool e representa a ordem de execução: o que acontece depois do quê.
• Fluxo de mensagem é uma linha tracejada, com círculo vazio na origem e seta vazia (aberta) no destino. Conecta elementos em pools diferentes e representa comunicação entre participantes — a empresa envia um pedido de cotação, o fornecedor devolve a proposta.

Regra que resolve qualquer dúvida: se a seta cruza a borda de um pool, é fluxo de mensagem; dentro do mesmo pool, é fluxo de sequência. Uma tarefa nunca se conecta à tarefa de outro participante por sequência — isso é erro de modelagem, porque a notação não permite controlar a execução de quem está fora do seu processo.

Pool e lane: quando usar cada uma

Pool e lane resolvem perguntas diferentes, e confundi-las é o motivo mais comum de raias mal desenhadas.

• Pool é um retângulo grande que representa um participante inteiro e independente — uma empresa, um sistema externo, um órgão público. Dois pools só se comunicam por fluxo de mensagem, nunca por sequência, porque cada um controla seu próprio processo.
• Lane é uma faixa dentro de um único pool, uma subdivisão horizontal (às vezes vertical) que representa quem, na mesma organização, é responsável por cada etapa — não um participante independente.

Pergunta que decide: as duas partes têm processos internos separados que se comunicam por mensagem? Dois pools. É a mesma empresa, e você só quer deixar claro quem faz o quê? Lanes dentro de um pool só. Errar essa escolha — dois pools para a mesma empresa, por exemplo — cria fluxos de mensagem onde bastaria uma passagem de bastão, e complica o diagrama à toa.

Os símbolos que cobrem 90% dos processos reais

Junte as seções acima numa tabela só, e é isto que você vai reconhecer na maioria dos diagramas que encontrar:

Símbolo	Forma	Significado	Quando usar
Evento de início	Círculo, borda fina	Onde o processo começa	Um por processo, no mínimo
Evento intermediário	Círculo, borda dupla fina	Algo acontece no meio do fluxo (espera, mensagem, timer)	Quando o processo pausa ou reage sem ser uma tarefa
Evento de fim	Círculo, borda única grossa	Onde um ramo do processo termina	Um para cada desfecho possível
Tarefa	Retângulo de cantos arredondados, liso	Um trabalho atômico	A ação não se divide mais dentro do diagrama
Subprocesso	Retângulo de cantos arredondados com ”+” na base	Um bloco que esconde outro diagrama	Mais de cinco ou seis passos, ou bloco reutilizado
Gateway exclusivo (XOR)	Losango vazio ou com X	Só um caminho segue, por condição	Decisão do tipo “ou isso, ou aquilo”
Gateway paralelo (AND)	Losango com sinal de mais	Todos os caminhos seguem juntos	Ações que sempre acontecem em conjunto
Gateway inclusivo (OR)	Losango com um círculo	Um ou mais caminhos seguem, por condições independentes	Combinações não binárias
Fluxo de sequência	Linha sólida, seta cheia	Ordem de execução	Dentro do mesmo pool
Fluxo de mensagem	Linha tracejada, círculo vazio até seta vazia	Comunicação entre participantes	Atravessando pools
Pool	Retângulo grande, contêiner	Um participante independente	Dois processos que só se falam por mensagem
Lane	Faixa dentro do pool	Um papel ou responsável	Dividir responsabilidades na mesma organização

Onde a leitura — e o desenho — dão errado

• O diagrama vira espaguete. Linhas cruzando por todo lado, gateways empilhados, um subprocesso que devia existir mas virou vinte tarefas soltas. Sintoma: você não segue um caminho do início ao fim sem o dedo na tela. A correção começa no mapeamento, não no desenho — como mapear processos passo a passo detalha a granularidade certa para não chegar a este ponto.
• Modelar a exceção de 5% como se fosse regra. Um gateway extra para cada caso raro transforma um processo de seis passos num labirinto de vinte. A exceção deveria virar desvio simples, nota ou subprocesso à parte — não um ramo permanente no fluxo principal.
• Usar gateway para tudo. Nem toda ramificação é decisão de processo. Um campo que só muda de categoria conforme o valor não precisa de losango — precisa de uma condição dentro da própria tarefa. Gateway em excesso é sinal de quem pensa em fluxograma de código, não em processo de negócio.
• Raia por pessoa em vez de por papel. Uma lane chamada “Maria” em vez de “Analista Financeiro” quebra no dia em que ela sai de férias, muda de cargo ou desliga — e alguém reabre o editor só para trocar um nome. Lane representa responsabilidade, não pessoa.

Como a TAI resolve

Na TAI Processos, você não desenha losango nenhum. A modelagem acontece nas abas de configuração do fluxo — Geral, Fases, Campos, Automações, Templates, Visibilidade e Formulário Público —, mas o resultado carrega a mesma lógica de um diagrama BPMN por trás da tela. Cada fase equivale a uma tarefa (ou a um evento, se for do tipo Início ou Finalização), e a ordem das fases, junto com a regra “permitir mover cards desta fase para”, cumpre o papel do fluxo de sequência.

A fase do tipo Aprovação é, na prática, um gateway exclusivo simplificado: o card segue por um de dois caminhos, aprovado ou reprovado, e fica retido até alguém com permissão decidir — sem tela separada para desenhar o losango.

Uma lógica mais próxima de gateway paralelo — várias ações ao mesmo tempo — fica na aba Automações: cada regra combina um gatilho (solicitação criada, campo alterado, SLA vencido, entrada ou saída de fase, entre outros), condições opcionais e uma ou mais ações, como mover de fase, atribuir responsável, enviar e-mail ou disparar webhook. Uma automação que dispara duas notificações a partir do mesmo gatilho é, funcionalmente, um AND sem o desenho — e qual automação configurar primeiro é o tema de o que automatizar primeiro num processo.

Para quem chega sem prática em modelagem, o fluxo pode nascer descrito em texto livre no gerador com IA — algo como “processo de reembolso com aprovação do gestor” — e a plataforma propõe fases e campos para ajustar antes de publicar. Dentro de cada fase, os mesmos agentes de IA podem classificar e rotear uma solicitação sem intervenção manual: a diferença entre um processo que só organiza o trabalho e um que executa parte dele é o tema de agentes de IA em processos.