Fluxograma de processos: o mapa ficou pronto e a operação continuou igual

Fluxograma de processos é o entregável que mais sai bonito e menos muda a operação. A empresa contrata a consultoria ou trava três manhãs do time, o mapa fica pronto, alguém imprime em A3, cola na parede da sala de reunião. Seis meses depois o papel continua lá, amarelando, e o pedido do cliente segue passando pelos mesmos quatro retrabalhos de sempre.

Trabalhei trinta anos em indústria e vi esse ciclo se repetir em empresa de doze pessoas e em planta de oitocentas. O diagnóstico fácil é dizer que faltou disciplina para seguir o mapa. Na maior parte das vezes não é isso. É que o mapa foi desenhado grande demais, longe demais de onde o trabalho acontece, e para responder à pergunta errada.

Este artigo é sobre como mapear de um jeito que sobreviva ao contato com a operação, e sobre o que a pesquisa empírica em modelagem de processos já observou a respeito de tamanho, erro e compreensão. Tem um achado nessa literatura que contraria o instinto de quase todo dono de PME: quanto maior o mapa, maior a chance de ele conter erro de construção. Não mais confiável, apenas maior.

O que é um fluxograma de processos, e o que ele não é

Um fluxograma de processos é a representação gráfica de um processo: o gatilho que o inicia, a sequência de atividades, os pontos onde alguém decide, quem executa cada parte e o resultado que sai na ponta. Na prática de chão de fábrica e de escritório, ele serve para três coisas: alinhar o entendimento entre pessoas que fazem partes diferentes do mesmo trabalho, achar onde a peça ou o documento para, e decidir o que mudar.

O que ele não é, e é aqui que a PME costuma se perder:

• Não é documentação. Documentação é subproduto. Se o objetivo declarado do mapeamento é “documentar os processos”, o projeto já nasceu sem critério de parada, porque sempre há mais a documentar.
• Não é prova de que o processo é bom. Um processo ruim desenhado com capricho continua ruim, agora com diagrama.
• Não é o processo. É a descrição de alguém sobre o processo. A diferença entre as duas coisas é o assunto da próxima seção.
• Não é requisito de sistema. Fluxograma ajuda a especificar, mas mapear tudo antes de escolher ferramenta é a receita para automatizar o desperdício mais rápido.

Vale separar dois níveis, porque misturá-los é a causa mais comum de mapa inutilizável. O macroprocesso mostra a cadeia inteira em poucas caixas, do pedido à entrega, e serve para conversar com a diretoria. O processo detalha uma dessas caixas até o nível em que dá para agir. Quem tenta fazer os dois no mesmo desenho produz o pôster de A3 que ninguém lê.

O primeiro erro: mapear na sala de reunião

O mapeamento típico acontece assim. Junta-se o time numa sala, alguém pergunta “como funciona o processo de compras?”, e a pessoa mais antiga descreve. O desenho vai para o quadro. Todo mundo concorda. O mapa é digitalizado.

O problema é que ninguém descreveu o processo. Descreveram o processo como deveria ser, que é a versão que a pessoa lembra da última vez que alguém perguntou, filtrada pelo constrangimento de admitir os atalhos que ela usa todo dia porque o processo oficial não funciona. Os retrabalhos, as exceções combinadas por WhatsApp, o formulário que é preenchido depois porque o cliente estava com pressa, nada disso entra no quadro. E é exatamente aí que mora o problema que motivou o mapeamento.

A correção é barata e quase ninguém faz: vá até onde o trabalho acontece e acompanhe uma unidade real do começo ao fim. Um pedido. Uma nota. Um chamado. Ande com ele. Anote os horários, as esperas, quem toca, quantas vezes volta. Depois compare com o que foi descrito na sala. A distância entre as duas versões costuma ser o mapa que interessa.

Na indústria isso tem nome antigo e é o mesmo princípio por trás da fase de medição do Six Sigma: não se discute causa com opinião quando dá para observar o fato. Numa PME, acompanhar três pedidos do início ao fim leva menos tempo do que a reunião que teria sido marcada para debater o assunto.

Por que o mapa grande é o que tem mais chance de conter erro de construção

Aqui entra a parte que quase nunca aparece em conteúdo sobre fluxograma, e que muda a decisão de escopo.

Jan Mendling, Hajo Reijers e Wil van der Aalst publicaram em 2010, na Information and Software Technology, uma síntese da pesquisa empírica sobre a relação entre a estrutura de um modelo de processo, a probabilidade de erro e a compreensão. Dela saíram sete diretrizes, conhecidas pela sigla 7PMG. A primeira delas é direta: use o menor número possível de elementos no modelo. A justificativa que os autores registram é que o tamanho do modelo tem efeitos indesejáveis sobre a compreensão e sobre a probabilidade de erro, porque modelos maiores tendem a ser mais difíceis de entender e a apresentar probabilidade de erro maior que modelos pequenos.

A sétima diretriz coloca um número nisso. Os autores recomendam decompor o modelo quando ele passa de 50 elementos e relatam, com base na literatura empírica que sintetizam, que acima desse tamanho a probabilidade de erro tende a passar de 50%.

Convém ler essa frase devagar, porque ela é contraintuitiva. A intuição do dono de PME é que o mapa grande é o mapa completo, e que o mapa pequeno é o resumo. O que a literatura sintetizada em 7PMG indica é outra coisa: passado certo tamanho, a chance de o modelo conter um erro de construção fica maior que a chance de não conter. O pôster de A3 na parede até pode ser o mais completo, mas é também o que tem maior probabilidade de conter erro de construção.

Duas ressalvas de honestidade, porque elas mudam o peso do argumento:

• O 7PMG é uma síntese. A cifra dos 50 elementos vem de estudo anterior que os autores citam, e não de medição própria feita naquele artigo.
• Na nossa leitura, “erro” ali é erro de construção do modelo, o tipo que ferramenta de verificação detecta, como caminho que não fecha ou fluxo que trava. Não é a mesma coisa que “o mapa não corresponde à realidade”. São dois problemas distintos, e o segundo a pesquisa de estrutura não trata.

Ainda assim, a implicação prática para a PME é clara, e por experiência nós a estendemos também ao descompasso entre mapa e realidade: mapeie um processo por vez, no menor recorte que ainda responda à pergunta que motivou o mapeamento. Se o mapa está crescendo, quebre em subprocessos com entrada e saída únicas em vez de continuar acrescentando caixa.

Os símbolos que bastam para uma PME

Existe notação formal para isso, o BPMN, com dezenas de símbolos. Numa PME que está mapeando pela primeira vez, cinco resolvem quase tudo. Na nossa experiência, acrescentar símbolo antes de precisar dele só aumenta o custo de leitura de quem vai usar o mapa.

Símbolo	O que representa	Regra de uso
Oval (início e fim)	O gatilho que dispara o processo e o resultado que o encerra	Um de cada, sempre. Se aparecerem vários inícios, provavelmente são processos diferentes
Retângulo	Atividade: alguém faz alguma coisa	Nome no formato verbo mais objeto: “emitir nota”, “conferir pedido”
Losango	Decisão, com saídas rotuladas	Rotule as saídas (“sim” e “não”, “aprovado” e “reprovado”). Losango sem rótulo é armadilha
Seta	Sequência: o que vem depois do quê	Uma direção só no desenho inteiro, da esquerda para a direita ou de cima para baixo
Raia (faixa horizontal)	Quem é o responsável por aquele trecho	Uma raia por papel, não por pessoa. Papel sobrevive à rotatividade

A regra do nome da atividade não é preciosismo. No 7PMG, a sexta diretriz trata justamente de rótulo, e os autores registram que as pessoas consideram o estilo verbo mais objeto, do tipo “informar reclamante”, significativamente menos ambíguo e mais útil que rótulos em forma de substantivo de ação, do tipo “análise da reclamação”. Numa PME isso aparece na hora de atribuir responsabilidade: “conferência de pedido” não diz qual é a ação nem quando ela termina. “Conferir pedido” diz, e o responsável vem da raia.

Como mapear em seis passos

Este é o roteiro que uso quando a empresa não tem área de processos e não vai contratar uma. Ele cabe em uma semana de trabalho parcial de duas pessoas.

1. 1. Escolher a dor

   Um processo só, o que está custando dinheiro ou cliente agora. Não a lista inteira

2. 2. Fixar as bordas

   Qual evento inicia e qual resultado encerra. Sem isso o mapa cresce sem parar

3. 3. Seguir uma unidade real

   Acompanhar um pedido de verdade do começo ao fim, anotando esperas e retornos

4. 4. Desenhar o que existe

   Inclusive os atalhos e as exceções. O mapa do processo ideal não serve para diagnóstico

5. 5. Validar com quem executa

   Quem faz aponta o que faltou. Quem só supervisiona valida a versão oficial, não a real

6. 6. Marcar as decisões

   Onde parou, onde voltou, onde esperou. São esses três pontos que viram plano de ação

Duas observações sobre o passo 4, que é onde a maioria trava. Desenhar o que existe expõe combinações informais que às vezes constrangem quem as criou. Se o clima da empresa faz com que admitir um atalho vire problema para quem admitiu, o mapa vai sair mentiroso, e nenhuma técnica de desenho corrige isso. É um assunto de cultura antes de ser de método.

A segunda: resista a corrigir enquanto desenha. Toda vez que alguém diz “mas isso deveria ser feito de outro jeito”, anote em separado e continue. Misturar diagnóstico com solução no mesmo desenho produz um mapa que não descreve nem o processo atual nem o futuro.

As sete regras de desenho, e como profissionais as priorizam

O 7PMG reúne sete diretrizes. Elas tratam de forma, não de conteúdo, e isso importa para saber o que esperar delas.

Diretriz	O que diz
G1	Use o menor número possível de elementos
G2	Minimize os caminhos de roteamento por elemento
G3	Use um único evento de início e um único de fim
G4	Modele de forma tão estruturada quanto possível
G5	Evite elementos de roteamento do tipo OR
G6	Use rótulos de atividade no formato verbo mais objeto
G7	Decomponha o modelo se ele tiver mais de 50 elementos

O artigo não parou nas diretrizes. Os autores levaram as sete a dois workshops com modeladores profissionais, 7 de uma comunidade de prática alemã e 14 da operação holandesa de uma grande consultoria, 21 ao todo, com 5 anos de experiência em média e mais de 50 modelos criados no período. Cada participante atribuiu postos de 1 a 7 conforme o potencial percebido de melhorar a compreensão de um modelo, podendo repetir posições, com a soma dos postos de cada participante sempre igual a 28, e os postos foram somados por diretriz.

Duas leituras práticas saem daí. A primeira: as duas diretrizes mais bem colocadas foram modelar de forma estruturada (G4) e decompor acima de 50 elementos (G7), as duas que tratam de organizar em vez de acrescentar. A segunda: a pior colocada foi evitar conectores do tipo OR (G5), o que sugere que os profissionais viam ali menos ganho de compreensão do que nas demais. É preciso dizer o que isso é e o que não é: é uma ordenação de percepção de 21 profissionais, não uma medição de compreensão de leitores. Serve para desempatar quando duas diretrizes conflitam, e esse é o uso que damos a essa ordenação. O que os autores registram é que analisaram como especialistas da indústria priorizam as diretrizes.

Um resultado lateral desse mesmo levantamento é fácil de aplicar em PME: a heurística mais citada pelos profissionais como ausente das sete foi desenhar sempre no mesmo sentido, da esquerda para a direita ou de cima para baixo. É de graça e, na nossa experiência, derruba boa parte das reclamações de “não consigo ler esse mapa”.

O que o fluxograma não prova

Chegamos ao limite da ferramenta, e ele precisa ser dito com clareza porque é onde a PME perde dinheiro.

Os próprios autores do 7PMG registram a limitação: as diretrizes não se referem ao conteúdo de um modelo de processo, apenas à forma como esse conteúdo é organizado e representado. Em outras palavras, é possível seguir as sete à risca e produzir um diagrama impecável de um processo que não existe daquele jeito. As regras de desenho ajudam na legibilidade, não atestam veracidade. A validação de que o mapa corresponde ao trabalho real continua sendo o passo 5 do roteiro acima, feito com quem executa.

Há um segundo limite, e ele é mais incômodo. Reijers e Mendling investigaram, em estudo publicado em 2011 na IEEE Transactions on Systems, Man, and Cybernetics, os fatores que influenciam a compreensão de modelos de processo, separando fatores pessoais de fatores do modelo. Conforme o resumo do artigo, os dois tipos afetam a compreensão, e os fatores pessoais aparecem como os mais importantes dos dois. O resumo informa ainda que os dois fatores do modelo que mais convincentemente se relacionam à compreensão dizem respeito ao número de conexões, e que os resultados foram validados em uma replicação com modeladores profissionais.

Para quem gere uma PME, a tradução é desconfortável e útil: comprar uma ferramenta melhor de desenho não mexe em nenhum dos dois tipos de fator que aquele resumo aponta, porque não muda o número de conexões do modelo, a que se referem os dois fatores do modelo destacados no resumo, nem age sobre quem lê, que é onde ficam os fatores pessoais, não nomeados no resumo. Pelo resumo, quem lê o mapa parece pesar mais que o desenho do mapa. Na nossa leitura, isso recomenda investir em treino e simplicidade antes de trocar de software. O estudo não testou ferramentas.

Kathrin Figl publicou em 2017, na Business & Information Systems Engineering, uma revisão da literatura sobre compreensão de modelos visuais de processo, reunindo 40 estudos empíricos que mediram compreensão objetiva, 7 que mediram compreensão subjetiva e preferência de usuário, e 32 artigos que discutem os fatores envolvidos. O ponto de partida declarado pela autora resume o problema deste artigo inteiro: modelos visuais de processo existem para facilitar a compreensão dos processos de negócio, mas, na prática, podem ser difíceis de entender.

Mapear antes de automatizar: as quatro perguntas

A expressão “mapear antes de automatizar” virou clichê de vendedor de sistema, e o clichê esconde uma inversão. Mapear não existe para justificar a automação. Existe para descobrir se ela é necessária. Na maioria dos mapeamentos que acompanhei, o ganho maior veio de eliminar etapa, não de acelerá-la.

Antes de contratar qualquer ferramenta para um processo recém-mapeado, responda a estas quatro na ordem. Se a primeira não passar, as outras três não importam.

1. 1. Essa etapa precisa existir?

   Conferência que só confere o que já foi conferido antes não deve ser automatizada, deve ser removida

2. 2. A regra está estável?

   Regra que muda a cada cliente vira exceção no sistema, e exceção em sistema custa mais que trabalho manual

3. 3. Qual o volume real?

   Conte quantas vezes por mês a etapa roda. Automação de baixo volume raramente paga o custo de manter

4. 4. Quem mantém depois?

   Toda automação tem dono. Sem nome definido antes de contratar, ela para na primeira mudança de regra

Vale registrar de onde vem essa lista: é a nossa prática, não achado de pesquisa. As três fontes citadas aqui tratam de como modelos de processo são construídos e entendidos, e nenhuma delas testou decisões de automação nem mediu retorno de ferramenta. Quem quiser aprofundar o passo seguinte encontra o caminho em como implementar inovação na empresa, e o enquadramento mais amplo em o que é inovação.

Erros comuns no mapeamento de PME

Erro	Como aparece	Correção
Mapear tudo de uma vez	Projeto de “mapeamento dos processos” sem data de fim	Um processo por vez, escolhido pela dor. Critério de parada definido antes de começar
Desenhar o processo ideal	O mapa não tem retrabalho nem exceção, e todo mundo sabe que eles existem	Desenhar o que existe. O processo desejado é um segundo desenho, feito depois
Validar com quem não executa	Aprovação do gestor, silêncio de quem faz	Validar com quem opera a etapa, individualmente se necessário
Misturar níveis	Uma caixa diz “atender cliente” e a seguinte diz “clicar em salvar”	Um nível de detalhe por desenho. Subprocesso vira mapa próprio
Rótulo ambíguo	Caixas com “análise”, “tratativa”, “verificação”	Verbo mais objeto, conforme a sexta diretriz do 7PMG
Mapa sem dono	Ninguém atualiza depois da primeira mudança de regra	Nome definido para revisão, com data. Sem dono, o mapa envelhece em semanas

Nota de método

Vale explicitar até onde as fontes deste artigo foram verificadas, porque isso muda o peso de cada afirmação.

• Mendling, Reijers e van der Aalst (2010): texto completo lido. Todas as citações e os números do ranking foram conferidos contra o texto do artigo. É uma síntese da literatura empírica anterior somada a um levantamento de prioridade com profissionais, não um experimento novo de medição.
• Reijers e Mendling (2011) e Figl (2017): acesso somente ao resumo. Por isso, deste par só se afirma o que o resumo declara, e nenhum tamanho de efeito é citado.
• Sobre generalização: essa literatura vem da área de sistemas de informação e estuda modelos de processo em geral, não pequenas e médias empresas brasileiras. O experimento que o 7PMG cita como base da relação entre estrutura e compreensão usou 73 estudantes de três universidades, e o estudo de 2011 também usou estudantes, com replicação profissional relatada no resumo. O levantamento próprio do 7PMG foi feito com 21 profissionais, e é de percepção, não de compreensão medida. A transposição para a rotina da PME é leitura nossa, e é feita para orientar decisão de escopo, não para prever resultado.

Perguntas frequentes

Qual a diferença entre fluxograma e mapeamento de processos?

Fluxograma é o desenho. Mapeamento é o trabalho de descobrir como o processo funciona, que inclui observar a operação, entrevistar quem executa, medir esperas e validar o resultado. O fluxograma é uma das saídas do mapeamento, não o mapeamento inteiro. Empresa que entrega o desenho sem ter feito a descoberta entrega uma opinião formatada.

Qual ferramenta usar para fazer um fluxograma de processos?

Para o primeiro mapeamento, papel e post-it na parede resolvem melhor que software, porque qualquer pessoa da operação consegue mexer sem pedir licença. Depois de validado, passar para uma ferramenta de diagrama facilita manter. As fontes citadas neste artigo não compararam ferramentas. Vale lembrar o que o resumo de Reijers e Mendling (2011) declara: fatores pessoais e fatores do modelo afetam a compreensão, e os pessoais aparecem como os mais importantes dos dois. Aquele estudo não testou ferramentas de desenho, e ferramenta não é nem fator pessoal nem fator do modelo, então não há evidência ali a favor nem contra a troca.

Quantas caixas deve ter um fluxograma?

Não há número ideal, mas há um limiar útil. Mendling, Reijers e van der Aalst (2010) recomendam decompor o modelo acima de 50 elementos e relatam, com base na literatura que sintetizam, que acima desse tamanho a probabilidade de erro tende a passar de 50%. Na nossa leitura, erro ali é erro de construção do modelo, não infidelidade ao processo real, e elemento não é só a caixa de atividade: entram também conectores de decisão e eventos. Na prática de PME, se o desenho não cabe em uma folha A4 legível, provavelmente já são dois processos.

Preciso usar BPMN na minha empresa?

Não para começar. O BPMN é útil quando o modelo vai alimentar um sistema ou quando várias áreas precisam ler o mesmo padrão. Para o primeiro mapeamento de uma PME, a CGLC recomenda cinco símbolos: início e fim, atividade, decisão, seta e raia. Na nossa experiência, adotar a notação completa antes de precisar dela aumenta o custo de leitura justamente para quem mais precisa entender o mapa, que é quem executa.

O fluxograma resolve o problema do processo?

Não sozinho. Ele mostra onde o trabalho para, volta ou espera, e essas três marcas viram plano de ação. Mas os próprios autores do 7PMG registram que as diretrizes de modelagem tratam de como o conteúdo é organizado e representado, não do conteúdo em si. Um diagrama bem construído de um processo ruim continua descrevendo um processo ruim. A mudança acontece quando alguém assume cada decisão marcada no mapa, com prazo.

Fontes e referências

• Mendling, J., Reijers, H. A., & van der Aalst, W. M. P. (2010). Seven process modeling guidelines (7PMG). Information and Software Technology, 52(2), 127-136. https://doi.org/10.1016/j.infsof.2009.08.004
• Reijers, H. A., & Mendling, J. (2011). A study into the factors that influence the understandability of business process models. IEEE Transactions on Systems, Man, and Cybernetics – Part A: Systems and Humans, 41(3), 449-462. https://doi.org/10.1109/TSMCA.2010.2087017
• Figl, K. (2017). Comprehension of procedural visual business process models: a literature review. Business & Information Systems Engineering, 59(1), 41-67. https://doi.org/10.1007/s12599-016-0460-2

A CGLC (Centro de Gestão e Liderança Contemporânea) é um laboratório de cocriação de soluções que apoia empresas e líderes no desenvolvimento de lideranças, cultura de inovação e gestão de pessoas.