Quem pesquisa BPMN encontra, quase sempre, um catálogo de símbolos: círculo é evento, retângulo é tarefa, losango é decisão. Está certo, mas é a metade menos útil da história. A notação foi feita para que o mesmo desenho sirva ao analista que rascunha o processo, ao desenvolvedor que o implementa e ao gestor que o acompanha.
Este guia volta à fonte, a especificação da OMG, para mostrar o que ela realmente define: os cinco grupos de elementos, os três níveis de detalhe e o formato que leva o modelo de uma ferramenta a outra. No fim, você sabe o que cada símbolo faz e quanto detalhe o seu diagrama precisa ter para documentar ou para rodar numa automação.
O que é BPMN?
BPMN é a sigla de Business Process Model and Notation, em português "modelo e notação de processos de negócio". É um padrão aberto, mantido pela Object Management Group (OMG), que define um conjunto de símbolos e regras para desenhar como um processo acontece: o que dispara o trabalho, quais atividades são feitas, quem faz, onde o caminho se divide e como termina.
A especificação declara o objetivo principal logo na abertura: ser uma notação compreensível por todos os usuários de negócio, do analista que cria o primeiro rascunho ao técnico que implementa a tecnologia que vai executar o processo. Ela se descreve como uma ponte padronizada entre o desenho do processo e a sua implementação.
Na prática, isso quer dizer que um diagrama BPMN não é só uma figura. Por trás de cada símbolo há um elemento com atributos definidos, e o conjunto pode ser salvo num arquivo XML que outra ferramenta consegue abrir. É essa camada invisível que separa o BPMN de um desenho livre feito em qualquer editor.
Quem criou o BPMN e o que é o BPMN 2.0?
A primeira versão nasceu fora da OMG: o registro da especificação 1.0 no site da organização traz copyright de 2004 da BPMI.org. A versão 1.0 formal publicada pela OMG tem data de março de 2007.
O salto veio com a família 2.0. Segundo a própria especificação, a versão 2.0.2 amplia a 1.2 em cinco frentes: formaliza a semântica de execução de todos os elementos, cria um mecanismo de extensão, refina eventos e correlação, amplia a definição de interação humana e acrescenta o modelo de coreografia. Também corrige inconsistências e ambiguidades conhecidas da 1.2.
Quando alguém fala em "BPMN 2.0" hoje, está falando dessa família. Nenhuma ferramenta precisa de outra referência: o PDF da especificação e os esquemas XML estão abertos no site da OMG, sem cadastro.
Quais são os cinco grupos de elementos do BPMN?
A especificação explica por que agrupa os símbolos: o BPMN precisava ser simples de ler e, ao mesmo tempo, dar conta da complexidade real dos processos. A solução foi organizar a notação em poucas categorias básicas, para que o leitor reconheça o tipo de cada elemento de relance, e permitir variações dentro de cada categoria sem mudar o aspecto geral do diagrama.
Objetos de fluxo: eventos, atividades e gateways
São os elementos principais, os que definem o comportamento do processo. Eventos (círculos) são algo que acontece: o início, um ponto intermediário, o fim. Atividades (retângulos de cantos arredondados) são o trabalho feito, como tarefa ou subprocesso. Gateways (losangos) controlam onde os caminhos se dividem e se juntam.
Dados: objetos, entradas, saídas e repositórios
O grupo dos dados tem quatro elementos. O objeto de dados mostra a informação que uma atividade exige ou produz, como um pedido ou uma nota. Entrada e saída de dados fazem o mesmo para o processo como um todo, e o repositório de dados representa onde a informação fica guardada além da duração do processo, como um banco ou um sistema.
Objetos de conexão: os quatro tipos de linha
São quatro formas de ligar os elementos. O fluxo de sequência (linha cheia) mostra a ordem das atividades. O fluxo de mensagem (linha tracejada) mostra a troca de mensagens entre dois participantes. A associação liga anotações e artefatos aos elementos, e a associação de dados liga os dados às atividades.
Raias: pools e lanes
A pool é a representação de um participante, como uma empresa, um cliente ou um fornecedor. A lane é uma subdivisão dentro do processo, normalmente dentro de uma pool, usada para organizar e categorizar as atividades, por área ou por papel. Uma pool pode até ficar vazia por dentro, como "caixa-preta", quando importa só a conversa com ela.
Artefatos: grupo e anotação de texto
Os artefatos acrescentam informação sem alterar o fluxo. A especificação padroniza dois: o grupo, uma moldura que reúne elementos da mesma categoria sem mexer nas sequências, e a anotação de texto, um comentário ligado a um elemento por associação. O texto deixa a porta aberta para que ferramentas acrescentem outros artefatos.
Por que tantos tutoriais falam em quatro grupos?
Boa parte do material em português apresenta a notação em quatro famílias: objetos de fluxo, conexões, raias e artefatos. Nessa versão, o objeto de dados aparece encaixado entre os artefatos. A especificação BPMN 2.0.2, porém, trata os dados como categoria própria, com quatro elementos, e é ela a referência que vale.
A diferença não é preciosismo. Na versão vigente, entradas, saídas e associações de dados têm significado na execução: são o que o motor de workflow usa para levar a informação de uma tarefa à próxima. Quem aprende que "dado é só um enfeite no desenho" costuma descobrir o contrário na hora de automatizar.
Vale um cuidado oposto também: a especificação diz que o BPMN mostra o fluxo de dados e a associação de dados às atividades, mas não é uma linguagem de fluxo de dados. Modelos de dados e de informação, aliás, estão listados entre os assuntos fora do escopo do padrão.
Qual a diferença entre BPMN e fluxograma?
A própria especificação diz que o BPMN segue a tradição dos fluxogramas em legibilidade e flexibilidade. A diferença está no que vem junto: símbolos com significado único, regras de conexão e uma semântica de execução formalizada.
| Fluxograma livre | BPMN 2.0.2 | |
|---|---|---|
| Quem define os símbolos | Quem desenha, ou o costume da equipe | A especificação da OMG, igual para todos |
| Quem faz cada etapa | Às vezes indicado no texto | Pools e lanes, como elemento da notação |
| Troca entre empresas | Sem forma própria | Fluxo de mensagem entre participantes |
| Dados do processo | Desenho opcional | Categoria própria, com entradas e saídas |
| Arquivo | Imagem ou formato do editor | XML com esquema público, que outra ferramenta abre |
| Execução | Não se aplica | Semântica de execução formal e nível Executável Comum |
Comparativo elaborado pela Alliance Comunicação com base na especificação BPMN 2.0.2 (OMG, 2014).
Se o objetivo é só explicar a ideia de um processo numa reunião, um fluxograma resolve. Quando o desenho vai circular entre áreas, virar documentação oficial ou alimentar uma automação, a padronização do BPMN começa a pagar o esforço.
Qual a diferença entre BPMN, BPM e BPMS?
As três siglas aparecem juntas e são coisas distintas. BPM (Business Process Management) é a disciplina de gestão: identificar, desenhar, executar, medir e melhorar processos. BPMN é a notação, a linguagem visual usada na etapa de desenho. BPMS é o sistema, o software que executa e monitora os processos.
Uma comparação ajuda: BPM é a prática da gestão, BPMN é a planta do processo e o BPMS é a obra funcionando. A especificação deixa claro que simulação, monitoramento e implantação ficam fora do seu escopo. O BPMN descreve o processo e quem roda é o software.
Para quem está começando, a ordem costuma ser esta: primeiro mapear o processo como ele acontece, depois escolher a notação e só então decidir o sistema. Comprar o BPMS antes de ter o mapa é o caminho mais caro.
Como funciona um diagrama BPMN por dentro?
Para explicar o comportamento do processo, a especificação usa a ideia de token, uma ficha imaginária que percorre os fluxos de sequência. O evento de início gera o token, que passa pelas atividades e gateways até ser consumido num evento de fim. Se você consegue seguir a ficha do começo ao fim, o diagrama está coerente.
O token só anda pelo fluxo de sequência. Entre duas pools, o que circula é uma mensagem, pelo fluxo de mensagem, e é por isso que, pela especificação, o fluxo de sequência não pode cruzar a fronteira de uma pool. Essa regra resolve um erro clássico: desenhar a empresa e o cliente como se fossem uma única sequência de tarefas.
Os gateways definem o que acontece com o token nas bifurcações. A especificação define cinco tipos: exclusivo (só um caminho segue), inclusivo (um ou mais caminhos), paralelo (todos os caminhos ao mesmo tempo), baseado em evento (segue o caminho do evento que acontecer primeiro, como a chegada de uma mensagem) e complexo, para sincronizações que os outros não cobrem, como seguir adiante quando três de cinco caminhos chegarem.
As tarefas também têm tipo. A tarefa de serviço chama um serviço automatizado, a de usuário vai para uma pessoa num sistema, a de envio e a de recebimento trocam mensagens, a de script roda um script e a de regra de negócio chama uma regra. A tarefa manual e a tarefa sem tipo, diz a especificação, são só conceituais e nunca são executadas por um sistema.
Que nível de detalhe o seu diagrama precisa ter?
Este é o ponto que os catálogos de símbolos costumam pular. A especificação não exige que toda ferramenta ou todo modelo use o padrão inteiro: como alternativa à conformidade completa de modelagem, ela define três subclasses, cada uma com uma lista fechada de elementos e atributos.
O Descritivo já inclui bastante coisa: pools e lanes, tarefas simples, de usuário e de serviço, subprocessos, gateways exclusivo e paralelo, objetos de dados, anotações e eventos de início e fim, incluindo os de mensagem e o início por tempo. O Analítico acrescenta fluxos condicionais e padrão, tarefas de envio e recebimento, laços, multi-instância e os gateways inclusivo e baseado em evento.
O Executável Comum é outra conversa. Ele foi pensado para ferramentas que emitem modelos executáveis e fixa as linguagens: tipos de dados em XML Schema, interfaces de serviço em WSDL e acesso a dados em XPath. É aqui que o desenho deixa de ser figura e vira instrução para uma máquina.
| Uso do diagrama | Nível que basta | O que não pode faltar |
|---|---|---|
| Explicar o processo a um cliente ou à diretoria | Descritivo | Início, fim, tarefas com nome claro e quem faz cada uma |
| Manual de procedimento e treinamento | Descritivo | Lanes por área e decisões nomeadas |
| Encontrar gargalo, retrabalho e exceção | Analítico | Condições nos caminhos, laços e eventos intermediários |
| Integração com parceiro ou fornecedor | Analítico | Pools separadas e fluxo de mensagem |
| Rodar num motor de workflow | Executável Comum | Dados tipados, serviços definidos e tarefas com tipo |
Elaborado pela Alliance Comunicação a partir das subclasses de conformidade da cláusula 2.2 da especificação BPMN 2.0.2.
A regra prática: desenhe no nível mais baixo que resolve o uso. Um diagrama executável apresentado à diretoria afoga a mensagem em detalhe técnico; um descritivo entregue à TI como "especificação" vai voltar com perguntas.
Como fazer um diagrama BPMN na prática?
O caminho abaixo vale para qualquer ferramenta. Ele parte do processo real e acrescenta detalhe só quando o uso pede.
1. Defina o começo, o fim e o dono
Escreva em uma frase o que dispara o processo e qual resultado o encerra, por exemplo "pedido recebido" e "pedido entregue". Esses são o evento de início e o de fim. Diga também quem responde pelo processo, porque é essa pessoa que vai validar o desenho.
2. Separe os participantes e as áreas
Cada empresa ou parte externa vira uma pool; cada área ou papel interno vira uma lane. Se o cliente participa, ele ganha a pool dele, e a conversa entre vocês passa a ser fluxo de mensagem, não sequência.
3. Desenhe o caminho feliz primeiro
Coloque em sequência as atividades do caso que dá certo, com nomes no formato verbo mais objeto: "aprovar orçamento", "emitir nota". Só depois de esse caminho estar validado é que entram as exceções.
4. Acrescente decisões, exceções e dados
Cada "depende" vira um gateway com a condição escrita em cada saída. Prazos viram eventos de tempo, mensagens esperadas viram eventos de mensagem. Onde uma tarefa precisa de um documento ou gera um registro, desenhe o objeto ou o repositório de dados.
5. Siga o token e valide com quem executa
Percorra o diagrama como se fosse a ficha da especificação: todo caminho chega a um fim? Algum gateway paralelo abre caminhos que nunca se juntam? Depois, mostre a quem faz o trabalho no dia a dia. É quem executa que aponta a etapa que o desenho esqueceu.
Quais os erros mais comuns ao modelar em BPMN?
- Usar fluxo de sequência entre pools. Entre participantes diferentes, o que passa é mensagem.
- Gateway sem condição escrita. Um losango com três saídas sem rótulo obriga o leitor a adivinhar a regra.
- Desenhar o organograma em vez do processo. Lanes organizam atividades; modelos organizacionais estão fora do escopo do BPMN, segundo a própria especificação.
- Colocar regra de negócio inteira dentro do diagrama. Uma cascata de gateways para calcular desconto ou crédito vira um labirinto; modelos de regras de negócio também ficam fora do escopo do padrão, e a tarefa de regra de negócio existe justamente para chamar a regra de fora.
- Misturar níveis de detalhe. Metade do diagrama com tarefas genéricas e metade com atributos técnicos não serve nem à diretoria nem à TI.
- Modelar o processo ideal e não o real. O diagrama bonito que ninguém segue não ajuda a melhorar nem a automatizar.
Como escolher uma ferramenta BPMN?
Não existe "a melhor ferramenta BPMN" em abstrato; existe a que serve ao nível de detalhe que você precisa. Para documentar e treinar, qualquer editor que respeite os símbolos padronizados resolve. Para automatizar, a pergunta muda: a ferramenta precisa gerar ou importar um modelo que um motor consiga executar.
O critério mais importante é a portabilidade. A especificação define um formato de intercâmbio para levar definições de processo, o modelo e o desenho, de uma ferramenta a outra, e a OMG publica o esquema XML correspondente. Antes de adotar um editor, teste exportar um diagrama em XML BPMN e abrir em outro programa. Se o arquivo só abre onde nasceu, o seu mapa fica preso ao fornecedor.
Do lado da execução, plataformas de automação já aceitam BPMN diretamente. Na documentação do plano Community da UiPath, por exemplo, o Maestro, módulo de orquestração, suporta Flow, BPMN e Case Management, com limite mensal de execuções. É o tipo de ambiente em que o nível Executável Comum deixa de ser teoria.
- O editor usa os símbolos da especificação, sem atalhos próprios?
- Exporta e importa XML BPMN 2.0 sem perder lanes, dados e anotações?
- Diz qual subclasse de conformidade suporta: Descritiva, Analítica ou Executável Comum?
- Se a meta é automatizar, conversa com o motor de workflow que você pretende usar?
- Quem vai manter os diagramas consegue usá-lo sem depender de um especialista?
Quando vale levar o BPMN até a automação?
Nem todo processo precisa chegar ao nível executável. Vale o esforço quando o processo se repete muito, tem regras estáveis, passa por vários sistemas e hoje depende de alguém lembrar de cobrar a próxima etapa. É o caso clássico da etapa de workflow que fica esperando alguém agir.
Quando o processo muda toda semana ou depende de julgamento caso a caso, o nível descritivo, bem feito, já entrega muito: alinha a equipe, mostra o gargalo e prepara o terreno. A decisão sobre o que vale automatizar vem antes da notação, não depois.
Na Alliance, o trabalho de automação de processos começa exatamente por esse mapa: desenhar o processo real, decidir o que fica com pessoas e o que vai para o sistema, e só então construir o fluxo automatizado.
Por onde começar hoje
Escolha um processo que incomoda, com começo e fim claros, e desenhe-o no nível Descritivo: eventos de início e fim, lanes por área, tarefas com verbo e decisões com condição. Mostre a quem executa e corrija. Esse diagrama já responde à pergunta mais útil: onde o trabalho para e espera.
Se a resposta apontar gargalos que se repetem, aí sim vale subir o nível e pensar em execução. E se você quer entender onde processos e automação entram no conjunto do seu marketing e da sua operação, o diagnóstico gratuito de marketing mostra a maturidade da empresa em tecnologia e automação ao lado das outras dimensões.