BPMN (notação de modelagem de processos)

A sigla vem de Business Process Model and Notation, modelo e notação de processos de negócio. A notação é mantida pela OMG, um consórcio internacional de padrões, e também foi publicada como norma ISO. Por ser padrão, qualquer pessoa treinada lê o desenho do mesmo jeito, seja analista de processos, gestor da área ou desenvolvedor.

Os símbolos se dividem em quatro grupos. Os objetos de fluxo são o centro: a atividade, um retângulo de cantos arredondados, é o trabalho feito; o evento, um círculo, é algo que acontece, como o início, o fim ou a chegada de uma mensagem; e o gateway, um losango, é o ponto de decisão ou de divisão do caminho. Os objetos de conexão são as setas, que mostram a sequência e a troca de mensagens. As piscinas e raias separam quem executa: a piscina representa um participante, como a empresa ou o cliente, e cada raia dentro dela, uma área ou função. E os artefatos, como anotação e documento, acrescentam informação sem mudar o fluxo.

Um exemplo simples é a aprovação de compra. O processo começa com o evento de requisição recebida. A atividade seguinte é conferir o pedido, na raia de compras. Um gateway pergunta se o valor está acima da alçada: se não, segue direto para a cotação; se sim, desvia para a raia da diretoria, onde a atividade é aprovar ou recusar. A recusa devolve a requisição ao solicitante com o motivo, e o fluxo termina num evento de fim. Mesmo nesse desenho curto aparecem as perguntas que importam: quem aprova quando o diretor está de férias, quanto tempo a aprovação pode esperar, o que acontece com a compra urgente.

O valor não está no diagrama, está na conversa que ele obriga. Para desenhar o processo é preciso responder o que acontece quando o pedido chega incompleto, quem aprova acima de certo limite, o que se faz quando o cliente não responde. Muita empresa descobre ali que cada área executa uma versão diferente do mesmo processo.

Há níveis de detalhe para públicos diferentes. O desenho descritivo, com poucos símbolos, serve para a diretoria e para alinhar as áreas. O analítico inclui exceções, eventos de tempo e mensagens, e serve para quem vai redesenhar ou automatizar. O executável traz cada detalhe técnico que um motor de processos precisa para rodar o diagrama. Querer o nível executável na primeira conversa com a operação trava o mapeamento; ficar no descritivo quando o objetivo é automatizar deixa a especificação pela metade.

Também vale separar o processo como ele é do processo como deveria ser. O primeiro desenho registra a realidade, com o retrabalho, a planilha paralela e a aprovação por mensagem. O segundo é a proposta, e só faz sentido depois do primeiro. Pular direto para o processo ideal produz um diagrama bonito que ninguém reconhece e que a operação ignora.

Onde quebra: o desenho feito uma vez, para um projeto, e nunca mais atualizado. Em poucos meses ele descreve um processo que não existe, e quem consulta toma decisão errada com base nele. Outro erro frequente é desenhar só o caminho feliz e deixar as exceções de fora, que é onde mora o trabalho manual.

Quando o processo vai ser automatizado, o desenho em BPMN é a especificação. Algumas plataformas executam o diagrama diretamente; mesmo quando não, ele é o documento que diz o que o sistema precisa fazer e o que continua com pessoas, e é contra ele que a homologação confere o resultado.

Os erros de desenho são fáceis de reconhecer. Um diagrama com dezenas de atividades numa folha só, que ninguém consegue ler, quando o certo seria quebrar em subprocessos. Gateway sem rótulo, em que não se sabe qual pergunta está sendo respondida. Atividade com nome de área no lugar de verbo, como "financeiro", quando deveria ser "conferir a nota". E raia que não corresponde a ninguém de verdade, o que esconde quem responde pela etapa.