PDCA e SDCA: diferença e quando usar cada ciclo
A equipe resolveu o problema das medições devolvidas pela fiscalização, comemorou na reunião de status e, quatro meses depois, as devoluções voltaram. Ninguém desfez a solução de propósito: entrou um engenheiro novo, o checklist ficou numa pasta que ele não conhecia, e o jeito antigo voltou. Esse vaivém é exatamente o que separa PDCA e SDCA, dois ciclos parecidos no nome e diferentes no objetivo.
O PDCA serve para mudar o jeito de trabalhar e atingir um resultado melhor. O SDCA serve para manter o jeito de trabalhar que já funciona. Quem usa só o primeiro melhora e perde; quem usa só o segundo conserva o que tem, mas não avança. A seguir você vê o que cada ciclo faz, a tabela de diferenças, como decidir qual girar em cada situação do projeto e como passar de um para o outro sem perder o ganho.
Formação relacionada
Panorama das habilidades técnicas e comportamentais esperadas de um gestor de projetos.
O que é PDCA, em poucas linhas
PDCA é a sigla de Plan, Do, Check, Act: planejar, executar, verificar e agir. Ele começa por uma meta que o processo atual não atinge, investiga as causas, testa uma mudança, mede o efeito e, se deu certo, transforma a mudança em padrão. É o ciclo da melhoria.
As quatro etapas aplicadas ao planejamento e ao controle do projeto estão em ciclo PDCA em projetos. Aqui interessa um ponto só: o PDCA termina com um padrão novo. E padrão novo, sem cuidado, não dura.
O que é SDCA
SDCA é a sigla de Standardize, Do, Check, Act: padronizar, executar, verificar e agir. O ciclo parte de um padrão que já entrega o resultado esperado e cuida para que ele continue sendo cumprido.
- Standardize (padronizar). O jeito certo de fazer está escrito, acessível e conhecido: procedimento, checklist, modelo de documento, critério de aceite, definição de pronto.
- Do (executar). As pessoas trabalham conforme o padrão, depois de treinadas nele. Quem entra no projeto aprende o padrão antes de executar.
- Check (verificar). Alguém confere se o padrão está sendo seguido e se o resultado continua dentro da meta. É verificação de rotina, não investigação.
- Act (agir). Se houve desvio, a ação é corretiva e rápida: retreinar, ajustar o modelo, corrigir o item fora do padrão. Se o padrão foi seguido e o resultado mesmo assim piorou, o problema é outro, e aí cabe abrir um PDCA.
No Brasil, a dupla ficou conhecida pela obra de Vicente Falconi sobre gerenciamento da rotina, que trata o PDCA de melhoria e o SDCA de manutenção como dois giros do mesmo método. Na literatura sobre kaizen, Masaaki Imai descreve a mesma divisão: a gestão tem uma parte de melhoria e outra de manutenção dos padrões, e a manutenção depende de treinamento e disciplina.
PDCA e SDCA: tabela de diferenças
| Critério | PDCA | SDCA |
|---|---|---|
| Objetivo | Melhorar: atingir uma meta que o processo atual não alcança | Manter: garantir que o resultado atual se sustente |
| Ponto de partida | Um problema ou uma meta nova | Um padrão que já funciona |
| Primeira etapa | Planejar a mudança (análise de causa, plano de ação) | Padronizar e treinar |
| Pergunta da verificação | A mudança trouxe o resultado esperado? | O padrão está sendo seguido e o resultado se mantém? |
| Ação típica | Adotar, ajustar ou abandonar a mudança | Corrigir o desvio e reforçar o padrão |
| Quem conduz | Gerente do projeto, PMO, equipe de melhoria | Dono do processo e a própria equipe, na rotina |
| Frequência | Por problema ou por meta, com início e fim | Contínua, a cada execução ou em verificações periódicas |
| Ferramentas comuns | Pareto, Ishikawa, 5 porquês, 5W2H | Procedimento, checklist, auditoria, indicador de rotina |
| Sinal de falha | Problema volta depois da melhoria | Padrão existe no papel e ninguém o segue |
A diferença central está na primeira letra. O PDCA planeja uma mudança; o SDCA parte de algo que não deve mudar até que um novo PDCA prove que existe um jeito melhor.
Quando usar cada ciclo no projeto
Uma pergunta resolve a maior parte dos casos: o resultado está dentro da meta?
- Está dentro e você quer que continue: gire o SDCA. Exemplo: o processo de aprovação de medições numa obra passou a sair sem devolução. O trabalho agora é garantir que todo engenheiro novo use o checklist e que alguém confira, por amostragem, as medições enviadas.
- Está fora e o padrão foi seguido: abra um PDCA. O padrão em si não dá conta, e é preciso investigar causas e testar mudanças.
- Está fora e o padrão não foi seguido: volte ao SDCA antes de qualquer outra coisa. Retreine, corrija o desvio e só depois avalie se o padrão é suficiente. Abrir um PDCA nesse caso desperdiça análise com um problema que é de disciplina, não de método.
- Não existe padrão: você não tem o que manter. Primeiro escreva o jeito atual de fazer, mesmo imperfeito, e meça o resultado. Uma frase atribuída a Taiichi Ohno resume a lógica: sem padrão, não há base para melhorar.
A terceira situação é a mais comum e a mais ignorada. Muitos problemas de projeto que parecem pedir melhoria são, na verdade, padrões combinados que ninguém cumpre.
Como os dois ciclos se alternam
Pense numa escada. O PDCA sobe um degrau; o SDCA segura a equipe no degrau enquanto o próximo PDCA não começa. O fluxo prático é este:
- SDCA em rotina. O processo roda conforme o padrão, com verificação periódica.
- Gatilho de melhoria. O indicador sai da meta sem desvio do padrão, ou a meta sobe (novo contrato, novo prazo, exigência do cliente).
- PDCA. A equipe analisa causas, testa uma mudança em pequena escala e mede.
- Padronização. A mudança aprovada vira o novo padrão: o procedimento é reescrito, o modelo atualizado, as pessoas treinadas.
- Volta ao SDCA, agora com o padrão novo.
O ponto frágil é a passagem do passo 4 para o 5. É ali que a melhoria se perde quando o "A" do PDCA vira só um parágrafo na ata. Na relação entre os dois métodos de melhoria contínua, o mesmo raciocínio aparece em PDCA e Kaizen: a melhoria pequena só soma quando cada passo é padronizado antes do seguinte.
Exemplo: implantação de sistema em várias unidades
O exemplo é ilustrativo. Um projeto implanta um sistema de gestão em oito unidades de uma rede, uma por mês.
Unidades 1 e 2: PDCA. Na primeira virada, 30% dos usuários não conseguiram acessar o sistema no primeiro dia. A equipe investigou e encontrou duas causas: cadastros de usuário feitos com dados incompletos e treinamento marcado para depois da virada. Testou na unidade 2 um roteiro novo: carga dos cadastros validada uma semana antes e treinamento na semana anterior à virada. O problema de acesso caiu para poucos casos isolados.
Padronização. O roteiro virou o checklist de pré-virada, com responsável por item, e entrou no plano de cada unidade.
Unidades 3 a 8: SDCA. Para cada virada, o coordenador da unidade segue o checklist (Do), o PMO confere os itens marcados uma semana antes (Check) e qualquer item atrasado gera ação imediata (Act). Na unidade 5, o indicador piorou. A verificação mostrou que o checklist foi seguido, mas a unidade tinha um perfil de usuário que não existia nas outras. Isso abriu um PDCA curto só para esse perfil, e o checklist ganhou um item novo.
Repare que o projeto não fez seis análises de causa. Fez duas e manteve o resultado nas outras com verificação simples.
Erros comuns com PDCA e SDCA
- Tratar desvio de padrão como problema novo. A equipe monta Ishikawa e plano de ação quando bastava conferir se o procedimento foi seguido.
- Padrão que ninguém encontra. Procedimento salvo numa pasta pessoal não é padrão. O SDCA começa por deixar o padrão acessível a quem executa.
- Check sem dono. "A equipe vai acompanhar" não é verificação. Defina quem confere, com que frequência e o que acontece com o desvio.
- Padrão engessado. O SDCA mantém, não proíbe mudar. Se o resultado piora com o padrão sendo seguido, insistir nele é teimosia.
- Fechar o projeto sem passar o padrão adiante. Em projetos, o padrão criado costuma morrer no encerramento. Registre-o como lição aprendida e entregue-o ao dono do processo na operação. O caminho para isso está em como aplicar lições aprendidas em novos projetos.
Onde o SDCA entra num projeto, que tem começo e fim
Um projeto é temporário, então pode parecer estranho falar em rotina. Mas todo projeto tem atividades repetidas: medições mensais, publicações de versão, reuniões de status, aceite de entregas, viradas em unidades diferentes. Nessas, o SDCA economiza retrabalho. E há um segundo momento: a transição para a operação. Se o projeto melhorou um processo do cliente, o padrão novo precisa de um dono que gire o SDCA depois que a equipe do projeto sair.
Para ver onde PDCA, SDCA, DMAIC, A3 e Kaizen se encaixam entre si, o comparativo de metodologias de melhoria contínua organiza a escolha. E para o conjunto de ferramentas que alimentam cada etapa, do Pareto ao gráfico de controle, veja o guia de ferramentas da qualidade em projetos.
Escolha o ciclo do problema desta semana
Pegue o problema que mais incomoda no projeto agora e responda às duas perguntas: o resultado está dentro da meta? O padrão foi seguido? Se o padrão não foi seguido, retreine e confira antes de qualquer análise. Se foi seguido e o resultado não veio, abra um PDCA com meta e prazo. Quando a melhoria funcionar, escreva o padrão no mesmo dia e diga quem vai verificá-lo. Para quem quer dominar esses ciclos dentro da gestão completa do projeto, a formação Gerente de Projetos Expert da Projeto Diário trabalha qualidade, controle e melhoria com casos práticos.
