Un
amigo mío que es piloto aviador me contó que -en aproximación para aterrizar en
el AICM durante el segundo día de niebla- no pudo ver la pista sino hasta que
estuvo a 3 kilómetros (1.8 millas)... eso no es peligroso para la aviación,
pero sí lo es para las personas que viven en CDMX. Y la verdad es que, si
Tláloc no se hubiera mostrado misericordioso, la cosa se hubiera puesto muy,
muy mal. Y por si creen que la lluvia “limpia el aire”, la noticia es que eso
no es tan cierto como parece. Lo digo por cultura nomás.
Por
eso no se entiende que durante 4 días completos no se haya hecho nada para
controlar ni el problema, ni sus efectos. Fuera de las recomendaciones de
siempre (que no están mal), no hubo ni una sola acción realmente útil o bien
enfocada. Y luego viene Don Goyo y expulsa ceniza, haciendo la cosa más
complicada... hay que chingarse.
Pero
el fondo de esto es que, sin un plan de contingencia bien organizado, parece
que lo que se espera es que todo el personal diga “bueno, pues no pasa nada...
me pongo un tapabocas bien chido y con eso la hago” ... y eso no funciona así,
pero eso es tema para otro día.
Según
el diccionario, una contingencia es “algo que tiene el potencial de ocurrir,
pero sobre lo que no se tiene certeza”. Por lo tanto, hablar de contingencias
es hablar de “cosas que podrían pasar, pero no sabemos cuándo, ni dónde”.
Por
lo tanto, el control de contingencias tiene que ver con prever para protegerse,
y para poder responder y controlar la situación cuando algo no va bien. Por lo
tanto, un punto básico de los planes de contingencia es que no es buena idea
esperar a que la contingencia suceda para diseñarlos, porque si no, mal
asunto.
¿Todo
claro, niños? Muy bien. Ahora a lo que los truje: Crear un plan de contingencia
requiere ciencia -en verso y todo ¿eh? - pero tampoco es necesario ser físico
teórico como el gran Sheldon Cooper.
A
grandes rasgos, un plan de contingencia (desde ahora “PC”) es una secuencia de
acciones establecidas de antemano para que cuando una contingencia se
manifiesta y afecta a un entorno determinado, los daños se puedan controlar lo
antes posible, y sea posible recuperarse más rápido.
Nota: Para hacer esto
más simple, a las “contingencias” les llamaremos “disrupciones”, al “entorno”
le llamaremos “sistema” y a los “efectos” de les llamaremos “daños”.
Otra nota: La
situación ideal sería que la recuperación del sistema sea a condiciones mejores
que las que había antes de la disrupción, pero esto no siempre es posible
(lana, recursos, personal etc.), así que vamos dejándolo ahí, porque si me meto
en eso el asunto ya causa honorarios J
Para
generar un PC existe una secuencia básica -y buena por probada- que es más o
menos así:
1.
Lo primero es
definir el sistema que se quiere proteger, o sea definir en dónde se va a
aplicar el plan si hace falta... puede ser cualquier cosa: una casa, una
ciudad, una planta industrial, una oficina, un campus universitario, un
estadio, el metro... ustedes decídanlo y así escribo menos. Lo que quiero decir
es que un PC se puede aplicar a cualquier sistema, chico o grande y -de
nuevo- no hay que ser genio. Protección Civil tiene muy buena información sobre
cómo hacer uno para una casa, por ejemplo.
2.
Luego hay que investigar
un poco para identificar disrupciones pasadas y potenciales. Para esto hay que echarse
un clavado en históricos y registros -y además buscar “datos duros”
actualizados- para identificar dos cosas súper importantes:
a.
Disrupciones que
hayan afectado el sistema anteriormente (tan atrás en el tiempo como sea
posible para tener la mayor cantidad de información), los daños que causaron, y
cómo se recuperó el sistema. Además de encontrar qué pasó, esto se hace por si
hay alguna que otra “lección aprendida” que se pueda adaptar a las condiciones
y circunstancias actuales.
b.
Disrupciones que
tengan el potencial de afectar el sistema, es decir, eventos que por su
importancia puedan causar daños, o afectar la rutina diaria de un “algo”,
definido algunos párrafos arriba.
3.
Ya identificadas
las disrupciones, hay que analizar la información disponible para definir el
nivel de afectación de cada una, es decir, entender claramente qué tan duro le
pegaron o pueden pegarle al sistema (pinches disrupciones... nomás andan viendo
a qué darle en la torre). Y a partir de ahí, establecer prioridades para
atenderlas según el grado de daño conocido o esperado -léase “dependiendo de
qué tan cabrona pueda ponerse la cosa”.
Ahora
sí, aquí viene lo bueno:
4.
Con las
prioridades en la mano, hay que establecer medidas para “neutralizar” las
disrupciones antes de que sucedan siempre que sea posible. Esto es el “no va
más” de los PC. Cuando funcionan como herramienta preventiva. Y no
crean... la verdad es que se puede hacer pocas veces, más por una cuestión de
costos y recursos que por otra cosa.
5.
Y ahora sí, hay
que establecer las medidas/programas/métodos/protocolos de control para que,
cuando la maldita disrupción “pegue”, los daños se puedan controlar lo antes
posible, y se pueda regresar a la “condición normal” tan pronto como se pueda. ÉSTO
son los planes de contingencia como tales, y tienen todo escrito ahí: Quién
hace qué, cuándo, con qué y hasta dónde -y eso aplica para todo: autoridad para
tomar decisiones, organización de operaciones, comunicaciones, etc.
6.
Y por último,
cada vez que se activan deben evaluarse para asegurarse de que funcionaron, y
para mejorar la cosa en preparación para la próxima vez.
Eso sí: No son enchiladas porque cualquier PC necesita
inversión, recursos, y entrenamiento, así que si es muy grande es complicado, pero
siempre se pueden hacer.
Y lo importante de los últimos días no es que no
hubiera uno: es que los protocolos existen, se han aplicado antes y han
funcionado. ¿Qué sucedió ahora? Que nadie tuvo los tamaños para tomar
decisiones hasta que la cosa se puso crítica y no sólo eso: El manejo de todo
el asunto fue, por lo menos, malo.
Mal hecho, Señora. Muy mal.
Atte.
Nalgador Sobo. Director General de Asuntos Sin
Importancia.
No hay comentarios:
Publicar un comentario