Investigação de Incidentes e Acções Correctivas HSE

# Investigação de Incidentes e Acções Correctivas: O Relatório que Ninguém Volta a Abrir

TL;DR: a maioria dos sistemas de HSE não falha na investigação — falha a meio caminho, quando a acção correctiva fica atribuída a alguém, sem data de verificação real, e a não conformidade que a originou vive num registo separado que ninguém volta a fechar.

Um relatório de investigação de incidente, bem escrito, com causa raiz identificada e acções atribuídas, é o tipo de documento que impressiona numa auditoria e não serve para nada seis meses depois se ninguém sabe, sem ter de perguntar a três pessoas, se a acção 14 daquele relatório foi efectivamente implementada. Isto não é um problema de disciplina das equipas de campo. É, na maior parte dos casos que uma equipa de engenharia encontra ao desenhar estes sistemas, um problema de modelo de dados: a forma como o sistema regista a constatação, a não conformidade e a acção correctiva como três objectos separados, em vez de um único registo com estados.

Onde o processo parte: a acção que fica "atribuída" para sempre

O padrão é sempre o mesmo. Uma inspecção de HSE, uma auditoria interna ou a investigação de um incidente identificam um desvio — um extintor fora de validade, um procedimento de bloqueio e etiquetagem (LOTO) que não foi seguido, uma barreira de protecção em falta numa plataforma de trabalho. Alguém regista a constatação, atribui uma acção correctiva a um responsável, define um prazo. Até aqui, o processo funciona.

O problema aparece depois. A acção fica no estado "atribuída" ou "em curso" indefinidamente, porque:

o prazo passou e ninguém foi notificado, porque a notificação depende de alguém abrir o módulo e ver a lista;
a pessoa que devia fechar a acção mudou de função, e a acção não foi reatribuída;
a acção foi fisicamente executada — o extintor foi trocado, o procedimento foi corrigido — mas nunca foi verificada por alguém diferente de quem a implementou, pelo que o sistema continua a mostrá-la como aberta;
ou, o cenário mais comum, a acção foi marcada como "concluída" pela mesma pessoa que a implementou, sem qualquer evidência anexada, e ninguém tem forma de distinguir isso de uma acção genuinamente fechada.

Nenhum destes casos é um problema de má vontade. É a consequência directa de tratar "fechar uma acção correctiva" como um campo de estado que qualquer pessoa pode mudar, em vez de uma transição que exige um segundo actor e uma evidência.

A bifurcação que ninguém desenhou de propósito: uma constatação, dois registos

Há um segundo problema, mais subtil, que aparece sistematicamente em sistemas de HSE construídos por acumulação — um módulo de checklists de inspecção adicionado primeiro, um módulo de "não conformidades" adicionado depois, para satisfazer um requisito de auditoria ISO 45001 ou de um cliente operador. Quando isto acontece, o item de checklist marcado como "não conforme" não é, ele próprio, a não conformidade. Alguém tem de abrir um segundo registo, num módulo diferente, para descrever formalmente a não conformidade e associar-lhe uma acção correctiva.

O resultado prático: duas entradas para o mesmo facto. O item do checklist mostra "não conforme" e fica ali congelado, porque o fluxo de fecho está no outro módulo. O registo de não conformidade avança, é investigado, a acção correctiva é fechada — e ninguém volta ao checklist original para actualizar o estado. Numa auditoria, um avaliador que cruze os dois módulos encontra uma inconsistência que não existe na realidade operacional: a inspecção continua a "reportar" um desvio que já foi corrigido há meses.

Isto não é um detalhe cosmético. A Cláusula 10.2 da ISO 45001 trata precisamente disto como um único processo — reportar, investigar, agir — e não como três actividades independentes que cada uma vive no seu próprio ecrã. Quando o software separa aquilo que a norma trata como um processo contínuo, está a criar trabalho de reconciliação manual que, na prática, ninguém tem tempo de fazer de forma consistente.

Porque é que a resposta ao item do checklist deve SER a constatação

A correcção estrutural é conceptualmente simples, ainda que raramente trivial de implementar num sistema já em produção: o registo da resposta a um item de checklist marcado como não conforme não deve gerar um segundo objecto — deve ser a constatação. Um único registo, com um identificador único, que nasce no momento em que o inspector marca "não conforme" e que transporta consigo, ao longo do seu ciclo de vida, todos os estados seguintes:

1. Aberto — constatação criada a partir do item de checklist ou da investigação, com evidência fotográfica e descrição obrigatórias.

2. Causa raiz atribuída — depois de uma análise (5 Porquês, diagrama de Ishikawa, ou uma árvore de causas mais formal para incidentes graves), com o método usado registado, não apenas a conclusão.

3. Acção correctiva definida — com responsável, prazo, e critério de verificação explícito (o que é que tem de ser observado para confirmar que a acção resolveu a causa, não apenas o sintoma).

4. Acção implementada — marcada por quem a executou.

5. Verificada — marcada por uma segunda pessoa, tipicamente o responsável de HSE ou o auditor que abriu a constatação, com nova evidência.

6. Fechada — só possível depois do estado "Verificada".

Este desenho elimina a bifurcação porque não há um segundo registo para desalinhar. O item de checklist e a não conformidade são o mesmo registo visto de dois ângulos: a lista de inspecções mostra o estado actual da constatação que dele nasceu, sempre, porque é uma referência à mesma linha na base de dados, não uma cópia.

O que isto significa no modelo de dados

Em termos de esquema, isto implica que a tabela de "constatações" (findings) tenha uma chave estrangeira opcional para o item de checklist ou para o registo de investigação de incidente que a originou — nunca o inverso, e nunca uma tabela de "não conformidades" paralela com o seu próprio ciclo de vida. A máquina de estados fica centralizada num único campo status, com transições validadas no lado do servidor (não apenas na interface), e cada transição grava uma linha imutável no trilho de auditoria — quem mudou o estado, quando, com que evidência anexada. Sem essa validação de transição no backend, alguém encontra sempre uma forma de saltar de "Aberto" directamente para "Fechada" a partir de uma chamada API mal protegida ou de uma importação em lote, e todo o desenho de verificação em duas pessoas deixa de valer nada.

Esta separação entre validação de estado no cliente e no servidor é exactamente o tipo de decisão de arquitectura que só um sistema construído à medida das regras operacionais de uma equipa consegue impor de forma consistente — um pacote genérico de checklists resolve a captura de dados, mas raramente impõe a máquina de estados completa sem configuração extensa. É esse desenho de estados e permissões, adaptado ao fluxo real de uma operação, que faz parte do trabalho de desenvolvimento de software à medida para operações industriais.

Análise de causa raiz: registar o método, não só a conclusão

Um problema relacionado, que raramente é tratado com o mesmo cuidado que o fecho da acção: a análise de causa raiz é frequentemente registada como um campo de texto livre — "causa: falta de manutenção preventiva" — sem que fique claro que método produziu essa conclusão, nem que alternativas foram consideradas e descartadas. Isto tem duas consequências práticas. Primeira, torna impossível auditar a qualidade da investigação mais tarde — não há forma de distinguir uma causa raiz bem fundamentada de um palpite justificado a posteriori. Segunda, torna impossível agregar causas raiz ao longo do tempo para identificar padrões, porque o texto livre de um investigador nunca coincide, palavra por palavra, com o de outro para o mesmo tipo de causa.

A alternativa não exige um sistema complexo: um campo estruturado que registe o método (5 Porquês, Ishikawa, árvore de causas) como um tipo enumerado, os passos intermédios da análise como sub-registos ligados à constatação, e só depois a causa raiz final como um campo classificado a partir de uma lista controlada (falha de equipamento, falha de procedimento, falha de competência, falha de supervisão, e por aí em diante). É esta estrutura que permite, mais tarde, perguntar "quantas constatações dos últimos doze meses têm causa raiz classificada como falha de procedimento" sem ter de reler cada relatório.

Fechar uma acção correctiva não é marcar uma caixa

Vale a pena repetir isto de forma directa, porque é o ponto onde a maior parte dos sistemas — e dos processos manuais em Excel que os precedem — falha na prática: fechar uma acção correctiva não pode ser um botão que a pessoa responsável pela acção também controla. A verificação por uma segunda pessoa não é burocracia adicional; é a única forma de o registo de fecho significar alguma coisa. Um sistema onde o mesmo utilizador que implementa a acção também a fecha é indistinguível, para efeitos de auditoria, de um sistema sem verificação nenhuma — mesmo que tecnicamente exista um campo "verificado por".

Isto liga-se directamente ao desenho de permissões do sistema: a separação de funções entre quem implementa e quem verifica só é real se o sistema impedir, ao nível de permissões, que a mesma conta execute as duas transições sobre a mesma constatação — não apenas por convenção documentada num procedimento que ninguém vai reler durante uma auditoria.

Indicadores que valem a pena olhar

O objectivo de acompanhar indicadores de HSE operacionais não é produzir um número bonito para um relatório mensal — é detectar, cedo, que o fecho de acções está a acumular atraso antes que isso se torne visível numa auditoria externa ou, pior, num incidente repetido. Sem inventar valores de referência que não existem publicamente e de forma verificável para o contexto angolano, os indicadores estruturais que um sistema bem desenhado consegue produzir directamente do modelo de dados descrito acima incluem:

Idade média das acções abertas, por responsável e por unidade operacional — não apenas o total de acções abertas, que esconde acções antigas atrás de acções novas.
Percentagem de acções fechadas dentro do prazo definido, calculada a partir da data de verificação, não da data em que alguém marcou "concluído".
Distribuição de causas raiz por categoria estruturada, ao longo do tempo, para identificar se o mesmo tipo de falha (procedimento, equipamento, competência) está a repetir-se em diferentes constatações que, isoladamente, pareceriam eventos independentes.
Constatações sem acção correctiva atribuída passado um número de dias definido internamente — o sintoma mais directo de uma acção que ficou esquecida entre a investigação e a atribuição.

Nenhum destes indicadores exige estatística sofisticada. Exigem que o modelo de dados subjacente não permita que uma constatação "desapareça" entre módulos — o mesmo argumento que fundamenta todo o resto deste artigo.

Enquadramento legal em Angola

Em Angola, a obrigação de organizar serviços de segurança e saúde no trabalho não é uma boa prática opcional — está fixada na Lei Geral do Trabalho (Lei n.º 12/23, de 27 de dezembro de 2023) e detalhada em diplomas específicos: o Decreto n.º 31/94, de 5 de agosto, que estabelece os princípios do sistema de segurança, higiene e saúde no trabalho, o Decreto Executivo n.º 6/96, que aprova o Regulamento Geral dos Serviços de Segurança e Higiene no Trabalho nas Empresas, e o Decreto Presidencial n.º 179/24, de 1 de agosto, que regula o licenciamento dos serviços de segurança, higiene e saúde no trabalho nas empresas. Para as operações petrolíferas especificamente, o Decreto n.º 38/09, de 14 de agosto, aprova o Regulamento sobre Segurança, Higiene e Saúde nas Operações Petrolíferas.

Nenhum destes diplomas prescreve o desenho de um sistema informático — mas todos assumem, implicitamente, que existe um registo consistente das constatações e das acções tomadas para as corrigir. Um sistema onde uma inspecção mostra um desvio por resolver há seis meses, quando a acção correctiva já foi implementada e verificada num módulo diferente, não sobrevive bem a uma inspecção da Inspecção Geral do Trabalho ou a uma auditoria de um operador internacional que exija evidência do ciclo completo de fecho. É este o mesmo raciocínio que já discutimos a propósito das inspecções, EPI e registo de incidentes com rasto auditável: o valor de um sistema de HSE não está em produzir relatórios bonitos, está em manter um registo que continua a fazer sentido seis meses depois de ter sido criado.

Para equipas que ainda gerem este ciclo em folhas de cálculo partilhadas, vale a pena olhar para os mesmos problemas estruturais discutidos a propósito da migração de operações petrolíferas de folhas de cálculo para um ERP: a bifurcação entre checklist e não conformidade descrita acima é, estruturalmente, a mesma bifurcação entre a folha de inspecções e a folha de acções correctivas que qualquer equipa que já tentou reconciliar as duas manualmente reconhece de imediato.

Perguntas frequentes

Um item de checklist "não conforme" e uma "não conformidade" formal têm de ser sempre o mesmo registo?

Não em todos os casos — uma não conformidade pode nascer de uma auditoria externa, de uma reclamação de cliente ou de uma investigação de incidente, sem passar por um checklist. Mas quando a origem É um item de checklist, esse item deve gerar directamente o registo de constatação, por referência, não por duplicação. A regra estrutural é: uma origem, um registo, vários estados — nunca um segundo objecto paralelo para a mesma origem.

Quem deve poder fechar uma acção correctiva?

Nunca a mesma pessoa que a implementou, e idealmente uma pessoa com um papel distinto no sistema de permissões (responsável de HSE, auditor interno, ou um segundo técnico independente), com essa restrição imposta pelo sistema e não apenas por procedimento escrito.

Vale a pena migrar já um sistema legado com este problema, ou corrigir por cima?

Depende da dimensão da dívida acumulada. Corrigir a máquina de estados sobre um esquema existente é possível quando o problema é sobretudo de processo (falta de segunda verificação); quando o problema é estrutural — tabelas separadas para checklist, não conformidade e acção correctiva, sem chave estrangeira comum — a correcção sustentável passa quase sempre por remodelar o esquema de dados, não por adicionar mais um campo de sincronização manual.

Isto aplica-se só a HSE, ou também a qualidade e a auditorias de conteúdo local?

O mesmo padrão de bifurcação aparece em qualquer módulo de conformidade que combine checklists com um fluxo de não conformidade separado — auditorias de qualidade, verificações de conteúdo local, ou requisitos contratuais de EPC. O princípio — a resposta ao item é a constatação, não um segundo registo — transfere-se directamente.

Investigação de Incidentes e Acções Correctivas: O Relatório que Ninguém Volta a Abrir