Guia BPMN com Visual Paradigm

1. O que é BPMN

Modelagem e Notação de Processos de Negócio (BPMN)é uma linguagem visual padronizada para descrever como o trabalho flui através de um processo. Ajuda partes interessadas de negócios, analistas e equipes técnicas a discutir o mesmo fluxo de trabalho usando símbolos consistentes. O BPMN é mantido pelo Object Management Group; o BPMN 2.0.2 é publicado como ISO/IEC 19510.

Um diagrama BPMN é mais do que um fluxograma: seus símbolos têm significados definidos, e suas regras de conexão distinguem o fluxo do processo das mensagens entre participantes. Um modelo útil pode documentar o processo atual (“as-is”), esclarecer um processo proposto (“to-be”) e ajudar as equipes a identificar atrasos, transferências, retrabalho ou caminhos de exceção ausentes.

2. Conceitos fundamentais do BPMN

Os principais blocos de construção do BPMN são objetos de fluxo, objetos de conexão, raias, dados e artefatos.

Eventos

O contorno e o marcador de um evento transmitem seu papel e gatilho:

• Evento de início:inicia um caminho de processo.

• Evento intermediário:ocorre durante o processo — por exemplo, uma mensagem recebida ou um temporizador expirando.

• Evento de término:encerra um caminho. Diferentes tipos de eventos de término podem indicar diferentes resultados, como uma conclusão normal ou um erro.

• Evento de fronteira:anexado a uma atividade ou subprocesso para mostrar um evento que pode interrompê-lo ou afetá-lo, como um tempo limite.

Use um evento de mensagemquando o processo responde a uma comunicação, e um evento de temporizadorquando o tempo faz parte da regra do processo, como um prazo.

Atividades

Nomeie as atividades com um verbo + objeto, como “Verificar estoque”, “Aprovar pagamento” ou “Enviar confirmação”. Use:

• Tarefapara uma única etapa.

• Subprocessoquando uma etapa tem detalhes suficientes para ser modelada separadamente.

• Atividade de chamadaao reutilizar um processo definido globalmente, se sua abordagem de modelagem permitir.

Marcadores de tarefa comuns podem especificar o tipo de trabalho, como realizado pelo usuário, manual ou automatizado. Adicione esse detalhe apenas quando ajudar os leitores ou a implementação.

Portões

Escolha um portão com base na lógica do processo — não apenas na forma que deseja desenhar:

• Exclusivo (XOR): segue um dos caminhos de saída. Exemplo: “Em estoque?” → Sim ou Não.

• Paralelo (AND): inicia todos os caminhos de saída; um join correspondente pode aguardar todos os caminhos necessários.

• Inclusivo (OR): segue um ou mais caminhos de saída, dependendo das condições.

• Baseado em eventos: o próximo caminho é determinado pelo evento que ocorre primeiro, como uma resposta de pagamento ou um tempo limite.

Rotule os fluxos de decisão de saída com condições, como Sim / Não ou Aprovado / Recusado. Quando um portão divide um fluxo, deixe a lógica de junção clara. Uma junção exclusiva reúne caminhos alternativos; um join paralelo sincroniza caminhos que foram iniciados em paralelo.

Conectando objetos e pools

Um fluxo de sequência mostra a ordem do processo e normalmente permanece dentro de um único pool. Um fluxo de mensagem mostra a comunicação entre pools separados — por exemplo, um cliente enviando um pedido a uma empresa. Não use um fluxo de mensagem para mostrar a próxima tarefa interna, nem um fluxo de sequência para representar a comunicação entre participantes distintos.

Pools podem representar participantes independentes, como um cliente, uma empresa e um provedor de pagamento. Faixas dentro de um pool mostram funções ou departamentos. Mantenha os limites de responsabilidade significativos: uma faixa deve esclarecer quem realiza o trabalho, não apenas decorar o diagrama.

3. Um fluxo de trabalho prático de modelagem

1. Defina o escopo. Declare o gatilho, o resultado e os limites do processo. Por exemplo: “Do recebimento de um pedido à confirmação do envio.”

2. Identifique os participantes e as funções. Decida quais participantes precisam de pools separados e quais responsabilidades pertencem às faixas.

3. Descreva o caminho feliz. Liste as etapas comuns em ordem antes de adicionar portões e caminhos de exceção.

4. Adicione eventos e decisões.Mostre gatilhos significativos, resultados, regras de negócio e caminhos alternativos.

5. Adicione transferências de tarefas e dados.Marque as comunicações entre participantes e as informações necessárias ou produzidas, quando isso melhorar a compreensão.

6. Verifique a completude.Rastreie cada caminho de um início até um fim. Confirme que as portas de decisão têm condições compreensíveis e que os caminhos de exceção não desaparecem de forma ambígua.

7. Revise com os usuários do processo.Valide o modelo com as pessoas que executam ou recebem o trabalho. Revise-o quando diferir da prática real.

8. Mantenha o diagrama legível.Use nomenclatura consistente, minimize linhas cruzadas e mova subprocessos detalhados para diagramas separados quando necessário.

Comece com um modelo que responda à questão de negócio. Adicionar todos os símbolos BPMN ou detalhes de implementação de uma só vez frequentemente torna o diagrama mais difícil de revisar.

4. Exemplo: atendimento de pedido online

Escopo:Da submissão do pedido pelo cliente até a confirmação do envio. Este exemplo foca no processo da empresa e usa uma piscina separada para o cliente, mostrando o pedido de entrada e a confirmação de saída.

Narrativa do processo

1. O cliente submete um pedido.

2. A empresa recebe o pedido e verifica o estoque.

3. Se um item não estiver disponível, a empresa notifica o cliente e encerra esse caminho de pedido.

4. Se o item estiver disponível, a empresa processa o pagamento.

5. Se o pagamento for recusado, a empresa notifica o cliente e encerra esse caminho.

6. Se o pagamento for aprovado, o armazém separa e embala o pedido.

7. A empresa entrega o pacote ao transportador e envia uma confirmação de envio.

Diagrama de texto

Piscina do cliente:
(Início) → Submeter pedido ──mensagem──▶

Piscina da empresa:
(Início por mensagem: pedido recebido)
  → Verificar estoque
  → XOR: Em estoque?
      Não  → Notificar cliente: indisponível → (Fim)
      Sim → Processar pagamento
             → XOR: Pagamento aprovado?
                 Não  → Notificar cliente: pagamento recusado → (Fim)
                 Sim → Separar e embalar pedido
                         → Entregar pacote ao transportador
                         → Enviar confirmação de envio ──mensagem──▶ Cliente
                         → (Fim)

Código PlantUML personalizado para BPMN (Apenas suportado pelo Editor VPasCode)

@startuml
title Diagrama de Processo de Negócio de Atendimento de Pedido
<style>
    element { MaximumWidth 160 }
    start   { Backgroundcolor #00695C }
    stop    { Backgroundcolor #C2185B }
    activity{ Backgroundcolor #81D4FA; MaximumWidth 150 }
    diamond { Backgroundcolor #FFB74D; MaximumWidth 80 }
    arrow   { LineColor #424242; Fontcolor #000000 }
    swimlane{ Fontcolor #000000; FontSize 14 }
</style>

|#F0F8FF|Cliente|
start
:<<SendTask>>
Submeter pedido;

|#E8F5E9|Empresa|
:<<ReceiveTask>>
Pedido recebido;
:<<UserTask>>
Verificar estoque;
if (Em estoque?) then (sim)
  :<<ServiceTask>>
  Processar pagamento;
  if (Pagamento aprovado?) then (sim)
    :<<ManualTask>>
    Separar e embalar pedido;
    :<<SendTask>>
    Entregar pacote ao transportador;
    :<<SendTask>>
    Enviar confirmação de envio;
  else (não)
    :<<SendTask>>
    Notificar cliente: pagamento recusado;
  endif
else (não)
  :<<SendTask>>
  Notificar cliente: indisponível;
endif
stop
@enduml

Use fluxos de sequência para as etapas internas da empresa e fluxos de mensagem entre as pools do Cliente e da Empresa. Rotule os fluxos de saída de cada porta XOR com suas condições. No Visual Paradigm, as perguntas “Em estoque?” e “Pagamento aprovado?” podem ser colocadas como rótulos da porta, enquanto as setas de saída carregam “Sim” e “Não.”

Possíveis extensões: Adicione um evento de limite de temporizador ao processamento de pagamento se a empresa tiver um prazo de pagamento; adicione um caminho de exceção para falha na entrega ao transportador; ou modele a separação e embalagem como um subprocesso se precisar de seu próprio fluxo de trabalho detalhado.

5. Construindo o modelo no Visual Paradigm

O Visual Paradigm oferece uma ferramenta de modelagem BPMN 2.0 e suporta a exploração de subprocessos, de modo que um processo de alto nível pode ser vinculado a um diagrama de processo mais detalhado. Suas funcionalidades BPMN também incluem a documentação de procedimentos de trabalho e a modelagem de processos ‘como está’ e ‘como deve ser’.

Uma sequência prática de construção:

1. Crie um Diagrama de Processo de Negócio BPMN no Visual Paradigm.

2. Adicione uma pool do Cliente e uma pool da Empresa; divida a pool da Empresa em faixas como Atendimento ao Cliente, Armazém e Expedição, se essas responsabilidades forem relevantes.

3. Posicione o evento de início e as atividades, em seguida, adicione as portas de estoque e pagamento.

4. Desenhe fluxos de sequência dentro da pool da Empresa; use fluxos de mensagem para trocas com o Cliente.

5. Rotule tarefas e caminhos condicionais em linguagem simples. Adicione objetos de dados, como um Pedido ou Resultado de Pagamento, apenas onde ajudem os leitores a entender o processo.

6. Organize o diagrama de modo que o fluxo principal seja lido de forma consistente — frequentemente da esquerda para a direita — e minimize conectores cruzados.

7. Revise o diagrama com as partes interessadas. Se os detalhes de uma etapa obscurecerem o caminho principal, considere colocar esses detalhes em um diagrama de subprocesso.

8. Salve e compartilhe o modelo no formato e no espaço de trabalho adequados para sua equipe.

O Visual Paradigm anuncia modelagem de diagramas BPMN, exploração de processos, documentação de procedimentos de trabalho e modelagem ‘como está’/’como deve ser’. A disponibilidade de funcionalidades específicas pode depender da edição.

6. Erros comuns de modelagem

• Usar o conector errado: O fluxo de sequência é a ordem interna do processo; o fluxo de mensagem é a comunicação entre participantes.

• Usar uma porta sem lógica clara: rotule a decisão e suas condições de saída.

• Tratar cada ação como uma piscina separada: use faixas para responsabilidades dentro de um único participante; use piscinas separadas para participantes distintos.

• Deixar os caminhos pouco claros: mostre o que ocorre em caso de recusas, expirações de tempo, informações ausentes e outras exceções relevantes.

• Sobrecarregar um único diagrama: use subprocessos para separar o trabalho detalhado da visão geral.

• Modelar o ideal em vez da realidade: documente o processo atual com precisão antes de propor melhorias.

• Adicionar detalhes sem propósito: inclua dados, eventos e marcadores de tarefa quando eles responderem a uma pergunta de modelagem ou revisão.

7. Lista de verificação rápida de revisão

• O diagrama tem um início e um fim claros para cada caminho relevante?

• Um leitor pode identificar quem executa cada atividade?

• As decisões e as condições de saída estão explícitas?

• Os fluxos de sequência e os fluxos de mensagem estão sendo usados de forma adequada?

• As exceções e os resultados alternativos estão representados?

• O diagrama é legível no tamanho de visualização pretendido?

• As pessoas que executam o processo confirmaram que ele é preciso?