A cena é sempre a mesma. O problema é apresentado na reunião, alguém propõe uma solução, todos concordam que faz sentido, e a solução é implantada na semana seguinte.
Meses depois, ninguém sabe dizer se funcionou. O indicador oscilou, houve um mês bom, houve outro ruim, e o problema voltou a aparecer na pauta — às vezes com outro nome.
Isso não é falta de empenho. É o que acontece quando se pula do problema para a solução sem passar pelas duas etapas que ficam no meio: entender por que o processo entrega o que entrega, e verificar se a mudança deslocou o resultado.
Melhoria de processos não é melhoria contínua
Os dois termos são usados como sinônimo e descrevem coisas diferentes, com ritmos e mecanismos próprios.
Melhoria de processos é uma intervenção estruturada: tem alvo, escopo, prazo e critério de encerramento. Ataca um processo específico que entrega abaixo do necessário, e termina quando o novo patamar está verificado e sustentado.
Melhoria contínua é a prática permanente, sem alvo único e sem fim — o hábito de encontrar e remover pequenos desperdícios no dia a dia, tratado em melhoria contínua e materializado no Kaizen.
Uma organização precisa das duas, e elas resolvem problemas diferentes. Melhoria contínua não corrige um processo estruturalmente incapaz — nenhum acúmulo de pequenos ajustes muda o patamar de um processo mal desenhado. E projeto de melhoria não substitui o hábito: sem ele, o resultado conquistado escorrega de volta em alguns meses.
O que precisa ser verdade para chamar de melhoria
Antes do roteiro, três condições — e elas são o critério pelo qual o resultado será julgado no fim.
Existe um indicador declarado, com valor e prazo. “Melhorar o atendimento” não é alvo; “reduzir o tempo de primeira resposta de quatro horas para uma, até dezembro” é. Sem isso, o encerramento não tem critério e qualquer resultado pode ser apresentado como sucesso.
Existe uma linha de base. Sem saber como o processo se comportava antes, não há como afirmar que algo mudou depois. E linha de base não é um número — é a faixa em que o indicador vinha oscilando.
Existe um contrapeso. O que não pode piorar enquanto o alvo melhora. Reduzir tempo de atendimento é fácil se ninguém olhar a rechamada; cortar custo é fácil se ninguém olhar o retrabalho. A lógica está em indicadores de desempenho.
O roteiro, e a pergunta de cada etapa
| Etapa | Pergunta que precisa ser respondida | Sinal de que foi pulada |
|---|---|---|
| Escolher | Este problema vale um projeto? | O alvo é o problema mais recente, não o maior |
| Definir | Que número deveria mudar, e quanto? | Objetivo escrito com adjetivo, sem unidade |
| Medir | Como o processo se comporta hoje? | Um número em vez de uma série |
| Analisar | Por que ele entrega isso? | A causa foi decidida por consenso na reunião |
| Testar | A mudança produz o efeito previsto? | Cinco mudanças implantadas juntas |
| Sustentar | O novo patamar se mantém sem atenção? | Nenhum responsável pelo indicador depois do encerramento |
A coluna da direita é a que importa na prática. Cada uma dessas falhas produz um projeto que termina com relatório e sem mudança — e nenhuma delas é visível enquanto o projeto corre.
Escolher: o filtro que economiza meses
Antes de abrir qualquer projeto, uma pergunta derruba boa parte dos candidatos: esse problema é um problema, ou é a variação normal do processo?
Muita lista de projeto nasce de comparação entre dois pontos — o mês pior que o anterior, a unidade pior que a outra. Quando o indicador oscila naquela faixa há dois anos, o “problema” é um mês dentro dela, e o projeto vai perseguir ruído com método. Olhar a série resolve isso em minutos, e é o que a carta de controle permite ver.
Passado esse filtro, escolher entre os candidatos restantes exige critério explícito — impacto, esforço, dados disponíveis e controle sobre a causa —, tratado em priorização de projetos.
Medir: uma série, não um número
A etapa mais pulada, e a que decide o que será possível concluir no fim. Ela exige três decisões anteriores à coleta: o critério de contagem que duas pessoas apliquem igual — a definição operacional —, a verificação de que o instrumento não varia mais que o processo, e o registro dos fatores que podem explicar a variação. O conjunto está em plano de coleta de dados.
Nada disso é refinamento técnico. É o que permite, três meses depois, separar os dados por turno e descobrir onde o problema mora — ou descobrir que não dá, e recomeçar.
Analisar: hipótese não é causa
Aqui está a etapa em que a maioria dos projetos se perde, e o mecanismo é sempre o mesmo: a equipe levanta hipóteses, escolhe a mais convincente e age sobre ela.
Ferramentas como o diagrama de Ishikawa organizam hipóteses — não confirmam nenhuma. Entre a hipótese e a causa há um teste, e ele pode ser simples: separar os dados pelo fator suspeito e verificar se a diferença sobrevive. Uma relação observada entre duas variáveis também não basta, pelo motivo tratado em correlação e causalidade.
Investigar por que o processo entrega o que entrega, em vez de reagir onde o problema aparece, é o objeto da análise de causa raiz.
Testar: uma mudança por vez
Quando cinco alterações entram juntas e o indicador melhora, não se sabe qual funcionou — e no ciclo seguinte a organização carrega as cinco, incluindo as que não fizeram nada.
Testar em escala pequena, com previsão registrada antes, permite aprender a cada rodada. É a lógica do PDSA, e quando há vários fatores conhecidos que interessam ao mesmo tempo, o caminho é planejar as combinações em vez de variar um a um.
Sustentar: onde o resultado escorrega
O projeto muda o processo, escreve o procedimento novo, treina a equipe — e seis meses depois tudo voltou. Documentar não é implementar: o que sustenta o comportamento novo é o processo padronizado, o indicador com responsável e a consequência coerente. É o que a padronização protege.
Como saber se funcionou
A verificação é a etapa que separa melhoria de alegação de melhoria, e ela falha quase sempre da mesma forma: comparando um ponto antes com um ponto depois.
Um indicador melhor no mês seguinte à mudança pode ser o mês bom de sempre. O que sustenta a afirmação é o comportamento ao longo do tempo, com a faixa histórica visível, e a previsão registrada antes de mudar. Se o processo oscilava entre 3,4% e 4,6% e terminou em 3,9%, não houve melhoria — houve um mês. A distinção está em mudança e melhoria, e o conceito por trás em variação.
Conduzir essa sequência inteira com rigor — do filtro inicial à verificação — é o que uma formação como o Green Belt desenvolve, e o roteiro que a organiza é o DMAIC.
Onde a melhoria costuma estar
Quando se cronometra um processo de ponta a ponta, o padrão se repete em qualquer setor: a maior parte do prazo total não é trabalho, é espera. Peça parada entre operações, solicitação aguardando aprovação, paciente esperando resultado.
Isso tem uma consequência que muda a prioridade: acelerar quem executa rende pouco, porque o tempo de execução é fração pequena do total. O ganho está nos intervalos entre as etapas, e eles só aparecem quando alguém desenha o percurso completo — o que faz o mapeamento do fluxo de valor.
O segundo lugar onde a melhoria costuma estar é menos óbvio: a causa quase nunca está onde o problema aparece. O defeito detectado na inspeção final nasce no ajuste do lote; o pedido incompleto nasce no cadastro. Cobrar o último elo é a intervenção mais fácil de anunciar e a menos eficaz de todas.
O projeto que entrega tudo e não muda nada
Vale registrar o desfecho mais comum, porque ele não deixa rastro e por isso não é corrigido.
O projeto cumpre o cronograma, entrega as ações previstas, treina quem precisava e encerra com apresentação. O indicador que motivou a abertura termina onde começou — dentro da faixa em que já vivia. Nenhum critério foi violado, porque nenhum tinha sido declarado.
Esse projeto passa em qualquer auditoria de processo e reaparece no ano seguinte com outro nome. A defesa contra ele custa uma frase escrita na abertura — qual número, quanto, até quando — e a disposição de olhar esse número no fim, mesmo quando ele não coopera.
Conteúdo revisado pelo Master Black Belt Marcelo Petenate, estatístico, formado pela Unicamp, mestre pela USP e especialista em Lean Six Sigma e melhoria contínua. Nesta revisão, o foco foi a distinção entre intervenção estruturada e prática permanente, e o critério de verificação do encerramento.
O White Belt gratuito da EDTI apresenta as três questões fundamentais que estruturam qualquer projeto de melhoria.
Perguntas frequentes
O que é melhoria de processos?
É uma intervenção estruturada sobre um processo específico, com alvo declarado, prazo e critério de encerramento. Termina quando o novo patamar do indicador está verificado ao longo do tempo e sustentado — não quando as ações previstas foram executadas.
Qual a diferença entre melhoria de processos e melhoria contínua?
A melhoria de processos é um projeto: tem alvo, escopo e fim. A melhoria contínua é a prática permanente de encontrar e remover pequenos desperdícios no dia a dia. Uma organização precisa das duas — nenhum acúmulo de pequenos ajustes corrige um processo estruturalmente incapaz, e nenhum projeto sustenta o resultado sem o hábito.
Por onde começar um projeto de melhoria?
Por verificar se o problema é real: olhar a série do indicador e confirmar que o resultado observado está fora da faixa em que ele já oscilava. Boa parte das listas de projeto nasce de comparações entre dois pontos, e persegue variação normal com método.
Quanto tempo leva um projeto de melhoria?
Depende de quanto tempo o indicador leva para responder, não de quanto tempo as ações levam para ser implantadas. Processos com ciclo longo exigem janelas de observação maiores — e definir isso na abertura evita encerrar antes de haver dado suficiente para concluir.
Como saber se a melhoria funcionou?
Comparando o comportamento do indicador ao longo do tempo, antes e depois, com a faixa histórica visível e a previsão registrada antes da mudança. Um valor melhor no mês seguinte pode ser o mês bom de sempre — a comparação entre dois pontos não distingue melhoria de oscilação.
Por que os resultados voltam ao que eram?
Porque documentar a mudança não é implementá-la. Sem processo padronizado, indicador com responsável nomeado e consequência coerente, o comportamento anterior volta em poucos meses — e a pasta do projeto permanece perfeitamente organizada.
Preciso de ferramentas estatísticas para melhorar processos?
Precisa de leitura de série e de critério de medição; o restante depende do problema. A maior parte dos ganhos vem de enxergar as esperas entre etapas e de investigar a causa antes de agir — nenhuma das duas exige análise estatística avançada.