O estudo de caso mais instrutivo de cadeia de abastecimento que conheço não é um sucesso. Em junho de 2017, o malware NotPetya atingiu a Maersk e a empresa reconstruiu cerca de 4.000 servidores e 45.000 computadores pessoais em aproximadamente dez dias, a um custo estimado de 250 a 300 milhões de dólares. A recuperação funcionou em parte porque um controlador de domínio no Gana estava offline quando o ataque ocorreu, e essa cópia sobrevivente do diretório tornou a reconstrução possível. Cobrimos o ataque da Maersk na íntegra separadamente.
A maioria das coleções de estudos de caso omite esse tipo de detalhe. Descrevem uma empresa que adotou um sistema e melhorou uma métrica, o que é uma leitura agradável e inútil para planeamento. Os casos abaixo são aqueles que eu realmente cito, escolhidos porque cada um tem um número público associado e uma causa raiz com a qual se pode argumentar.
Dez casos da cadeia de suprimentos com números anexados
| Caso | Ano | Impacto publicado | Causa raiz que vale a pena estudar |
|---|---|---|---|
| Maersk e NotPetya | 2017 | 250 a 300 milhões de dólares, 4.000 servidores reconstruídos | Rede plana, diretório partilhado único, sem cópia de recuperação offline por conceção |
| Nike e i2 planeamento da procura | 2000 | Cerca de 100 milhões de dólares em vendas perdidas | Previsão confiável para gestores de loja que poderiam ver a demanda real |
| Lançamento do ERP da Hershey | 1999 | Cerca de 150 milhões de dólares em encomendas não entregues | Grande corte agendado para o pico do Halloween |
| Lidl e SAP | 2018 | Cerca de 500 milhões de euros baixados após aproximadamente sete anos | Lógica principal de avaliação de inventário personalizada em vez de adotada |
| Target Canadá | 2013 a 2015 | Saída do mercado após dois anos, perdas de cerca de 2 mil milhões de dólares | Erros nos dados mestre em dimensões e códigos de barras atascaram os centros de distribuição |
| Ever Given no Canal do Suez | 2021 | 6 dias encalhado, cerca de 400 navios em fila, perdas seguradas estimadas acima de 2 mil milhões de dólares | Ponto único de falha numa rota com uso intenso, com a pilotagem em ventos fortes como causa próxima |
| Toyota após o terramoto de Tohoku | 2011 | Base de dados multicamadas que abrange centenas de milhares de peças | A visibilidade de primeiro nível nunca foi a restrição, a de quarto nível foi |
| TradeLens | 2018 a 2022 | Encerrou após 4 anos, apesar de 175 ou mais participantes | A tecnologia funcionou e as operadoras aderiram, mas não se comprometeram a fornecer dados para a plataforma de um concorrente. |
| Escassez de semicondutores na Ford | 2021 | Empresa projetou cerca de 2,5 mil milhões de dólares de impacto | As encomendas de chips canceladas em 2020 não puderam ser repostas à vontade. |
| Regionalização da rede Amazon | 2023 | Rede dos Estados Unidos reorganizada em aglomerados regionais | Reduzir a distância percorrida superou o aumento da capacidade |
Maersk 2017: o caso que mudou as minhas perguntas
O NotPetya entrou através de uma atualização comprometida de software fiscal ucraniano e propagou-se lateralmente, encriptando máquinas mais rapidamente do que qualquer um conseguia responder. A Maersk perdeu os seus sistemas de reservas e as operações dos terminais em grande parte da sua rede voltaram a ser manuais. Os navios continuaram a chegar porque os navios não param, o que é a parte que os planeadores subestimam: uma falha digital no transporte marítimo não pausa o fluxo físico, remove a sua capacidade de saber o que o fluxo contém.
Duas lições sobrevivem à recontagem. A capacidade de recuperação decidiu o resultado mais do que a prevenção, e a recuperação dependeu de um acidente em vez de um plano. Quando revejo planos de continuidade agora, a minha primeira pergunta já não é se existem cópias de segurança. É se alguém já reconstruiu um serviço de diretório a partir dessas cópias de segurança dentro de uma janela de teste e quanto tempo demorou.
Hershey 1999 e Lidl 2018: o mesmo erro com vinte anos de diferença
A Hershey substituiu os sistemas principais com um *cutover* simultâneo e atingiu a época alta da indústria de confeitaria com um processo de encomenda a entrega que ninguém tinha executado em volume. Cerca de 150 milhões de dólares em encomendas não puderam ser enviados, e o lucro do trimestre caiu acentuadamente.
A Lidl dedicou cerca de 7 anos a um programa de inventário e merchandising antes de o abandonar e de desvalorizar cerca de 500 milhões de euros. O problema técnico reportado era banal: a Lidl avaliava o stock ao preço de compra, o software padrão assumia o preço de retalho e, em vez de alterar a prática comercial, o projeto alterou o software. A personalização no núcleo da avaliação propagou-se então para jusante. A decisão de parar foi comercial e não técnica, tomada assim que o benefício restante deixou de justificar os gastos que o programa ainda necessitava.
Ambos os casos defendem a mesma disciplina. Sequencie a mudança para fora do pico e trate cada pedido de personalização de um cálculo central como uma decisão que sobreviverá às pessoas que a tomam.
Toyota 2011: visibilidade ao nível que não se vê
Após o sismo de março de 2011, a Toyota descobriu que a sua exposição estava bem abaixo da dos seus fornecedores diretos, em produtos químicos e componentes especializados, onde uma única fábrica servia grande parte da indústria. A resposta foi uma base de dados da cadeia de abastecimento que mapeava peças e fornecedores vários níveis abaixo, o que permitiu à empresa responder a uma pergunta que a maioria dos fabricantes ainda não consegue: se esta cidade for inundada, quais dos meus veículos param.
A razão pela qual continuo a usar este caso é que ele contrasta com a forma como a maioria dos projetos de visibilidade são definidos. As equipas compram ferramentas que mostram posições de contentores, que são dados logísticos de primeira linha, enquanto o risco que impede uma linha de produção vive quatro níveis acima numa fábrica cujo nome não consta em nenhum dos seus sistemas.
TradeLens: um fracasso que não foi técnico
O TradeLens foi uma plataforma blockchain para documentação de transporte marítimo, lançada pela Maersk com a IBM em 2018 e descontinuada em 2022. A tecnologia funcionou e a rede não estava vazia: mais de 175 organizações aderiram, incluindo cinco das seis maiores companhias de transporte de contentores. Mesmo assim, fechou. A adesão e o compromisso acabaram por ser decisões diferentes, e as companhias rivais nunca encaminharam dados comerciais suficientes através de uma plataforma detida pelo seu maior concorrente para que os volumes funcionassem.
Este é o caso a ler antes de qualquer iniciativa de partilha de dados em toda a indústria. O problema difícil na visibilidade partilhada é a governação e a propriedade, não a criptografia, e a neutralidade tem de ser estrutural em vez de prometida. O contraste é o Padrões DCSA de rastreamento e rastreabilidade, que as transportadoras adotaram porque nenhum concorrente único os possuía.
Como ler um estudo de caso sem ser vendido
A maioria dos estudos de caso publicados são material de marketing produzido com a cooperação do fornecedor, o que não os torna inúteis, mas altera a forma como deve lê-los. O meu checklist:
- Encontre o valor de referência. Uma alegação de trinta por cento de melhoria não significa nada sem o valor inicial e a janela de medição.
- Verifique quem o publicou. Se o fornecedor de software o escreveu, os modos de falha estarão em falta. Documentos regulamentares, documentos judiciais e relatórios pós-incidente contêm os detalhes que os comunicados de imprensa removem.
- Procure o contrafactual. Volumes, preços e procura moveram-se durante o período. Pergunte o que teria acontecido de qualquer forma.
- Prefira casos com datas e valores em dólares. Qualquer coisa que não possa ser associada a um trimestre e a um número é uma anedota vestida a rigor.
- Leia primeiro os fracassos. Projetos bem-sucedidos são diversos e difíceis de copiar. Fracassos repetem-se, o que os torna mais preditivos do que acontecerá com o seu.
- Verifique o nível. Pergunte qual o nível da cadeia que o caso aborda realmente, pois a maioria reivindica um âmbito ponta a ponta e entrega um âmbito de nível um.
Usando estes casos num estudo de caso empresarial
Um estudo de caso justifica o seu lugar numa proposta interna quando estabelece um número que, de outra forma, teria de adivinhar. A Maersk 2017 fornece uma ordem de magnitude defensável para uma interrupção total de sistemas num grande operador logístico. A Hershey e a Lidl atribuem um preço ao risco de entrada em funcionamento. A Ford, em 2021, mostra o custo de cancelar compromissos com fornecedores durante uma desaceleração, quando a procura regressa mais depressa do que a capacidade.
O que nenhum deles fará é provar que uma ferramenta específica se adequa à sua operação. O padrão que observei funcionar é mais restrito: escolha os dois casos cujo modo de falha mais se assemelha ao seu próprio ponto fraco, quantifique quanto essa falha custaria nos seus volumes e deixe que a comparação defina o orçamento. Esse argumento sobrevive ao escrutínio de um diretor financeiro, o que é mais do que a maioria das apresentações de referência consegue.