SAP IBP, o9, Kinaxis — o que os demos não mostram

O demo vai ser impecável. Os consultores vão chegar com um tenant pré-montado no template da sua indústria. Vão mostrar um dashboard que reconcilia planos financeiros e operacionais em tempo real, um módulo de demand sensing que se ajusta a dados de ponto de venda, e uma tela de comparação de cenários onde você testa seu plano de suprimentos contra três opções de disrupção simultaneamente. Os slides vão trazer os logos dos seus concorrentes com a frase "mais de 200 clientes na sua indústria". Os números vão ser impecáveis.

Nada disso é desonesto. A plataforma faz tudo isso. O que o demo não mostra são os dezoito meses de trabalho de harmonização de dados que precedem qualquer coisa, o quadro interno necessário para manter tudo funcionando, e a distância entre o que a plataforma pode fazer e o que sua organização vai realmente usar três anos depois do go-live.

É essa distância que vamos mapear aqui, e o que perguntar antes de assinar.

As três plataformas, sem o marketing

SAP IBP — Integrated Business Planning — é o módulo de S&OP e planejamento de suprimentos dentro do ecossistema S/4HANA da SAP. Roda sobre o banco de dados in-memory da HANA, o que dá vantagens reais de velocidade em grandes volumes de dados. A arquitetura é modular: Supply, Response & Supply, Demand, Inventory e Sales & Operations são licenças separadas. Dá para começar restrito. A armadilha é que os módulos são precificados separadamente e o valor real emerge da integração entre eles, então sua implementação "básica" já vem com um caminho de upsell embutido na arquitetura do produto.

O preço para um fabricante de porte médio (5.000 a 15.000 SKUs ativos, 10 a 15 planejadores) fica na faixa de US$ 380.000 a US$ 520.000 anuais só de software. A implementação por uma Big Four costuma levar de 18 a 24 meses e custar de 1,5 a 2,5 vezes o custo do software no primeiro ano. O lar natural do IBP é uma empresa já profundamente dentro do SAP, se seu ERP é S/4 e seu cadastro mestre vive no SAP, o argumento de integração é real. Se seu ERP é Oracle ou um stack personalizado, você está adicionando uma camada de integração cujo custo de manutenção vai crescer todo ano.

O Magic Quadrant de 2024 do Gartner para Supply Chain Planning colocou o IBP como Challenger, não Leader. O raciocínio: profundidade funcional forte, encaixe forte no ecossistema SAP, mais fraco em facilidade de uso e velocidade de implantação em relação aos concorrentes puros. As notas de satisfação de clientes no Gartner Peer Insights são reveladoras, não ruins, mas consistentemente abaixo da Kinaxis em "tempo de valor."

O Kinaxis Maestro (antes RapidResponse) opera sobre um princípio arquitetural diferente: planejamento concorrente. Em vez de rodar otimizações sequenciais, o plano de demanda alimenta o plano de suprimentos que alimenta o plano financeiro, o Maestro mantém todos os planos simultaneamente em memória e propaga mudanças entre eles quase em tempo real. Quando um fornecedor confirma uma escassez de componente, o Maestro não coloca na fila um batch noturno para repropagar pelo plano. Ele cascateia o impacto imediatamente, através de demanda, suprimento e finanças, e apresenta as opções de decisão.

Essa arquitetura é genuinamente diferenciada. É também genuinamente cara: US$ 100.000 a US$ 500.000+ anuais dependendo do número de usuários e do escopo de módulos, com um multiplicador de implementação parecido, de 1,2 a 1,8 vezes. A Kinaxis é Leader no Gartner MQ de 2024, e suas notas de peer review são consistentemente as mais altas das três plataformas em satisfação do usuário e velocidade do ciclo de planejamento. Sua fraqueza é o oposto da SAP: forte em agilidade de planejamento, mais fraca em integração profunda com S/4 para empresas onde o ERP é o sistema de registro para tudo que vem depois do plano.

A proposta de planejamento concorrente importa mais para empresas com alta volatilidade de suprimento, prazos curtos de entrega ao cliente, e ciclos de planejamento que hoje rodam semanalmente ou mais devagar porque a janela de batch é o gargalo. Se seu ciclo de planejamento é diário ou mais rápido, a arquitetura da Kinaxis tira o relógio da restrição. Se seu ciclo de planejamento é mensal e movido por alinhamento humano em vez de tempo de computação, você não vai ver a vantagem arquitetural na prática.

A o9 Solutions compete no topo da pirâmide: Fortune 500, redes globais complexas, planejamento multi-empresa. Seu diferencial é o Enterprise Knowledge Graph, um modelo de dados unificado que mapeia as relações entre clientes, SKUs, fornecedores, instalações e contratos, e permite que planejadores consultem o plano do jeito que você consultaria um banco de dados de grafo: "quais são as dependências de fornecedores de segundo nível para este SKU na EMEA?" em vez de "rode este relatório."

A o9 foi Visionary no Gartner MQ de 2023. Foi rebaixada a Niche Player em 2024, o relatório citou preocupações de execução conforme a o9 escalava sua base de clientes rapidamente. As avaliações de clientes são mais polarizadas que as da Kinaxis: notas altas em amplitude de capacidade, notas mais baixas em experiência de implementação e capacidade de resposta do suporte. O preço é sob medida e não público, mas benchmarks da indústria colocam a o9 acima da Kinaxis na camada enterprise.

Figure

A pergunta que o demo não responde

Toda plataforma produz um plano melhor que seu processo atual em um ambiente de demo controlado. O tenant do demo tem um cadastro mestre limpo: unidades de medida consistentes, nenhum número de material duplicado, prazos de entrega de fornecedores que refletem a realidade em vez do padrão do sistema de 2017. O seu tenant não vai ter isso.

A restrição fundamental do software de planejamento de supply chain não é algorítmica. É dado. O plano só é tão bom quanto o cadastro mestre que o restringe e os dados reais que o alimentam. Toda implementação que já vi entregar abaixo do esperado no business case bateu na mesma causa raiz: a ferramenta de planejamento foi implantada antes de os dados estarem prontos, e os dados nunca foram totalmente limpos porque o projeto ficou sem orçamento depois que o software entrou no ar.

Antes de avaliar a lógica de planejamento de qualquer plataforma, audite seu cadastro mestre contra quatro perguntas:

1. Precisão de lead time. Seus lead times no sistema refletem o desempenho atual dos fornecedores, ou o lead time contratual de três anos atrás? Na maioria das implementações, a resposta é o lead time contratual. A distância entre o lead time do sistema e o lead time real é a maior fonte isolada de erro de planejamento, e nenhuma plataforma corrige isso algoritmicamente.
2. Consistência de unidade de medida. Todos os inputs, previsões de demanda, planos de suprimento, posições de estoque, estão expressos na mesma unidade? UoMs misturadas são comuns em ambientes multi-ERP e produzem planejadores que sobrescrevem o sistema porque não confiam nas quantidades.
3. Completude de BOM. Para fabricantes discretos, todo produto acabado ativo está coberto por uma lista de materiais atual e precisa? O plano de suprimento é construído sobre a explosão de BOM. Uma BOM incompleta ou desatualizada produz um plano estruturalmente errado antes de qualquer otimização rodar.
4. Dados de capacidade de fornecedor. Você tem capacidade confirmada de fornecedor por período, ou planeja contra uma produção de fornecedor irrestrita? A maioria das empresas planeja sem restrição e descobre as restrições durante a execução. A plataforma não consegue modelar restrições que não estão no sistema.

O que perguntar antes de assinar

As perguntas que valem a pena fazer em negociações com fornecedores não são sobre matrizes de funcionalidades. São sobre modos de falha.

Peça uma referência com o seu perfil de dados. Não a sua indústria, a sua complexidade de dados. Se você tem 80.000 SKUs ativos em 14 sites de fabricação com 6 ERPs alimentando a camada de planejamento, peça para falar com um cliente de perfil parecido que esteja há três anos ou mais depois do go-live. Os early adopters são os que aparecem nos case studies. Os clientes de três anos te contam como é o estado estável.

Pergunte quem é dono do modelo depois da implementação. A maioria das implementações é entregue por um system integrator. Quando a SI sai, o modelo fica com uma equipe interna. Pergunte especificamente: quantos FTEs internos um cliente comparável precisa para operar essa plataforma em estado estável? A resposta deveria ser verificável. "Dois power users e um recurso de TI parcial" e "quatro planejadores dedicados e um arquiteto de TI em tempo integral" são ambas respostas legítimas. A primeira é otimista para uma implementação complexa; a segunda é cara, mas honesta. Qualquer número que te derem, dobre para os dois primeiros anos.

Pergunte sobre o escopo de change management. Ferramentas de planejamento de supply chain mudam como planejadores trabalham todo dia. A plataforma não é um sistema de fundo, é a interface primária dos planejadores. Se o plano de implementação não inclui uma frente de change management estruturada com donos internos nomeados, a implementação vai produzir um sistema que os planejadores contornam em vez de usar. Isso não é hipotético. A maioria das implementações de planejamento "fracassadas" que já vi foram entregues tecnicamente no prazo e no orçamento. Fracassaram porque os planejadores continuaram usando o Excel como sistema de registro e usaram a nova plataforma só para gerar um relatório para o deck de S&OP.

A sequência certa

As plataformas são reais e o valor está disponível. A sequência para capturá-lo:

1. Faça o baseline do seu processo atual. Meça a precisão de previsão em cada camada, meça o tempo de ciclo de planejamento, identifique os cinco principais workarounds manuais do seu processo atual. Esses são seus benchmarks. Qualquer fornecedor deveria conseguir mostrar especificamente como a plataforma dele endereça cada um.
2. Limpe os dados primeiro. Ou, no mínimo, defina e financie a frente de limpeza de dados antes do go-live, não depois. Trate isso como uma trilha paralela à implementação, não como uma limpeza pós-go-live.
3. Faça um piloto em escopo restrito. Uma família de produtos, uma região, um site de fabricação. Prove o conceito contra os seus dados antes de escalar a licença. A maioria dos fornecedores vai concordar com um piloto pago que converte para licença completa em caso de sucesso, se não concordarem, isso já diz alguma coisa.
4. Defina o que você vai parar de fazer. Toda ferramenta de planejamento é adotada mais rápido quando o processo antigo é desligado. Se os planejadores puderem continuar usando o processo legado em paralelo, eles vão, principalmente quando a nova plataforma enfrentar os inevitáveis percalços do início da implantação. Defina a data de corte e a mantenha.

A plataforma não é o gargalo. Você é. A pergunta é se sua organização tem a disciplina para arrumar seus dados, mudar seu processo, e construir a capacidade interna para operar a ferramenta que você acabou de comprar. Os fornecedores vão ajudar na venda e na implementação. A capacidade que sobrevive depois que eles saem é inteiramente sua para construir.

---

Sources

• Gartner. (2024). Magic Quadrant for Supply Chain Planning Solutions. gartner.com
• Gartner Peer Insights. (2024). Reviews for Supply Chain Planning, 2024. gartner.com
• Lee, H.L. (2004). The Triple-A Supply Chain. Harvard Business Review.
• Lapide, L. (2005). Sales and Operations Planning Part I: The Process. Journal of Business Forecasting.
• SAP. (2024). SAP IBP Product Overview. sap.com
• Kinaxis. (2024). Maestro Platform Overview. kinaxis.com
• o9 Solutions. (2024). Enterprise Knowledge Graph. o9solutions.com