El 23 de septiembre de 1999, una nave espacial de la NASA estaba a punto de llegar a Marte.
Había recorrido millones de kilómetros por el espacio.
Durante meses, ingenieros, científicos y especialistas habían seguido su trayectoria, calculado maniobras y preparado su llegada al planeta rojo.
El error de US$125 millones: la misión espacial que se perdió porque dos equipos no hablaban el mismo idioma
El 23 de septiembre de 1999, una nave espacial de la NASA estaba a punto de llegar a Marte.
Había recorrido millones de kilómetros por el espacio.
Durante meses, ingenieros, científicos y especialistas habían seguido su trayectoria, calculado maniobras y preparado su llegada al planeta rojo.
La misión tenía un nombre: Mars Climate Orbiter.
Su objetivo era estudiar la atmósfera y el clima marciano, además de servir como apoyo de comunicaciones para otras misiones.
Representaba años de trabajo, tecnología avanzada y una inversión de aproximadamente 125 millones de dólares en el desarrollo de la nave.
Pero cuando llegó el momento decisivo, algo salió mal.
La nave pasó demasiado cerca de Marte.
La comunicación se perdió.
Y nunca volvió a recuperarse.
No fue una tormenta espacial inesperada.
No fue una colisión con un asteroide.
No fue un fallo espectacular de un motor.
El problema que contribuyó a perder aquella misión era mucho más sencillo.
La diferencia parecía pequeña. Sus consecuencias fueron enormes.
Y aquella historia se convirtió en uno de los ejemplos más conocidos de cómo una falla de estandarización, comunicación y verificación puede destruir un proyecto extraordinariamente complejo.
Una misión diseñada para comprender Marte
A finales de la década de 1990, la NASA impulsaba un programa de exploración de Marte con objetivos científicos ambiciosos.
Una de sus misiones era Mars Climate Orbiter, lanzada el 11 de diciembre de 1998 desde Cabo Cañaveral, Florida.
La nave debía estudiar las condiciones atmosféricas del planeta.
Entre sus objetivos se encontraban observar la distribución del polvo, el vapor de agua y otros fenómenos relacionados con el clima marciano.
Para conseguirlo, necesitaba llegar a Marte y realizar una maniobra precisa que le permitiera entrar en órbita.
Ese último detalle era fundamental.
Una nave espacial no puede simplemente aproximarse a un planeta y detenerse.
Debe llegar con una trayectoria y velocidad cuidadosamente calculadas.
Una diferencia relativamente pequeña en las estimaciones puede convertirse en una desviación considerable después de millones de kilómetros.
Por eso, durante el viaje, los equipos de navegación realizaban cálculos y correcciones.
Cada dato importaba.
Cada maniobra debía estar controlada.
Cada sistema necesitaba proporcionar información compatible con los demás.
Al menos, así debía funcionar.
Dos equipos, dos sistemas de medición
La NASA trabajaba con contratistas especializados para desarrollar distintos componentes de la misión.
Lockheed Martin participó en la construcción de la nave y en el desarrollo de determinados sistemas.
El equipo de navegación de la NASA utilizaba información generada por esos sistemas para calcular la trayectoria.
Aquí apareció el problema.
Un archivo de datos relacionado con los impulsos producidos por los propulsores de la nave contenía valores expresados en libra-fuerza segundo, una unidad del sistema inglés.
Sin embargo, el software que procesaba esos datos esperaba valores expresados en newton-segundo, correspondientes al Sistema Internacional.
Ambas unidades sirven para expresar impulso. Pero no representan la misma cantidad.
Eso significa que interpretar una cantidad expresada en una unidad como si estuviera expresada en la otra puede producir un error importante.
Y lo más peligroso era que los datos no necesariamente parecían incorrectos.
Eran números.
El sistema podía procesarlos.
Los cálculos podían continuar.
Los archivos podían circular entre equipos.
Pero la interpretación física de aquellos valores era equivocada.
El peligro de los errores que no generan una alarma
Cuando imaginamos un error informático, solemos pensar en una pantalla que se bloquea, un mensaje de advertencia, un programa que deja de funcionar o un archivo que no puede abrirse.
Pero algunos de los errores más peligrosos no producen ninguna señal evidente.
El sistema sigue funcionando.
Los datos continúan circulando.
Los resultados aparecen en pantalla.
Los procedimientos avanzan.
Y las personas pueden interpretar esa continuidad como una confirmación de que todo está correcto.
En Mars Climate Orbiter, el problema de las unidades contribuyó a errores acumulados en la estimación de la trayectoria.
La nave recibió maniobras y ajustes durante su viaje. Pero la información utilizada para reconstruir su movimiento no reflejaba correctamente determinados impulsos.
Con el tiempo, las diferencias entre la trayectoria calculada y la trayectoria real se volvieron críticas.
La misión no se perdió porque alguien escribiera una cifra absurda que todos ignoraron. Se perdió en un contexto donde información aparentemente válida era interpretada de manera incorrecta.
Esa es una situación especialmente peligrosa para cualquier sistema de gestión.
Porque el problema no está necesariamente en la ausencia de información. Está en confiar en información que no ha sido adecuadamente verificada.
El día en que la nave desapareció
El 23 de septiembre de 1999, Mars Climate Orbiter se aproximó a Marte.
La nave debía realizar una maniobra para ingresar en órbita.
Sin embargo, su trayectoria la llevó a una altitud mucho menor de la prevista.
Según las investigaciones posteriores, la nave pasó aproximadamente a 57 kilómetros de la superficie marciana, cuando se esperaba una aproximación considerablemente más alta.
A esa altitud, las condiciones atmosféricas representaban un riesgo grave para la misión.
La NASA perdió la señal de la nave. Los intentos posteriores de recuperar las comunicaciones no tuvieron éxito. La misión fue declarada perdida.
Meses de viaje.
Años de desarrollo.
Equipos especializados.
Millones de dólares.
Todo terminó en un instante.
Pero la causa del fracaso no comenzó aquel día.
El problema no fue solamente convertir mal una unidad
La explicación más popular de Mars Climate Orbiter suele resumirse así: “Alguien confundió millas con kilómetros”.
Pero esa frase no describe correctamente el error técnico. El problema documentado involucraba unidades de impulso: libra-fuerza segundo y newton-segundo.
Y tampoco sería correcto reducir toda la responsabilidad a una sola conversión.
La investigación identificó problemas más amplios en la organización y ejecución de la misión. Entre ellos, deficiencias en la comunicación entre equipos, en los procedimientos de navegación, en la identificación y resolución de anomalías y en los mecanismos de verificación.
Esta distinción es importante. Porque una investigación de calidad no debería detenerse al encontrar el error más visible. Debe preguntarse:
- ¿Por qué se utilizó una unidad diferente de la requerida?
- ¿Por qué el intercambio de información no detectó esa incompatibilidad?
- ¿Por qué los controles no identificaron el problema a tiempo?
- ¿Por qué determinadas discrepancias en la navegación no fueron resueltas adecuadamente?
- ¿Y qué condiciones permitieron que un error persistiera hasta convertirse en una pérdida irreversible?
Cuando cada departamento cree estar haciendo correctamente su trabajo
Imaginemos una organización cualquiera.
- El departamento comercial registra cantidades en cajas.
- Producción interpreta las cantidades como unidades individuales.
- Compras utiliza kilogramos.
- El proveedor entrega en libras.
- El área financiera calcula utilizando otra referencia.
Cada departamento puede estar trabajando correctamente dentro de sus propios criterios. Sin embargo, cuando la información atraviesa las fronteras entre procesos, aparecen las incompatibilidades.
Y una organización no funciona como una colección de departamentos independientes. Funciona como un sistema. El resultado de un proceso suele convertirse en la entrada del siguiente.
Por eso, no basta con que cada área controle su propio trabajo. También es necesario controlar las interfaces entre procesos.
- ¿Qué información se entrega?
- ¿En qué formato?
- ¿Con qué unidades?
- ¿Bajo qué criterios?
- ¿Quién verifica su interpretación?
- ¿Quién confirma que el receptor comprende exactamente lo mismo que el emisor?
Mars Climate Orbiter demuestra que estas preguntas no son detalles administrativos. Pueden determinar el éxito o fracaso de una operación.
El costo de la no calidad puede ser mucho mayor que el costo del control
En las organizaciones suele existir presión para reducir gastos: menos revisiones, menos ensayos, menos verificaciones, menos tiempo dedicado a documentar, menos reuniones técnicas, menos controles antes de liberar un producto o ejecutar una actividad.
Muchas veces esas medidas se presentan como mejoras de eficiencia. Y algunas realmente pueden serlo.
Pero existe una diferencia fundamental entre eliminar actividades innecesarias y eliminar controles que protegen el resultado.
En Mars Climate Orbiter, la pérdida de la nave representó aproximadamente US$125 millones correspondientes a su desarrollo. El costo del proyecto y de la misión completa fue mayor, según el alcance de los gastos considerados.
El valor económico es impactante. Pero también se perdieron oportunidades científicas, tiempo de trabajo y capacidades que habían sido destinadas a aquella misión.
Esto permite introducir un concepto fundamental: el costo de la no calidad.
Un error puede generar retrabajos, desperdicios, reclamaciones, penalizaciones, paradas de producción, pérdida de clientes, daños reputacionales, accidentes o, en casos extremos, la pérdida completa de un proyecto.
La estandarización no es burocracia
Para muchas personas, hablar de procedimientos, especificaciones y unidades de medida parece poco emocionante. Son asuntos que suelen quedar escondidos detrás de la innovación.
Cuando observamos una nave espacial, admiramos sus motores, sus sensores, su capacidad de comunicación, sus materiales, su diseño. Pocas veces pensamos en el documento que establece qué unidad debe utilizar cada sistema.
Sin embargo, ese documento puede ser tan importante como cualquiera de los componentes tecnológicos.
La estandarización permite que diferentes personas y sistemas trabajen sobre referencias comunes. No significa eliminar toda flexibilidad. Significa establecer reglas claras allí donde la variación puede producir errores.
Un procedimiento correctamente definido debe indicar no solamente qué hacer. También debe establecer cómo interpretar los resultados, qué criterios utilizar, qué información registrar, cómo verificarla y qué hacer cuando aparecen discrepancias.
Porque una organización puede tener tecnología extraordinaria y procesos incapaces de comunicarse entre sí.
La diferencia entre verificar y suponer
Hay una expresión muy peligrosa en cualquier empresa: “Yo pensé que…”
- Yo pensé que el proveedor utilizaba las mismas unidades.
- Yo pensé que el departamento técnico había revisado los datos.
- Yo pensé que el procedimiento estaba actualizado.
- Yo pensé que alguien había confirmado la información.
- Yo pensé que el software realizaba automáticamente la conversión.
- Yo pensé que el otro equipo sabía.
La palabra pensé no representa necesariamente una falla individual. Muchas veces revela una falla del sistema.
Cuando una actividad crítica depende de supuestos que nadie confirma, existe una vulnerabilidad.
La verificación consiste precisamente en sustituir determinados supuestos por evidencia.
Acerca del autor
