O Teste das 3 da Manhã: Construindo um Sistema de Gestão de Barragens que Funciona Quando Ninguém Está Olhando

São 3:17 da manhã de um domingo. O centro de operações está vazio, exceto pelo supervisor do turno noturno. Ele está verificando o telefone a cada dez minutos na última hora, observando o aplicativo de rastreamento de tempestades. A chuva começou à meia-noite. Já 80mm e ainda caindo forte. A previsão do tempo errou nesta — deveria ser um sistema de rotina. Às 3:22 da manhã, o telefone vibra. Alerta automático: “Piezômetro P-14 excedeu o limite Amarelo. Leitura: 24.3 kPa. Anterior: 19.1 kPa. Taxa de aumento: 5.2 kPa em 90 minutos.” Ele abre o painel de monitoramento. P-14 está na zona crítica na face sul. O TARP é claro: limite Amarelo requer notificação ao RTFE e aumento da frequência de monitoramento. Mas são 3 da manhã de domingo. O RTFE está em casa, provavelmente dormindo. O superintendente está fora de turno. O EOR está em outra cidade. Ele tem duas opções: Opção 1: Acordar as pessoas, seguir o TARP, parecer que está exagerando por causa de uma tempestade. Opção 2: Monitorar ele mesmo, esperar até o turno da manhã para reportar. Talvez estabilize. Não há necessidade de entrar em pânico. O que acontece a seguir revela se você tem um Sistema de Gestão de Barragens ou apenas documentos de gestão de barragens.

O Requisito 8.2 do GISTM determina: “Estabelecer uma estrutura de governança de barragens e um TMS baseado em desempenho.” Mas aqui está o que esse requisito não te diz: O verdadeiro teste do seu TMS não é durante operações normais, reuniões programadas, ou quando a liderança está observando. É às 3 da manhã. Durante mudanças de turno. Em feriados. Quando pessoas experientes estão de férias. Quando condições inusuais surgem. Quando ninguém está olhando. É quando você descobre se tem sistemas que funcionam - ou sistemas que existem no papel.

O que “Sistema” Realmente Significa (A Maioria das Pessoas Erra Nisso)

O que um sistema NÃO é:

• Uma pasta cheia de procedimentos
• Um organograma
• Uma plataforma de software
• Um conjunto de requisitos
• Uma lista de verificação de conformidade

O que um sistema É:

• Componentes interconectados que trabalham juntos
• Loops de feedback que permitem autocorreção
• Redundância para que falhas individuais não se propaguem em cascata
• Funções de força que tornam o certo fácil e o errado difícil
• Resiliência para absorver condições inesperadas
• Capacidade de aprendizado que melhora com o tempo

A diferença:

Documentos: “No caso de ativação do TARP amarelo, o RTFE deve ser notificado dentro de 24 horas.”

Sistema: O alerta automático envia SMS para o telefone do RTFE e telefone de backup, cria um ticket no sistema de gestão com temporizador, escala automaticamente se não for reconhecido em 2 horas, registra a notificação para trilha de auditoria, alertas similares ativam reconhecimento de padrões para ver se múltiplos parâmetros mostram preocupações.

Vê a diferença? O documento te diz o que deveria acontecer. O sistema faz acontecer.

As Seis Características dos Sistemas que Funcionam às 3 da Manhã

Característica 1: Padrão Seguro (Não Padrão Conveniente)

Sistemas que falham às 3 da manhã tornam a escolha errada a escolha fácil:

Exemplo:

• O TARP requer notificação imediata
• Mas a notificação requer encontrar números de telefone, acordar pessoas, explicar a situação
• Escolha fácil: Esperar até a manhã
• Escolha segura: Notificar agora

Sistemas que funcionam às 3 da manhã tornam a escolha segura a escolha fácil:

Como isso se parece:

• Botão único: “Acionar Resposta TARP Amarelo”
• O botão notifica automaticamente todas as pessoas necessárias através de múltiplos canais (SMS, ligação, notificação de app)
• Cria registro de incidente com carimbo de data/hora
• Exibe ações imediatas recomendadas na tela
• Fornece modelo para relatório de situação
• Conecta-se a dados de monitoramento relevantes automaticamente

Agora a escolha fácil e a escolha segura são a mesma.

Exemplo real de mina no Chile:

Antes do redesenho do sistema:

• A ativação do TARP exigia que o operador ligasse para o RTFE (número de telefone na pasta)
• Depois ligar para o superintendente
• Depois documentar no livro de registro
• Depois enviar resumo por e-mail
• Tempo médio para completar notificações: 45 minutos (se feito imediatamente)
• Realidade: Frequentemente atrasado até mudança de turno ou turno diurno

Depois do redesenho do sistema:

• O sistema de monitoramento detecta automaticamente a ativação do TARP
• Envia notificações sem ação do operador
• Mas o operador ainda tem um papel: Confirmar situação, adicionar observações, indicar quaisquer ações imediatas tomadas
• O sistema apresenta ao operador uma interface simples: O que você vê? O que você fez?
• Tempo médio desde ativação até notificações completas: 90 segundos

O resultado: O trabalho do operador ficou mais fácil (menos trabalho) enquanto a segurança melhorou (resposta mais rápida, sem notificações perdidas).

Característica 2: Responsabilidade Visível (Todos Sabem Quem Faz O Quê)

Sistemas que falham às 3 da manhã têm responsabilidade ambígua:

Perguntas de exemplo que operadores não conseguem responder:

• “Para quem eu ligo primeiro?”
• “E se o RTFE não atender?”
• “Eu ligo para o EOR ou o RTFE faz isso?”
• “Posso tomar esta decisão ou preciso de aprovação?”

Quando a responsabilidade não está clara, as pessoas hesitam ou adiam.

Sistemas que funcionam às 3 da manhã têm responsabilidade cristalina:

Exemplo real de matriz de responsabilidade (simplificada):

Situação	Ação Imediata	Quem Decide	Quem Deve Ser Notificado	Quem Pode Parar Operações
TARP Amarelo	Aumentar monitoramento	Supervisor	RTFE (dentro de 2 hrs)	RTFE
TARP Laranja	Implementar restrições operacionais	RTFE	RTFE + Superintendente + EOR	RTFE ou superior
TARP Vermelho	Parar operações imediatamente	Qualquer um	Todos + Resposta de emergência	Qualquer um
Falha de equipamento afetando monitoramento	Mudar para backup/manual	Supervisor	Manutenção + RTFE	N/A (operações continuam)
Infiltração visível no pé	Parar deposição, documentar, investigar	Supervisor	RTFE imediatamente	RTFE

Esta matriz é:

• Visível (afixada na sala de controle, em dispositivos móveis, em escritórios de campo)
• Específica (sem ambiguidade)
• Empoderadora (pessoas sabem que têm autoridade para agir)

E aqui está o ponto-chave: A matriz diz explicitamente que “Qualquer um” pode acionar o TARP Vermelho.

A mensagem: Se você acha que é uma emergência, você está empoderado para declarar. Você não precisa de permissão para estar preocupado.

Característica 3: Funções de Força (Tornando Escolhas Erradas Difíceis)

Funções de força são recursos do sistema que previnem ou sinalizam ações perigosas.

Exemplo da aviação: Portas de aeronaves projetadas para que não possam ser abertas durante o voo (diferencial de pressão torna fisicamente impossível). Você não pode acidentalmente fazer a coisa errada.

Equivalente em gestão de barragens:

Cenário: Operações de deposição aproximando-se do bordo livre mínimo

Sistema sem função de força:

• Operações continuam até alguém notar que o bordo livre é inadequado
• Depende de vigilância humana

Sistema com função de força:

• Sistema de monitoramento rastreia bordo livre continuamente
• A 2.5m de bordo livre: Alerta amarelo exibido nas telas de operações (“Aproximando-se do bordo livre mínimo”)
• A 2.0m de bordo livre (mínimo): Alerta laranja + notificação automática ao RTFE + recomendação de suspender deposição
• A 1.5m de bordo livre (crítico): Alerta vermelho + operações devem reconhecer alerta e documentar justificativa para continuar

A função de força: Sistema torna difícil continuar operações sem reconhecer que você está em estado de não conformidade.

Exemplo real de mina de ouro em Nevada:

Implementaram funções de força de “Verificação de Intenção de Projeto”:

Monitoramento de declive da praia:

• Declive alvo: 1-2%
• Levantamento com drone calcula declives reais semanalmente
• Se qualquer área exceder 3%: Sistema sinaliza, operações recebe notificação
• Função de força: Não pode prosseguir com deposição naquela área até que o declive seja corrigido ou aprovação de engenharia seja obtida e documentada

Resultado: Antes da implementação, declives de praia ocasionalmente alcançavam 5-6% (preocupante da perspectiva de estabilidade) antes de serem corrigidos. Após implementação, nunca excedeu 3.5% porque o sistema detectou e forçou correção cedo.

Característica 4: Redundância (Sem Pontos Únicos de Falha)

Sistemas que falham às 3 da manhã dependem de indivíduos ou componentes únicos:

Cenários de falhas de ponto único:

• Apenas o RTFE entende os TARPs (o que acontece quando o RTFE está de férias?)
• Apenas uma pessoa sabe como interpretar dados de monitoramento específicos (e se não estiver disponível?)
• Informação crítica existe em uma localização (e se esse sistema falhar?)
• Canal de comunicação único (e se estiver fora do ar?)

Sistemas que funcionam às 3 da manhã têm redundância:

Redundância em pessoas:

• RTFE principal e RTFE de backup designado (treinamento cruzado, ambos têm autoridade)
• Múltiplas pessoas treinadas em TARPs e protocolos de resposta
• Planejamento de sucessão para funções-chave
• Documentação suficiente para que pessoal qualificado possa intervir

Redundância em tecnologia:

• Sistema de monitoramento principal e backup (plataformas diferentes se possível)
• Alertas automatizados através de múltiplos canais (SMS + e-mail + app + ligação telefônica)
• Dados armazenados de forma redundante (local + nuvem, múltiplos backups)
• Backup de energia para sistemas críticos (geradores, UPS)

Redundância em comunicação:

• Múltiplos métodos de contato para pessoal-chave (telefone de trabalho + telefone pessoal + e-mail + telefone de casa)
• Árvores de comunicação (se pessoa principal não responder, sistema contata secundária)
• Backups físicos (contatos de emergência impressos na sala de controle)

Exemplo real de mina na Indonésia:

Incidente de 2019: Sistema principal de monitoramento de piezômetros falhou durante o fim de semana. Registrador de dados corrompido. Ninguém notou até segunda-feira porque não havia backup.

Redesenho do sistema:

• Instalado monitoramento redundante (dois sistemas independentes lendo os mesmos instrumentos)
• Validação automática diária de dados (compara leituras entre sistemas, sinaliza se divergentes)
• Verificações manuais semanais (pessoal de campo verifica fisicamente que instrumentos-chave estão funcionando)
• Sistemas de energia de backup com comutação automática
• Sistemas de comunicação redundantes (celular + satélite)

Teste de 2023: Sistema principal teve falha de hardware na sexta à noite. Sistema de backup continuou operando, falha foi detectada via validação automatizada, equipe de manutenção notificada e consertou no sábado à tarde. Operações continuaram com segurança durante todo o tempo.

Sem ponto único de falha significou que o sistema degradou graciosamente em vez de falhar catastroficamente.

Característica 5: Loops de Feedback (Sistema se Autocorrige)

Sistemas que falham às 3 da manhã são de loop aberto:

Sistema de loop aberto:

• Entrada → Ação → Saída
• Sem verificação de que a saída está correta
• Sem correção se a saída estiver errada

Exemplo: Procedimento diz “realizar inspeção visual diária.” Pessoa faz a inspeção. Completa a lista de verificação. Pronto.

Mas: E se perderam algo? E se as condições mudaram após a inspeção? E se a lista de verificação não captura o que importa hoje?

Sistemas que funcionam às 3 da manhã são de loop fechado:

Sistema de loop fechado:

• Entrada → Ação → Saída → Medição → Comparação com o Esperado → Correção se Necessário

Exemplo: Inspeção visual diária, mas com feedback:

• Inspeção realizada, lista de verificação completada
• Fotos tiradas em locais-chave
• Fotos comparadas automaticamente com dias anteriores (IA sinaliza mudanças)
• Supervisor revisa mudanças sinalizadas
• Se mudança significativa: Aciona investigação
• Resultados da investigação alimentam de volta a lista de verificação de inspeção (o que devemos procurar no futuro?)

O sistema aprende e melhora.

Exemplo real de loop de feedback de mina de cobre no Canadá:

Sistema de rastreamento de resposta TARP:

• Evento: Ativação de TARP ocorre
• Ação: Protocolo de resposta implementado
• Medição: Sistema rastreia tempo de resposta, ações tomadas, resultado
• Análise: Revisão mensal de todas as ativações de TARP:
  • Quão rápido respondemos?
  • As respostas foram eficazes?
  • Seguimos os protocolos?
  • Os protocolos foram apropriados?
• Correção: Atualizar TARPs, treinamento, sistemas baseados na análise
• Verificação: Rastrear se as mudanças melhoraram o desempenho

O que descobriram através da análise de feedback:

Descoberta 1: Tempo médio desde ativação Amarela até notificação ao RTFE: 3.2 horas (meta era 2 horas)

• Causa raiz: Operadores do turno noturno hesitavam em acordar o RTFE por “talvez nada”
• Correção: Protocolo alterado - notificação automatizada mais operador adiciona contexto (“chuva forte em andamento, tendência de aumento continua” vs “chuva parou, leitura estabilizando”). RTFE pode avaliar a situação sem operador se preocupar com falsos alarmes.
• Resultado: Tempo médio de notificação caiu para 0.3 horas.

Descoberta 2: TARPs Laranjas acionados três vezes em 6 meses, cada vez durante chuva forte. Piezômetros subiram repentinamente, depois caíram de volta ao normal dentro de 48 horas conforme a água drenava.

• Pergunta: Os limites são muito sensíveis? Ou a resposta rápida é apropriada?
• Análise: EOR revisou. Determinou que limites eram apropriados para detectar problemas potenciais, mas reversões rápidas indicavam que drenagem estava funcionando bem. Não falsos alarmes - sistema funcionando conforme projetado.
• Correção: Sem mudança de limite, mas treinamento aprimorado para operações: “Esses picos durante tempestades são esperados. Respondemos porque é prudente, não porque achamos que a falha é iminente. Se os piezômetros NÃO caírem depois que a chuva parar, essa é a verdadeira preocupação.”
• Resultado: Pessoal de operações entendeu melhor o sistema, menos fadiga de alarmes, manteve vigilância apropriada.

O loop de feedback transformou dados em aprendizado.

Característica 6: Resiliência (Sistema Funciona Sob Estresse)

Sistemas que falham às 3 da manhã são frágeis:

Sistemas frágeis:

• Funcionam bem sob condições normais
• Falham quando estressados (clima inusual, falhas de equipamento, múltiplos problemas simultâneos, pessoal-chave ausente)
• Modos de falha catastrófica (pequenas perturbações causam grandes falhas)

Sistemas que funcionam às 3 da manhã são resilientes:

Sistemas resilientes:

• Funcionam sob condições normais E anormais
• Degradam graciosamente sob estresse (desempenho diminui mas não colapsa)
• Recuperam rapidamente de distúrbios
• Aprendem com eventos estressantes e se tornam mais fortes

Exemplo real: Testando resiliência através de simulação:

Mina na Austrália conduziu “simulações de teste de estresse”:

Simulação 1: “Tudo Quebra na Sexta à Noite”

• Cenário: Sistema de monitoramento principal falha às 10 PM de sexta. Sistema de backup mostra tendência preocupante de piezômetro. Previsão de tempestade para a noite. RTFE de férias. Superintendente em casamento (inalcançável). EOR não atende o telefone.
• Pergunta: O que acontece?

Realidade pré-2020: Teria sido caos. Provavelmente resposta atrasada até segunda. Possivelmente perigoso.

Sistema pós-2020:

• Monitoramento de backup continua
• RTFE de backup recebe alerta automatizado
• Supervisor de operações tem autoridade para implementar medidas de precaução (reduzir deposição, preparar para emergência)
• Engenheiro de plantão (designado semanalmente) fornece suporte técnico
• EOR tem contato de backup (parceiro na firma que conhece a instalação)
• Sistema degradou mas não falhou

Simulação 2: “Cenário de Cascata”

• Chuva forte → Piezômetros subindo → TARP Amarelo acionado → Monitoramento aumentado revela falha de instrumento → Necessidade de avaliar com instrumentação reduzida → Enquanto isso, declive da praia aumentando detectado → Múltiplos problemas simultaneamente
• Pergunta: O sistema consegue lidar com múltiplos problemas concorrentes?

Resultado: Identificaram que seu sistema podia lidar com 2 problemas simultâneos mas teria dificuldades com 3+. Criaram plano de capacidade de surto: Contratados pré-identificados em espera, autoridade de orçamento de emergência, protocolos de mobilização rápida.

O valor dos testes de estresse: Revela fraquezas do sistema antes que emergências reais ocorram.

O Elemento Humano: Sistemas Devem Considerar Como Humanos Realmente se Comportam

Aqui está uma verdade desconfortável: Mesmo procedimentos perfeitos falham se não consideram a psicologia humana.

Fator Humano 1: Fadiga de Decisão

Realidade: Às 3 da manhã em um turno de 12 horas, a capacidade de tomada de decisão das pessoas está prejudicada.

Resposta do design do sistema:

• Minimizar decisões necessárias fora do horário
• Automatizar o que pode ser automatizado
• Fornecer orientação clara para decisões necessárias
• Escalar para pessoal descansado quando possível

Exemplo:

Sistema ruim: “Se a leitura do piezômetro estiver elevada, determinar resposta apropriada baseada em condições, histórico de chuva, outras leituras de instrumentos e julgamento de engenharia.”

Às 3 da manhã após 9 horas de turno: Isso é muita carga cognitiva. A pessoa provavelmente optará por “esperar até o turno diurno.”

Sistema bom: “Se o piezômetro exceder o limite: (1) Alerta automático enviado. (2) Você: Verifique a leitura checando outros instrumentos na mesma zona. (3) Sistema exibe: Outras leituras também estão elevadas? Sim/Não. (4) Se Sim: Implementar Protocolo A (exibido na tela). Se Não: Possível problema de instrumento - mudar para backup se disponível, documentar no registro.”

Decisão reduzida a verificação simples e seguir protocolo exibido.

Fator Humano 2: Normalização do Desvio

Realidade: Quando nada de ruim acontece apesar de desvios menores dos procedimentos, as pessoas gradualmente aceitam desvios maiores como normais.

Exemplo de progressão:

• Semana 1: TARP diz notificar dentro de 2 horas. Notificamos dentro de 3 horas. Nada de ruim aconteceu.
• Semana 4: Notificamos dentro de 6 horas. Ainda bem.
• Semana 12: Esperando até o próximo turno para notificar. Se torna a norma.
• Semana 30: Evento maior ocorre. Resposta atrasada porque a prática real havia se desviado muito do procedimento.

Resposta do design do sistema:

Trilha de auditoria e monitoramento de desempenho:

• Sistema rastreia tempos de resposta REAIS, não apenas se a resposta ocorreu
• Relatórios automatizados sinalizam desvios (relatório mensal ao Executivo Responsável mostra: Notificação meta de 2 horas alcançada 73% do tempo, média real 4.1 horas)
• Desvios acionam revisão: Por que não estamos atingindo metas? As metas são irrealistas? Ou os procedimentos não estão sendo seguidos?

De qualquer forma, visibilidade previne deriva.

Exemplo real de mina que capturou normalização cedo:

Auditoria mensal de TARP revelou: Ativações Laranjas deveriam parar deposição imediatamente pendente avaliação. Prática real: Deposição continuou enquanto avaliação ocorria (média 4 horas). Aconteceu 5 vezes em 6 meses.

Investigação revelou: Operações sentiam que parar imediatamente era “exagerar” porque avaliações sempre concluíam que deposição podia ser retomada. Então continuaram enquanto esperavam avaliação.

Resposta:

• Curto prazo: Lembrete de que protocolo deve ser seguido conforme escrito
• Longo prazo: Protocolo atualizado - ativação Laranja permite deposição contínua por até 2 horas SE avaliação estiver em andamento E RTFE autorizar explicitamente. Após 2 horas, deve parar até que avaliação seja completa.

Resultado: Protocolo modificado para corresponder à realidade enquanto mantém segurança. Mas protocolo original foi aplicado até que mudança formal ocorresse - prevenindo que normalização continuasse sem controle.

Fator Humano 3: Efeito Espectador e Difusão de Responsabilidade

Realidade: Quando múltiplas pessoas estão presentes (ou poderiam estar envolvidas), indivíduos são menos propensos a tomar ação, assumindo que outra pessoa o fará.

Exemplo: Múltiplos supervisores de turno veem tendência de monitoramento preocupante. Cada um assume que outro supervisor reportará. Ninguém reporta.

Resposta do design do sistema:

Atribuição individual clara:

• Não “alguém deveria verificar piezômetros”
• Mas “Charlie: Você está designado para verificação de piezômetros hoje, resultados devidos às 14:00, sistema alertará se não completado”

Forçar reconhecimento:

• Alertas críticos requerem reconhecimento: “Clique aqui para confirmar que VOCÊ recebeu este alerta e está assumindo responsabilidade pela resposta”
• Sem ambiguidade sobre quem é responsável

Escalação por inação:

• Se alerta não for reconhecido dentro do prazo, escala ao supervisor
• Cria responsabilidade

Fator Humano 4: Viés de Retrospectiva (O Problema do “Deveria Ter Sabido”)

Realidade: Após um incidente, é fácil dizer “eles deveriam ter sabido que isso era sério.” Mas no momento, sem retrospectiva, os sinais são ambíguos.

Resposta do design do sistema:

Projetar para ambiguidade:

• Aceitar que pessoas enfrentarão situações ambíguas
• Errar do lado da precaução
• Tornar “escalar quando incerto” o comportamento encorajado
• Não punir pessoas por “falsos alarmes”

Exemplo real de lidar bem com ambiguidade:

Mina no Peru, 2 da manhã, supervisor noturno observa:

• Leitura do piezômetro P-7 aumentou 8% em 6 horas
• Ainda bem abaixo do limite Amarelo
• Chuva forte antes (parou há 3 horas)
• Leitura pode ser apenas resposta à chuva
• Ou pode ser início de tendência

O que ele fez: Ligou para RTFE de backup (pessoa de plantão designada). Explicou a situação: “Provavelmente nada, mas queria que você soubesse. Estou observando.”

Resposta do RTFE de backup: “Boa decisão. Continue monitorando a cada hora. Se continuar subindo ou se outros instrumentos mostrarem mudanças, me ligue imediatamente de volta. Se estabilizar, revisaremos pela manhã.”

Resultado: Leitura estabilizou dentro de 2 horas. Foi resposta à chuva.

Mas aqui está a parte importante:

Na semana seguinte, na reunião de operações:

• Supervisor mencionou a ligação
• Alguns colegas: “Você acordou o RTFE por nada?”
• RTFE (que estava lá): “Não - isso foi exatamente certo. Prefiro receber dez ligações sobre tendências que se revelam ser nada do que perder uma que seja realmente importante. Você fez o julgamento certo.”

A mensagem cultural: Errar do lado da precaução é encorajado, não ridicularizado.

Isso é um sistema que funciona.

Construindo Sistemas, Não Apenas Procedimentos: Uma Estrutura Prática

Se você está convencido de que seu TMS precisa ser um sistema em vez de documentos, mas não sabe como chegar lá:

Passo 1: Mapear Estado Atual (Onde os Sistemas Quebram)

Exercício para sua equipe:

Apresente cenários e pergunte: “O que realmente aconteceria?”

Exemplos de cenários:

• “3 da manhã sábado. Alerta automático mostra limite Amarelo do piezômetro. O que acontece nos próximos 30 minutos?”
• “Turno diurno. Múltiplos instrumentos mostrando leituras incomuns (não ativações de TARP mas estranhas). Quem investiga? Quanto tempo leva?”
• “RTFE de férias, superintendente em conferência. TARP Laranja acionado. Quem toma as decisões?”

Mapeie o processo real:

• Quem é notificado (realmente, não teoricamente)?
• Quanto tempo leva (realmente, não conforme procedimento)?
• Que decisões são tomadas e por quem?
• Onde o processo quebra?
• Que informação não está disponível quando necessária?

Identifique lacunas:

• Responsabilidades ambíguas
• Fluxos de informação faltantes
• Tecnologia que não suporta fluxo de trabalho
• Procedimentos que ninguém segue realmente
• Pontos únicos de falha

Passo 2: Projetar Componentes do Sistema (Tecnologia + Pessoas + Processos)

Para cada função-chave, projete sistema integrado:

Exemplo: Sistema de Resposta TARP

Componentes necessários:

Tecnologia:

• Detecção automática de limites
• Sistema de notificação multicanal
• Ferramentas de suporte à decisão (que dados devo olhar?)
• Ferramentas de documentação (capturar o que aconteceu)
• Temporizadores de escalação (alerta se sem resposta)

Pessoas:

• Atribuições de função claras
• Pessoal principal e de backup
• Treinamento sobre uso do sistema
• Níveis de autoridade definidos

Processos:

• Limites TARP e respostas
• Protocolos de comunicação
• Estruturas de tomada de decisão
• Processo de revisão pós-ação

Integração:

• Tecnologia suporta pessoas executando processos
• Processos aproveitam capacidades de tecnologia
• Pessoas entendem por que sistema é projetado desta forma

Passo 3: Construir Feedback e Melhoria

Cada componente do sistema precisa de mecanismo de feedback:

Exemplos:

Sistema TARP:

• Rastrear cada ativação: Tempo de resposta, ações tomadas, resultado, se eficaz
• Análise mensal: Os limites são apropriados? As respostas funcionam? As pessoas seguem protocolos?
• Revisão trimestral: Melhorias do sistema baseadas na análise

Sistema de treinamento:

• Rastrear conclusão de treinamento
• Testar retenção de conhecimento
• Medir desempenho de pessoal treinado vs não treinado
• Atualizar treinamento baseado em erros reais cometidos em campo

Sistema de monitoramento:

• Rastrear confiabilidade de instrumentos
• Medir qualidade de dados
• Identificar instrumentos que frequentemente falham ou dão leituras questionáveis
• Otimizar rede de monitoramento baseada no valor de diferentes instrumentos

Passo 4: Testar Sob Condições Realistas

Não apenas assuma que o sistema funcionará - teste-o:

Tipos de teste:

Teste funcional: Cada componente funciona? (Teste técnico de software, instrumentos, comunicações)

Teste de integração: Os componentes funcionam juntos? (Testes de fluxo de trabalho completo)

Teste de estresse: O sistema funciona sob condições anormais? (Simulações de múltiplas falhas, cenários fora de horário, pessoal-chave ausente)

Teste de usuário: Os usuários reais conseguem usar o sistema efetivamente? (Observar usuários reais, identificar onde têm dificuldades)

Exemplo real de teste revelando problemas:

Mina testou seu sistema de resposta de emergência:

• Simulou TARP Laranja às 2 da manhã de sexta
• Testou se sistema de notificação funcionava, se pessoal respondia apropriadamente, se informação estava disponível

O que descobriram:

• Tecnologia funcionou: Alertas enviados, recebidos, reconhecidos
• Lacuna de informação: Pessoal precisava revisar dados recentes de clima e operações para avaliar situação. Esses dados não eram facilmente acessíveis às 2 da manhã (exigia fazer login em múltiplos sistemas)
• Lacuna de suporte à decisão: RTFE recebeu alerta mas sem orientação sobre que informação revisar ou quem consultar

Resultado: Redesenho do sistema incluiu painel integrado acessível via telefone mostrando clima recente, operações e todos os dados de monitoramento relevantes em um só lugar.

O teste revelou que sistema funcionava tecnicamente mas não suportava efetivamente tomada de decisão.

Passo 5: Incorporar Melhoria Contínua

Sistemas devem evoluir:

Como isso se parece:

Revisão trimestral do sistema:

• Que incidentes ocorreram?
• Como o sistema se desempenhou?
• Que quase acidentes aconteceram?
• Que aprendizados externos são relevantes? (incidentes em outras instalações, novas tecnologias, mudanças regulatórias)
• Que melhorias devemos fazer?

Auditoria anual do sistema:

• O sistema ainda é adequado ao propósito?
• Os riscos mudaram exigindo atualizações do sistema?
• As tecnologias estão obsoletas?
• O pessoal tem as habilidades e conhecimentos necessários?
• Os procedimentos ainda são seguidos e eficazes?

Captura contínua de aprendizado:

• Revisões pós-ação para cada evento significativo
• Aprendizado documentado e compartilhado
• Sistema atualizado baseado em aprendizados
• Tendências analisadas para problemas sistêmicos

Exemplo real de mina com melhoria contínua madura:

Mantêm “Registro de Evolução do Sistema”:

• Cada mudança do sistema documentada com justificativa
• Links para incidentes ou aprendizados que impulsionaram mudança
• Eficácia de mudanças rastreada ao longo do tempo

Entrada de exemplo:

• Data: Março 2023
• Mudança: Adicionada comunicação redundante celular e satélite para sistema de monitoramento
• Justificativa: Incidente de novembro de 2022 - rede celular fora durante tempestade, dados de monitoramento não disponíveis remotamente
• Rastreamento de eficácia: Tempo de atividade de comunicação 99.97% desde mudança (vs 97.3% antes). Sem lacunas de comunicação durante 8 eventos climáticos significativos desde implementação.

O registro mostra que o sistema está aprendendo e melhorando continuamente.

O Papel do Sistema de Conformidade: Habilitando Pensamento de Sistemas

Sua plataforma de conformidade GISTM deveria suportar sistemas, não apenas documentar requisitos:

O que Plataformas de Conformidade com Pensamento de Sistemas Habilitam:

1. Integração de Fluxo de Trabalho

• Conectar dados de monitoramento → Avaliação TARP → Ações de resposta → Documentação → Revisão
• Roteamento automatizado de informação para pessoas certas no momento certo
• Capturar atividade completa do sistema, não apenas pontos finais

2. Análise de Desempenho

• Rastrear desempenho do sistema (tempos de resposta, eficácia, taxas de conformidade)
• Identificar tendências e padrões
• Sinalizar degradação antes da falha

3. Suporte a Loop de Feedback

• Modelos de revisão pós-ação e rastreamento
• Captura e compartilhamento de aprendizado
• Rastreamento de melhoria do sistema

4. Teste de Cenários

• Simular eventos e testar resposta do sistema
• Documentar exercícios e aprendizados
• Rastrear preparação ao longo do tempo

5. Integração com Sistemas Operacionais

• Conectar a sistemas de monitoramento (dados fluem automaticamente)
• Conectar a operações (registros de deposição, manutenção, clima)
• Vista única do status da instalação habilitando melhores decisões

6. Acesso Móvel

• Sistema acessível de qualquer lugar (crítico para cenários de 3 da manhã)
• Funciona em telefones, tablets, laptops
• Capacidade offline para locais remotos

O objetivo: Sistema de conformidade se torna a infraestrutura que permite que seu TMS funcione como um sistema integrado, não um repositório de documentação.

A Pergunta que Só Você Pode Responder

Como Executivo Responsável, imagine isto:

São 3 da manhã. Você está dormindo. Condições incomuns se desenvolvem em sua instalação - não catastróficas, mas exigindo julgamentos e resposta coordenada.

Seu supervisor do turno noturno está enfrentando esta situação sem você.

Pergunta: Você confia no seu sistema?

Não: Você confia naquele indivíduo? (O pessoal muda)

Mas: Você confia que seu TMS vai:

• Detectar a situação
• Notificar as pessoas certas
• Fornecer a informação necessária
• Suportar decisões apropriadas
• Documentar o que acontece
• Escalar se necessário
• Manter as pessoas seguras

Se sua resposta honesta é “espero que sim” ou “provavelmente” ou “não tenho certeza” - você tem trabalho a fazer.

Porque o GISTM não apenas requer que você tenha um TMS.

Ele requer que seu TMS realmente funcione - o dia todo, todos os dias, inclusive às 3 da manhã quando ninguém está olhando.

Esse é o teste que importa.

Seu TMS está passando nele?

---

Seu sistema de conformidade GISTM habilita um TMS integrado, ou apenas documenta procedimentos isolados? [Descubra plataformas que suportam pensamento de sistemas e operações resilientes]