Quando o sistema sai do ar, você ainda consegue despachar?

A Boston Scientific vem lidando com um ataque cibernético desde 25 de agosto. A lição não é sobre hackers. É sobre o que a sua operação ainda consegue fazer no dia em que o ERP não está lá.

Por Rodolfo Kong | ARMKU LLC | setembro de 2026

Em 25 de agosto de 2026, uma das maiores fabricantes de dispositivos médicos do mundo descobriu que sua rede havia sido comprometida. Em poucas horas, a Boston Scientific teve uma queda de rede, a produção foi interrompida e a empresa já não conseguia processar nem despachar os pedidos dos clientes. Não "mais devagar". Não conseguia. Uma semana depois, a expedição estava voltando aos principais centros de distribuição, mas as palavras da própria empresa na atualização de 3 de setembro merecem ser lidas duas vezes: "Vai levar tempo para processar o acúmulo de pedidos existente" e "O prazo para a restauração completa ainda não é conhecido."

Estamos falando de marca-passos e stents. Os hospitais que encomendam esses dispositivos não deixaram de ter pacientes. E a única coisa que continuou funcionando, segundo a empresa, foi que ainda era possível receber pedidos eletronicamente via EDI e colocar tudo em fila. A recepção de pedidos sobreviveu. Tudo o que vinha depois dela, não.

Não sei o que aconteceu dentro da rede da Boston Scientific, nem ninguém que esteja escrevendo sobre o assunto nesta semana. Mas já comandei operações por tempo suficiente para reconhecer a parte desta história que não tem nada a ver com segurança. Tem a ver com o que uma empresa ainda consegue fazer com as próprias mãos quando a tela fica em branco.

A mentira que contamos a nós mesmos na reunião de orçamento

Todo líder de operações já ouviu alguma versão de "temos backup" ou "a TI tem um plano para isso." Eu mesmo já disse isso. Parece uma resposta. Não é.

Um backup restaura seus dados. Não restaura sua operação. Entre "os dados existem em algum lugar" e "um caminhão saiu da doca com o produto certo", existe uma cadeia de pessoas, telas, impressoras, scanners, integrações com transportadoras e aprovações que partem do princípio de que o sistema está no ar. Quando ele cai, a maioria das empresas descobre que ninguém com menos de quarenta anos nunca despachou um pedido sem ele, e ninguém com mais de quarenta lembra como se faz.

Isso não é um problema de TI. É um problema de operações fantasiado de TI. E quanto mais integrado é o seu ERP, maior a fantasia. A mesma integração que você comprou porque liga pedido, separação, expedição e faturamento em um único fluxo faz com que, quando o fluxo para, tudo pare de uma vez.

O que os dados realmente dizem

Não se trata de uma empresa azarada. A manufatura é o setor mais atacado do mundo há cinco anos seguidos. O X-Force Threat Index 2026 da IBM coloca a manufatura em 27,7% de todos os incidentes atendidos no ano passado e informa que os grupos ativos de ransomware e extorsão cresceram 49% em relação ao ano anterior. Ninguém está mais seguro em 2026 do que estava em 2025.

Veja quanto custa, de fato, uma fábrica parada. Quando a Jaguar Land Rover foi atacada em setembro de 2025, a produção ficou parada por cerca de cinco semanas. As estimativas que circularam falavam em cerca de £ 50 milhões por semana para a empresa e em aproximadamente £ 1,9 bilhão de prejuízo total para a economia do Reino Unido, incluindo a cadeia de suprimentos. É a esse segundo número que eu sempre volto. Fornecedores que não tinham feito nada de errado estavam demitindo gente em poucas semanas, porque o único cliente deles parou de pedir peças.

Em julho deste ano, a Coca-Cola suspendeu a produção nos EUA da sua unidade de laticínios Fairlife após um ataque de ransomware. Uma marca bilionária, e as fábricas pararam. Agora, a Boston Scientific. Três empresas com orçamentos de segurança maiores do que o faturamento total da maioria dos meus clientes. Se pode acontecer com elas, a pergunta para o resto de nós não é "vai acontecer?" É "o que fazemos no primeiro dia?"

A leitura de quem opera

Vinte anos atrás, um armazém conseguia despachar com uma lista de separação impressa e um telefonema. Essa resiliência não era uma estratégia. Era um acidente: quase nada estava integrado. Passamos duas décadas eliminando esse acidente de propósito, e por bons motivos: menos erros, ciclos mais rápidos, estoque em tempo real. Mas eliminamos o plano B junto com o atrito, e ninguém deixou por escrito o que fazer quando o único sistema por onde tudo passa é justamente o que falha.

Vale a pena guardar um detalhe do caso da Boston Scientific. O incidente atingiu certos sistemas locais (on-premises). As aplicações em nuvem, segundo a empresa, não foram afetadas. É por isso que a recepção de pedidos continuou funcionando enquanto a expedição parou. A fronteira entre os dois sistemas definiu o tamanho do estrago. A maioria das empresas de médio porte não tem essa fronteira. Um servidor, um banco de dados, um login para tudo. Prático, até o dia em que deixa de ser.

A tradução operacional

Nada disso exige comprar um produto de segurança. Exige a mesma disciplina que você aplicaria a qualquer outro risco operacional. É aqui que eu colocaria a energia, em ordem:

• Escreva a lista do primeiro dia. As dez coisas que precisam continuar acontecendo se todas as telas apagarem amanhã de manhã: receber pedidos, despachar o que já foi separado, receber materiais críticos, pagar as pessoas, dizer a verdade aos clientes. Para cada uma, um procedimento manual no papel, com o nome dos responsáveis. Se o procedimento existe só no ERP, ele não existe.
• Separe a recepção de pedidos do processamento. A Boston Scientific ainda conseguia receber pedidos porque esse canal não ficava nos mesmos sistemas que caíram. Seus canais de entrada voltados ao cliente, sua loja virtual, seu EDI, sua caixa de e-mail, devem sobreviver a uma falha do back office. Teste isso desligando o back office, não lendo o diagrama de arquitetura.
• Restaure, não apenas faça backup. Um backup que você nunca restaurou é uma esperança. Faça uma restauração cronometrada em uma infraestrutura limpa uma vez por ano e anote o número de horas. Se ninguém na empresa sabe dizer quanto tempo leva para ir de "fora do ar" a "funcionando", você não tem um plano de recuperação. Você tem um arquivo.
• Levante um muro entre a fábrica e o escritório. Máquinas, controladores e dispositivos do armazém não devem compartilhar rede, credenciais ou domínio com os notebooks usados para acessar o e-mail. É esse muro que transforma uma queda da empresa inteira em uma queda de um só departamento.
• Faça as mesmas perguntas aos seus fornecedores. Os fornecedores da JLR caíram junto com a JLR. Se um fornecedor é sua única fonte de uma peça crítica, o plano de recuperação dele é o seu plano de recuperação. Peça o plano dos seus vinte principais fornecedores. O silêncio que você receber em resposta já é um dado.
• Decida agora quem pode dizer "despachem mesmo assim." Nas primeiras horas, alguém precisa decidir se a empresa despacha com registros em papel e concilia depois, ou se segura tudo e protege os dados. Essa decisão é muito mais fácil de tomar numa terça-feira tranquila do que às 3 da manhã com um cliente na linha.

Cada um desses itens é um projeto de duas semanas, não de dois anos. Cada um deles era mais barato no ano passado do que será no ano que vem. Nenhum deles aparece na demonstração de um fornecedor, e é exatamente por isso que acabam ficando de lado.

Se a sua operação passa por um único sistema, e a maioria passa, a pergunta honesta não é se esse sistema é seguro. É se o seu pessoal consegue tocar o negócio por uma semana sem ele. É esse o trabalho que fazemos com os clientes na ARMKU: mapear o que precisa continuar andando, testar a recuperação com cronômetro na mão e escrever os planos B antes que sejam necessários. Se essa pergunta anda rondando a sua cabeça, vamos conversar antes que ela vire uma ligação de emergência.