Rollout de IBP, mês 18: o que erramos
O sistema entrou no ar. As previsões melhoraram marginalmente. A organização brigou com o processo por dezoito meses. Um post-mortem sobre o que uma transformação de IBP custa de verdade.
O go-live aconteceu numa terça-feira de outubro. O diretor do programa mandou um e-mail para o comitê diretivo. Dashboard verde. Todos os marcos atingidos. O sistema estava no ar em seis mercados, cobrindo 78% da receita, com 14 meses de dados históricos carregados e o motor de previsão estatística rodando todas as noites.
Em março seguinte, três dos seis mercados tinham voltado a manter arquivos paralelos de Excel ao lado do sistema. A planejadora de demanda do maior mercado tinha silenciosamente reconstruído toda a sua planilha de planejamento e exportava do sistema para ela todas as manhãs. O processo de S&OP que a ferramenta de IBP deveria viabilizar rodava aproximadamente no mesmo nível de maturidade em que rodava antes da implementação de US$ 4,2 milhões.
Isto é um post-mortem. Nomes foram trocados. O padrão não é incomum.
O que o IBP deveria entregar
Integrated Business Planning é a forma evoluída do S&OP - a mesma lógica de alinhamento interfuncional, estendida para cobrir o horizonte de planejamento completo (tipicamente 24 a 36 meses), totalmente integrada ao planejamento financeiro, e viabilizada por uma única plataforma de planejamento em vez da colcha de retalhos de Excel e ERP que a maioria das empresas roda.
Os fornecedores - SAP IBP, o9 Solutions, Kinaxis, OMP, Anaplan - prometem versões do mesmo resultado: uma versão única da verdade, capacidade de planejamento de cenários, reconciliação de oferta e demanda em tempo real, e a eliminação da sobrecarga de reconciliação manual que mata a produtividade na maioria das equipes de planejamento.
O Gartner Market Guide for Supply Chain Planning Solutions (2023) estima que empresas com capacidade madura de IBP alcançam reduções de 15-20% em estoque, melhora de 10-15% na acurácia de previsão, e redução de 20-30% no ciclo de planejamento. Esses são números reais de implementações reais. São também os números do quartil superior das implementações. A história mediana é diferente.
O que a pesquisa diz sobre falha de implementação de IBP
O relatório 2023 ERP/Planning da Panorama Consulting, cobrindo 271 implementações, constatou que 58% das implementações de planejamento de supply chain estouraram o orçamento original, com estouro médio de custo de 24%. O estouro médio de cronograma foi de 33%. Mais significativo: apenas 41% dos respondentes disseram que a implementação entregou os benefícios de negócio esperados dentro de três anos após o go-live.
Um estudo da Gartner de 2022 constatou que a causa nº 1 de falha em implementações de planejamento de supply chain foi a gestão de mudança organizacional, citada por 67% dos respondentes - à frente de problemas de tecnologia (31%), qualidade de dados (48%) e lacunas de design de processo (44%). Note que qualidade de dados foi citada por quase metade dos respondentes, mas ainda assim ficou abaixo de gestão de mudança.
A análise de 2023 do Boston Consulting Group sobre transformações digitais de supply chain constatou que 70% das transformações digitais de supply chain falharam em atingir seus objetivos declarados - um número consistente com a taxa mais ampla de falha em transformação digital, que a McKinsey estimou em 70% entre setores.
O que as estatísticas agregadas não capturam é a textura específica de como as implementações de IBP falham. O sistema funciona. Os dados carregam. Os modelos estatísticos rodam. A falha está na adoção - e a falha de adoção segue um padrão consistente.
Mês 1-3: a lua de mel
Os três primeiros meses após o go-live são genuinamente produtivos. A equipe de planejamento foi intensamente treinada. Os consultores ainda estão no local. O comitê diretivo está prestando atenção. Problemas de qualidade de dados que eram conhecidos mas tolerados no sistema antigo estão sendo ativamente endereçados porque o novo sistema os torna visíveis.
A acurácia de previsão melhora modestamente - tipicamente 3 a 5 pontos percentuais - porque os novos modelos estatísticos são melhores do que os baseados em Excel que substituíram, e porque a limpeza de dados feita durante a implementação removeu parte do ruído do histórico.
A equipe está aprendendo a ferramenta. Todo ciclo de planejamento é mais lento do que antes porque o processo é desconhecido. Isso é esperado e comunicado. Os consultores explicam que há uma queda de produtividade antes da curva subir. O comitê diretivo aceita isso. O diretor do programa reporta que as métricas de adoção estão no rumo certo.
Mês 4-6: a primeira crise
Algo dá errado com os dados. É sempre algo com os dados.
No caso que descrevo, foi o histórico promocional. A empresa rodava promoções comerciais significativas - ofertas BOGOF, descontos por volume, promoções de preço coordenadas com contas-chave - e os dados históricos carregados no sistema não sinalizavam sistematicamente esses períodos. A previsão estatística, portanto, extrapolava a partir de um histórico que incluía uplifts promocionais sem saber que eram uplifts promocionais. O resultado foi uma previsão de baseline estruturalmente enviesada para cima em certos SKUs.
Os planejadores de demanda sabiam disso. Sabiam havia anos. No sistema antigo, corrigiam manualmente, usando conhecimento institucional sobre quais períodos eram promocionais e mais ou menos quanto descontar do histórico. O novo sistema não tinha esse conhecimento. A lógica de correção deveria ter sido construída durante a implementação. Foi parcialmente construída - o suficiente para passar no UAT - mas não robusta o bastante para lidar com toda a variedade de mecânicas promocionais que a empresa usava.
A planejadora de demanda do mercado três, que estava na função havia nove anos, levantou o ponto na semana seis. A resposta da equipe de implementação foi que uma correção estava sendo escopada. A correção levou onze semanas para ser totalmente implementada. Durante essas onze semanas, ela manteve seu arquivo de Excel.
Ela nunca parou de vez.
Mês 7-12: a saída dos consultores
A equipe de consultoria saiu no mês oito. Isso é padrão. O contrato de implementação cobre go-live e um período de estabilização. No mês oito, a estabilização é declarada. Os consultores transferem conhecimento para a equipe interna, documentam o processo e saem.
O que sai com eles: o conhecimento institucional de por que certas decisões de design foram tomadas, a capacidade de escalar problemas de dados rapidamente dentro da estrutura de suporte do fornecedor, e a energia de mudança que mantinha o comitê diretivo engajado.
O que fica: uma equipe interna que entende a ferramenta no nível de usuário mas não no nível de configuração, um conjunto de documentos de processo que descrevem como o processo deveria ser em vez de como ele realmente é, e um contrato de suporte do fornecedor que trata bugs mas não adoção.
O primeiro ciclo de S&OP depois que os consultores saíram levou três dias a mais do que o ciclo anterior. A reunião de revisão de demanda estourou duas horas do horário porque um problema de dados no sistema não pôde ser diagnosticado na sala. O time comercial, que vinha tolerando os ciclos mais lentos por deferência ao programa, começou a perguntar abertamente se o novo sistema era mesmo melhor que o antigo.
Mês 13-18: o problema dos arquivos paralelos
No mês treze, os arquivos paralelos de Excel já eram visíveis para quem soubesse onde olhar.
Não eram segredo. As planejadoras não os escondiam. Eram adaptações práticas a lacunas específicas do sistema. A planejadora de demanda do mercado um tinha um arquivo para gerenciar lançamentos de novos produtos - o processo de NPI do sistema era lento demais para a velocidade com que o comercial lançava produtos. A planejadora do mercado quatro tinha um arquivo para gerenciar previsões específicas de cliente - três contas-chave exigiam envios semanais de previsão que não encaixavam nos buckets de planejamento do sistema. A planejadora do mercado três tinha seu arquivo de correção de histórico promocional, que nunca chegou a ser totalmente substituído.
Cada arquivo era uma resposta razoável a uma lacuna real. Cada arquivo também era uma fratura na "versão única da verdade" que a implementação de IBP prometia vender.
O problema se acumula porque os arquivos não ficam contidos. Uma vez que uma planejadora tem um arquivo paralelo em que confia mais do que no sistema para um propósito, a fronteira dessa confiança se expande. Ela passa a checar o número do sistema contra o dela antes de confirmar. Quando divergem, ela usa o próprio número. O sistema vira o insumo do processo dela em vez do resultado.
No mês dezoito, a diretora de planejamento não conseguia dizer ao comitê diretivo, com confiança, que os números no sistema de IBP eram os números com os quais os mercados de fato estavam planejando.
O que realmente falhou
Não a tecnologia. O SAP IBP é um sistema capaz. O motor de previsão funciona. As ferramentas de planejamento de cenários funcionam. A integração financeira funciona.
Não os dados. A qualidade de dados foi genuinamente melhorada pela implementação - o cadastro mestre ficou mais limpo, os dados históricos mais completos, e o problema do histórico promocional, embora tenha levado três meses, foi corrigido.
O que falhou foram três coisas que a metodologia de implementação não endereçou adequadamente:
O processo foi desenhado para a organização aspiracional, não para a organização que existia. O processo de estado futuro assumia que o comercial forneceria input de volume promocional estruturado em cadência mensal. Na prática, o comercial fornecia informação promocional deal a deal, muitas vezes duas semanas antes da execução, em formatos que variavam por mercado e por gerente de contas-chave. A lacuna de design de processo entre "comercial insere uplift de volume mensalmente" e "comercial liga para o planejamento na quinta-feira antes de uma promoção entrar no ar" nunca foi fechada.
Os incentivos não mudaram. Os planejadores de demanda eram medidos pela acurácia de previsão. A previsão estatística do sistema de IBP era o baseline deles - mas o bônus deles era calculado pela acurácia da previsão de consenso, pela qual eram responsáveis ao ajustar o baseline estatístico. Quando o baseline estatístico do sistema estava errado (como no caso do histórico promocional), ajustá-lo corretamente melhorava a acurácia. Mas o ajuste levava tempo e exigia defender o override diante do time comercial. O caminho de menor resistência era manter o arquivo de Excel, usá-lo para produzir o número certo, e inserir esse número no sistema. O sistema registrava o resultado. O arquivo de Excel continha o raciocínio.
O programa de gestão de mudança terminou no go-live. A frente de trabalho de gestão de mudança na implementação - comunicações, treinamento, gestão de stakeholders - foi estruturada em torno da adoção da ferramenta, não da adoção do processo. Media se os usuários conseguiam operar o sistema, não se confiavam nele o suficiente para parar de usar alternativas. Depois do go-live, o orçamento de gestão de mudança se esgotou e a atenção seguiu adiante. A resistência da organização ao processo - que tinha sido suprimida durante a implementação pela energia do programa - ressurgiu assim que essa energia foi retirada.
O que uma transformação de IBP real exige e ninguém orça
Com base no post-mortem, e no que já vi em outras implementações:
O Ano 2 é a implementação de verdade. O primeiro ano é a implantação do sistema. O segundo ano é o processo de fato pegando - o que exige recurso interno dedicado, atenção executiva contínua, e orçamento para as correções que emergem do uso real. A maioria dos contratos de implementação orça o Ano 1. O Ano 2 é uma reflexão tardia.
Um arquiteto de processo que não seja funcionário do fornecedor. Os consultores de implementação dos fornecedores são especialistas em implantar a ferramenta dentro da arquitetura de referência do fornecedor. Não têm incentivo para dizer que o processo comercial da sua organização é estruturalmente incompatível com ciclos mensais de planejamento. Esse julgamento exige alguém que responda pelos resultados do seu negócio, não pelo projeto de implementação.
Alinhamento de incentivos antes do redesenho de processo. Se a estrutura de bônus do time comercial recompensa receita no ano corrente sem considerar a acurácia de previsão, nenhum processo de IBP produzirá sinais de demanda honestos. O processo é derivado do incentivo. Corrigir o processo sem corrigir o incentivo produz números que parecem corretos, mas não refletem a realidade comercial.
Uma avaliação honesta dos arquivos paralelos. No mês dezoito, a resposta certa para o problema dos arquivos paralelos não era mandar as planejadoras pararem de usá-los. Era entender por que cada arquivo existia, corrigir as lacunas que os criaram, e conquistar a confiança que faria as planejadoras dispostas a abrir mão deles. Não fizemos isso rápido o suficiente.
O número que importa
Nos dezoito meses entre o go-live e o momento em que este post-mortem foi encomendado, a implementação de IBP tinha custado a taxa de implementação original de US$ 4,2 milhões, mais aproximadamente US$ 1,1 milhão em estabilização e correções, mais uma estimativa de 2.400 horas-pessoa de tempo interno de planejamento gasto gerenciando a diferença entre o sistema e os arquivos paralelos.
A acurácia de previsão, a métrica de manchete, tinha melhorado 4 pontos percentuais em relação ao baseline. O estoque tinha reduzido 8% em dois mercados e aumentado 3% em um mercado onde o problema do histórico promocional causou compras excessivas antes de a correção ser implantada. A integração financeira funcionava de forma limpa em quatro dos seis mercados.
O diretor do programa chamou isso de sucesso parcial. Provavelmente tinha razão. Também não era o que tinha sido prometido, não era o que tinha sido comprado, e não era o que os US$ 5,3 milhões de custo total justificavam.
A lição não é que o IBP não funciona. A lição é que o contrato de implementação precifica a tecnologia e o go-live. A transformação é precificada à parte - em tempo executivo, recurso interno, redesenho de processo e ajuste de incentivo - e esse preço raramente é cotado antecipadamente.
Fontes
- Panorama Consulting Group. (2023). 2023 ERP Report. Panorama Consulting.
- Gartner. (2023). Market Guide for Supply Chain Planning Solutions. Gartner Research.
- Gartner. (2022). "Top Reasons Supply Chain Planning Implementations Fail." Gartner Research Note.
- Boston Consulting Group. (2023). "Digital Supply Chain Transformation: Why Most Fail and How to Succeed." BCG.
- McKinsey & Company. (2018). "Unlocking success in digital transformations." McKinsey Digital.
- Oliver Wight International. (2023). IBP Maturity Assessment Framework. Oliver Wight.
- ASCM. (2022). Supply Chain Resilience and Digital Readiness Report. ASCM.
- Wallace, T. F. (2004). Sales & Operations Planning: The Executive's Guide. T.F. Wallace & Company.
- Cecere, L. (2022). Supply Chain Metrics That Matter. Supply Chain Insights LLC.
- Lapide, L. (2011). "IBP: Not your father's S&OP." The Journal of Business Forecasting. 30(3).