IA para Supply Chain Build or BuyIA para Supply ChainBuild or Buy

O que investigar: tudo que sai do caixa no horizonte de cinco anos, não apenas a licença ou o custo do time no primeiro ano. Licença, desenvolvimento, infraestrutura, integração, upgrade de versão, retrabalho de dado, horas internas de TI, treinamento e sustentação.

Sustentação é o ponto cego mais comum. Não orce apenas a construção: em muitos casos, a sustentação acumulada dos anos seguintes supera o investimento inicial, e ela raramente aparece no modelo financeiro que sustenta a decisão.

O teste é simples: peça o custo do ano três, isolado, dos dois cenários. Se ninguém souber responder sem fazer conta na hora, o business case não está pronto para decidir nada.

O que investigar: quanto tempo leva, hoje, para mudar uma regra de alocação, um critério de priorização ou uma política de estoque. Não a resposta teórica. O tempo real da última vez que isso foi feito, incluindo fila de priorização, homologação e janela de deploy.

Regras de negócio em supply chain mudam com frequência maior do que o ciclo de projeto de TI suporta. Uma plataforma rígida transforma cada ajuste em demanda formal e a operação passa a conviver com regra errada por meses. Um sistema interno mal arquitetado produz o mesmo efeito, com a diferença de que a fila é interna.

Onde as pessoas erram: confundem configurabilidade de tela com flexibilidade de regra. Conseguir renomear um campo não é conseguir mudar como o plano é calculado.

O que investigar: quantas pessoas na empresa entendem o suficiente para tocar a solução sozinhas. Se a resposta for uma ou duas, o risco não está no fornecedor nem na tecnologia. Está na agenda dessas pessoas e na data em que elas pedirem demissão.

Projetos grandes de TI carregam risco relevante de prazo, orçamento e escopo. Isso vale tanto para implantação de plataforma quanto para desenvolvimento interno. Entra aqui também o tempo até o primeiro resultado em produção: iniciativa que passa muito tempo sem entregar valor visível perde patrocínio antes de terminar, e a decisão de continuar deixa de ser técnica.

O melhor preditor disponível não é o otimismo do plano, é o histórico interno de projeto da própria empresa. Como foi a última implantação de sistema aqui dentro? Quanto atrasou? O que entrou em produção e o que ficou pelo caminho?

O que investigar: a confiabilidade do dado mestre. Lead time, BOM, calendário de produção, capacidade dos recursos, política de estoque. Não a existência do campo, mas o quanto o número dentro dele corresponde à realidade da operação.

Também: se o processo de planejamento está documentado e é executado de forma estável, ou se depende de uma planilha que uma pessoa mantém e de um conjunto de ajustes que ninguém escreveu.

Onde as pessoas erram: tratam qualidade de dado como uma etapa do projeto de implantação, a ser resolvida durante. Dado mestre ruim não é resolvido por sistema novo. Ele é herdado pelo sistema novo, que passa a errar mais rápido e com mais confiança.

O que investigar: o nome da pessoa e a área a que ela pertence. Não a estrutura genérica, não "o time de TI", não "o fornecedor tem suporte". Quem, especificamente, é responsável por manter isso funcionando no ano dois.

Vale para os dois caminhos, com listas diferentes. Comprando: produto, parametrização, versões, integrações e conhecimento de planejamento. Construindo: código, arquitetura, infraestrutura, evolução e conhecimento funcional.

Onde as pessoas erram: avaliam a capacidade de colocar em produção, não a capacidade de manter. Se essa pergunta não tem resposta com nome antes de assinar, ela vai ter resposta ruim depois.