La Prueba de las 3 AM: Construyendo un Sistema de Gestión de Relaves que Funciona Cuando Nadie Está Mirando

Son las 3:17 AM un domingo. El centro de operaciones está vacío excepto por el supervisor del turno nocturno. Ha estado revisando su teléfono cada diez minutos durante la última hora, observando la aplicación de seguimiento de tormentas. La lluvia comenzó a medianoche. Ya 80mm y sigue cayendo fuerte. El pronóstico del tiempo falló con este — se suponía que sería un sistema rutinario. A las 3:22 AM, su teléfono vibra. Alerta automática: “El piezómetro P-14 excedió el umbral Amarillo. Lectura: 24.3 kPa. Anterior: 19.1 kPa. Tasa de aumento: 5.2 kPa en 90 minutos.” Abre el panel de monitoreo. P-14 está en la zona crítica en la cara sur. El TARP es claro: el umbral Amarillo requiere notificación al RTFE y aumento de la frecuencia de monitoreo. Pero son las 3 AM un domingo. El RTFE está en casa, probablemente dormido. El superintendente no está de turno. El EOR está en otra ciudad. Tiene dos opciones: Opción 1: Despertar a la gente, seguir el TARP, parecer que está exagerando por una tormenta. Opción 2: Monitorearlo él mismo, esperar hasta el turno de la mañana para reportarlo. Quizás se estabilice. No hay necesidad de entrar en pánico. Lo que sucede a continuación revela si tienes un Sistema de Gestión de Relaves o solo documentos de gestión de relaves.

El Requisito 8.2 del GISTM exige: “Establecer un marco de gobernanza de relaves y un TMS basado en el desempeño.” Pero aquí está lo que ese requisito no te dice: La verdadera prueba de tu TMS no es durante operaciones normales, reuniones programadas, o cuando el liderazgo está observando. Es a las 3 AM. Durante cambios de turno. En días festivos. Cuando las personas experimentadas están de vacaciones. Cuando surgen condiciones inusuales. Cuando nadie está mirando. Ahí es cuando descubres si tienes sistemas que funcionan - o sistemas que existen en papel.

Qué Significa “Sistema” Realmente (La Mayoría de las Personas Se Equivocan en Esto)

Lo que un sistema NO es:

• Una carpeta llena de procedimientos
• Un organigrama
• Una plataforma de software
• Un conjunto de requisitos
• Una lista de verificación de cumplimiento

Lo que un sistema ES:

• Componentes interconectados que trabajan juntos
• Bucles de retroalimentación que permiten la autocorrección
• Redundancia para que fallas individuales no se propaguen en cascada
• Funciones de forzado que hacen lo correcto fácil y lo incorrecto difícil
• Resiliencia para absorber condiciones inesperadas
• Capacidad de aprendizaje que mejora con el tiempo

La diferencia:

Documentos: “En caso de activación del TARP amarillo, se debe notificar al RTFE dentro de 24 horas.”

Sistema: La alerta automática envía SMS al teléfono del RTFE y al teléfono de respaldo, crea un ticket en el sistema de gestión con temporizador, escala automáticamente si no se reconoce en 2 horas, registra la notificación para la pista de auditoría, alertas similares activan el reconocimiento de patrones para ver si múltiples parámetros muestran preocupaciones.

¿Ves la diferencia? El documento te dice qué debería suceder. El sistema hace que suceda.

Las Seis Características de los Sistemas que Funcionan a las 3 AM

Característica 1: Predeterminado a Seguro (No Predeterminado a Conveniente)

Los sistemas que fallan a las 3 AM hacen que la elección incorrecta sea la elección fácil:

Ejemplo:

• El TARP requiere notificación inmediata
• Pero la notificación requiere encontrar números de teléfono, despertar a la gente, explicar la situación
• Elección fácil: Esperar hasta la mañana
• Elección segura: Notificar ahora

Los sistemas que funcionan a las 3 AM hacen que la elección segura sea la elección fácil:

Cómo se ve esto:

• Botón único: “Activar Respuesta TARP Amarillo”
• El botón notifica automáticamente a todas las personas requeridas a través de múltiples canales (SMS, llamada, notificación de aplicación)
• Crea registro de incidente con marca de tiempo
• Muestra acciones inmediatas recomendadas en pantalla
• Proporciona plantilla para informe de situación
• Se conecta a datos de monitoreo relevantes automáticamente

Ahora la elección fácil y la elección segura son la misma.

Ejemplo real de mina en Chile:

Antes del rediseño del sistema:

• La activación del TARP requería que el operador llamara al RTFE (número de teléfono en carpeta)
• Luego llamar al superintendente
• Luego documentar en el libro de registro
• Luego enviar resumen por correo electrónico
• Tiempo promedio para completar notificaciones: 45 minutos (si se hace inmediatamente)
• Realidad: A menudo retrasado hasta el cambio de turno o turno diurno

Después del rediseño del sistema:

• El sistema de monitoreo detecta automáticamente la activación del TARP
• Envía notificaciones sin acción del operador
• Pero el operador todavía tiene un papel: Confirmar situación, agregar observaciones, indicar cualquier acción inmediata tomada
• El sistema presenta al operador una interfaz simple: ¿Qué ves? ¿Qué has hecho?
• Tiempo promedio desde la activación hasta notificaciones completas: 90 segundos

El resultado: El trabajo del operador se volvió más fácil (menos trabajo) mientras que la seguridad mejoró (respuesta más rápida, sin notificaciones perdidas).

Característica 2: Responsabilidad Visible (Todos Saben Quién Hace Qué)

Los sistemas que fallan a las 3 AM tienen responsabilidad ambigua:

Preguntas de ejemplo que los operadores no pueden responder:

• “¿A quién llamo primero?”
• “¿Qué pasa si el RTFE no contesta?”
• “¿Llamo al EOR o lo hace el RTFE?”
• “¿Puedo tomar esta decisión o necesito aprobación?”

Cuando la responsabilidad no está clara, las personas dudan o aplazan.

Los sistemas que funcionan a las 3 AM tienen responsabilidad cristalina:

Ejemplo real de matriz de responsabilidad (simplificada):

Situación	Acción Inmediata	Quién Decide	Quién Debe Ser Notificado	Quién Puede Detener Operaciones
TARP Amarillo	Aumentar monitoreo	Supervisor	RTFE (dentro de 2 hrs)	RTFE
TARP Naranja	Implementar restricciones operacionales	RTFE	RTFE + Superintendente + EOR	RTFE o superior
TARP Rojo	Detener operaciones inmediatamente	Cualquiera	Todos + Respuesta de emergencia	Cualquiera
Falla de equipo que afecta monitoreo	Cambiar a respaldo/manual	Supervisor	Mantenimiento + RTFE	N/A (operaciones continúan)
Filtración visible en el pie	Detener deposición, documentar, investigar	Supervisor	RTFE inmediatamente	RTFE

Esta matriz es:

• Visible (publicada en sala de control, en dispositivos móviles, en oficinas de campo)
• Específica (sin ambigüedad)
• Empoderadora (las personas saben que tienen autoridad para actuar)

Y aquí está la clave: La matriz dice explícitamente que “Cualquiera” puede activar el TARP Rojo.

El mensaje: Si crees que es una emergencia, estás empoderado para declararlo. No necesitas permiso para estar preocupado.

Característica 3: Funciones de Forzado (Hacer Difíciles las Elecciones Incorrectas)

Las funciones de forzado son características del sistema que previenen o señalan acciones peligrosas.

Ejemplo de aviación: Las puertas de las aeronaves están diseñadas para que no puedan abrirse durante el vuelo (el diferencial de presión lo hace físicamente imposible). No puedes hacer accidentalmente lo incorrecto.

Equivalente en gestión de relaves:

Escenario: Operaciones de deposición acercándose al francobordo mínimo

Sistema sin función de forzado:

• Las operaciones continúan hasta que alguien nota que el francobordo es inadecuado
• Depende de la vigilancia humana

Sistema con función de forzado:

• El sistema de monitoreo rastrea el francobordo continuamente
• A 2.5m de francobordo: Alerta amarilla se muestra en pantallas de operaciones (“Acercándose al francobordo mínimo”)
• A 2.0m de francobordo (mínimo): Alerta naranja + notificación automática al RTFE + recomendación de suspender deposición
• A 1.5m de francobordo (crítico): Alerta roja + operaciones deben reconocer alerta y documentar justificación para continuar

La función de forzado: El sistema hace difícil continuar operaciones sin reconocer que estás en estado de no cumplimiento.

Ejemplo real de mina de oro en Nevada:

Implementaron funciones de forzado de “Verificación de Intención de Diseño”:

Monitoreo de pendiente de playa:

• Pendiente objetivo: 1-2%
• Levantamiento con dron calcula pendientes reales semanalmente
• Si alguna área excede 3%: El sistema marca, operaciones recibe notificación
• Función de forzado: No puede proceder con deposición en esa área hasta que se corrija la pendiente o se obtenga y documente la aprobación de ingeniería

Resultado: Antes de la implementación, las pendientes de playa ocasionalmente alcanzaban 5-6% (preocupante desde perspectiva de estabilidad) antes de ser corregidas. Después de la implementación, nunca excedió 3.5% porque el sistema detectó y forzó la corrección temprano.

Característica 4: Redundancia (Sin Puntos Únicos de Falla)

Los sistemas que fallan a las 3 AM dependen de individuos o componentes únicos:

Escenarios de fallas de punto único:

• Solo el RTFE entiende los TARPs (¿qué pasa cuando el RTFE está de vacaciones?)
• Solo una persona sabe cómo interpretar datos de monitoreo específicos (¿qué pasa si no está disponible?)
• La información crítica existe en una ubicación (¿qué pasa si ese sistema falla?)
• Canal de comunicación único (¿qué pasa si está caído?)

Los sistemas que funcionan a las 3 AM tienen redundancia:

Redundancia en personas:

• RTFE principal y RTFE de respaldo designado (capacitación cruzada, ambos tienen autoridad)
• Múltiples personas capacitadas en TARPs y protocolos de respuesta
• Planificación de sucesión para roles clave
• Documentación suficiente para que personal calificado pueda intervenir

Redundancia en tecnología:

• Sistema de monitoreo principal y respaldo (diferentes plataformas si es posible)
• Alertas automatizadas a través de múltiples canales (SMS + correo electrónico + aplicación + llamada telefónica)
• Datos almacenados de forma redundante (local + nube, múltiples respaldos)
• Respaldo de energía para sistemas críticos (generadores, UPS)

Redundancia en comunicación:

• Múltiples métodos de contacto para personal clave (teléfono de trabajo + teléfono personal + correo electrónico + teléfono de casa)
• Árboles de comunicación (si la persona principal no responde, el sistema contacta al secundario)
• Respaldos físicos (contactos de emergencia impresos en sala de control)

Ejemplo real de mina en Indonesia:

Incidente de 2019: El sistema principal de monitoreo de piezómetros falló durante el fin de semana. El registrador de datos se corrompió. Nadie lo notó hasta el lunes porque no había respaldo.

Rediseño del sistema:

• Se instaló monitoreo redundante (dos sistemas independientes leyendo los mismos instrumentos)
• Validación automática diaria de datos (compara lecturas entre sistemas, marca si son divergentes)
• Verificaciones manuales semanales (personal de campo verifica físicamente que los instrumentos clave estén funcionando)
• Sistemas de energía de respaldo con conmutación automática
• Sistemas de comunicación redundantes (celular + satélite)

Prueba de 2023: El sistema principal tuvo una falla de hardware el viernes por la noche. El sistema de respaldo continuó operando, la falla fue detectada a través de la validación automatizada, el equipo de mantenimiento fue notificado y lo arregló el sábado por la tarde. Las operaciones continuaron de manera segura durante todo el tiempo.

Sin punto único de falla significó que el sistema se degradó con gracia en lugar de fallar catastróficamente.

Característica 5: Bucles de Retroalimentación (El Sistema se Autocorrige)

Los sistemas que fallan a las 3 AM son de bucle abierto:

Sistema de bucle abierto:

• Entrada → Acción → Salida
• Sin verificación de que la salida sea correcta
• Sin corrección si la salida está mal

Ejemplo: El procedimiento dice “realizar inspección visual diaria.” La persona hace la inspección. Completa la lista de verificación. Listo.

Pero: ¿Qué pasa si se perdieron algo? ¿Qué pasa si las condiciones cambiaron después de la inspección? ¿Qué pasa si la lista de verificación no captura lo que importa hoy?

Los sistemas que funcionan a las 3 AM son de bucle cerrado:

Sistema de bucle cerrado:

• Entrada → Acción → Salida → Medición → Comparación con lo Esperado → Corrección si es Necesario

Ejemplo: Inspección visual diaria, pero con retroalimentación:

• Inspección realizada, lista de verificación completada
• Fotos tomadas en ubicaciones clave
• Fotos comparadas automáticamente con días anteriores (IA marca cambios)
• Supervisor revisa cambios marcados
• Si hay cambio significativo: Activa investigación
• Los resultados de la investigación vuelven a alimentar la lista de verificación de inspección (¿qué deberíamos buscar en el futuro?)

El sistema aprende y mejora.

Ejemplo real de bucle de retroalimentación de mina de cobre en Canadá:

Sistema de seguimiento de respuesta TARP:

• Evento: Ocurre activación de TARP
• Acción: Se implementa el protocolo de respuesta
• Medición: El sistema rastrea el tiempo de respuesta, las acciones tomadas, el resultado
• Análisis: Revisión mensual de todas las activaciones de TARP:
  • ¿Qué tan rápido respondimos?
  • ¿Fueron efectivas las respuestas?
  • ¿Seguimos los protocolos?
  • ¿Fueron apropiados los protocolos?
• Corrección: Actualizar TARPs, capacitación, sistemas basados en el análisis
• Verificación: Rastrear si los cambios mejoraron el desempeño

Lo que descubrieron a través del análisis de retroalimentación:

Descubrimiento 1: Tiempo promedio desde activación Amarilla hasta notificación al RTFE: 3.2 horas (el objetivo era 2 horas)

• Causa raíz: Operadores del turno nocturno dudaban en despertar al RTFE por “tal vez nada”
• Corrección: Protocolo cambiado - notificación automatizada más el operador agrega contexto (“lluvia fuerte en curso, tendencia de aumento continúa” vs “lluvia detenida, lectura estabilizándose”). El RTFE puede evaluar la situación sin que el operador se preocupe por falsas alarmas.
• Resultado: El tiempo promedio de notificación bajó a 0.3 horas.

Descubrimiento 2: TARPs Naranjas activados tres veces en 6 meses, cada vez durante lluvia fuerte. Los piezómetros aumentaron bruscamente, luego cayeron de nuevo a normal dentro de 48 horas a medida que el agua drenaba.

• Pregunta: ¿Son los umbrales demasiado sensibles? ¿O es apropiada la respuesta rápida?
• Análisis: EOR revisó. Determinó que los umbrales eran apropiados para detectar problemas potenciales, pero las reversiones rápidas indicaban que el drenaje estaba funcionando bien. No falsas alarmas - sistema funcionando según lo diseñado.
• Corrección: Sin cambio de umbral, pero capacitación mejorada para operaciones: “Estos picos durante tormentas son esperados. Respondemos porque es prudente, no porque pensemos que la falla es inminente. Si los piezómetros NO bajan después de que pare la lluvia, esa es la verdadera preocupación.”
• Resultado: El personal de operaciones entendió mejor el sistema, menos fatiga de alarmas, mantuvo la vigilancia apropiada.

El bucle de retroalimentación convirtió los datos en aprendizaje.

Característica 6: Resiliencia (El Sistema Funciona Bajo Estrés)

Los sistemas que fallan a las 3 AM son frágiles:

Sistemas frágiles:

• Funcionan bien bajo condiciones normales
• Fallan cuando están estresados (clima inusual, fallas de equipo, múltiples problemas simultáneos, personal clave ausente)
• Modos de falla catastrófica (pequeñas perturbaciones causan grandes fallas)

Los sistemas que funcionan a las 3 AM son resilientes:

Sistemas resilientes:

• Funcionan bajo condiciones normales Y anormales
• Se degradan con gracia bajo estrés (el desempeño disminuye pero no colapsa)
• Se recuperan rápidamente de perturbaciones
• Aprenden de eventos estresantes y se vuelven más fuertes

Ejemplo real: Probar la resiliencia a través de simulación:

Mina en Australia realizó “simulaciones de prueba de estrés”:

Simulación 1: “Todo se Rompe el Viernes por la Noche”

• Escenario: El sistema de monitoreo principal falla a las 10 PM del viernes. El sistema de respaldo muestra tendencia preocupante del piezómetro. Pronóstico de tormenta para la noche. RTFE de vacaciones. Superintendente en boda (inalcanzable). EOR no contesta el teléfono.
• Pregunta: ¿Qué sucede?

Realidad pre-2020: Habría sido caos. Probablemente respuesta retrasada hasta el lunes. Posiblemente peligroso.

Sistema post-2020:

• El monitoreo de respaldo continúa
• El RTFE de respaldo recibe alerta automatizada
• El supervisor de operaciones tiene autoridad para implementar medidas de precaución (reducir deposición, prepararse para emergencia)
• El ingeniero de guardia (designado semanalmente) proporciona apoyo técnico
• EOR tiene contacto de respaldo (socio en la firma que conoce la instalación)
• El sistema se degradó pero no falló

Simulación 2: “Escenario de Cascada”

• Lluvia fuerte → Piezómetros en aumento → TARP Amarillo activado → Monitoreo aumentado revela falla de instrumento → Necesidad de evaluar con instrumentación reducida → Mientras tanto, pendiente de playa aumentando detectada → Múltiples problemas simultáneamente
• Pregunta: ¿Puede el sistema manejar múltiples problemas concurrentes?

Resultado: Identificaron que su sistema podía manejar 2 problemas simultáneos pero tendría dificultades con 3+. Crearon plan de capacidad de oleada: Contratistas preidentificados en espera, autoridad de presupuesto de emergencia, protocolos de movilización rápida.

El valor de las pruebas de estrés: Revela debilidades del sistema antes de que ocurran emergencias reales.

El Elemento Humano: Los Sistemas Deben Tener en Cuenta Cómo se Comportan Realmente los Humanos

Aquí hay una verdad incómoda: Incluso los procedimientos perfectos fallan si no tienen en cuenta la psicología humana.

Factor Humano 1: Fatiga de Decisión

Realidad: A las 3 AM en un turno de 12 horas, la capacidad de toma de decisiones de las personas está deteriorada.

Respuesta del diseño del sistema:

• Minimizar las decisiones requeridas fuera del horario
• Automatizar lo que se puede automatizar
• Proporcionar orientación clara para las decisiones requeridas
• Escalar a personal fresco cuando sea posible

Ejemplo:

Sistema malo: “Si la lectura del piezómetro está elevada, determinar la respuesta apropiada según las condiciones, historial de lluvia, otras lecturas de instrumentos y juicio de ingeniería.”

A las 3 AM después de 9 horas de turno: Eso es demasiada carga cognitiva. La persona probablemente se predeterminará a “esperar hasta el turno diurno.”

Sistema bueno: “Si el piezómetro excede el umbral: (1) Alerta automática enviada. (2) Tú: Verifica la lectura revisando otros instrumentos en la misma zona. (3) El sistema muestra: ¿Otras lecturas también están elevadas? Sí/No. (4) Si Sí: Implementar Protocolo A (mostrado en pantalla). Si No: Posible problema de instrumento - cambiar a respaldo si está disponible, documentar en registro.”

Decisión reducida a verificación simple y seguimiento del protocolo mostrado.

Factor Humano 2: Normalización de la Desviación

Realidad: Cuando nada malo sucede a pesar de desviaciones menores de los procedimientos, las personas gradualmente aceptan desviaciones mayores como normales.

Ejemplo de progresión:

• Semana 1: TARP dice notificar dentro de 2 horas. Notificamos dentro de 3 horas. No pasó nada malo.
• Semana 4: Notificamos dentro de 6 horas. Todavía bien.
• Semana 12: Esperando hasta el siguiente turno para notificar. Se convierte en la norma.
• Semana 30: Ocurre evento mayor. Respuesta retrasada porque la práctica real se había desviado mucho del procedimiento.

Respuesta del diseño del sistema:

Pista de auditoría y monitoreo de desempeño:

• El sistema rastrea tiempos de respuesta REALES, no solo si ocurrió la respuesta
• Informes automatizados marcan desviaciones (informe mensual al Ejecutivo Responsable muestra: Notificación objetivo de 2 horas lograda 73% del tiempo, promedio real 4.1 horas)
• Las desviaciones desencadenan revisión: ¿Por qué no estamos cumpliendo objetivos? ¿Son objetivos poco realistas? ¿O no se están siguiendo los procedimientos?

De cualquier manera, la visibilidad previene la deriva.

Ejemplo real de mina que detectó la normalización temprano:

La auditoría mensual de TARP reveló: Las activaciones Naranjas deberían detener la deposición inmediatamente pendiente de evaluación. Práctica real: La deposición continuó mientras ocurría la evaluación (promedio 4 horas). Sucedió 5 veces en 6 meses.

La investigación reveló: Las operaciones sintieron que detener inmediatamente era “exagerar” porque las evaluaciones siempre concluían que la deposición podía reanudarse. Así que continuaron mientras esperaban la evaluación.

Respuesta:

• Corto plazo: Recordatorio de que el protocolo debe seguirse como está escrito
• Largo plazo: Protocolo actualizado - la activación Naranja permite deposición continua durante hasta 2 horas SI la evaluación está en curso Y el RTFE autoriza explícitamente. Después de 2 horas, debe detenerse hasta que se complete la evaluación.

Resultado: Protocolo modificado para coincidir con la realidad mientras se mantiene la seguridad. Pero el protocolo original se hizo cumplir hasta que ocurrió el cambio formal - previniendo que la normalización continuara sin control.

Factor Humano 3: Efecto Espectador y Difusión de Responsabilidad

Realidad: Cuando múltiples personas están presentes (o podrían estar involucradas), los individuos tienen menos probabilidades de tomar acción, asumiendo que alguien más lo hará.

Ejemplo: Múltiples supervisores de turno ven tendencia de monitoreo preocupante. Cada uno asume que otro supervisor lo reportará. Nadie lo reporta.

Respuesta del diseño del sistema:

Asignación individual clara:

• No “alguien debería revisar los piezómetros”
• Sino “Charlie: Estás asignado a la verificación de piezómetros hoy, resultados debidos para las 14:00, el sistema alertará si no se completa”

Forzar reconocimiento:

• Las alertas críticas requieren reconocimiento: “Haz clic aquí para confirmar que TÚ has recibido esta alerta y estás asumiendo la responsabilidad de la respuesta”
• Sin ambigüedad sobre quién es responsable

Escalación por inacción:

• Si la alerta no se reconoce dentro del plazo, escala al supervisor
• Crea responsabilidad

Factor Humano 4: Sesgo de Retrospección (El Problema del “Debería Haber Sabido”)

Realidad: Después de un incidente, es fácil decir “deberían haber sabido que esto era serio.” Pero en el momento, sin retrospección, las señales son ambiguas.

Respuesta del diseño del sistema:

Diseñar para la ambigüedad:

• Aceptar que las personas enfrentarán situaciones ambiguas
• Errar del lado de la precaución
• Hacer que “escalar cuando no estás seguro” sea el comportamiento alentado
• No castigar a las personas por “falsas alarmas”

Ejemplo real de manejo bien de la ambigüedad:

Mina en Perú, 2 AM, supervisor nocturno observa:

• La lectura del piezómetro P-7 aumentó 8% en 6 horas
• Todavía muy por debajo del umbral Amarillo
• Lluvia fuerte antes (detenida hace 3 horas)
• La lectura podría ser solo respuesta a lluvia
• O podría ser el comienzo de una tendencia

Lo que hizo: Llamó al RTFE de respaldo (persona de guardia designada). Explicó la situación: “Probablemente nada, pero quería que estuvieras al tanto. Lo estoy vigilando.”

Respuesta del RTFE de respaldo: “Buena decisión. Sigue monitoreando cada hora. Si continúa aumentando o si otros instrumentos muestran cambios, llámame de inmediato. Si se estabiliza, lo revisaremos en la mañana.”

Resultado: La lectura se estabilizó dentro de 2 horas. Fue respuesta a lluvia.

Pero aquí está la parte importante:

La semana siguiente, en la reunión de operaciones:

• El supervisor mencionó la llamada
• Algunos colegas: “¿Despertaste al RTFE por nada?”
• RTFE (que estaba allí): “No - eso fue exactamente correcto. Prefiero recibir diez llamadas sobre tendencias que resultan ser nada que perderme una que sea realmente importante. Hiciste el juicio correcto.”

El mensaje cultural: Errar del lado de la precaución es alentado, no burlado.

Eso es un sistema que funciona.

Construyendo Sistemas, No Solo Procedimientos: Un Marco Práctico

Si estás convencido de que tu TMS necesita ser un sistema en lugar de documentos, pero no sabes cómo llegar allí:

Paso 1: Mapear el Estado Actual (Dónde se Rompen los Sistemas)

Ejercicio para tu equipo:

Presenta escenarios y pregunta: “¿Qué sucedería realmente?”

Ejemplos de escenarios:

• “3 AM sábado. Alerta automática muestra umbral Amarillo del piezómetro. ¿Qué sucede en los próximos 30 minutos?”
• “Turno diurno. Múltiples instrumentos mostrando lecturas inusuales (no activaciones de TARP pero raras). ¿Quién investiga? ¿Cuánto tiempo toma?”
• “RTFE de vacaciones, superintendente en conferencia. TARP Naranja activado. ¿Quién toma las decisiones?”

Mapea el proceso real:

• ¿Quién es notificado (realmente, no teóricamente)?
• ¿Cuánto tiempo toma (realmente, no según el procedimiento)?
• ¿Qué decisiones se toman y por quién?
• ¿Dónde se rompe el proceso?
• ¿Qué información no está disponible cuando se necesita?

Identifica brechas:

• Responsabilidades ambiguas
• Flujos de información faltantes
• Tecnología que no apoya el flujo de trabajo
• Procedimientos que nadie sigue realmente
• Puntos únicos de falla

Paso 2: Diseñar Componentes del Sistema (Tecnología + Personas + Procesos)

Para cada función clave, diseña un sistema integrado:

Ejemplo: Sistema de Respuesta TARP

Componentes necesarios:

Tecnología:

• Detección automática de umbrales
• Sistema de notificación multicanal
• Herramientas de apoyo a la decisión (¿qué datos debo mirar?)
• Herramientas de documentación (capturar lo que sucedió)
• Temporizadores de escalación (alerta si no hay respuesta)

Personas:

• Asignaciones de roles claras
• Personal principal y de respaldo
• Capacitación sobre uso del sistema
• Niveles de autoridad definidos

Procesos:

• Umbrales TARP y respuestas
• Protocolos de comunicación
• Marcos de toma de decisiones
• Proceso de revisión posterior a la acción

Integración:

• La tecnología apoya a las personas ejecutando procesos
• Los procesos aprovechan las capacidades de la tecnología
• Las personas entienden por qué el sistema está diseñado de esta manera

Paso 3: Construir Retroalimentación y Mejora

Cada componente del sistema necesita mecanismo de retroalimentación:

Ejemplos:

Sistema TARP:

• Rastrear cada activación: Tiempo de respuesta, acciones tomadas, resultado, si fue efectivo
• Análisis mensual: ¿Son apropiados los umbrales? ¿Funcionan las respuestas? ¿Siguen los protocolos las personas?
• Revisión trimestral: Mejoras del sistema basadas en el análisis

Sistema de capacitación:

• Rastrear finalización de capacitación
• Probar retención de conocimiento
• Medir desempeño de personal capacitado vs no capacitado
• Actualizar capacitación basada en errores reales cometidos en campo

Sistema de monitoreo:

• Rastrear confiabilidad de instrumentos
• Medir calidad de datos
• Identificar instrumentos que frecuentemente fallan o dan lecturas cuestionables
• Optimizar red de monitoreo basada en el valor de diferentes instrumentos

Paso 4: Probar Bajo Condiciones Realistas

No solo asumas que el sistema funcionará - pruébalo:

Tipos de pruebas:

Prueba funcional: ¿Funciona cada componente? (Prueba técnica de software, instrumentos, comunicaciones)

Prueba de integración: ¿Funcionan los componentes juntos? (Pruebas de flujo de trabajo completo)

Prueba de estrés: ¿Funciona el sistema bajo condiciones anormales? (Simulaciones de fallas múltiples, escenarios fuera de horario, personal clave ausente)

Prueba de usuario: ¿Pueden los usuarios reales usar el sistema efectivamente? (Observar usuarios reales, identificar dónde tienen dificultades)

Ejemplo real de prueba que revela problemas:

Mina probó su sistema de respuesta de emergencia:

• Simuló TARP Naranja a las 2 AM del viernes
• Probó si el sistema de notificación funcionaba, si el personal respondía apropiadamente, si la información estaba disponible

Lo que descubrieron:

• La tecnología funcionó: Alertas enviadas, recibidas, reconocidas
• Brecha de información: El personal necesitaba revisar datos recientes del clima y operaciones para evaluar la situación. Esos datos no eran fácilmente accesibles a las 2 AM (requería iniciar sesión en múltiples sistemas)
• Brecha de apoyo a decisiones: RTFE recibió alerta pero sin orientación sobre qué información revisar o a quién consultar

Resultado: El rediseño del sistema incluyó panel integrado accesible vía teléfono mostrando clima reciente, operaciones y todos los datos de monitoreo relevantes en un solo lugar.

La prueba reveló que el sistema funcionaba técnicamente pero no apoyaba efectivamente la toma de decisiones.

Paso 5: Incorporar Mejora Continua

Los sistemas deben evolucionar:

Cómo se ve esto:

Revisión trimestral del sistema:

• ¿Qué incidentes ocurrieron?
• ¿Cómo se desempeñó el sistema?
• ¿Qué casi accidentes ocurrieron?
• ¿Qué aprendizajes externos son relevantes? (incidentes en otras instalaciones, nuevas tecnologías, cambios regulatorios)
• ¿Qué mejoras deberíamos hacer?

Auditoría anual del sistema:

• ¿El sistema todavía es adecuado para el propósito?
• ¿Han cambiado los riesgos requiriendo actualizaciones del sistema?
• ¿Las tecnologías están obsoletas?
• ¿El personal tiene las habilidades y conocimientos necesarios?
• ¿Todavía se siguen y son efectivos los procedimientos?

Captura continua de aprendizaje:

• Revisiones posteriores a la acción para cada evento significativo
• Aprendizaje documentado y compartido
• Sistema actualizado basado en aprendizajes
• Tendencias analizadas para problemas sistémicos

Ejemplo real de mina con mejora continua madura:

Mantienen “Registro de Evolución del Sistema”:

• Cada cambio del sistema documentado con justificación
• Enlaces a incidentes o aprendizajes que impulsaron el cambio
• Efectividad de los cambios rastreada con el tiempo

Entrada de ejemplo:

• Fecha: Marzo 2023
• Cambio: Agregada comunicación redundante celular y satelital para sistema de monitoreo
• Justificación: Incidente de noviembre de 2022 - red celular caída durante tormenta, datos de monitoreo no disponibles remotamente
• Seguimiento de efectividad: Tiempo de actividad de comunicación 99.97% desde el cambio (vs 97.3% antes). Sin brechas de comunicación durante 8 eventos climáticos significativos desde la implementación.

El registro muestra que el sistema está aprendiendo y mejorando continuamente.

El Papel del Sistema de Cumplimiento: Habilitando el Pensamiento de Sistemas

Tu plataforma de cumplimiento GISTM debería apoyar sistemas, no solo documentar requisitos:

Lo que Habilitan las Plataformas de Cumplimiento con Pensamiento de Sistemas:

1. Integración de Flujo de Trabajo

• Conectar datos de monitoreo → Evaluación TARP → Acciones de respuesta → Documentación → Revisión
• Enrutamiento automatizado de información a las personas correctas en el momento correcto
• Capturar actividad completa del sistema, no solo puntos finales

2. Análisis de Desempeño

• Rastrear desempeño del sistema (tiempos de respuesta, efectividad, tasas de cumplimiento)
• Identificar tendencias y patrones
• Marcar degradación antes de la falla

3. Apoyo a Bucle de Retroalimentación

• Plantillas de revisión posterior a la acción y seguimiento
• Captura y compartición de aprendizaje
• Seguimiento de mejora del sistema

4. Prueba de Escenarios

• Simular eventos y probar respuesta del sistema
• Documentar ejercicios y aprendizajes
• Rastrear preparación con el tiempo

5. Integración con Sistemas Operacionales

• Conectar a sistemas de monitoreo (datos fluyen automáticamente)
• Conectar a operaciones (registros de deposición, mantenimiento, clima)
• Vista única del estado de la instalación habilitando mejores decisiones

6. Acceso Móvil

• Sistema accesible desde cualquier lugar (crítico para escenarios de 3 AM)
• Funciona en teléfonos, tabletas, portátiles
• Capacidad sin conexión para ubicaciones remotas

El objetivo: El sistema de cumplimiento se convierte en la infraestructura que permite que tu TMS funcione como un sistema integrado, no un repositorio de documentación.

La Pregunta que Solo Tú Puedes Responder

Como Ejecutivo Responsable, imagina esto:

Son las 3 AM. Estás dormido. Condiciones inusuales se desarrollan en tu instalación - no catastróficas, pero requieren juicios y respuesta coordinada.

Tu supervisor del turno nocturno está enfrentando esta situación sin ti.

Pregunta: ¿Confías en tu sistema?

No: ¿Confías en ese individuo? (El personal cambia)

Sino: ¿Confías en que tu TMS:

• Detectará la situación
• Notificará a las personas correctas
• Proporcionará la información necesaria
• Apoyará decisiones apropiadas
• Documentará lo que sucede
• Escalará si es necesario
• Mantendrá a las personas seguras

Si tu respuesta honesta es “espero que sí” o “probablemente” o “no estoy seguro” - tienes trabajo que hacer.

Porque el GISTM no solo requiere que tengas un TMS.

Requiere que tu TMS realmente funcione - todo el día, todos los días, incluso a las 3 AM cuando nadie está mirando.

Esa es la prueba que importa.

¿Tu TMS la está superando?

---

¿Tu sistema de cumplimiento GISTM habilita un TMS integrado, o solo documenta procedimientos aislados? [Descubre plataformas que apoyan el pensamiento de sistemas y operaciones resilientes]