Presentación proyecto Caso real de la NASA 000164510.pdf

Caso real de la NASA sobre la importancia de la responsabilidad en la toma de decisiones.

1. CASO REAL
DE LA NASA
Por: Leidy Janneth Raguex De León
Carnet: 000164510
RESPONSABILIDAD, EL LIDERAZGO, TRABAJO
EN EQUIPO Y TOMA DE DECISIONES

2. ¿Quién es el responsable del trabajo
de los controladores de vuelo?
El responsable dentro de esta misión fue
Gene Kranz quien tenía el puesto de
Director de Vuelo durante el programa
Apollo 1.
Adicionalmente, cada controlador fue
directamente responsable del control
completo del subsistema bajo su cargo,
por ejemplo, el subsistema de propulsión,
y principalmente, de detener el proceso
en caso de presentarse algún fallo.

3. ¿Cómo realizaron su trabajo los
controladores ya empoderados y en
control cada uno de su función?
En el contexto de los controladores se tiene la política
Go/No-Go para especificar si el procedimiento continúa o
debe detenerse. Tomando en cuenta el empoderamiento,
los controladores no hicieron un buen trabajo debido a las
siguientes causas:
· No actuaron para detener el procedimiento, incluso
cuando ellos contaban con la facultad para hacerlo
· Quizá fue por temor a represalias, pero según el video,
nada contaba con pruebas exhaustivas para corroborar el
correcto funcionamiento, es claro que existían fallas que
pudieron detectarse a tiempo y haber evitado la catástrofe.

4. ¿Cuál fue el error?
Puedo concluir que se tuvieron dos tipos de
error:
· El error técnico que fue el incendio dentro
de la cabina dado que la cabina tenía una
atmósfera de oxígeno 100% puro, lo cual pudo
constatar que habían elementos dentro de
ella que podrían reaccionar bajo una
atmósfera de ese tipo.
· El error humano que fue principalmente
de los controladores para no detener el
procedimiento incluso cuando tenían la
facultad para hacerlo.

5. ¿De quién fue el error?
Según Gene Kranz, la causa fue ellos mismos, es decir, los
Controladores en conjunto con el Director de Vuelo, debido a
los siguientes factores:
· Los simuladores no estaban preparados.
· El software del control de la misión no funcionaba.
· Los procedimientos no se completaron.
· Prácticamente no había periodo de prueba para todo lo
que habían hecho para la misión.

Pero lo más crucial, según mi punto de vista, fue que nadie
levantó la mano para alzar la voz y pedir que detuvieran todo.

6. ¿Cómo se pudo haber evitado?
En el contexto del empoderamiento, se pudo haber evitado que
llegara al catastrófico desenlace si todos los controladores
hubieran ejercido su autoridad y responsabilidad para detener el
proceso al momento de encontrar algún error en el subsistema
asignado a cada uno. Este proceso se puede desglosar en dos
incisos:
· La Política Go/No-Go da la facultad a cada controlador para
detener el procedimiento en caso de encontrar algún fallo en el
subsistema asignado
· Según Gene Kranz, los simuladores no estaban preparados y
el software del control de la misión no funcionaba, por lo tanto,
tener pruebas exhaustivas para todo lo que pueda repercutir
debería ser un estándar de calidad antes de cualquier
procedimiento de lanzamiento.

7. Identifique la responsabilidad, la
autoridad, la decisión y la consecuencia
expuesta en este caso.
Responsabilidad: Monitorear para asegurar que el
subsistema asignado esté funcionando
correctamente y, de no ser así, hacerlo saber para
detener el procedimiento.
Autoridad: Facultad de poder detener el
procedimiento de lanzamiento.
Decisión: La decisión que tomaron los controladores
fue errónea, ya que no hicieron saber cuando tenían
defectos en los subsistemas asignados a cada uno, y
decidieron continuar con el procedimiento a pesar
de estas anomalidades.
Consecuencia: Fallecimiento de tres astronautas:
Gus Grissom, Ed White y Roger Chaffee.

8. Con la autoridad para
interrumpir la operación,
corresponde emitir un
No-Go ante la detección
de cualquier falla en el
proceso de lanzamiento.1
En mi área de trabajo hemos
implementado un sistema de
pruebas cruzadas para comprobar
que los diseños vayan sin
inconvenientes, es decir, el trabajo
de un diseñador es posteriormente
revisado por otro diseñador, lo cual
ha reducido drásticamente los
errores de impresión flexográfica,
por lo tanto, considero que esta
práctica sería muy buena para ser
implementada por el área
tecnológica para generar algún
tipo de alertas al momento de
detectarse inconvenientes.
Generar una bitácora de
fallos donde se describa
cuál fue el fallo y cómo fue
corregido, de manera que
esas fallas puedan
verificarse durante las
pruebas y no generen
errores al momento de
ejecutar los procedimientos
de lanzamiento.
Póngase en el lugar de uno de los
controladores de vuelo empoderados y
proponga 3 soluciones que debieron
ponerse en acción para evitar el accidente.2 3

9. ¿Estoy dispuesto a asumir la
responsabilidad de mis decisiones?
Sí, esto es mi día a día en mi rol dentro de la
empresa donde trabajo. Sin importar si son
buenas o algún par de veces malas, siempre
he tomado la responsabilidad y para eso
traigo un ejemplo bastante sencillo y corto:
En mi trabajo estoy a cargo de realizar
diseños flexográficos relacionados a sellos,
en una ocasión tomé una mala decisión al
momento del diseño, lo cual significó que
los sellos salieron erróneos y tuve que darlo a
conocer lo más rápido posible para no tener
impacto en el tiempo de entrega, sin
importar que este fallo repercutiría en mi
salario ya que estos sellos son cobrados de
nómina al final del mes.