Capítulo 10 — Infraestructura crítica y seguridad sectorial: calidad y diagnóstico de averías

Capítulo 10 — Infraestructura crítica y seguridad sectorial: calidad y diagnóstico de averías

Mapa de la lección

Lección 10 publicada. Mapa, ejemplo, EX046.

flowchart TD
  N0["Resultados de aprendizaje y conexión"]
  N1["10.1 Cómo fallan los programas"]
  N2["10.2 Diagnosticar un fallo de coordinación"]
  N3["10.3 Calidad de las decisiones"]
  N4["10.5 Cerrar las acciones correctivas"]
  N5["10.6 Actividad práctica"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX046"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje y conexión"]
  N1["10.1 Cómo fallan los programas"]
  N2["10.2 Diagnosticar un fallo de coordinación"]
  N3["10.3 Calidad de las decisiones"]
  N4["10.5 Cerrar las acciones correctivas"]
  N5["10.6 Actividad práctica"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX046"]

[Resultados de aprendizaje y conexión]
    |
    v
[10.1 Cómo fallan los programas]
    |
    v
[10.2 Diagnosticar un fallo de coordinación]
    |
    v
[10.3 Calidad de las decisiones]
    |
    v
[10.5 Cerrar las acciones correctivas]
    |
    v
[10.6 Actividad práctica]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX046]

Resultados de aprendizaje y conexión

Al terminar este capítulo debería ser capaz de:

• reconocer los patrones de fallo habituales de los programas de coordinación de la seguridad;
• diagnosticar con método un fallo de coordinación (síntoma, hipótesis, evidencia, causa, corrección) en lugar de culpar a las personas;
• medir la calidad de las decisiones en un ejercicio o en un incidente, no solo su rapidez;
• conducir un proceso de acciones correctivas que de verdad cierre las acciones.

El capítulo 9 dejó al descubierto fallos reales de coordinación. Este capítulo trata el propio programa como un sistema que puede diagnosticarse y mejorarse.

10.1 Cómo fallan los programas

La mayoría de los fallos de coordinación encajan en unos pocos patrones:

• Lagunas de titularidad: actividades o riesgos sin nadie que rinda cuentas (capítulos 4 y 6).
• Responsabilidad duplicada: dos personas creen cada una que actuó la otra.
• Información obsoleta: contactos, mapas de dependencias, listas de proveedores o registros que eran correctos el año pasado.
• Controles de papel: documentados, pero nunca observados ni probados (capítulo 7).
• Cuellos de botella: una misma persona en todas las rutas críticas.
• Deterioro de las acciones: lecciones identificadas tras cada ejercicio y nunca aplicadas.
• Rapidez sin calidad: decisiones tomadas a tiempo, pero sin justificación, con información errónea o sin las personas adecuadas.

10.2 Diagnosticar un fallo de coordinación

Use la misma disciplina que usan los ingenieros con las averías técnicas:

1. Enuncie el síntoma con precisión («se llamó al hospital 15 minutos después de las 2 horas contractuales»).
2. Enumere hipótesis («nadie era responsable de la llamada»; «el número de contacto era erróneo»; «el reloj de 2 horas empezó en un momento distinto para personas distintas»).
3. Reúna evidencia (registros de decisiones, registros de llamadas, entrevistas) sin culpar a nadie.
4. Descarte las hipótesis que contradice la evidencia.
5. Corrija la causa, no el síntoma, y decida cómo verificará la corrección.

Un hábito útil: preguntar «¿qué hizo que esto fuera lo razonable en aquel momento?». Las personas rara vez actúan con descuido en una crisis; actúan con la información y las funciones que tenían.

10.3 Calidad de las decisiones

La puntualidad es fácil de medir; la calidad es más difícil, pero más importante. Para cada decisión clave de un ejercicio o un incidente, compruebe: ¿tenía un responsable? ¿Se tomó dentro del tiempo objetivo? ¿Se registró la justificación? ¿Se consultó a quienes había que consultar? ¿Se basó en información verificada, con los supuestos etiquetados? La guía del NIST sobre programas de pruebas, formación y ejercicios describe cómo evaluar los ejercicios frente a sus objetivos y recoger las lecciones (NIST SP 800-84).

10.4 Ejemplo resuelto: el registro del ejercicio de mesa de mayo (sintético)

En el ejercicio de mesa de mayo DRY CREEK (su diseño es el ejemplo resuelto del capítulo 11), un evaluador llevó un registro de decisiones. El Lab 10 lo comprueba. Lab 10 (guárdelo como lab10.py y ejecútelo con python3 lab10.py):

# Lab 10 - tabletop decision-log quality check (offline, standard library only; synthetic exercise log)
import csv, io
LOG = """minute,inject,decision,owner,target_min,taken_min,recorded_rationale
0,I1 HMI shows unexpected setpoint change,convene incident team,Coordinator,15,9,yes
20,I2 vendor reports stolen laptop,suspend vendor remote access,Ops manager,30,52,yes
35,I3 station KW-04 dosing alarm,switch KW-04 to manual,Ops manager,10,6,no
50,I4 journalist calls,holding statement,,30,41,yes
65,I5 hospital asks about water safety,brief hospital,Coordinator,20,,no
80,I6 regulator early-warning clock,send early warning,Coordinator,60,44,yes
"""
rows = list(csv.DictReader(io.StringIO(LOG)))
met = 0
for r in rows:
    f = []
    if not r["owner"]: f.append("no owner")
    if not r["taken_min"]: f.append("no decision taken")
    elif int(r["taken_min"]) > int(r["target_min"]): f.append(f"late {int(r['taken_min'])-int(r['target_min'])} min")
    else: met += 1
    if r["recorded_rationale"] != "yes": f.append("no rationale recorded")
    print(f"{r['inject'][:2]} {r['decision']:30s} {'ok' if not f else '; '.join(f)}")
print(f"decisions within target: {met}/{len(rows)}")

Salida esperada (Python 3.13.5):

I1 convene incident team          ok
I2 suspend vendor remote access   late 22 min
I3 switch KW-04 to manual         no rationale recorded
I4 holding statement              no owner; late 11 min
I5 brief hospital                 no decision taken; no rationale recorded
I6 send early warning             ok
decisions within target: 3/6

El titular «3/6 dentro del objetivo» oculta más de lo que muestra:

• La decisión de I3 de pasar KW-04 a manual fue rápida (6 minutos frente a 10) y se contó como puntual, pero no se registró ninguna justificación. En una decisión relacionada con la seguridad de las personas, eso importa: en un incidente real, la revisión no sabría si se tomó por los datos de dosificación, por precaución o por una conjetura.
• La declaración provisional de I4 no tenía responsable (otra vez el defecto de comunicación del capítulo 6) y llegó tarde.
• I5, la sesión informativa al hospital, nunca se decidió. En la puesta en común en caliente, los jugadores dijeron que «daban por hecho que se encargaba comunicación».
• I2, la suspensión del acceso del proveedor, llegó 22 minutos tarde. Los jugadores explicaron que nadie sabía si suspender el acceso de HydroLogic detendría el soporte a un problema de dosificación que estaba en curso. Esa es una causa de información que faltaba, no de lentitud.

La tabla de diagnóstico de la coordinadora:

10.5 Cerrar las acciones correctivas

Las lecciones no mejoran nada hasta que se convierten en acciones con responsables, fechas y verificación, y se cierran. Haga su seguimiento en un solo lugar, revíselas en el comité de riesgos y verifique cada cierre con evidencia (el próximo ejercicio, una prueba, un documento). Una métrica útil del programa es el porcentaje de acciones de ejercicios cerradas y verificadas dentro de su plazo. En la revisión de DRY CREEK, cada corrección tiene su verificación correspondiente: la próxima inyección del ejercicio sobre el hospital, un registro de proveedores con una columna de dependencias comprobado en la próxima revisión del acceso y una nueva ejecución del Lab 10 que muestre las justificaciones registradas.

10.6 Actividad práctica

Tome un fallo reciente de cualquier equipo que conozca (un plazo incumplido, una tarea duplicada). Rellene la tabla de diagnóstico sin nombrar a personas y proponga una corrección con un método de verificación. Escriba el síntoma como un hecho preciso con horas o recuentos, como en el ejemplo del hospital, y no como un juicio. Enumere al menos tres hipótesis antes de buscar evidencia y anote qué evidencia descartó cada una. Pregunte qué hizo que la acción fuera razonable para las personas implicadas en aquel momento. Después elija una corrección que cambie una función, una herramienta o una información, no una que pida a las personas que se esfuercen más, y diga cómo sabrá que funcionó, por ejemplo en el próximo ejercicio o revisión.

10.7 Errores comunes y límites

• Concluir «error humano» y detenerse ahí.
• Acciones sin verificación, cerradas por la palabra del responsable.

• Corregir en exceso con procesos pesados que ralentizan las respuestas reales; mantenga las correcciones proporcionadas.

• Corregir el síntoma con una exhortación («comunicarse mejor»), como recordar al personal que llame al hospital, mientras la RACI sigue mostrando dos R.

• Medir el éxito de un ejercicio solo por la rapidez, contando como buena una decisión rápida sin justificación registrada, como el paso de KW-04 a manual en DRY CREEK.
• Hacer el seguimiento de las acciones en varios lugares, de modo que nadie puede ver cuáles están vencidas.

Ejercicios — capítulo 10

EX046 — Lea el Lab 10. Objetivo: interpretar la calidad de las decisiones. Insumos: la salida del Lab 10. Pasos: explicar por qué «3/6 dentro del objetivo» exagera el desempeño y nombrar el defecto más grave. Evidencia esperada: la explicación. Rúbrica: 3 = I3 contado como puntual sin justificación; I5 no se tomó en absoluto (riesgo para un cliente crítico); I4 sin responsable; el más grave es I5 o I3, con razonamiento; 2 = enumera los defectos sin juicio; 1 = acepta el 3/6; 0 = nada.

EX047 — Añada una regla de calidad. Objetivo: codificar otra comprobación. Insumos: el Lab 10. Pasos: añadir las columnas safety y consulted; señalar toda decisión relacionada con la seguridad de las personas cuyo responsable no sea el jefe de operaciones y en la que no se consultara al jefe de operaciones; probarlo con las seis filas originales más una fila inventada en la que la responsable de seguridad decide aislar una estación sin consultar a operaciones; mostrar la salida. Evidencia esperada: código y salida. Rúbrica: 3 = columnas rellenadas en todas las filas, regla limitada a las decisiones de seguridad de las personas, la fila inventada señalada e I3 (cuyo responsable es operaciones) no señalada, con ese resultado explicado; 2 = la regla señala todas las filas sin entrada de consulta; 1 = solo la regla; 0 = nada.

EX048 — Diagnostique I4. Objetivo: aplicar 10.2. Insumos: la fila de I4 y la RACI del capítulo 6. Pasos: rellenar la tabla de diagnóstico para la declaración provisional. Evidencia esperada: una fila de la tabla con hipótesis. Rúbrica: 3 = al menos dos hipótesis, evidencia (la RACI no tenía A para la declaración pública), causa, corrección (consejero delegado A, comunicación R, plantilla), verificación (próximo ejercicio); 2 = sin verificación; 1 = «comunicación fue lenta»; 0 = nada.

EX049 — Diagnostique información obsoleta. Objetivo: reconocer el deterioro. Insumos: durante un incidente, el número fuera de horario del hospital daba a una línea desconectada. Pasos: proponer un análisis de causas y una corrección duradera. Evidencia esperada: análisis y corrección. Rúbrica: 3 = causa: ningún responsable ni calendario para verificar los contactos; corrección: llamadas de prueba trimestrales con responsable, actualización ante las reorganizaciones del hospital, segunda vía de contacto; métrica de verificación; 2 = actualización puntual; 1 = culpa; 0 = nada.

EX050 — Cierre las acciones. Objetivo: diseñar el seguimiento de las acciones correctivas. Insumos: las tres correcciones de 10.4. Pasos: escribir un registro de acciones con responsable, fecha límite, evidencia de cierre y método de verificación. Evidencia esperada: el registro. Rúbrica: 3 = cada una tiene un responsable con autoridad, una fecha realista, una evidencia de cierre distinta de la afirmación del responsable y una verificación en un ejercicio o una revisión posteriores; 2 = sin verificación; 1 = solo una lista; 0 = nada.

Síntesis del capítulo

Los programas de coordinación fallan de maneras reconocibles: lagunas de titularidad, responsabilidad duplicada, información obsoleta, controles de papel, cuellos de botella, deterioro de las acciones y rapidez sin calidad. Diagnostíquelos como averías, del síntoma a las hipótesis y la evidencia hasta la causa, sin culpar a nadie. Mida la calidad de las decisiones, no solo la rapidez, y cierre las acciones correctivas solo con evidencia verificada.

Siga estudiando — capítulo 10 de 12

← Capítulo 09 · Índice de capítulos del curso · Capítulo 11 →

Continúe con la siguiente lección escrita.