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

On August 25, 2026, one of the world's largest medical device makers discoverediscovered its network had beehad been compromised. Within hours, Boston Scientific had a network outage, manufacturing was disrupted, and the company could no longer process or ship customer orders. Not "slower." Could not. A week later, shipping was returning to the major distribution centers, but the company's own words in its September 3 update 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".

These are pacemakers and stents. The hospitals that order them did not stop having patients. And the one thing that kept working, according to the company, was that they could still take orders electronically via EDI and queue thequeue them. Intake survived. Everything after intake did not.

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.

Look at what a stopped plant actually costs. When Jaguar Land Rover was hit in September 2025, production stayed down for roughly five weeks. The estimates that circulated were around £50 million per week for the company, and about £1.9 billion in total damage to the UK economy, including the supply chain. That second number is the one I keep coming back to. Suppliers that had done nothing wrong were laying off people within weeks, because their only customer stopped calling for parts.

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.
• Put a wall between the plant and the office. Machines, controllers, and warehouse devices should not share a network, credentials, or a domain with the laptops used to accesused to access email. That wall is what turns a company-wide outage into a department-wide one.
• 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.