El estudio de caso de cadena de suministro más instructivo que conozco no es un éxito. En junio de 2017, el malware NotPetya llegó a Maersk y la compañía reconstruyó aproximadamente 4.000 servidores y 45.000 ordenadores personales en unos diez días, con un costo estimado de entre 250 y 300 millones de dólares. La recuperación funcionó en parte porque un controlador de dominio en Ghana había estado desconectado cuando ocurrió el ataque, y esa copia del directorio que sobrevivió hizo posible la reconstrucción. Cubrimos el ataque de Maersk al completo por separado.
La mayoría de las colecciones de estudios de caso omiten ese tipo de detalle. Describen una empresa que adoptó un sistema y mejoró una métrica, lo cual es una lectura agradable e inútil para la planificación. Los casos a continuación son los que realmente cito, elegidos porque cada uno tiene un número público adjunto y una causa raíz con la que se puede discutir.
Ten supply chain cases with numbers attached
| Caso | Año | Impacto publicado | Causa raíz que vale la pena estudiar |
|---|---|---|---|
| Maersk y NotPetya | 2017 | 250 a 300 millones de dólares, 4000 servidores reconstruidos | Red plana, directorio compartido único, sin copia de recuperación sin conexión por diseño |
| Nike y i2 planificación de la demanda | 2000 | Alrededor de 100 millones de dólares en ventas perdidas | Previsiones que se confían más que los gerentes de tienda que podrían ver la demanda real |
| Lanzamiento de Hershey ERP | 1999 | Unos 150 millones de dólares en pedidos sin entregar | Cambio radical programado para el pico de Halloween |
| Lidl y SAP | 2018 | Aproximadamente 500 millones de euros dados de baja después de aproximadamente siete años | Lógica de valoración de inventario principal personalizada en lugar de adoptada |
| Objetivo Canadá | 2013 a 2015 | Salida del mercado tras dos años, pérdidas de alrededor de 2 mil millones de dólares | Los errores en los datos maestros de las dimensiones y los códigos de barras atascaron los centros de distribución. |
| Ever Given en el Canal de Suez | 2021 | 6 días encallado, unos 400 barcos en cola, pérdidas aseguradas estimadas en más de 2 mil millones de dólares | Punto único de fallo en una ruta de mucho uso, con el pilotaje con viento fuerte como causa próxima |
| Toyota después del terremoto de Tohoku | 2011 | Base de datos multinivel que cubre cientos de miles de piezas | La visibilidad de nivel uno nunca fue la limitación, la de nivel cuatro sí lo fue |
| TradeLens | 2018 a 2022 | Cerrado después de 4 años a pesar de 175 o más participantes | La tecnología funcionó y las operadoras se unieron, pero no se comprometieron a entregar datos a la plataforma de un competidor. |
| Escasez de semiconductores en Ford | 2021 | La empresa proyectó un impacto de aproximadamente 2.500 millones de dólares. | Los pedidos de chips cancelados en 2020 no pudieron ser reinstaurados a voluntad. |
| Regionalización de la red de Amazon | 2023 | Red de Estados Unidos reorganizada en clústeres regionales | Reducir la distancia recorrida superó a añadir capacidad |
Maersk 2017: el caso que cambió mis preguntas
NotPetya entró a través de una actualización comprometida del software fiscal ucraniano y se propagó lateralmente, cifrando máquinas más rápido de lo que nadie pudo reaccionar. Maersk perdió sus sistemas de reserva y las operaciones de las terminales en una gran parte de su red pasaron a ser manuales. Los barcos siguieron llegando porque los barcos no se detienen, que es la parte que los planificadores subestiman: una interrupción digital en el transporte marítimo no detiene el flujo físico, sino que elimina tu capacidad de saber qué contiene el flujo.
Dos lecciones sobreviven a la narración. La capacidad de recuperación decidió el resultado más que la prevención, y la recuperación dependió de un accidente en lugar de un diseño. Cuando reviso los planes de continuidad ahora, mi primera pregunta ya no es si existen copias de seguridad. Es si alguien ha reconstruido un servicio de directorio a partir de esas copias de seguridad dentro de una ventana de prueba, y cuánto tiempo tardó.
Hershey 1999 y Lidl 2018: el mismo error con veinte años de diferencia
Hershey reemplazó sus sistemas centrales con una transición simultánea y se enfrentó a la temporada alta de la industria confitera con un proceso de pedido a entrega que nadie había ejecutado a gran escala. Aproximadamente 150 millones de dólares en pedidos no pudieron ser enviados, y las ganancias del trimestre cayeron drásticamente.
Lidl dedicó unos 7 años a un programa de inventario y comercialización antes de abandonarlo y amortizar alrededor de 500 millones de euros. El problema técnico reportado fue mundano: Lidl valoraba el stock al precio de compra, el software estándar asumía el precio de venta, y en lugar de cambiar la práctica comercial, el proyecto cambió el software. La personalización en el núcleo de valoración se propagó entonces de forma descendente. La decisión de detenerse fue comercial más que técnica, tomada una vez que el beneficio restante dejó de justificar el gasto que el programa aún necesitaba.
Ambos casos abogan por la misma disciplina. Secuencia la transición posterior al pico y trata cada solicitud para personalizar un cálculo central como una decisión que sobrevivirá a las personas que la toman.
Toyota 2011: visibilidad en el nivel que no puedes ver
Tras el terremoto de marzo de 2011, Toyota descubrió que su exposición se situaba muy por debajo de la de sus proveedores directos, en productos químicos y componentes especializados donde una sola planta daba servicio a gran parte de la industria. La respuesta fue una base de datos de la cadena de suministro que mapeaba piezas y proveedores varios niveles de profundidad, lo que permitió a la empresa responder a una pregunta que la mayoría de los fabricantes aún no pueden: si esta ciudad se inunda, ¿qué vehículos míos dejan de funcionar?
La razón por la que sigo usando este caso es que contradice cómo se enfoca la mayoría de los proyectos de visibilidad. Los equipos compran herramientas que muestran las posiciones de los contenedores, que son datos de logística de primer nivel, mientras que el riesgo que detiene una línea de producción vive cuatro niveles más arriba en una fábrica cuyo nombre no está en ninguno de sus sistemas.
TradeLens: un fracaso que no fue técnico
TradeLens fue una plataforma blockchain para la documentación de envíos, lanzada por Maersk con IBM en 2018 y descontinuada en 2022. La tecnología funcionó y la red tampoco estaba vacía: se unieron más de 175 organizaciones, incluyendo cinco de los seis principales transportistas de contenedores. Aun así, fracasó. Registrarse y comprometerse resultaron ser decisiones diferentes, y los transportistas rivales nunca enviaron suficientes datos comerciales a través de una plataforma propiedad de su mayor competidor como para que los volúmenes funcionaran.
Este es el caso a leer antes de cualquier iniciativa de intercambio de datos en toda la industria. El problema difícil en la visibilidad compartida es la gobernanza y la propiedad, no la criptografía, y la neutralidad tiene que ser estructural en lugar de prometida. El contraste es Estándares DCSA de seguimiento y localización, que los operadores adoptaron porque ningún competidor único era dueño de ellos.
Cómo leer un estudio de caso sin que te vendan algo
La mayoría de los estudios de caso publicados son material de marketing producido con la cooperación del proveedor, lo que no los hace inútiles, pero sí cambia la forma en que debes leerlos. Mi lista de verificación:
- Encuentra la línea base. Una afirmación de treinta por ciento de mejora no significa nada sin la cifra inicial y el período de medición.
- Compruebe quién lo publicó. Si lo escribió el proveedor del software, faltarán los modos de fallo. Las presentaciones regulatorias, los documentos judiciales y los informes posteriores a incidentes contienen el detalle que los comunicados de prensa eliminan.
- **Busca lo contrafactual.** Los volúmenes, los precios y la demanda se movieron durante el período. Pregunta qué habría sucedido de todos modos.
- Prefiera casos con fechas y cifras en dólares. Cualquier cosa que no se pueda vincular a un trimestre y a un número es una anécdota con traje.
- Lea primero los fracasos. Los proyectos exitosos son diversos y difíciles de copiar. Los fracasos se repiten, lo que los hace más predictivos de lo que le sucederá al suyo.
- Verifica el nivel. Pregunta a qué nivel de la cadena se dirige realmente el caso, porque la mayoría afirma un alcance de extremo a extremo y entrega un alcance de nivel uno.
Usando estos casos en un caso de negocio
Un caso de estudio se gana su lugar en una propuesta interna cuando establece una cifra que de otro modo tendría que adivinar. Maersk 2017 proporciona un orden de magnitud defendible para una interrupción total del sistema en un gran operador logístico. Hershey y Lidl ponen precio al riesgo de puesta en marcha. Ford en 2021 muestra lo que puede costar cancelar compromisos con proveedores durante una recesión cuando la demanda regresa más rápido que la capacidad.
Lo que ninguno de ellos hará es demostrar que una herramienta específica se adapta a su operación. El patrón que he visto funcionar es más limitado: elija los dos casos cuyo modo de fallo se parezca más a su propio punto débil, cuantifique cuánto costaría ese fallo en sus volúmenes y deje que la comparación establezca el presupuesto. Ese argumento sobrevive al escrutinio de un director financiero, que es más de lo que la mayoría de las presentaciones comparativas consiguen.