Como mapear o sistema antes de mudá-lo: um guia prático
Como mapear o sistema antes de uma transformação: desenhe atores, fluxos, regras e ciclos, descubra onde haverá resistência e escolha onde agir.

Como mapear o sistema antes de mudá-lo: um guia prático
Para mapear um sistema antes de mudá-lo, escolha um resultado que importe para as pessoas a quem a mudança se destina e desenhe tudo o que hoje produz esse resultado: as pessoas e áreas envolvidas, o que circula entre elas, as regras que as governam e os ciclos que mantêm o estado atual estável. Um bom mapa leva de duas a quatro semanas, é construído com as pessoas que estão dentro do sistema, e não sobre elas, e termina com uma lista curta de pontos onde uma mudança tem boas chances de se sustentar. Sem ele, a transformação costuma mudar a parte do sistema mais fácil de ver e depois assistir ao resto do sistema desfazê-la em silêncio.
Por que o mapa vem primeiro
A maioria dos planos de transformação é desenhada sobre um organograma. O organograma mostra quem se reporta a quem. Não mostra como o trabalho realmente circula, onde um pedido fica parado por três semanas ou qual regra informal todo mundo segue porque, na única vez em que foi quebrada, deu problema. São essas coisas que decidem se uma mudança sobrevive.
O pensamento sistêmico tem uma longa tradição nisso. A Quinta Disciplina (1990), de Peter Senge, popularizou a ideia de que as organizações se comportam de acordo com sua estrutura, não com suas intenções, e o ensaio Leverage Points: Places to Intervene in a System (1999), de Donella Meadows, argumentou que os pontos onde as pessoas instintivamente empurram, como orçamentos, impostos e normas, costumam ser os mais fracos para agir.
Este artigo é o complemento prático de A transformação falha na porta do cliente, que explica por que a mudança precisa ser sentida pelos clientes para contar. Mapear é como você descobre o que hoje se coloca entre a sua organização e essa percepção.
Passo 1: Escolha o resultado, não o departamento
Comece por um resultado descrito de fora para dentro: "uma pequena empresa obtém o alvará de funcionamento", "um paciente recebe alta e sabe o que fazer em seguida", "um fornecedor é pago em dia". Evite começar por uma área ("mapear o departamento de licenciamento"), porque o resultado quase sempre atravessa três ou quatro áreas e duas partes externas.
Escreva o resultado numa frase e combine dois limites: onde o sistema começa (o primeiro momento em que alguém precisa de algo) e onde termina (o momento em que a pessoa consegue o que precisa, ou desiste). Tudo o que está dentro desses limites e molda o resultado entra no mapa.
Passo 2: Liste os atores e depois posicione-os
Faça primeiro um mapa de stakeholders, porque é rápido e coloca nomes na parede. Inclua:
- As pessoas para quem o resultado existe, divididas nos dois ou três grupos que o vivenciam de formas diferentes.
- Todas as áreas internas que tocam um pedido, inclusive as que só aprovam ou conferem.
- Partes externas: reguladores, fornecedores, entidades parceiras, bancos, plataformas.
- Os atores silenciosos: a caixa de e-mail compartilhada, o sistema legado, o comitê que se reúne uma vez por mês. Trate um sistema ou uma reunião como ator se o trabalho fica esperando por ele.
Depois passe para um mapa de sistema e posicione os atores numa única superfície. Quando várias organizações compartilham o resultado, um mapa de ecossistema é o canvas mais adequado, porque mostra o valor trocado entre entidades, e não as etapas dentro de uma delas.
Passo 3: Desenhe os fluxos
Ligue os atores com setas e identifique em cada seta o que circula: informação, dinheiro, documentos, aprovações, pessoas, dados. Vale marcar quatro tipos de fluxo separadamente, em cores diferentes:
- Fluxos de trabalho. O pedido, o processo ou o caso à medida que avança.
- Fluxos de informação. Quem avisa quem sobre o quê, e com que atraso.
- Fluxos de dinheiro e recursos. Orçamentos, taxas, tempo das equipes.
- Fluxos de autoridade. Quem pode dizer sim, quem pode dizer não, quem precisa ser consultado.
Quando o fluxo é uma sequência dentro de uma única equipe, um fluxograma de processo o captura melhor do que setas num mapa grande. Quando envolve a experiência do cliente e o back office ao mesmo tempo, um blueprint de serviço mostra as duas camadas.
Não desenhe fluxos só a partir de documentos. Percorra a jornada você mesmo. Um safári de serviço, em que a equipe passa pelo serviço como um cliente passaria, revela com frequência etapas que o processo oficial não menciona.
Passo 4: Marque as regras e os ciclos
Esta é a etapa que a maioria das equipes pula, e é nela que está o insight útil.
Regras. Ao lado de cada ator e de cada fluxo, escreva as regras que moldam o comportamento: políticas escritas, metas de desempenho, alçadas de aprovação e as regras não escritas ("ninguém assina antes de o diretor ver"). Pergunte diretamente: "O que colocaria você em apuros aqui?" As respostas são as regras de verdade.
Ciclos. Procure cadeias que se realimentam. Um exemplo comum: as reclamações aumentam, então se acrescenta uma etapa de revisão, então o processamento fica mais lento, então as reclamações aumentam ainda mais. Outro: uma área é medida pela velocidade, então rejeita rapidamente processos incompletos, então os clientes reenviam, então o volume aumenta, então a área parece sobrecarregada e pede mais gente. Desenhe esses ciclos como círculos fechados. Um ciclo que mantém o estado atual estável é a razão pela qual as tentativas anteriores de mudança perderam força.
Use os cinco porquês em qualquer ponto de atraso ou falha para rastreá-lo até a regra ou o ciclo por trás dele.
Passo 5: Descubra onde a mudança vai encontrar resistência e onde vai se sustentar
Agora leia o mapa como um todo. Três perguntas ajudam:
- Onde o trabalho espera? Os pontos de espera costumam estar nos fluxos de autoridade, não nos fluxos de trabalho.
- Qual regra, se mudada, mudaria vários fluxos de uma vez? Esse é um candidato a ponto de alavancagem.
- Quem se beneficia do estado atual? Não como vilões. A maior parte da resistência vem de pessoas cujas metas, carga de trabalho ou status dependem do desenho atual.
Para cada ponto candidato, faça uma análise de campo de forças rápida (a ferramenta de Kurt Lewin): liste as forças que vão impulsionar a mudança e as que vão segurá-la. Escolha os dois ou três pontos em que as forças de impulso são reais e as forças de restrição podem ser tratadas. Eles se tornam os pontos de partida do roadmap, tema de Como conduzir um roadmap de transformação do qual as equipes são donas.
Passo 6: Valide o mapa com as pessoas que estão nele
Antes que alguém decida qualquer coisa, leve o mapa de volta às pessoas que aparecem nele, em pequenos grupos, e pergunte: "O que está errado ou faltando?" Espere correções. Cada correção transforma essas pessoas em coautoras do diagnóstico, e não em objeto dele. Um mapa que a linha de frente reconhece é o argumento mais forte que uma equipe de transformação pode levar a uma reunião com a liderança.
Exemplo ilustrativo
Ilustrativo. Uma prefeitura de porte médio no norte da Europa queria reduzir pela metade o prazo de aprovação de pequenas obras. O plano original era um novo portal online. A equipe mapeou o sistema primeiro, partindo do resultado "um morador obtém autorização para construir uma ampliação".
O mapa mostrou onze atores, entre eles duas agências externas e um comitê de planejamento que se reunia mensalmente. O fluxo de trabalho parecia razoável; o fluxo de autoridade, não. Qualquer pedido que envolvesse uma rua tombada ia para o comitê, independentemente do tamanho, e o comitê se reunia uma vez por mês. Havia um ciclo por trás disso. Reclamações antigas sobre uma ampliação polêmica tinham levado à regra de que "todos os casos de patrimônio vão ao comitê", o que atrasava tudo, o que levava mais requerentes a ligar para os vereadores, o que mantinha o comitê apreensivo e a regra em vigor.
O portal teria acelerado o envio e não teria mudado nada na espera. Em vez disso, a prefeitura delegou os pequenos casos de patrimônio a técnicos seniores com critérios claros, manteve o comitê para os grandes e só então construiu o formulário online. O portal entrou no ar num sistema capaz de aproveitá-lo.
O que fazer e o que evitar
Faça
- Comece por um resultado que o cliente reconheceria.
- Inclua partes externas e atores não humanos, como sistemas e comitês.
- Escreva as regras não escritas. Pergunte o que coloca as pessoas em apuros.
- Desenhe os ciclos como círculos, para que ninguém os confunda com linhas retas.
- Leve o mapa de volta às pessoas que estão nele antes de agir.
Não faça
- Mapear só a partir de documentos de política e manuais de processo.
- Mapear um departamento quando o resultado atravessa cinco.
- Buscar completude. Um mapa está pronto quando muda uma decisão, não quando todas as caixas foram desenhadas.
- Apresentar o mapa como uma conclusão sobre pessoas, e não sobre estrutura.
- Deixar o mapeamento virar o projeto. Duas a quatro semanas costumam bastar para um resultado.
Perguntas frequentes
Qual é a diferença entre um mapa de sistema e um mapa de processo? Um mapa de processo mostra as etapas pelas quais passa uma unidade de trabalho, geralmente dentro de uma equipe. Um mapa de sistema mostra todos os atores, fluxos, regras e ciclos que, juntos, produzem um resultado, inclusive os que estão fora da sua organização. Use um mapa de processo para dar zoom numa parte do mapa de sistema.
Quão detalhado deve ser um mapa de sistema? O suficiente para mostrar onde o trabalho espera e por quê. Se uma caixa ou uma seta não mudaria o lugar onde você escolhe agir, deixe-a de fora. Os mapas mais úteis cabem numa parede.
Quem deve estar na sala ao mapear um sistema? Pessoas que fazem o trabalho em cada etapa, pelo menos uma pessoa que vivencia o resultado como cliente, alguém que conhece as regras (políticas, jurídico ou finanças) e quem vai patrocinar a mudança. Mantenha o grupo central entre seis e dez pessoas e valide com as demais depois.
Para onde ir agora
Comece pelos guias de mapa de sistema e mapa de stakeholders, aprofunde com um blueprint de serviço e teste os pontos escolhidos com a análise de campo de forças. Se o seu último programa não mapeou nada e ainda assim produziu um relatório volumoso, Por que programas de transformação geram relatórios e ninguém muda a forma de trabalhar explica o padrão.