Consultoria APS, S&OP e MES para Indústrias | LSB Siemens Partner
Por que projetos de planejamento falham — e por que o software quase nunca é o culpado
Até 75% dos projetos de planejamento industrial falham, e quase nunca pelo software. As três causas dominantes (gestão da mudança, qualidade de dados e equipes inexperientes) são humanas, processuais e preveníveis. Este guia mostra onde os projetos de digitalização realmente morrem, por que go-live não é sucesso, o que os projetos bem-sucedidos fazem diferente e como medir resultado pela operação (não só pelo cronograma). Para diretoria, PCP, produção e TI que decidem antes de investir.
Na manufatura discreta, 73% dos projetos de ERP falham em atingir seus objetivos, e o estouro médio de orçamento chega a 215% (Panorama Consulting Group, 2025 ERP Report). A McKinsey, depois de mais de 15 anos pesquisando transformações corporativas, chega a uma conclusão equivalente: cerca de 70% dos programas de mudança de grande porte não alcançam as metas declaradas, e menos de um terço dos executivos entrevistados afirma que a transformação da própria empresa melhorou o desempenho e sustentou essa melhoria ao longo do tempo.
Agora a parte que quase ninguém diz em uma reunião comercial: em pouquíssimos desses fracassos o software foi o problema. As três maiores causas de falha identificadas pelas pesquisas são: gestão da mudança inadequada, migração de dados malfeita e equipes inexperientes. Percebe o ponto em comum? Todas elas são humanas, processuais e inteiramente preveníveis. O software nunca foi o problema. É gente, processo e adoção, e quase ninguém está olhando para lá.
Este artigo é para quem vai decidir, conduzir ou sustentar um projeto de planejamento industrial. Ao final, você vai saber onde os projetos realmente morrem, o que os bem-sucedidos fazem de diferente e como medir sucesso de um jeito que o cronograma de implantação não consegue esconder.
Por que isso importa agora
A decisão de investir em um sistema de planejamento avançado (APS, MES, MPS ou a combinação deles) raramente é de uma pessoa. É de um comitê: diretoria industrial, PCP, produção, TI, às vezes finanças. Cada um carrega uma dor diferente e todos carregam o mesmo medo: gastar alto, mobilizar a fábrica por meses e terminar com um sistema subutilizado rodando ao lado da velha planilha.
Esse medo é racional. Os números acima mostram que ele se concretiza na maioria dos casos. O que não é racional é a explicação que o mercado costuma dar quando isso acontece: “a ferramenta não serviu para a nossa realidade”. Essa afirmação aponta para o único fator que, estatisticamente, quase nunca é a causa. Enquanto a conversa ficar presa na comparação de softwares, o comitê seguirá decidindo sobre a variável errada.
1. O tamanho do problema: o que os números mostram
As taxas de fracasso que as pesquisas registram
O fracasso em projetos de tecnologia industrial não é um acidente ocasional, mas sim o resultado mais provável. A pesquisa global da McKinsey com 1.034 executivos que participaram de transformações nos cinco anos anteriores encontrou que menos de um terço considera a transformação bem-sucedida em melhorar o desempenho da organização e sustentar essa melhoria. O próprio John Kotter, referência acadêmica em gestão da mudança, registra há décadas a mesma ordem de grandeza: mais de 70% das mudanças necessárias não são lançadas ou não são concluídas.
No recorte que interessa à indústria, o quadro é ainda mais duro. O levantamento da Panorama Consulting aponta que projetos de ERP em manufatura discreta falham em 73% dos casos em atingir seus objetivos, com estouros médios de orçamento de 215%, o pior desempenho entre todos os setores analisados. Faixas mais conservadoras de outras pesquisas situam o fracasso de projetos de ERP entre 55% e 75% dos casos. Em qualquer ponto dessa faixa, a mensagem é a mesma: o sucesso é exceção.
Mesmo entre os projetos considerados bem-sucedidos, os executivos estimam ter capturado, em média, apenas 67% do benefício financeiro máximo que a transformação poderia ter gerado. Ou seja: até quem “dá certo” deixa um terço do valor na mesa.
O custo real: orçamento, prazo e confiança
O custo visível de um projeto fracassado aparece no orçamento e no cronograma. O custo invisível é maior. Um APS implantado e abandonado contamina a próxima tentativa: o planejador que viu o sequenciamento automático gerar planos inexequíveis vai resistir (com razão) quando alguém propuser “tentar de novo”. A diretoria que aprovou o investimento uma vez vai exigir o dobro de garantias na segunda.
Há também o custo de oportunidade operacional. Enquanto o projeto patina, a fábrica continua sequenciando no Excel, reprogramando todo dia e apagando incêndio de prazo. Cada mês de atraso na estabilização é um mês de setup excessivo, estoque desbalanceado e promessa de entrega feita no escuro.
O teatro do sucesso
Se a maioria dos projetos falha, por que ninguém fala disso? Porque a categoria inteira (fornecedores, integradores, consultorias) comunica a mesma coisa: cases vitoriosos, selos de parceria, rankings de software. Todos celebram vitórias; ninguém discute o que de fato decide um projeto. O resultado é um mercado cético, que já ouviu todas as promessas e aprendeu a descontar a maioria delas.
A consequência prática para quem está avaliando um investimento: as estatísticas de fracasso não aparecem na proposta comercial de ninguém. Elas precisam entrar na conversa por iniciativa do comprador, de preferência antes da assinatura, não na reunião de “post-mortem”.
2. Por que o software quase nunca é o vilão
O que uma ferramenta FAZ e o que ele NÃO PODE FAZER
Um APS sequencia ordens com capacidade finita, respeitando regras de setup, calendários, gargalos e prioridades. Um MES captura a execução no chão de fábrica e devolve visibilidade em tempo real. São tecnologias maduras, testadas em milhares de plantas no mundo, com algoritmos que resolvem em minutos o que um planejador experiente não resolveria em um turno. Quem quiser entender cada camada dessas tecnologias em profundidade encontra o detalhamento no nosso guia de tecnologias MOM.
O que nenhuma dessas ferramentas faz: corrigir um roteiro de produção cadastrado errado, convencer um programador a confiar no plano gerado, redesenhar um processo de S&OP que não existe, ou impedir que a fábrica ignore a sequência e produza “o que o cliente que gritou mais alto pediu”. A ferramenta opera dentro das condições que a organização oferece a ela. Se as condições são ruins, o resultado é ruim com qualquer software.
O teste mental da troca de ferramenta
Há um teste simples para diagnosticar um projeto que fracassou: pergunte se trocar o software resolveria. Se os tempos de setup cadastrados estão defasados, a troca não resolve. Se o planejador não foi treinado nem envolvido no desenho da solução, a troca não resolve. Se a produção não aponta o que executa, a troca também não resolve. O novo sistema vai enxergar a mesma fábrica invisível que o anterior.
Na prática, a resposta a esse teste é quase sempre “não”. E quando a resposta é não, o problema nunca foi a ferramenta. Era gente, processo ou dado, e trocá-la apenas reinicia o ciclo de fracasso com um logotipo diferente.
As três causas que respondem pela maioria das falhas
As pesquisas convergem para três causas dominantes, que juntas respondem por cerca de 75% das falhas em implementações industriais.
- Gestão da mudança inadequada: a organização não foi preparada para a nova rotina; o sistema entra no ar, mas as pessoas seguem trabalhando como antes.
- Migração e qualidade de dados: cadastros, roteiros, tempos e estoques migrados sem validação; o sistema calcula certo sobre uma base errada.
- Equipes inexperientes: times de implantação que dominam o software, mas não a operação industrial; ou times internos sem dedicação real ao projeto.
3. Gente: a variável que decide o ROI
Gestão da mudança não é treinamento de véspera
Em muitos projetos, “gestão da mudança” significa um treinamento de oito horas na semana do go-live e um manual em PDF. Isso não é gestão da mudança, é cumprimento de cronograma. Gestão da mudança real começa no diagnóstico: envolve os futuros usuários no desenho da solução, explicita o que muda na rotina de cada papel, define “quem decide o quê” quando o plano e a realidade divergirem, e cria os rituais que sustentam o uso depois que a consultoria for embora.
As transformações que chegam perto de capturar o benefício financeiro total são as que engajam as pessoas. Comunicação face a face, líderes de linha explicando o porquê, metas traduzidas para o dia a dia de cada função. Em um projeto de planejamento, isso significa que o programador de PCP precisa entender não só como usar o sequenciador, mas por que o critério de priorização mudou e o que ele ganha com isso.
O planejador que volta para a planilha
Existe um padrão de fracasso tão comum que merece nome próprio: o retorno silencioso à planilha. O sistema está implantado, a licença está paga, e três meses depois o planejador mantém uma planilha paralela “só para conferir”, que aos poucos volta a ser a fonte oficial da programação. O sistema vira um repositório caro de dados que ninguém consulta.
Esse padrão nasce de desconfiança legítima: o plano gerado na primeira semana era inexequível (porque os dados estavam errados), ninguém ajustou os parâmetros (porque a equipe de projeto já tinha sido desmobilizada), e a planilha (frágil, manual, mas conhecida) voltou a ser o refúgio. As pessoas não adotam aquilo em que não confiam. E confiança se constrói no projeto, não no go-live.
A expertise que se aposenta — o risco que ninguém contabiliza
Há um agravante que o mercado brasileiro conhece bem: boa parte do conhecimento de planejamento das indústrias está na cabeça de poucas pessoas. O programador com 25 anos de casa que sabe de cor qual máquina aceita qual produto, qual setup é traiçoeiro, qual cliente tolera atraso. Quando essa pessoa se aposenta ou sai, a empresa descobre que seu processo de planejamento nunca foi um processo: era uma pessoa.
Um projeto de planejamento bem conduzido é a oportunidade de transformar esse conhecimento tácito em regra explícita, cadastrada, auditável e transferível. Um projeto mal conduzido faz o oposto: ignora o veterano, parametriza o sistema sem capturar o que ele sabe, e entrega um plano que a fábrica inteira reconhece como ingênuo. A adesão morre na primeira semana.
4. Processo: resolver o problema antes de escolher a ferramenta
Automatizar o processo errado só acelera o erro
A pergunta “qual ferramenta devemos comprar?” costuma chegar antes da pergunta que deveria precedê-la: “como o nosso processo deveria funcionar?”. Quando a ordem se inverte, o projeto automatiza o processo existente, com seus vícios, exceções e gambiarras. O resultado é o mesmo caos de antes, mas executado mais rápido.
Exemplos concretos do que precisa ser resolvido antes da parametrização (para o exemplo de um APS): qual é o critério oficial de priorização quando dois pedidos disputam o mesmo gargalo? O sequenciamento respeita famílias de setup ou data prometida? Quem tem autoridade para furar a fila, e com que justificativa registrada? Se essas respostas não existem no processo, o software vai recebê-las por omissão, e a omissão vira regra.
As regras de negócio que só existem na cabeça de alguém
Toda fábrica complexa opera com dezenas de regras não escritas: a extrusora 3 não roda material reciclado depois de pigmento claro; o cliente X exige lote dedicado; a montagem do equipamento Y não pode começar sem a liberação da engenharia. Em operações sob encomenda (ETO/MTO), essas regras se multiplicam, e cada pedido carrega sua própria estrutura. A sincronização entre engenharia, compras e produção vira o próprio produto.
Um projeto sério dedica semanas a extrair, validar e formalizar essas regras antes de tocar no sistema. É trabalho de processo, não de TI. É aqui onde se separa a consultoria que entende de operação industrial do integrador que entende só de software. Pular essa etapa é o jeito mais caro de descobrir que ela existia.
O desenho do modelo futuro vem antes da parametrização
Entre o diagnóstico e a implementação existe uma etapa que projetos apressados suprimem: o desenho do modelo futuro. É nela que se define como planejamento e execução devem funcionar: fluxos, papéis, rituais de S&OP e S&OE, pontos de decisão, indicadores. O princípio desses processos cabe em uma frase: a ferramenta é consequência do modelo, nunca o contrário.
Quando o modelo futuro existe, a parametrização vira tradução. Quando não existe, a parametrização vira improviso, e cada decisão técnica tomada por omissão durante a implantação vira uma regra de negócio que ninguém escolheu conscientemente.
5. Dados: otimizar sobre dado ruim é achismo automatizado
Os cadastros que sustentam (ou derrubam) o plano
Um sistema de planejamento avançado é tão bom quanto os dados que o alimentam: roteiros de produção, tempos de ciclo, tempos de setup (e suas dependências de sequência), calendários de turno, taxas de refugo, estoques, lead times de compra. Se o tempo de setup cadastrado é o da planilha de 2018, o plano otimizado de hoje está otimizando uma fábrica que não existe mais.
Otimizar sobre dado ruim não é otimização, é achismo automatizado. O algoritmo entrega exatamente o que prometeu: a melhor resposta possível para uma pergunta errada.
O efeito perverso é que o dado ruim não quebra o sistema; ele quebra a confiança. O plano sai “bonito” e inexequível, a fábrica percebe na primeira semana, e a credibilidade do projeto (aquela que a gestão da mudança levou meses construindo) evapora. É por isso que dado é causa raiz de fracasso tão frequente quanto gente e processo: ele detona a adoção por tabela.
Migração de dados: a causa técnica mais subestimada
Entre as três causas dominantes de falha, a migração de dados é a única de natureza técnica, e mesmo ela é, no fundo, um problema de gestão. Migrar dados não é transportar tabelas: é decidir o que merece ser migrado, limpar o que está obsoleto, validar com quem vive a operação e estabelecer quem é o dono de cada cadastro dali em diante. Sem dono, todo cadastro degrada; a única dúvida é a velocidade.
Projetos bem conduzidos tratam a base de dados como entregável próprio, com critérios de aceite, amostragem validada no chão de fábrica e responsáveis nomeados. Projetos malconduzidos tratam a migração como tarefa de fim de cronograma e descobrem o custo disso depois do go-live, quando corrigir é dez vezes mais caro.
Como saber se seus dados aguentam um sistema de planejamento avançado
Três verificações rápidas antes de qualquer projeto.
- Primeira: pegue dez roteiros de produtos de alto volume e compare os tempos cadastrados com a realidade apontada do último trimestre. Desvios sistemáticos acima de 15–20% indicam base frágil.
- Segunda: pergunte quem é o responsável formal pela manutenção dos tempos de setup; se a resposta for “ninguém” ou “todo mundo”, a resposta é ninguém.
- Terceira: verifique se a fábrica aponta produção em tempo razoável ou se o apontamento é reconstruído no fim do turno. Planejamento em tempo real sobre apontamento de véspera é ficção.
Falhar nessas verificações não significa desistir do projeto. Significa que a etapa de dados precisa vir primeiro, e que qualquer fornecedor que proponha pular direto para a implantação está vendendo o fracasso estatisticamente mais provável.
6. Adoção: go-live não é sucesso
“Sistema no ar” NÃO SIGNIFICA “sistema em uso”
O go-live é o momento mais celebrado de um projeto (e o menos informativo). Ele prova que o sistema funciona tecnicamente. Não prova que a operação decide com ele. Adoção é o sucesso; go-live é só o começo da prova real. Um sistema “no ar” que não muda como a fábrica planeja, sequência e executa é um centro de custo com cerimônia de inauguração.
A diferença aparece em perguntas simples: a reunião diária de produção discute o plano do sistema ou uma planilha exportada e editada? Quando um pedido urgente entra, ele é simulado no sequenciador ou encaixado no grito? O indicador de aderência ao plano é medido, publicado e cobrado, ou ninguém sabe dizer qual é?
As métricas de adoção que antecipam o resultado
Adoção se mede, e se mede cedo. Quatro sinais vitais nos primeiros meses: percentual da programação efetivamente gerada pelo sistema (versus ajustada manualmente fora dele); frequência de replanejamento dentro da ferramenta; latência e completude do apontamento de produção; e aderência ao plano — quanto do que foi programado foi executado na sequência programada.
Esses indicadores antecipam o ROI porque o ROI depende deles. Redução de setup só acontece se a fábrica seguir a sequência otimizada. Confiabilidade de prazo só melhora se a promessa de entrega sair do sistema, não do feeling. Quem mede apenas “projeto entregue no prazo e no orçamento” está medindo o esforço, não o resultado.
Aderência ao plano: o exemplo de quem saiu de 33% para 80%
Um exemplo real do que adoção significa em números: a Seta Embalagens, indústria do setor de embalagens, operava com aderência ao plano de 33%. Isso significa que dois terços do que se programava não se cumpria como programado. Com processo redesenhado, dados tratados e a operação efetivamente usando o sistema, a aderência subiu para 80%, e o tempo total de setup caiu de mais de 100 horas para 60 horas (confira o case completo da Seta Embalagens).
O ponto não é o software que foi implantado, mas sim o que o número de partida revela. Aderência de 33% não é um problema de ferramenta; nenhum algoritmo do mundo conserta uma fábrica que não segue o próprio plano. O salto para 80% foi um salto de processo e de adoção, viabilizado pela tecnologia. A ordem dos fatores é essa, e ela não é comutativa.
Quer entender melhor sobre Aderência à Programação?
Baixe agora o e-book GRATUITO e entenda de vez o que esse indicador está te dizendo!
7. O que os projetos que dão certo fazem diferente
A tecnologia é uma etapa entre seis
Projetos bem-sucedidos tratam a implantação do software como uma etapa do caminho, não como o caminho. Na prática da LSB, o método tem seis etapas: diagnóstico de maturidade; desenho do modelo futuro; dados e integrações; implementação da tecnologia; capacitação e adoção; e evolução contínua. Repare na aritmética: quatro das seis etapas (diagnóstico, desenho, capacitação e evolução) são gente, processo e adoção. A tecnologia é uma entre seis.
Isso não diminui a tecnologia; contextualiza. O portfólio Siemens Opcenter que a LSB implementa é referência global em MOM, e é justamente por o produto ser de classe mundial que a estatística de fracasso do mercado precisa de outra explicação. O que separa um projeto que transforma a operação de um projeto que vira case de gaveta não é a ferramenta: é como ela é implantada, adotada e evoluída.
O que os resultados reais têm em comum
Os números que sustentam essa tese vêm de projetos reais, não de teoria. A Coamo, uma das maiores cooperativas agroindustriais do país, reduziu o ciclo de MPS/MRP/Scheduling de horas para cerca de 10 minutos, depois de já ter tentado outras soluções sem sucesso. A Parnaplast, do setor plástico, reduziu setups em 30%, aumentou a produtividade em 32% e cortou 94% do tempo de programação. A Fockink, em equipamentos sob encomenda, reduziu o lead time em 58% e aumentou a pontualidade em 40% (confira os cases na íntegra).
O que esses projetos têm em comum com certeza não é o setor, afinal, são três realidades industriais distintas. É a sequência: diagnóstico honesto, processo desenhado antes da parametrização, base de dados tratada como entregável, operação envolvida desde o início e indicadores de adoção acompanhados depois do go-live. O caso Coamo é particularmente instrutivo: a mesma empresa, com tentativas anteriores frustradas, obteve resultado quando o método mudou, não quando o problema mudou.
As perguntas a fazer antes de assinar qualquer proposta
Quem está avaliando fornecedores pode usar a estatística de fracasso a seu favor, transformando-a em filtro. Cinco perguntas que separam método de promessa:
- Como vocês diagnosticam a maturidade do nosso planejamento antes de propor escopo — e o que acontece se o diagnóstico indicar que não estamos prontos?
- Qual é o plano de tratamento e validação de dados, com critérios de aceite, antes da parametrização?
- Quem do nosso time precisa estar dedicado, com quantas horas, em cada fase?
- Como vocês medem adoção depois do go-live e por quanto tempo acompanham?
- Que projeto de vocês não saiu como o planejado, e o que mudou no método por causa dele?
Falhar nessas verificações não significa desistir do projeto. Significa que a etapa de dados precisa vir primeiro, e que qualquer fornecedor que proponha pular direto para a implantação está vendendo o fracasso estatisticamente mais provável.
8. Como medir o sucesso real de um projeto de planejamento
KPIs de operação (não de cronograma)
“Entregue no prazo e no orçamento” mede a saúde do projeto, não o sucesso do investimento. Sucesso real se mede na operação, comparando antes e depois: aderência ao plano, tempo total de setup por período, tempo de ciclo de planejamento (quanto demora gerar e ajustar um plano executável), confiabilidade de promessa de entrega (OTIF), giro e cobertura de estoque, e horas de esforço do time de PCP por ciclo de programação.
A linha de base precisa ser capturada antes do projeto (depois, ela desaparece). Parte do valor do diagnóstico inicial é exatamente esse: registrar, com números, como a operação funciona hoje, para que o “depois” tenha contra o que ser comparado. Sem linha de base, todo projeto vira sucesso por aclamação, e a próxima decisão de investimento volta a ser tomada no escuro.
A janela dos 12 meses
Os ganhos de um projeto de planejamento não aparecem no go-live; aparecem na curva dos meses seguintes, à medida que a operação confia, ajusta parâmetros e amplia o uso. Por isso a avaliação séria acontece em janelas: estabilização nos primeiros 90 dias (sistema em uso real, apontamento fluindo, planejamento rodando na ferramenta), primeiros ganhos mensuráveis em 6 meses, e leitura consolidada de ROI em 12 meses.
Essa janela também define o contrato psicológico com a diretoria: prometer transformação no go-live é armar a própria frustração; mostrar a curva de adoção e os indicadores subindo mês a mês é construir o caso para a evolução contínua, com novas áreas, novos módulos, mais profundidade. Os projetos que viram referência interna são os que tratam o pós-go-live como fase do projeto, não como ausência dele.
Próximo Passo
Se a maioria dos projetos falha por causas conhecidas e preveníveis, a pergunta certa antes de investir não é “qual software escolher”, mas sim “onde estão as nossas fragilidades de gente, processo e dado”.
É exatamente isso que o Diagnóstico de Maturidade da LSB responde: uma avaliação estruturada do seu planejamento atual (dados, processos, papéis e indicadores) com a indicação objetiva do que resolver antes (e durante) qualquer implantação.
Faça seu diagnóstico GRATUITO!
Entenda de forma simples e clara como
está o desempenho do seu PPCP!
FAQ
- Qual é a taxa de fracasso de projetos de ERP e de planejamento industrial? As pesquisas situam o fracasso entre 55% e 75% dos projetos, dependendo do recorte e do critério. Na manufatura discreta, o levantamento da Panorama Consulting (2025) aponta 73% de projetos que não atingem seus objetivos, com estouro médio de orçamento de 215%. A McKinsey (2021) encontra cerca de 70% de insucesso em transformações de grande porte em geral.
- Por que projetos de APS e MES falham mesmo com um bom software? Porque as causas dominantes de falha não são tecnológicas: gestão da mudança inadequada, migração e qualidade de dados ruins e equipes inexperientes respondem pela maioria dos fracassos. O software opera dentro das condições que a organização oferece. Processos indefinidos, cadastros defasados e usuários não engajados produzem mau resultado com qualquer ferramenta.
- O que é mais importante em um projeto de planejamento: a ferramenta ou a implementação? A ferramenta é pré-requisito; a implementação é o diferencial. Tecnologias líderes de mercado têm capacidade comprovada globalmente, e mesmo assim a taxa média de fracasso do mercado é alta. A variável que separa sucesso de fracasso é a execução: diagnóstico, processo, dados, adoção e evolução.
- O que é gestão da mudança em projetos de sistemas industriais? É o trabalho estruturado de preparar a organização para operar de um jeito novo: envolver os usuários no desenho da solução, redefinir papéis e rituais de decisão, treinar com profundidade e sustentar o uso depois do go-live. Não se resume a treinamento — começa no diagnóstico e continua meses após a implantação.
- Go-live significa que o projeto deu certo? Não. Go-live prova que o sistema funciona tecnicamente; sucesso é a operação decidir com ele no dia a dia. A medida que importa é a adoção: percentual da programação gerada no sistema, qualidade do apontamento e aderência ao plano. Um sistema no ar sem uso real é custo, não resultado.
- Como saber se minha empresa está pronta para implementar uma ferramenta? Três verificações iniciais: a confiabilidade dos dados mestres (roteiros, tempos, estoques), a existência de processos definidos de planejamento e priorização, e a disponibilidade real do time para se dedicar ao projeto. Um diagnóstico de maturidade formaliza essa avaliação e indica o que resolver antes de investir, reduzindo drasticamente o risco de engrossar a estatística de fracasso.
- Quanto tempo leva para um projeto de planejamento gerar resultado? A estabilização do uso ocorre tipicamente nos primeiros 90 dias após o go-live; os primeiros ganhos mensuráveis aparecem em torno de 6 meses; a leitura consolidada de retorno se faz em 12 meses (isso não é uma regra, esses números podem variar). Resultados dependem da curva de adoção, por isso, projetos sérios acompanham indicadores de uso desde a primeira semana.
