Manutenção preventiva para missão crítica, do plano à evidência

Cada plano liga um ativo a um modelo de checklist e a um ou mais gatilhos: tempo (a cada N dias), uso (a cada X horas de horímetro, com a data prevista calculada pela média de consumo) e condição (quando a leitura de uma métrica passa do limite, com opção de exigir N dias seguidos fora da faixa). Vale o que vencer primeiro. Uma vez por dia o H2O recalcula a próxima data e, dentro da antecedência que você define, abre a OS com checklist, técnico e grupo, por padrão só para ativos em operação. Quando a OS é solucionada ou fechada, o plano recomeça a contagem. Os gatilhos de uso e de condição precisam de uma métrica cadastrada no ativo, como o horímetro, e de leituras dela.

O plano acompanha um ativo e abre uma OS de cada vez, quando o gatilho que vence primeiro se aproxima. Serve bem para o GMG por horímetro ou para o CRAC por leitura. A programação gera de uma vez todas as OS de um período para vários ativos, com a periodicidade do modelo de checklist, de diária a anual ou a cada N dias, datas movidas para o dia útil mais próximo e horas previstas. Serve para o cronograma anual apresentado ao cliente. As duas aparecem no Calendário de Manutenção, e a próxima preventiva de cada plano aparece ali antes de a OS existir.

Na aba Manutenção do Dashboard: planos ativos, planos que vencem nos próximos 7 dias, separados por tipo de gatilho, planos atrasados e OS de plano executadas no mês. Abaixo, a lista do que vence em 30 dias e do que já atrasou, com plano, ativo, checklist, tipo de gatilho e técnico, as OS geradas por tipo de gatilho nos últimos 90 dias, o top 10 de ativos com preventivas e corretivas e as condições que já estão fora do limite, mas ainda não completaram os dias exigidos. O painel mostra só os sites que o perfil do usuário pode ver.

Por ativo, a partir das OS ligadas a ele e da modalidade de cada uma. Na web, o MTBF é a média dos intervalos entre as aberturas das OS corretivas, e o MTTR é a média do tempo entre a abertura e a solução delas. A disponibilidade desconta, do tempo desde o cadastro do ativo, o tempo parado nas corretivas. A mesma aba mostra MTTF e tempo parado, com a linha do tempo de preventivas e corretivas. Para os números saírem certos, cada OS precisa estar ligada ao ativo e com a modalidade certa, preventiva ou corretiva. Uma regra de automação pode definir a modalidade na abertura, inclusive nas OS geradas pelos planos. O relatório de confiabilidade reúne esses indicadores de todos os ativos por período, em PDF.

Cada componente fica ligado ao ativo, com data de instalação e vida útil por tempo, por uso (horas informadas no componente) ou pelo que vencer primeiro. O ativo mostra se o componente está em dia, a vencer ou vencido e guarda o histórico de cada troca. A situação dos componentes também sai no RAT, no checklist e no laudo. A troca reinicia a contagem, e o H2O avisa por e-mail as pessoas que você escolher quando o componente entra em a vencer ou vencido.

Não. A ATG não possui vínculo de parceria com o Uptime Institute, e o H2O não é certificado nem endossado por ele. O H2O nasceu dentro de datacenters de missão crítica e foi usado como ferramenta de gestão da manutenção em processos de auditoria de Sustentabilidade Operacional do Uptime Institute®. O que ele guarda são os registros que a operação usa para mostrar o programa de manutenção: o plano, as OS executadas com checklist, fotos e assinatura, e o histórico de cada ativo. Usar o H2O não garante certificação nem resultado de auditoria.

Ajuda a reunir a evidência num lugar só: planos e programação de manutenção, OS executadas com checklist, foto obrigatória por item, GPS da resposta pelo app, assinatura do técnico e do cliente na tela, PDF de cada execução, histórico do ativo, log de quem mudou o quê e quando, instrumentos com certificado de calibração anexado e auditorias por checklist em que o item não conforme pode virar RNC com chamado ligado à OS. Os critérios e a preparação da auditoria continuam com o seu time.

Você cria a ronda a partir de um modelo de checklist em que cada item aponta para um ativo, com frequência diária, semanal, mensal ou sob demanda, técnico e horário. A OS da ronda é aberta pela rotina diária ou na hora, pelo botão Executar. Pelo app ou pela web, o técnico marca Realizado, Não realizado ou NA e lança as leituras de cada equipamento, como a tensão das três fases do QGBT. A leitura fora da faixa fica marcada no histórico do ativo e é avaliada pelo gatilho de condição de um plano que use essa métrica. Para rondas por turno, configure uma ronda para cada turno.

A leitura é classificada como baixa, alta, crítica baixa ou crítica alta e aparece em destaque no gráfico do ativo, com as linhas de limite. No painel de Monitoramento, o ativo passa para Atenção ou Crítico, e o que está sem leitura no prazo aparece como Atrasado. Se um plano tiver gatilho de condição nessa métrica, ela conta para abrir a preventiva na verificação diária. Num checklist, o item numérico fora da tolerância vira não conforme e, se o modelo estiver configurado para gerar não conformidade, vira RNC com um chamado ligado à OS.

Sim. O trabalho de campo funciona offline: chamados, checklists das preventivas, rondas, inspeções de quadro, nobreak e termografia, leituras, fotos anotadas, assinaturas, abertura do ativo pelo QR e o PDF do checklist no aparelho. Quando a conexão volta, tudo sincroniza. O login e a primeira sincronização precisam de rede. Planos, programação, diagramas, painéis e o laudo completo são configurados na web.

Cada equipamento é um ativo com campos próprios. No nobreak: kVA, tensões de entrada e saída, autonomia, quantidade de baterias, data da troca das baterias e topologia. No gerador: tensão, corrente, potência, frequência, fases e dados do motor. O banco de baterias entra como componente com vida útil por tempo ou por uso. O teste do gerador é um checklist configurável, com faixa de tolerância em cada medição, fotos e assinatura, e pode ter um plano próprio por data ou por horímetro. O tempo de transferência, se você quiser registrar, entra como item numérico do modelo. Na web, o laudo de GMG em PDF traz a figura da sequência de transferência automática do QTA.

Mede o SLA de atendimento dos chamados: prazo para atender e prazo para resolver, com calendário de horário útil. O SLA entra no chamado manualmente, por regra ou pelo contrato ativo do site, com prazos por prioridade. Status de espera, como aguardando peça, podem pausar o prazo de solução. Os relatórios de SLA mostram resumo e evolução, e um filtro lista os chamados com SLA estourado. A disponibilidade é calculada por ativo, a partir das OS, e o relatório de confiabilidade reúne esses números por período.

Existe uma API REST de leituras: um gateway, supervisório ou script envia os valores identificando o ativo (pelo id ou por uma referência externa cadastrada nele) e a métrica. A autenticação usa o token de um usuário, e a métrica precisa estar cadastrada no ativo. As leituras passam pela mesma classificação de faixa e alimentam gráficos, painel e gatilhos de condição dos planos. Cada supervisório é ligado por um projeto de integração com essa API.