Reduzir custos de fabricação: não resolva duas vezes um problema que outro já resolveu

A redução de custos na fabricação costuma ser vista como uma corrida constante por novas ideias. Mas vale a pena parar primeiro para perguntar: uma empresa realmente precisa de uma solução nova toda vez, ou passa a maior parte do tempo resolvendo de novo um problema que outro engenheiro ou outra fábrica já resolveu?

Cada fábrica resolve o mesmo problema do zero, toda vez

Quando o preço da matéria-prima sobe, a engenharia vai atrás de um material substituto. Quando o custo de mão de obra sobe, a produção procura formas de reduzir o efetivo de uma etapa. Quando o tempo de ciclo está muito alto, os engenheiros se sentam para melhorar a máquina ou o processo. Quando a taxa de defeitos sobe, qualidade e produção saem à caça da causa. Cada uma dessas ações é necessária e correta — o problema não é que precisem ser feitas, é que quase toda vez se começa do zero: analisar a situação atual, encontrar a causa, fazer brainstorming, testar, avaliar, e só então implementar.

Enquanto isso, esse tipo de problema se repete muito mais do que se imagina, e a maioria já foi enfrentada por alguém antes. Um engenheiro de usinagem já reduziu o tempo de ciclo de uma peça mudando a ordem das etapas de usinagem. Outra fábrica já reduziu o desperdício de material no mesmo tipo de produto mudando a forma de aninhamento dos cortes na chapa. Um engenheiro de manutenção já levou semanas para encontrar a real causa de uma linha que parava repetidamente. Isso não é raro — acontece na maioria das fábricas, quase toda semana, só que nunca duas vezes no mesmo lugar ao mesmo tempo.

As soluções não faltam — estão trancadas, espalhadas por toda parte

O conhecimento sobre redução de custos na fabricação não é escasso. Ele só está fragmentado. Parte está na cabeça do engenheiro que fez o trabalho pessoalmente. Parte está num único arquivo Excel no computador de quem o escreveu. Parte está num relatório Kaizen salvo com um nome como `Kaizen_Final_2024_v3.xlsx` — alguns anos depois, quase ninguém lembra o que há nele, e quem o abre não tem certeza se é mesmo a versão final. O resto está espalhado em e-mails, desenhos, orçamentos de fornecedores, atas de reunião, e, mais do que tudo, na memória oral de quem está na fábrica há tempo suficiente.

Uma empresa pode já ter uma enorme quantidade de conhecimento sobre redução de custos — e ainda assim não ter capacidade de encontrar a peça certa exatamente no momento em que precisa. Um engenheiro pede demissão ou muda de setor, e a solução vai junto com ele. O conhecimento não se perde, mas escapa do alcance de quem precisará dele em seguida.

A pergunta que precisa mudar

A pergunta comum diante de um problema de custo é: "Que ideia consigo pensar para isso?" A pergunta que vale a pena fazer primeiro é diferente: "Alguém já resolveu esse problema?"

A diferença entre as duas perguntas não é pequena. A primeira começa do zero — reanalisar, testar de novo, cometer de novo erros que outra pessoa talvez já tenha cometido. A segunda começa de um ponto que já tem embasamento: se um problema semelhante já foi resolvido e o resultado medido, o engenheiro tem um lugar para buscar antes de pensar sozinho, e um lugar para comparar antes de confiar na própria abordagem. Isso não significa copiar integralmente a solução de outra pessoa — as condições reais de cada fábrica são sempre diferentes. Significa não precisar gastar esforço reinventando um conhecimento pelo qual outra pessoa já pagou em tempo e dinheiro.

Costdown não é uma biblioteca de conteúdo

Uma biblioteca de conteúdo consegue responder "dez formas de reduzir o custo de solda". Mas um engenheiro diante de um problema real não precisa de um artigo genérico — ele precisa de uma resposta para a sua situação concreta.

Suponha que um engenheiro esteja produzindo estruturas de tubo de aço, o tempo de solda atual seja de cerca de 50 segundos por peça, dois operadores, alguns milhares de peças por dia, e ele queira reduzir o custo de mão de obra dessa etapa. A pergunta nesse momento não é "como soldar mais rápido" de forma genérica, mas "alguém já resolveu um problema em condições mais ou menos parecidas, e qual resultado essa pessoa mediu". (Os números aqui servem apenas para ilustrar uma situação — não são dados de um projeto específico.)

É exatamente essa a fronteira entre duas coisas facilmente confundidas: conteúdo ajuda o leitor a entender um conceito; dados estruturados ajudam alguém a encontrar, comparar e reutilizar a solução certa para as próprias condições. O Costdown foi construído para a segunda coisa. Ele não substitui a leitura e compreensão, nem o pensamento do próprio engenheiro — existe uma etapa antes, no ponto que decide se o engenheiro precisa ou não começar do zero.

Uma solução não deveria morrer junto com quem a criou

O Costdown se apoia numa premissa: uma solução de redução de custo já comprovada não deveria desaparecer junto com o projeto, com o arquivo Excel, ou com o engenheiro que a criou. Um projeto de redução de custo bem-sucedido deveria virar dado estruturado — um dado que possa ser encontrado, que possa ser comparado, e o que já foi comprovado deveria poder ser reutilizado no próximo problema.

Uma fábrica resolve um problema. Outra fábrica não precisa começar do zero.