Capítulo 8 — El software ciego: La crisis del Boeing 737 MAX

Un KPI perfecto en la sala de juntas puede ocultar una catástrofe inminente en la trinchera.

La historia del Boeing 737 MAX es, sin duda, la crónica del peor y más devastador error de cálculo corporativo en la historia moderna de la aviación. Y lo más aterrador es que la tragedia no empezó por una grieta microscópica en el metal, ni por un tornillo mal ajustado en la línea de ensamblaje, sino por una obsesión enfermiza en las hojas de cálculo de los directivos financieros.

A mediados de la década pasada, la alta gerencia de Boeing entró en pánico. Su archirrival europeo, Airbus, acababa de lanzar el A320neo, una aeronave inmensamente más eficiente en consumo de combustible que estaba devorando rápidamente las órdenes de compra de las aerolíneas a nivel mundial. Boeing necesitaba lanzar una respuesta de mercado inmediatamente, pero enfrentaban una restricción financiera letal y autoimpuesta: rediseñar un fuselaje completamente nuevo desde cero tomaría una década y, lo que es peor, obligaría a las aerolíneas compradoras a gastar millones de dólares en costosas horas de simulador para re-certificar a sus pilotos.

Para ganar la guerra de ventas, la directiva de Boeing estableció un KPI (Indicador Clave de Rendimiento) supremo e innegociable: el nuevo avión debía pilotarse y sentirse exactamente igual que los antiguos modelos de la generación anterior, al menos en los manuales de papel y ante las autoridades reguladoras. Se prometió a las aerolíneas que no habría necesidad de costosos entrenamientos en simulador. Este objetivo financiero aplastó cualquier otra consideración técnica.

Para lograr los ahorros de combustible prometidos y competir con Airbus, los ingenieros de Boeing tuvieron que instalar motores muchísimo más grandes y pesados bajo las alas del viejo diseño del 737. Como no cabían, tuvieron que colocarlos más arriba y más adelantados.

Pero la aerodinámica del avión cambió para siempre. La física atmosférica es implacable, no obedece a proyecciones financieras. En la trinchera de vuelo, este radical cambio estructural provocaba que, bajo ciertas condiciones aerodinámicas, el morro (la nariz) de la aeronave tendiera a elevarse peligrosamente durante maniobras de alta potencia, acercando al avión a un riesgo inminente de entrada en pérdida aerodinámica (stall).

¿Cuál fue la fatídica solución de la gerencia para no arruinar su KPI de ventas? En lugar de rediseñar el avión correctamente, o asumir el costo político y financiero de re-entrenar a los miles de pilotos para manejar la nueva realidad física del avión, decidieron ocultar el problema aerodinámico bajo una alfombra digital. Decidieron taparlo con una capa de software barata, silenciosa y secreta.

Instalaron el Maneuvering Characteristics Augmentation System (MCAS). Un oscuro trozo de código diseñado para empujar automáticamente el morro hacia abajo de forma agresiva si sus sensores creían que el avión subía demasiado rápido. Y decidieron, en un acto de soberbia letal, no contarle a nadie sobre su existencia. En el manual oficial de vuelo, el que leían y memorizaban los pilotos para sobrevivir, el acrónimo MCAS ni siquiera aparecía en el índice.

El resultado fue una tragedia anunciada. Durante los fatales vuelos del Lion Air 610 y el Ethiopian Airlines 302, un frágil y único sensor externo de ángulo de ataque se averió y envió datos erróneos al sistema informático. El MCAS, careciendo de redundancia, confiando ciegamente en su algoritmo y sin la menor consciencia del contexto situacional humano, empujó brutalmente la nariz de los aviones hacia el suelo una y otra vez, anulando las acciones físicas de la tripulación.

En la cabina, sudando frente a los controles, estaban los pilotos —los verdaderos dueños de la trinchera operativa, con miles de horas de experiencia humana— luchando desesperadamente contra un software rebelde, intentando salvar el día basados en su intuición. Pero el software corporativo los ignoró sistemáticamente. Estaba diseñado para ser un dictador ciego de silicio que imponía sus reglas matemáticas estáticas sobre la caótica realidad física.

El código corporativo ganó la batalla contra el humano. El saldo fue devastador: murieron 346 personas y Boeing perdió decenas de miles de millones de dólares, además de hundir su reputación histórica en el fango.

La empresa había creado un sistema informático perfecto en la teoría del laboratorio, pero completamente divorciado del caos, la fricción y el impredecible contexto del mundo material.

La escalofriante catástrofe del Boeing 737 MAX ilustra, de la manera más dolorosa e imperdonable posible, una de nuestras afirmaciones más absolutas y fundamentales en este libro: el proceso formal y codificado en las asépticas oficinas de la gerencia casi nunca corresponde a la sucia realidad operativa del Gemba, el lugar donde ocurre el trabajo real y donde la sangre fluye.

El reconocido experto en seguridad de sistemas, Erik Hollnagel, define magistralmente esta dicotomía brutal bajo su aclamado modelo de Safety-I vs. Safety-II. Hollnagel expone la brecha insalvable e invisible entre el "Trabajo Imaginado" (las perfectas hojas de cálculo de finanzas, las líneas de código del MCAS, los manuales de procedimientos ISO 9001) y el "Trabajo Real" (lo que tiene que improvisar un operario de fábrica, una enfermera de urgencias o un piloto de aerolínea comercial para que las cosas realmente funcionen ante las variaciones y fallos constantes del mundo físico).

Y aquí reside la incómoda verdad: tu empresa está atrapada en esa misma ilusión corporativa de control.

Cuando los líderes de tecnología y finanzas firman cheques multimillonarios para comprar un ERP carísimo, un sistema CRM de última generación, o programan un algoritmo logístico rígido para controlar el inventario global, lo hacen basándose casi exclusivamente en el Trabajo Imaginado. Ellos genuinamente creen que, al obligar a la empresa a usar ese software cerrado, han automatizado y resuelto para siempre el problema de la operación.

Pero automatizar un proceso imperfecto, o imponer un sistema que es ciego e indiferente al contexto de la trinchera, no produce eficiencia a largo plazo; simplemente acelera la generación de errores a escala industrial.

El software transaccional tradicional moderno es una caja negra impenetrable, un autócrata digital. Le dice al operario logístico o al contador qué hacer, asumiendo ciegamente que el dato inerte en su base de datos es la palabra de Dios. Y cuando la cruda realidad de la planta de producción (una máquina troqueladora trabada, un cliente enfurecido exigiendo una devolución, una tormenta que retrasa a un proveedor de materias primas) no cuadra con las celdas del código, el sistema no tiene forma fisiológica de escuchar.

Ese sistema desautoriza burocráticamente a quien está en la trinchera sudando. Lo obliga a hacer trampa, a falsear datos, a crear grupos paralelos e informales de WhatsApp para resolver la urgencia, o peor aún, a rendirse y estrellar la operación por cumplir ciegamente el manual.

Silenciar el conocimiento táctico e instintivo de la operación humana en favor del cumplimiento ciego de la herramienta digital es una receta suicida, lenta pero segura, para cualquier negocio.

Frente a la tiranía y la dictadura de los sistemas tradicionales que operan de forma estática y sorda, la respuesta arquitectónica ineludible de la empresa verdaderamente inteligente es doblegar el software a la voluntad del contexto humano.

El concepto de workflow contextual y la filosofía detrás de un OKS (Organizational Know-how System) nacen bajo la premisa indiscutible de que absolutamente ninguna instrucción preprogramada en una oficina puede anticipar todas las microscópicas variaciones del mundo real. A diferencia de un sistema hermético y autoritario como el funesto MCAS de Boeing, que impone una solución técnica sin preguntar ni escuchar al operador, un OKS asume un modelo de colaboración operativa radical.

En esta nueva arquitectura, el sistema tecnológico no busca sustituir ni anular el criterio intuitivo de la trinchera; su único propósito es amplificarlo, estructurarlo y, sobre todo, dejarse corregir ágilmente por él.

Supongamos, para alejarlo de la aviación y llevarlo a tu realidad comercial, que estamos hablando del despacho crítico de un cargamento de materias primas o de tu producto terminado más valioso. Si el curtido operario de logística nota una anomalía física evidente (un embalaje defectuoso o una temperatura incorrecta en el contenedor frigorífico), no tiene que enfrentarse ni pelear con un software rígido que le exige hacer clic en "Avanzar" de todos modos para no arruinar el KPI de tiempo de entrega.

En un entorno gobernado por un OKS, el operario detiene el despacho basándose en lo que observa. Pero en lugar de quedar atrapado en el limbo de la burocracia tradicional —donde resolver el problema tomaría horas o días de llamadas, correos cruzados y escalamientos jerárquicos para descifrar quién tiene la autoridad para solucionarlo—, el operario simplemente registra la eventualidad (por ejemplo, con un comando de voz rápido). El OKS, gracias a su Mapa de Acción Operacional y su conocimiento del contexto, sabe exactamente a quién acudir. Conecta de inmediato el fallo con los sistemas de gestión de tareas (task managers) de la compañía, enlazando la alerta con las personas correctas: el ingeniero de empaques, el técnico de calibración o el responsable de envíos. Asigna la actividad precisa, la prioridad adecuada y, lo más importante, el contexto completo de la falla directamente a su bandeja de entrada.

Aquí reside un principio del trabajo moderno: una organización cuyos sistemas de gestión de tareas (task managers) no están directamente unidos a su forma de operar real es mucho más lenta. La evidencia científica y económica es contundente. El célebre economista Erik Brynjolfsson ha demostrado que la tecnología de información solo dispara la productividad cuando viene acompañada de un rediseño organizacional y de la autonomía de los equipos. Asimismo, estudios de la firma Forrester sobre sistemas como Microsoft Planner estiman que la adopción de herramientas colaborativas estructuradas puede ahorrar entre un 5% y un 12% del tiempo de trabajo y reducir drásticamente las improductivas reuniones de seguimiento de diez horas semanales a solo dos o tres.

Sin embargo, hay una trampa: el task manager común te dice el "qué hay que hacer ahora", pero carece del "cómo, por qué y bajo qué criterios". Al unir los gestores de tareas con un OKS, la organización no solo automatiza la asignación de buena parte de las responsabilidades; inyecta el know-how necesario para desbloquear la operación en tiempo récord. Quien recibe la tarea no solo sabe qué debe resolver; tiene a mano el contexto, el criterio histórico y la solución técnica validada.

Ese es el inmenso y disruptivo poder del Motor de inteligencia organizacional. El sistema informático de la empresa ya no es ciego. Al conectar el frío dato estadístico con el ardiente instante operativo en tiempo real, la Inteligencia Artificial no te obliga a hundirte estoicamente abrazado al manual oficial. Lee el entorno cambiante y te sugiere agresivamente una Solución nueva y viable, basándose instantáneamente en la memoria acumulada de todos tus mejores operarios. El humano y la máquina se alinean para salvar el día.

No necesitas comprar más software pasivo ni bases de datos estáticas en tu empresa. Necesitas instalar verdaderos sistemas nerviosos centrales, redes vivas donde un simple dolor en un extremo del cuerpo (la trinchera operativa o el piso de ventas) modifique y adapte instantáneamente la respuesta de todo el organismo, hasta llegar a la alta gerencia.

Cuando finalmente dejamos de venerar el algoritmo cerrado y soberbio, y empezamos a escuchar con atención y tecnología el conocimiento de la acción humana en el campo de batalla, el proceso corporativo deja de ser un lastre pesado que arrastra a la empresa al abismo. Se convierte en un diálogo ininterrumpido, simbiótico y altamente rentable entre la tecnología y el mundo real.

Automatizar un proceso sin entender su contexto físico no genera eficiencia; simplemente codifica el desastre.

¿Por qué falló el software MCAS en el Boeing 737 MAX?

El software MCAS falló porque fue diseñado para parchar digitalmente un cambio físico y aerodinámico sin informar ni capacitar a los pilotos en la trinchera. Al depender de un sensor averiado y carecer de consciencia del contexto operativo, anuló el criterio de la tripulación y forzó el descenso fatal de las aeronaves.

¿Por qué automatizar procesos sin contexto es peligroso para una empresa?

Porque la automatización y la inteligencia artificial multiplican exponencialmente la velocidad de ejecución. Si el proceso automatizado contiene fallas lógicas, supuestos erróneos o desconexión con la realidad física, el sistema simplemente escalará el error a una velocidad que ningún humano podrá frenar a tiempo.

¿Cómo protege VIBEWORKFLOW a la empresa contra fallos de automatización?

En VIBEWORKFLOW, la automatización y los agentes de IA no operan en cajas negras aisladas, sino anclados a flujos contextuales que monitorean condiciones de contorno (KPIs críticos, restricciones de entrada e información requerida). Si una variable se sale de los rangos tolerados, el sistema detiene la propagación y solicita validación humana contextual.

¿Cuál es la relación ideal entre algoritmos y criterio humano en las operaciones?

Debe ser simbiótica: los algoritmos y la IA se encargan de la velocidad de cálculo y la orquestación rutinaria, mientras que los operadores humanos en la trinchera aportan el juicio crítico, detectan excepciones contextuales y alimentan el sistema con nuevos hallazgos.