Cuando el sistema se apaga, ¿todavía podés despachar?

Boston Scientific lleva desde el 25 de agosto lidiando con un ciberataque. La lección no es sobre hackers. Es sobre lo que tu operación todavía puede hacer el día que el ERP no está.

Por Rodolfo Kong | ARMKU LLC | Septiembre 2026

El 25 de agosto de 2026, uno de los fabricantes de dispositivos médicos más grandes del mundo descubrió que su red había sido comprometida. En cuestión de horas, Boston Scientific tenía la red caída, la manufactura interrumpida y ya no podía procesar ni despachar los pedidos de sus clientes. No "más lento". No podía. Una semana después, los despachos estaban volviendo a los principales centros de distribución, pero las propias palabras de la empresa en su actualización del 3 de septiembre merecen leerse dos veces: "Tomará tiempo trabajar el atraso de pedidos acumulado" y "Todavía no se conoce el plazo para la restauración completa".

Hablamos de marcapasos y stents. Los hospitales que los piden no dejaron de tener pacientes. Y lo único que siguió funcionando, según la empresa, fue que todavía podían recibir pedidos electrónicamente por EDI y ponerlos en cola. La recepción de pedidos sobrevivió. Todo lo que venía después, no.

No sé qué pasó adentro de la red de Boston Scientific, y tampoco lo sabe nadie de los que escriben sobre esto esta semana. Pero he manejado operaciones el tiempo suficiente para reconocer la parte de esta historia que no tiene nada que ver con seguridad. Tiene que ver con lo que una empresa todavía puede hacer con las manos cuando la pantalla se queda en blanco.

La mentira que nos contamos en la reunión de presupuesto

Todo líder de operaciones ha oído alguna versión de "tenemos respaldos" o "IT tiene un plan para eso". Yo mismo lo he dicho. Suena a respuesta. No lo es.

Un respaldo restaura tus datos. No restaura tu operación. Entre "los datos existen en algún lado" y "salió un camión del muelle con el producto correcto" hay una cadena de personas, pantallas, impresoras, escáneres, integraciones con transportistas y aprobaciones que asumen que el sistema está arriba. Cuando está abajo, la mayoría de las empresas descubre que nadie menor de cuarenta años ha despachado un pedido sin el sistema, y nadie mayor de cuarenta se acuerda cómo.

Eso no es un problema de IT. Es un problema de operaciones disfrazado de IT. Y mientras más integrado está tu ERP, más grande el disfraz. La misma integración que compraste porque conecta pedido, picking, despacho y factura en un solo flujo hace que, cuando el flujo se detiene, todo se detenga al mismo tiempo.

Lo que dicen los datos

Esto no es una empresa con mala suerte. La manufactura ha sido la industria más atacada del mundo cinco años seguidos. El X-Force Threat Index 2026 de IBM pone a la manufactura en el 27.7% de todos los incidentes que atendió el año pasado, y reporta que los grupos activos de ransomware y extorsión crecieron 49% año contra año. Nadie está más seguro en 2026 de lo que estaba en 2025.

Mirá lo que cuesta de verdad una planta parada. Cuando atacaron a Jaguar Land Rover en septiembre de 2025, la producción estuvo detenida aproximadamente cinco semanas. Las estimaciones que circularon rondaban las £50 millones por semana para la empresa, y cerca de £1,900 millones en daño total a la economía del Reino Unido, incluida la cadena de suministro. Ese segundo número es al que siempre vuelvo. Proveedores que no habían hecho nada mal estaban despidiendo gente en pocas semanas, porque su único cliente dejó de pedirles piezas.

En julio de este año, Coca-Cola suspendió la producción en Estados Unidos de su unidad láctea Fairlife tras un ataque de ransomware. Una marca de mil millones de dólares, y las plantas simplemente pararon. Ahora Boston Scientific. Tres empresas con presupuestos de seguridad más grandes que las ventas totales de la mayoría de mis clientes. Si les pasa a ellos, la pregunta para el resto de nosotros no es "¿nos va a pasar?". Es "¿qué hacemos el día uno?".

La lectura del operador

Hace veinte años, una bodega podía despachar con una lista de picking impresa y una llamada. Esa resiliencia no era una estrategia. Era un accidente de lo poco que estaba integrado. Llevamos dos décadas eliminando ese accidente a propósito, y con buenas razones: menos errores, ciclos más rápidos, inventario en tiempo real. Pero junto con la fricción eliminamos el plan B, y nadie dejó escrito qué hacer cuando el único sistema por el que pasa todo es justamente el que falla.

Hay un detalle de Boston Scientific que vale la pena guardar. El incidente golpeó ciertos sistemas en sus propias instalaciones. Las aplicaciones en la nube, según la empresa, no se vieron afectadas. Por eso la recepción de pedidos siguió funcionando mientras el despacho se detuvo. La frontera entre los dos sistemas decidió el tamaño del daño. La mayoría de las empresas medianas no tiene esa frontera. Un servidor, una base de datos, un usuario para todo. Cómodo, hasta el día que deja de serlo.

La traducción operativa

Nada de esto requiere comprar un producto de seguridad. Requiere la misma disciplina que le aplicarías a cualquier otro riesgo operativo. Aquí es donde yo pondría la energía, en orden:

• Escribí la lista del día uno. Las diez cosas que tienen que seguir pasando si mañana en la mañana todas las pantallas se apagan: recibir pedidos, despachar lo que ya está pickeado, recibir materiales críticos, pagarle a la gente, decirle la verdad a los clientes. Para cada una, un procedimiento manual en papel, con nombres. Si el procedimiento solo existe dentro del ERP, no existe.
• Separá la recepción del procesamiento. Boston Scientific pudo seguir recibiendo pedidos porque ese canal no vivía en los mismos sistemas que se cayeron. Tu recepción de cara al cliente, tu tienda web, tu EDI, tu correo, deberían sobrevivir a que se caiga el back office. Probalo desconectando el back office, no leyendo el diagrama de arquitectura.
• Restaurá, no solo respaldés. Un respaldo que nunca has restaurado es una esperanza. Hacé una restauración cronometrada sobre infraestructura limpia una vez al año y anotá el número de horas. Si nadie en la empresa puede decir cuánto se tarda en pasar de "apagado" a "funcionando", no tenés un plan de recuperación. Tenés un archivo.
• Poné un muro entre la planta y la oficina. Las máquinas, los controladores y los dispositivos de bodega no deberían compartir red, credenciales ni dominio con las laptops que se usan para leer el correo. Ese muro es lo que convierte una caída de toda la empresa en la caída de un solo departamento.
• Hacele las mismas preguntas a tus proveedores. Los proveedores de JLR se cayeron con JLR. Si un proveedor es tu única fuente de una parte crítica, su plan de recuperación es tu plan de recuperación. Pedile el suyo a tus veinte principales. El silencio que recibás de vuelta también es un dato.
• Decidí ahora quién puede decir "despachen igual". En las primeras horas, alguien tiene que decidir si se despacha con registros en papel y se concilia después, o si se frena todo para proteger los datos. Esa decisión es mucho más fácil un martes tranquilo que a las 3 de la mañana con un cliente en la línea.

Cada uno de estos puntos es un proyecto de dos semanas, no de dos años. Cada uno era más barato el año pasado de lo que va a ser el próximo. Ninguno aparece en el demo de un proveedor, y justo por eso se saltan.

Si tu operación pasa por un solo sistema, y la mayoría lo hace, la pregunta honesta no es si ese sistema es seguro. Es si tu gente puede correr el negocio una semana sin él. Ese es el trabajo que hacemos con los clientes en ARMKU: mapear qué tiene que seguir moviéndose, probar la recuperación con cronómetro y escribir los planes B antes de que hagan falta. Si esa pregunta lleva tiempo dando vueltas en tu cabeza, hablemos antes de que se convierta en una llamada de emergencia.