Esta é a versão recorrente de uma conversa que tenho. Alguém da área de operações de uma empresa de médio porte decide que precisa de “BPM”. Compra uma ferramenta. Faz um workshop de mapeamento de processos de duas semanas. Documenta tudo, os fluxogramas ficam ótimos no Confluence, e declara sucesso. Seis meses depois, os mesmos gargalos voltam. As mesmas cadeias de aprovação continuam lentas. Os mesmos dois departamentos seguem trocando dados com problemas entre si em planilhas.
Eles não falharam na gestão de processos de negócios. Na verdade, nunca chegaram a começar. Fizeram documentação de processos, que é algo completamente diferente.
É disso que este artigo trata: o que uma estrutura real de gestão de processos de negócios de fato governa, como o ciclo de vida funciona na prática e em que ponto a maioria das equipes se desvia silenciosamente do caminho antes que o trabalho se torne útil.
A parte que as equipes aprendem tarde
- BPM é uma disciplina de gestão cíclica, não um exercício de mapeamento que se conclui uma única vez.
- O ciclo de vida tem seis etapas; a maioria das equipes financia duas e se pergunta por que as outras quatro não acontecem.
- Tratar BPM como automação ou software é o equívoco mais caro da categoria.
- O porte da organização não determina a relevância do BPM. A complexidade dos processos, sim.
O que a gestão de processos de negócios realmente é
A definição funcional mais citada vem do Gartner, conforme apresentada pela IBM: gestão de processos de negócios é uma disciplina que usa métodos para descobrir, modelar, analisar, medir, melhorar, otimizar e automatizar processos de negócios em apoio aos objetivos empresariais. Leia essa lista de novo e conte os verbos. São sete. Isso não é por acaso.
BPM não é uma categoria de software. Não é uma metodologia que você conclui. A perspectiva do BPMInstitute.org é útil aqui: uma gestão eficaz de processos de negócios conecta a execução operacional à intenção estratégica, o que significa que ela trata fundamentalmente de governança e responsabilização, e não apenas de diagramas de fluxo. Os processos que você documenta precisam ter responsáveis, ser medidos e evoluir de forma iterativa. Caso contrário, você tem artefatos, não uma estrutura.
Essa distinção confunde todas as equipes que já vi abordarem o tema de forma equivocada. Elas tratam BPM como uma entrega: um conjunto de mapas, uma licença de ferramenta, um marco de projeto. O que ele realmente é: uma disciplina contínua de gestão que repete a mesma pergunta em um ciclo — nossos processos de negócios estão funcionando da maneira que nossos objetivos exigem? Caso contrário, o que vamos mudar?
A metodologia de gestão aqui é genuinamente cíclica. Você projeta, executa, monitora, otimiza e então volta ao projeto porque o negócio mudou. Não existe “concluído”. Existe apenas a “iteração atual”. Organizações que entendem isso desenvolvem capacidades ao longo do tempo. Organizações que não entendem continuam refazendo o mesmo workshop de duas semanas a cada poucos anos e se perguntando por que nada se sustenta.
Os 3 tipos de BPM que a maioria das estruturas reconhece
Antes de escolher como gerenciar seus processos, é útil saber com qual tipo de trabalho de processos você realmente está lidando. A maior parte da literatura sobre BPM — IBM, SAP Signavio e Ardoq abordam isso — converge em três tipos. Eles não são mutuamente exclusivos dentro de uma organização. A maioria das empresas executa os três simultaneamente e os trata como uma única categoria, que é onde a confusão começa.
BPM centrado em integração
Esse tipo é construído em torno da conexão entre sistemas e da automação de transferências entre plataformas, com mínima intervenção humana. Pense em sincronização de CRM para ERP, gatilhos de confirmação de pedidos, roteamento de dados entre ferramentas com base em regras de negócio. A automação de processos aqui é predominantemente técnica: algo acontece em um sistema, e a estrutura o direciona para o próximo sem que alguém no meio precise copiar informações manualmente.
O BPM centrado em integração é o tipo mais frequentemente confundido com “software de BPM” como um todo. Quando alguém diz “implementamos BPM”, há uma chance razoável de querer dizer que implantou uma camada de integração. Isso é trabalho real de alinhamento entre negócio e tecnologia, mas é uma parte da estrutura, não a estrutura em si.
BPM centrado em pessoas
Esse tipo é projetado para fluxos em que julgamento humano, decisões e aprovações são essenciais. Revisões de contratos, validações de conformidade, caminhos de escalonamento, avaliações de desempenho — qualquer situação em que uma pessoa precise tomar uma decisão antes que o processo avance. A automação aqui cuida do roteamento e das notificações; a pessoa continua responsável pela decisão.
É aqui que a governança e a clareza de papéis na estrutura mais importam. Os responsáveis pelos processos precisam ser claramente definidos, as regras de negócio sobre quem aprova o quê precisam ser explícitas, e a trilha de auditoria precisa registrar não só que uma decisão foi tomada, mas quem a tomou e quando. Continuo vendo equipes tratarem isso como um problema de fluxo, quando na verdade é um problema de responsabilização.
BPM centrado em documentos
Construído em torno do ciclo de vida de documentos que exigem revisão, aprovação, controle de versões e acompanhamento de conformidade. Finanças, seguros, saúde e governo são os contextos mais óbvios para isso — onde o próprio documento é o trabalho do processo, não apenas um subproduto dele. Os requisitos de negócio aqui costumam ser regulatórios: você precisa comprovar qual versão estava ativa, quem a aprovou e quando, às vezes para auditorias realizadas anos depois. Esse tipo se sobrepõe bastante ao BPM centrado em pessoas, mas coloca o documento no centro, e não a tarefa.
O ciclo de vida do BPM: o que cada etapa da estrutura realmente controla
Há dois modelos que vale a pena conciliar aqui. O BOC Group organiza o ciclo de vida como: gestão estratégica de processos, design e documentação, análise e otimização, implementação e gestão de mudanças, execução e operação, e controle e feedback. A HighGear o apresenta como: design, modelagem, execução, monitoramento e otimização. Eles descrevem o mesmo ciclo sob perspectivas ligeiramente diferentes. Nenhum está errado. O ponto importante que nenhum enfatiza o suficiente é que ele é iterativo, não sequencial. Concluir a “execução” não significa parar de projetar. Organizações que tratam isso como um projeto linear, em vez de um processo contínuo de BPM, são as que acabam voltando à estaca zero a cada poucos anos.
Design e documentação de processos
É aqui que ocorre a descoberta de processos: identificar quais processos existem, quem é responsável por eles, o que devem produzir e onde realmente falham. Você ainda não está modelando nada. Está criando um mapa defensável da realidade atual — desorganizada, não oficial e muitas vezes diferente do que o organograma sugere.
A maioria das equipes investe pouco nessa fase porque quer chegar à parte interessante. Na visão delas, a parte interessante costuma ser a automação de processos: software, ferramentas, fluxos. Mas você não pode automatizar o que não documentou com precisão. E não pode documentar com precisão se pular o trabalho de descoberta e depender do que os gestores acham que acontece na operação. Essas duas coisas quase nunca são iguais.
Alguns sinais de que sua fase de design e documentação está incompleta: seus mapas de processo foram criados em um workshop sem a participação das pessoas que realmente executam o processo, sua documentação cobre apenas o caminho ideal, ou ninguém atribuiu um responsável nominal a cada processo documentado. Qualquer uma dessas lacunas vai assombrar você depois.
Modelagem de processos e arquitetura de processos
A modelagem de processos traduz processos documentados em representações visuais ou estruturadas formais. BPMN (Business Process Model and Notation) é a abordagem mais padronizada, embora a adoção varie — continuo ouvindo de equipes que tentaram BPMN, acharam a curva de aprendizado íngreme e voltaram para diagramas em raias ou fluxogramas informais. Essa é uma tensão real. A formalidade do BPMN é valiosa para processos complexos entre sistemas. Para fluxos mais simples e centrados em pessoas, uma notação mais leve geralmente vence em usabilidade.
A arquitetura de processos é a disciplina de nível mais alto: como os fluxos de processos individuais se relacionam entre si em toda a organização, como se conectam aos objetivos estratégicos e como mudanças em um processo se propagam para os processos dependentes. A representação visual do processo no nível arquitetural é o que separa equipes com uma estrutura de BPM coerente de equipes com uma pasta cheia de fluxogramas que ninguém consulta. A arquitetura de negócios como um todo está aqui: o mapa de como capacidades, processos, sistemas e unidades organizacionais estão conectados.
Sem essa camada arquitetural, você está melhorando processos em silos. Otimiza o processo de um departamento, cria atrito em três transferências posteriores e depois se pergunta por que o resultado de ponta a ponta não melhorou. Isso é comum. Já vi acontecer nos dois sentidos: empresas que otimizam o processo de vendas sem ajustar os critérios de qualificação do marketing, e empresas que automatizam aprovações financeiras sem verificar como a mudança afeta os processos de RH que as alimentam.
Execução, monitoramento e métricas de processos
A execução de processos é onde o fluxo projetado opera em produção. Isso parece óbvio, mas é na execução que a diferença entre o comportamento documentado e o real se torna visível pela primeira vez. O mapa de processo diz três etapas. A realidade tem cinco por causa de uma solução improvisada que existe desde 2019, que ninguém documentou oficialmente, mas da qual todos dependem de maneira não oficial.
O monitoramento de processos é o que mantém a execução honesta. Você precisa acompanhar métricas de processo que indiquem se ele está funcionando como projetado: tempo de ciclo (quanto tempo cada instância leva do gatilho à conclusão), taxa de erros, taxa de retrabalho, frequência de exceções e atraso nas transferências. O ciclo de controle e feedback do modelo do BOC Group se encaixa aqui: dados em tempo real retornam à camada de governança e revelam desvios antes que se transformem em falhas normalizadas.
A saúde do processo é o que você realmente está observando. Um processo pode funcionar sem falhar e, ainda assim, ter uma saúde ruim — se estiver levando três vezes mais tempo do que o ciclo projetado, se cada quinta instância acionar uma exceção manual ou se as equipes posteriores estiverem corrigindo consistentemente suas entregas. Esses são sinais de saúde. Eles não aparecem em um painel de aprovado/reprovado. Aparecem nas métricas, se você as estiver acompanhando.
Equipes que pulam o monitoramento quase sempre descobrem que precisavam dele da maneira mais difícil.
Otimização de processos como um ciclo contínuo, não um projeto
A otimização de processos é onde os dados monitorados durante a execução se transformam em mudanças. Uma variação no tempo de ciclo alimenta uma análise. A análise revela um gargalo. O gargalo é redesenhado. O redesenho retorna às fases de documentação e modelagem. Esse é o mecanismo de melhoria contínua que transforma BPM em uma disciplina, e não em uma implantação.
O padrão que continuo vendo em equipes que travam: elas tratam a primeira otimização como a última. A metodologia de melhoria de processos é aplicada uma vez, os números melhoram e a iniciativa é declarada concluída. Então o negócio muda, o processo se desvia e, dezoito meses depois, alguém realiza o mesmo workshop novamente e age como se estivesse surpreso com os resultados. Projetos de melhoria de processos têm datas de encerramento. Uma estrutura de BPM não. A fase de otimização é uma etapa recorrente de um processo contínuo, não um marco de projeto. Para otimizar processos de negócios de forma sustentável, você precisa manter o ciclo em funcionamento — o que exige alguém permanentemente responsável por ele, e não apenas durante a iniciativa.
🤔 Pense nisso:
A maioria das equipes investe bastante em design e documentação de processos — as fases que produzem entregas visíveis, como fluxogramas e resultados de workshops. Monitoramento e otimização, onde a melhoria sustentada realmente acontece, recebem uma fração desse investimento. A fase de design produz artefatos. Só a fase de monitoramento mostra se esses artefatos refletem algo que realmente está funcionando.
Estrutura de BPM versus gestão de fluxos: onde realmente está o limite
Esta é uma das confusões mais comuns que vejo, e ela importa porque confundi-las leva à compra de soluções para o problema errado.
Uma estrutura de BPM é uma disciplina organizacional. Ela define estruturas de governança, estabelece a responsabilidade pelos processos, cria padrões de medição e gerencia todo o ciclo de vida, da descoberta à otimização. É o sistema que decide quais processos existem, quem é responsável por eles, como o desempenho é medido e quando eles são alterados. A estrutura é uma abordagem organizada para toda a camada de governança operacional.
A gestão de fluxos é uma camada tática de execução. Ela lida com o roteamento de processos individuais: esta tarefa vai para esta pessoa, este documento precisa desta aprovação, este gatilho inicia esta sequência. Ferramentas de gestão de fluxos são o que você implanta para executar uma instância específica de processo. Elas operam dentro da estrutura, não a substituem.
A consequência prática de misturar os dois: as equipes compram uma ferramenta de gestão de fluxos e assumem que o software cria a estrutura de BPM ao redor dela. Não cria. A ferramenta cuida do roteamento de tarefas para instâncias individuais de processos. A estrutura define quais processos existem, quem é responsável por eles em toda a organização, como o desempenho é medido e quais regras de governança se aplicam. Você precisa dos dois, mas eles não substituem um ao outro.
Uma analogia que funciona bem: gestão de projetos versus software de gestão de projetos. A disciplina e a ferramenta são coisas diferentes. A ferramenta apoia a disciplina. A disciplina não surge da ferramenta.
| Camada | Escopo | Quem a governa | Exemplo |
|---|---|---|---|
| Estrutura de BPM | Toda a organização | Responsável pelo processo, COO, equipe de BPM | “Quais processos existem, quem é responsável por eles, como são medidos” |
| Gestão de fluxos | Instância individual de processo | Líder de equipe, operações do departamento | “Este documento é encaminhado para Finanças, depois Jurídico, depois aprovação final” |
| Ferramentas de automação | Mecânica de execução | Desenvolvedor, especialista em automação | “O gatilho dispara, a carga útil é encaminhada, o status é atualizado” |
Como uma estrutura de BPM adequada funciona em diferentes níveis de maturidade organizacional
Um dos equívocos persistentes nesse campo é que BPM só é relevante para grandes empresas com equipes dedicadas à excelência de processos. Isso está errado. A formalidade e o escopo da estrutura mudam conforme a escala organizacional. A disciplina subjacente — gerenciar, medir e melhorar seus processos — se aplica em todos os lugares. Veja como uma abordagem adequada de BPM realmente se apresenta em cada nível de maturidade e onde as equipes de cada nível normalmente saem do rumo.
- Equipes em estágio inicial com processos informais
O sinal organizacional: os processos existem como conhecimento tribal, acordos ad hoc e “pergunte ao Jordan como isso é feito”. O escopo adequado de BPM nesse nível é deliberadamente pequeno: documentar de três a cinco processos críticos, atribuir um responsável nominal a cada um e estabelecer uma métrica por processo para acompanhar se está funcionando. O erro comum é não fazer nada — sem nenhuma disciplina de processos — ou ir direto para uma implementação completa de governança de processos com ferramentas e workshops, o que representa mais estrutura do que a organização consegue absorver. Uma prática eficaz de processos nesta fase significa começar de forma leve e adicionar governança conforme a equipe cresce.
- Operações de médio porte padronizando entre departamentos
O sinal organizacional: diferentes departamentos desenvolveram seus próprios hábitos de processo, e as transferências entre eles são uma fonte recorrente de erros, atrasos e trabalho duplicado. É aqui que as iniciativas de processos devem focar no alinhamento multifuncional, na responsabilidade formal pelos processos e em padrões consistentes de medição. O escopo adequado de BPM aqui inclui uma visão da arquitetura de processos — como os processos se conectam entre departamentos, não apenas dentro deles. O erro comum é conduzir projetos de melhoria de processos departamento por departamento, sem conectá-los. Você melhora o processo de vendas isoladamente e depois descobre que a transferência para finanças ainda é manual, e a melhoria para no limite da equipe.
- Empresas maduras com governança completa de processos
O sinal organizacional: patrocínio executivo para a gestão de processos, uma função dedicada de BPM ou excelência de processos, controle formal de mudanças para atualizações de processos e integração entre dados de desempenho dos processos e planejamento estratégico. A governança de processos nesse nível significa caminhos de escalonamento definidos, controles de conformidade e revisões regulares de processos vinculadas a objetivos de negócio. Um estudo de 2026 publicado no International Journal for Quality in Health Care constatou que, entre os fatores mais associados à maior maturidade de BPM em hospitais públicos, a gestão de riscos e o controle de conformidade, juntamente com o envolvimento da alta administração, ficaram nas posições mais altas. Esse padrão se mantém fora da saúde: governança e alinhamento executivo não são elementos decorativos de uma estrutura madura de BPM. São o que torna a disciplina funcional em escala. O erro comum neste nível é criar estruturas de governança excessivamente complexas, que desaceleram os próprios processos que deveriam gerenciar.
As equipes no nível intermediário — padronizando entre departamentos — geralmente são as que mais se beneficiam de uma abordagem de governança de processos favorável à automação. Há alguns anos, uma equipe de operações com a qual trabalhei fazia aprovações de mudanças de processo em uma planilha com 14 colunas e um diretor financeiro muito paciente. O problema não era que a estrutura estivesse errada. O problema era que a camada de execução para gerenciar mudanças de processo não tinha trilha de auditoria nem roteamento aplicável. Quando passaram a enviar solicitações de mudança de processo por meio de um fluxo estruturado — em que cada atualização era roteada, versionada e registrada — a camada de governança finalmente passou a funcionar como havia sido projetada. Na Latenode, algo assim pode ser configurado combinando lógica de roteamento, comparação de versões em um nó JavaScript e OAuth automático para enviar aprovações ao sistema que a equipe já usa para aprovações finais. A precificação por execução também ajudou: um fluxo de aprovação de seis etapas contava como uma execução, não seis, o que manteve os custos previsíveis à medida que o volume aumentava.
Onde as estruturas de BPM falham na prática
Já vi iniciativas de BPM suficientes travarem para ter uma taxonomia aproximada de como elas falham. Quase nunca é uma única falha dramática. Geralmente é um acúmulo lento de meias decisões: a ferramenta foi comprada, mas a governança não foi construída; o mapa foi desenhado, mas a medição não começou; o projeto foi lançado, mas a responsabilidade não foi atribuída. Então a iniciativa sobrevive ao seu patrocinador, a energia se dissipa e a organização volta aos processos informais seis meses depois.
Confundir software de BPM com um sistema de BPM
Isso aparece no suporte mais do que eu gostaria de admitir. Uma equipe compra uma plataforma de BPM — boas ferramentas de BPM, funcionalidades reais — e trata a compra como a implementação de um sistema de BPM. O software se torna a estrutura no modelo mental da equipe. Não é.
Plataformas e softwares de BPM fornecem infraestrutura de execução. Eles não oferecem responsabilidade pelos processos, cultura de governança, supervisão de processos manuais ou a disposição organizacional para executar as fases de monitoramento e otimização. Esses são problemas de pessoas. O sistema de BPM — o sistema que realmente funciona — é uma combinação de ferramentas, papéis, regras e hábitos. Você não pode comprar os papéis, as regras e os hábitos. É preciso construí-los separadamente.
O sintoma desse modo de falha: a plataforma de BPM está ativa e funcionando, os painéis parecem movimentados, e os mesmos problemas operacionais que existiam antes da compra da ferramenta continuam acontecendo. Às vezes de forma mais evidente, porque agora há dados confirmando esses problemas e ninguém recebeu a responsabilidade de agir sobre eles. A melhoria de processos de negócios exige uma estrutura de governança por trás das ferramentas. As ferramentas apenas tornam a governança mais fácil de executar.
É aí que o chamado de suporte geralmente começa.
Tratar o mapeamento de processos como o objetivo final
O mapeamento de processos é realmente útil. Ele revela como os processos de fato funcionam em comparação com como as pessoas acham que funcionam, o que quase sempre é diferente. O problema ocorre quando o mapa se torna a entrega — quando concluir o exercício de mapeamento é considerado o mesmo que concluir o trabalho de BPM.
Um mapa de processo sem medição associada é arqueologia, não operação. Você documentou o processo atual, o que é valioso. Mas se essa documentação não se conecta a métricas que indiquem se o processo está cumprindo seu objetivo, e se não há governança para decidir quando e como alterá-lo, o mapa simplesmente fica desatualizado. O processo atual evolui por meio de soluções improvisadas informais, tratamento de casos extremos e rotatividade de pessoal. Em um ano, até mesmo um mapa bem desenhado é uma imagem de um processo que já não existe.
A abordagem para a melhoria de processos deve tratar o mapeamento como a primeira fase de um ciclo contínuo, não como um projeto isolado. Problemas de processo não são resolvidos por documentação — são resolvidos fechando o ciclo entre o mapa, a medição e a camada de governança que decide o que muda.
💡 Vale saber:
As falhas de BPM mais caras não ocorrem na fase de design. Elas acontecem na lacuna entre os processos documentados e o que as pessoas realmente fazem. Essa lacuna só se fecha por meio de monitoramento e ciclos de feedback — as duas fases que recebem o menor investimento organizacional. Um mapa detalhado de processo sem monitoramento ativo é um retrato de como seu processo era na época do workshop.
Como as estruturas de BPM se aplicam em diferentes setores e departamentos
Às vezes, as estruturas de BPM são descritas como aplicáveis “em todos os setores”, o que é verdade, mas inútil sem detalhes. A razão para essa ampla aplicação é que toda organização tem processos de negócios, e todos eles se beneficiam de terem responsáveis, serem medidos e melhorados. O escopo, a formalidade e as restrições variam significativamente conforme o contexto.
Setores regulados: conformidade, riscos e documentação de processos
Em finanças, seguros, saúde e governo, as estruturas de BPM carregam uma camada adicional de restrição: conformidade regulatória. A documentação de processos não é apenas uma boa prática nesses ambientes. É uma exigência de auditoria. Você precisa demonstrar não apenas que um processo existe, mas que a versão autorizada atualmente está documentada, que as mudanças passaram por aprovação formal e que desvios do procedimento padrão foram identificados e registrados.
O estudo de saúde de 2026 constatou que, em hospitais com menor maturidade de BPM, o déficit apareceu com mais clareza nas capacidades de controle de conformidade e gestão de riscos — exatamente os aspectos verificados por órgãos de licenciamento e organizações de acreditação. A melhoria de processos de negócios em ambientes regulados não é uma otimização opcional. É o mecanismo pelo qual você demonstra que opera dentro de limites definidos. A modelagem de processos nesse contexto precisa ser precisa o bastante para servir tanto à melhoria operacional quanto aos propósitos de auditoria externa, criando uma disciplina que tende a produzir estruturas mais rigorosas no geral.
Equipes de operações e TI: alinhando automação à governança de processos
Para equipes de operações e TI que conduzem a transformação digital, as estruturas de BPM fornecem a camada de governança que evita que a automação se transforme em caos. Sem governança de processos por trás dela, automação em escala significa mais velocidade em processos que podem estar mal projetados, medidos de forma inconsistente ou sem responsável. Você obtém erros mais rápidos, não resultados mais rápidos.
A mineração de processos — análise de logs de eventos de sistemas para reconstruir como os processos realmente funcionam — é cada vez mais usada aqui para revelar a diferença entre os fluxos projetados e os reais. Ela funciona como uma ferramenta de descoberta para organizações com ambientes ricos em dados. O caso de uso de triagem de gargalos é prático e acessível: quando uma equipe de processos tem uma entrada estruturada para registrar pontos de atraso, atritos nas transferências e aprovações desnecessárias, ela pode criar uma lista priorizada de melhorias que alimenta diretamente a fase de otimização. O fluxo S-03 da Latenode reflete esse padrão: um fluxo de entrada conectado à classificação por IA e à pontuação de severidade envia problemas estruturados de processo para o sistema de tarefas da equipe correta, substituindo mensagens dispersas por um sinal rastreável. Configurar isso corretamente costuma levar menos de 30 minutos após a definição do canal de entrada. Implementar melhorias de processos ainda exige julgamento humano. A estrutura encaminha as informações. As pessoas tomam a decisão.
Departamentos funcionais: fluxos de RH, finanças e cadeia de suprimentos
Equipes de RH, finanças, jurídico e cadeia de suprimentos têm necessidades recorrentes de fluxos que se encaixam perfeitamente no território do BPM centrado em pessoas e em documentos: aprovações de integração, revisões de despesas, encaminhamento de contratos, aprovações de pedidos de compra. Esses não são desafios de governança de processos em escala empresarial. São problemas de gestão de recursos em nível departamental que se beneficiam enormemente de responsabilidade estruturada e medição básica.
Isso contrapõe o equívoco de que BPM é uma disciplina empresarial ou de TI. Uma equipe financeira de cinco pessoas com um processo claro para aprovações de despesas — etapas definidas, responsável nominal, tempo de ciclo acompanhado — está fazendo BPM. Melhorar processos de negócios nessa escala consiste principalmente em substituir fluxos informais por fluxos definidos e adicionar supervisão suficiente para identificar quando algo se desvia.
