PAX / Paladium · Projeto GTE · Alinhamento de estruturação
Área de Manutenção GTE
Da instalação à disponibilidade: por que precisamos de uma área formal de manutenção, como ela funciona e as 8 decisões que este alinhamento precisa tomar.
1 O tamanho do gap hoje
Números do painel de gestão v11 (fontes F1–F5). Cada um destes números é receita em risco ou custo de campo desperdiçado.
~64
câmeras offline sem nenhum ticket aberto — invisíveis para o processo
F2 vs. F1
~122
tickets encerrados com o ponto ainda offline — encerramento falso
F3 vs. F5
~15
contradições documentadas: fornecedor diz "funciona", plataforma mostra offline
F4 vs. F5
8×
visitas ao mesmo ponto sem resolução definitiva (pior caso relatado)
Diagnóstico especialista
2 Consolidação das dores
As 10 dores que a estruturação precisa resolver. Clique em cada uma para ver o detalhe e os caminhos de solução — elas alimentam a árvore de problemas da seção seguinte.
D1
Câmeras offline invisíveis para o processo~64 offline sem ticket aberto
Detalhe
Não existe alerta automático de queda: a descoberta depende de alguém olhar dashboards manualmente. Há relato de ponto 10 dias offline sem ninguém saber a causa. Cada dia invisível é indisponibilidade que não entra em nenhuma fila.
Possíveis soluções
Varredura diária no painel com responsável nomeado (imediato)
Alerta automático aos 30 min de queda (Onda 3)
Meta operacional: zero offline sem ticket
D2
Ticket encerrado não significa ponto online~122 tickets fechados com o ponto ainda offline
Detalhe
A visita resolve o sintoma reportado e o ticket fecha — mas ninguém valida se o ponto voltou de fato. O mesmo local recebe 5 a 8 visitas sem resolução definitiva, cada uma tratando um pedaço do problema.
Possíveis soluções
Etapa de validação obrigatória: encerra só com o ponto comprovadamente online na plataforma
Auditar e reabrir os ~122 encerramentos falsos
KPI permanente de "encerramento falso" (meta: zero)
Checklist completo do ponto para reincidentes
D3
"Ping-pong" entre fornecedores~15 contradições fornecedor vs. plataforma documentadas
Detalhe
ISP declara que o link funciona, energia declara que o fornecimento está ok — e a câmera segue offline. O escalonamento é informal (WhatsApp), sem SLA, e cada parte defende sua versão sem confronto de evidência.
Possíveis soluções
Protocolo de 5 regras: chamado formal, evidência antes de opinião, janela de 4 h, inspeção conjunta na 3ª ocorrência, tratamento de queda em lote
Dossiê de evidências por parceiro
Reunião quinzenal por fornecedor baseada em dado
D4
Chamados junto a ISPs não formalizadosMaioria dos tickets sem chamado registrado no Odoo
Detalhe
Sem chamado formal não há rastro: impossível cobrar prazo, medir resposta do fornecedor ou provar histórico numa negociação. Parcela relevante dos chamados que existem fica sem resposta do provedor.
Possíveis soluções
Chamado formal no Odoo obrigatório para todo acionamento
Janela anti-bloqueio de 4 h: sem resposta, despacho liberado
KPIs de formalização e de tempo de resposta por fornecedor
D5
Não existe definição única de "câmera online"GTE e Paraná usam critérios opostos para o mesmo cenário
Detalhe
Uma câmera que envia detecção sem responder VPN conta como online no GTE e como offline no Paraná. Resultado: números de disponibilidade que mudam conforme a fonte — e disponibilidade é o indicador que sustenta a receita.
Publicação única valendo para painel, relatórios e comunicação com a GTE
D6
Cadastro (Odoo) não reflete o estado real do campoOdoo registra a instalação e nunca é atualizado
Detalhe
O Odoo pode indicar "tem fibra" ou "tem energia" para pontos onde isso já não é verdade há meses — ele reflete o que foi registrado na instalação, não o estado atual. Diagnósticos feitos em cima dele partem de premissa falsa.
Possíveis soluções
Definir a plataforma como fonte de estado atual e o Odoo como cadastro de origem
Rotina de reconciliação periódica entre as fontes (já iniciada no painel v11)
Atualização de cadastro como item do checklist de visita
D7
Dependência de uma única pessoa para diagnósticoConhecimento tácito em consultor externo sobrecarregado
Detalhe
As ferramentas que sustentam o diagnóstico (planilha de status, consultas de IP em lote, versão pessoal da plataforma) rodam na máquina de um consultor da Peers que declarou ter "largado" parte do trabalho. Sem transferência, a saída dele apaga a capacidade de diagnóstico do GTE.
Reconhecimento formal do trabalho já feito como condição de engajamento
D8
Erros de cadastro em campo alimentam falhas em cascata300+ IPs corrigidos manualmente; pares de pontos quebrados
Detalhe
Pontos vizinhos sem identificação física levam o instalador a cadastrar o ponto errado. O erro se propaga: IP duplicado, automação de troca de senha quebrando os dois pontos de uma vez, técnico resetando equipamento e piorando o cadastro.
Possíveis soluções
Etiquetagem física de postes e câmeras (Decisão 8)
Validação de novos pontos contra o blueprint
Suspender a troca automática de senha até sanear o cadastro
Retrabalho de cadastro sob responsabilidade da instaladora
D9
Parque majoritariamente sem contrato de conectividadeMaior parte dos pontos dependente de 4G / prospecção
Detalhe
Cobertura de provedor não é contrato: a coluna de contrato é a única verdade contratual. Ponto em 4G é instabilidade estrutural que nenhum processo de manutenção resolve — só contratação de link resolve.
Possíveis soluções
Frente própria de contratação de conectividade (Onda 3)
Indicador dedicado de exposição 4G no painel
Priorização de contratação por criticidade do ponto
D10
Pontos presos em "Need to Bootstrap"Lotes de câmeras que nunca terminaram a configuração
Detalhe
A configuração remota exige energia contínua; se um técnico liga inversor temporário só para testar e vai embora, a câmera fica presa no bootstrap para sempre — e na superfície parece instalada ("já pingou uma vez"). Parte dos casos é bug de software da plataforma, que exige tratamento totalmente diferente.
Possíveis soluções
Levantar o passivo separando causa de campo vs. bug de software
Mutirão de saneamento (Decisão 6)
Regra de instalação: energia definitiva estável antes da configuração
Chamado formal ao time de plataforma para o lote com bug
3 Árvore de problemas
Leitura de baixo para cima: uma única ausência estrutural alimenta cinco causas (C1–C5), que produzem os efeitos (E1–E4) que a liderança e o cliente enxergam. Todo nó é clicável e os chips mostram exatamente o que causa o quê.
Efeitos — o que se enxerga (clique para o detalhe)
E1Receita em riscoPontos offline por dias sem tratamento
← C1← C2← C3
Disponibilidade é o indicador que dispara reconhecimento de receita. Ponto invisível (C1) não entra em fila; diagnóstico frágil (C2) atrasa a restauração; visita que fecha ticket sem restaurar (C3) mantém o ponto fora do ar enquanto o sistema diz que foi tratado.
E2Custo de campo infladoAté 8 visitas ao mesmo ponto
← C3← C4← C5
Despacho por sintoma (C3) gera retorno; ping-pong sem protocolo (C4) gera visitas motivadas pelo silêncio do fornecedor; cadastro errado (C5) faz o técnico ir ao ponto errado ou resetar equipamento saudável. Cada visita evitável é diária, deslocamento e hora técnica.
E3Números sem credibilidadeDisponibilidade muda conforme a fonte
← C2← C5
Dois critérios de "online" (C2/D5) + cadastro desatualizado (C5/D6) fazem painel, Odoo e fornecedor contarem histórias diferentes. Sem número único, a liderança decide no escuro e a GTE questiona qualquer relatório.
E4Exposição junto à GTESem evidência para responder ao cliente
← C1← C4
Quando o cliente pergunta por um ponto offline, hoje não há trilha: não se sabe quando caiu (C1), quem foi acionado nem o que o fornecedor respondeu (C4). A resposta vira opinião — e opinião não segura contrato.
▲ ▲ ▲ ▲
Problema central: a disponibilidade da rede não é gerida como processo — é reagida caso a caso, com base em esforço individual e boa vontade de parceiros
▲ ▲ ▲ ▲ ▲
Causas de primeiro nível — os chips mostram as dores que alimentam (D) e os efeitos que produzem (→ E)
A queda de um ponto não gera nenhum evento: nem alerta, nem ticket. Os ~64 offline sem ticket (D1) e os lotes presos em bootstrap que parecem instalados (D10) existem porque nada avisa. Enquanto ninguém vê, o ponto acumula dias de indisponibilidade (E1) e vira surpresa quando a GTE pergunta (E4).
C2Diagnóstico não institucionalizadoCritérios divergentes; conhecimento em 1 pessoa
D5D6D7→ E1→ E3
Não há critério único de online (D5), o cadastro mente (D6) e o método de diagnóstico vive na cabeça e nas planilhas de um consultor externo (D7). Resultado: restauração lenta (E1) e três versões do mesmo número (E3).
C3Despacho sem causa raizVisita resolve sintoma; ticket fecha, ponto segue offline
D2→ E1→ E2
O técnico vai resolver o que foi reportado, não o ponto. Os ~122 encerramentos falsos (D2) são a prova: o ticket morre, o ponto não volta (E1) e a próxima visita já está contratada (E2). É a causa mais cara em dinheiro direto.
C4Parceiros sem protocoloChamados informais, sem SLA, sem evidência
D3D4→ E2→ E4
Sem chamado formal (D4) não há prazo a cobrar; sem evidência confrontável, o ping-pong (D3) se perpetua. A operação paga visitas motivadas pelo silêncio do fornecedor (E2) e não tem trilha para mostrar à GTE quem falhou (E4).
C5Cadastro ruim na origemIPs errados, pontos trocados, fora do blueprint
D8D9→ E2→ E3
Erros de instalação (D8) se propagam por automações e visitas — e a exposição 4G sem contrato (D9) torna parte do parque estruturalmente instável. Além de custo de campo (E2), o cadastro errado contamina qualquer relatório (E3). Também realimenta C3: técnico despachado com informação errada resolve o ponto errado.
▲
Causa raizO GTE nunca passou por um gate formal de aceite implantação → manutenção, com definição única de "ponto operacional", dono nomeado, ferramentas institucionais e protocolo de fornecedores
Por que uma única causa raiz: cada causa de primeiro nível é a ausência de um componente do gate — C1 falta detecção (ferramenta institucional), C2 falta definição e dono, C3 falta critério de encerramento, C4 falta protocolo de parceiros, C5 falta critério de aceite na origem. Tratar sintomas isolados (mais visitas, mais planilhas) sem fechar o gate apenas realoca o problema. É por isso que a Decisão 1 (definição única) e a Decisão 2 (dono do processo) vêm antes de tudo no alinhamento.
D# dor que alimenta a causa (seção 2)→ E# efeito que a causa produz← C# causa que origina o efeito
4 Árvore completa de falhas — clusterizada
Todos os modos de falha conhecidos que impedem uma câmera de operar, agrupados em 8 clusters por natureza da causa — cada cluster com responsável primário de acionamento. Cada folha traz a assinatura (padrão de sinais que identifica o problema à distância), o mecanismo, o diagnóstico passo a passo, a ação padrão e a prevenção. Esta é a base do runbook de triagem: toda ocorrência é classificada em um destes ramos antes de qualquer despacho.
Câmera com problemaTriagem obrigatória: qual é a assinatura? (ping · VPN · detecção · energia · histórico · vizinhos)
▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼
4.1 · Sequência lógica de triagem — a escada de decisão
A ordem importa: cada pergunta elimina clusters inteiros e é sempre mais barata que a seguinte (consulta → cruzamento → chamado → visita). Descer a escada inteira sem conclusão significa que a visita é inevitável — mas ela sai com diagnóstico, não às cegas.
0
Coletar a assinatura completa antes de qualquer hipótese
Ping · VPN · detecção (e quando foi a última) · energia concluída · situação dos vizinhos e do outro equipamento do mesmo poste · histórico do ponto (visitas, reincidência, bootstrap) · contrato de conectividade. Fontes: plataforma (estado atual), F5 (cadastro/contrato), histórico do painel. Nunca o Odoo como estado.
1
É um evento em lote? (vários pontos caíram juntos)
SIM →Agrupar por dimensão: mesmo ISP = bloqueio de VPN / falha da operadora (cluster 2, incidente único via Oc); mesma região/circuito = queda regional de energia (cluster 1, Equatorial); mesma data/hora exata em muitos pontos = suspeita de credencial/certificado ou bug (cluster 5). Nunca despachar ponto a ponto.
NÃO ↓É ponto isolado — seguir para a triagem individual.
2
O ponto envia detecção?
SIM →O cliente está atendido. Responde VPN também? Sim = operacional pleno — se há reclamação, o problema é de qualidade de captura (cluster 8) ou falso alarme. Não = Degradado: VPN rompida (cluster 2), fila média via Oc.
NÃO ↓Ponto indisponível — o cliente não está atendido. Seguir com prioridade.
3
A energia do ponto está confirmada?
SIM →Energia OK — eliminado o cluster 1. Seguir.
NÃO ↓"Energia concluída: não" ou queda confirmada → cluster 1: escalonar Equatorial, sem visita até normalizar. Ponto que cai e volta várias vezes ao dia = oscilação/mau contato (cluster 1, folhas de intermitência).
4
O ponto responde ping?
SIM →Rede viva mas sem detecção → configuração da câmera (cluster 4: pinga mas não detecta; cartão SD; firmware; NTP) ou falso status na plataforma (cluster 5). Verificar config via VPN antes de despachar.
NÃO ↓Ponto totalmente mudo com energia OK — seguir.
5
Está preso em "Need to Bootstrap"?
SIM →Bifurcação crítica: a energia esteve estável durante a configuração? Não/incerto → bootstrap travado por energia (cluster 1). Sim → candidato a bug de software (cluster 5): chamado formal ao time de plataforma com o lote.
NÃO ↓Bootstrap concluído no passado — o ponto já operou. Seguir.
6
O cadastro do ponto é consistente?
SIM →Checar em lote: IP dentro da sub-rede do MikroTik? Sem IP duplicado? Sem cadastro duplo no Odoo? Sem par vizinho quebrado junto (automação de senha)? Coordenadas batem com o local? Qualquer inconsistência → cluster 3: corrigir cadastro ANTES de despachar — visita com cadastro errado vai ao ponto errado.
NÃO ↓Cadastro íntegro. Seguir.
7
O link contratado está ativo? (chamado ao ISP)
SIM →ISP confirma queda → aguardar reparo dentro da janela de 4 h; sem resposta em 4 h, despacho liberado. ISP declara "link OK" com ponto mudo → contradição documentada (cluster 2: fibra cortada / problema físico) → dossiê + inspeção conjunta na 3ª ocorrência.
NÃO ↓Ponto sem contrato de fibra (4G) → instabilidade estrutural (cluster 2): não é incidente, é frente de contratação. Seguir para as hipóteses físicas.
8
As câmeras do mesmo poste caíram em horários diferentes?
SIM →Assinatura de remoção física → cluster 6: suspeita de furto — visita prioritária, B.O., avaliação de exposição do ponto.
NÃO ↓Queda simultânea ou poste de câmera única. Seguir.
9
Sobrou hardware ou causa física não confirmável
SIM →Reincidência sem causa externa + reset não resolve → equipamento danificado (cluster 4): substituição com análise do equipamento. Padrão concentrado num lote/modelo → conversa de garantia.
NÃO ↓Sem conclusão remota → visita diagnóstica com checklist completo (energia, no-break, cabos, IP real, VPN, câmeras, lente, enquadramento, etiqueta) — a visita sai com roteiro, nunca às cegas.
4.2 · Catálogo exaustivo por cluster
1 · EnergiaEquatorial
Falta de energia real no ponto
sem pingsem detecçãoenergia concluída: nãoSeveridade alta
Mecanismo — por que acontece
A obra elétrica do ponto nunca foi concluída pela concessionária (ligação pendente, padrão reprovado, pendência de poste). Sem alimentação, câmera e MikroTik ficam completamente mortos — nenhum sinal chega à plataforma. É o caso mais simples do catálogo porque a causa é binária e verificável sem campo.
Diagnóstico passo a passo
Consultar o campo "energia concluída" no Hex/base master (F5) para o ponto
Verificar se o ponto já foi reportado no canal de erros da Equatorial
Confirmar que pontos vizinhos do mesmo circuito estão operando (se todos caíram, é queda regional, não pendência de ligação)
Ação padrão
Escalonar à Equatorial pelo canal formal com número do ponto e evidência. Nenhuma visita técnica até a energia normalizar — despachar campo aqui é desperdício puro. Assim que a energia subir, o ponto deve voltar sozinho; se não voltar em 24 h, reclassificar (provável bootstrap travado).
Prevenção: Gate de aceite: ponto só entra em manutenção com checklist elétrico aprovado e 72 h estável — pendência de energia fica com a implantação.
Queda de energia prolongada (ponto que já operou)
sem pingsem detecçãohistórico de operação normalSeveridade alta
Mecanismo — por que acontece
O fornecimento caiu depois de o ponto estar operacional: tempestade, desarme na rede, corte da concessionária, religamento que não voltou. Armadilha clássica: o Odoo continua indicando "tem energia" porque reflete o registro da instalação, não o estado atual — houve caso real de ponto 10 dias offline sem ninguém saber a causa.
Diagnóstico passo a passo
Medir tempo offline na plataforma (timestamp da última comunicação)
Verificar se outros pontos da mesma região/circuito caíram no mesmo horário (queda regional vs. ponto isolado)
Consultar a Equatorial sobre ocorrências na região antes de despachar
Ignorar o status de energia do Odoo — ele não é confiável para estado atual
Ação padrão
Processo-alvo: 30 min offline = aviso ao técnico da região (quedas curtas se resolvem sozinhas); 3 h = visita física para verificar fornecimento, disjuntor e no-break.
Prevenção: Meta de médio prazo: equipamento com reporte remoto de energia (hoje "só vou saber quando eu chegar lá").
Disjuntor desarmado / no-break desligado
sem pingsem detecçãoregião com energia OKSeveridade média
Mecanismo — por que acontece
Surto desarma o disjuntor, ou o no-break foi desligado numa visita anterior e ninguém religou (caso real do ponto "1493/19": no-break desligado permaneceu assim porque a visita foi resolver outro sintoma). Um único ponto morto numa região saudável é a assinatura.
Diagnóstico passo a passo
Confirmar com a Equatorial que o fornecimento na região está normal
Verificar histórico de visitas recentes ao ponto (visita anterior pode ter deixado o no-break desligado)
Checar se a queda coincide com horário de manutenção/obra conhecida
Ação padrão
Visita com checklist elétrico completo. Regra de ouro: religar disjuntor e no-break faz parte de TODA visita ao ponto, independentemente do motivo do despacho — é a materialização da abordagem "resolver tudo numa visita" (Decisão 7).
Prevenção: Checklist de saída de visita: técnico só encerra confirmando disjuntor armado, no-break ligado e câmera respondendo.
Bootstrap travado por queda de energia
pingou uma vezpreso em Need to Bootstrapenergia instável na instalaçãoSeveridade alta
Mecanismo — por que acontece
O processo de bootstrap é longo e frágil: a plataforma envia uma configuração, depois outra, reinicia a câmera mais de uma vez e formata o cartão de memória — tudo automático, mas exigindo energia contínua do início ao fim. O padrão de erro mais traiçoeiro: o técnico liga um inversor temporário só para testar/configurar, desliga e vai embora — "a câmera nunca saiu do bootstrap, porque a energia nem chegou lá". Na superfície parece instalada (registrou um ping), mas o processo nunca terminou.
Diagnóstico passo a passo
Verificar status "Need to Bootstrap" na plataforma
Cruzar com "energia concluída" — se negativo, é este caso (não bug)
Conferir histórico: houve ping isolado na época da instalação e silêncio depois?
Se energia concluída = sim e mesmo assim travado, reclassificar para o cluster 5 (bug de software)
Ação padrão
Garantir energia definitiva estável no ponto e reiniciar o processo de configuração do zero, monitorando até a saída do bootstrap.
Prevenção: Regra de instalação: configuração só inicia com energia definitiva ligada — proibido configurar em inversor temporário. Item de checklist da instaladora.
Referência
Pergunta em aberto do diagnóstico: quantos pontos do parque estão presos em bootstrap por energia vs. por bug — o mutirão (Decisão 6) começa respondendo isso.
Oscilação / subtensão — reboot em loop
ponto cai e volta várias vezes ao diauptime sempre curtoSeveridade média
Mecanismo — por que acontece
A rede elétrica do ponto oscila (subtensão, transitórios, carga vizinha pesada) e o equipamento reinicia em ciclo. O ponto nunca fica offline "de vez" — flapeia. Perigoso porque cada janela online engana a triagem ("voltou sozinho") e o ciclo degrada o hardware ao longo do tempo.
Diagnóstico passo a passo
Analisar o histórico de conexões do ponto: múltiplas quedas/retornos por dia = flap, não queda
Cruzar horários das quedas com padrão local (horário de pico de carga, chuva)
Verificar se o vizinho do mesmo circuito flapeia junto (problema da rede) ou não (problema da instalação do ponto)
Ação padrão
Reportar qualidade de fornecimento à Equatorial com o histórico de flaps como evidência; em campo, validar no-break/estabilizador e conexões.
Prevenção: KPI de estabilidade (nº de quedas/ponto/semana) no painel — flap crônico entra em fila própria antes de virar falha dura.
Mau contato / conexão elétrica degradada
intermitência correlacionada com vento ou chuvaflap sem padrão de redeSeveridade média
Mecanismo — por que acontece
Conexão elétrica na caixa ou no poste degradada: oxidação, crimpagem ruim, borne solto. O sintoma acompanha o clima — venta, mexe, cai; chove, oxida, piora. Indistinguível da oscilação de rede sem visita.
Diagnóstico passo a passo
Cruzar timestamps das quedas com dados de clima/vento da região
Confirmar que a rede da região está estável (Equatorial sem ocorrências)
Levantar a idade e o histórico de instalação do ponto
Ação padrão
Visita com reaperto e inspeção de todas as conexões elétricas + tratamento de oxidação; substituir conectores degradados.
Prevenção: Item permanente do checklist da preventiva (T3): reaperto e inspeção visual das conexões.
Desligamento programado / religamento da concessionária
quedas em janela fixaregião inteira juntoretorna sozinhoSeveridade baixa
Mecanismo — por que acontece
A Equatorial executa manutenção programada ou religamentos na região: todos os pontos do circuito caem e voltam juntos, em janelas previsíveis. Sem o aviso prévio, a operação trata como incidente e desperdiça triagem.
Diagnóstico passo a passo
Queda simultânea de região inteira com retorno espontâneo em horas
Confirmar com a Equatorial se havia janela programada
Registrar a janela para não contar contra a disponibilidade indevidamente
Ação padrão
Nenhuma ação de campo. Registrar como indisponibilidade programada de terceiro no histórico do ponto.
Prevenção: Acordar com a Equatorial o envio antecipado do calendário de manutenções programadas nas regiões com pontos PAX — pauta da interface formal.
2 · ConectividadeISPs / Oc
Link de fibra caído (queda lógica)
sem pingenergia OKponto com contrato de fibraSeveridade alta
Mecanismo — por que acontece
O provedor perdeu o link do ponto: falha de autenticação, porta da OLT, equipamento do ISP. Câmera e MikroTik ficam sem WAN — VPN e detecção caem juntas, simultaneamente. Diferencia-se da energia porque o fornecimento elétrico está confirmado.
Diagnóstico passo a passo
Confirmar energia OK (Equatorial/F5) — elimina o cluster 1
Identificar o ISP contratado do ponto na coluna de contrato (F5) — contrato, nunca cobertura
Verificar se é ponto isolado ou se há outros pontos do mesmo ISP caídos (se lote, ver folha de bloqueio de VPN)
Registrar timestamp da queda para o chamado
Ação padrão
Chamado formal ao ISP no Odoo com evidência (print da plataforma, timestamp). Janela de 4 h: sem resposta, despacho de campo liberado e o custo da visita entra no dossiê do parceiro.
Prevenção: Reunião quinzenal com dossiê por ISP: tempo de resposta e reincidência viram pauta com dado, não com versão.
Fibra cortada fisicamente
queda abrupta sem retornoISP declara link OKregião com obras/tráfego pesadoSeveridade alta
Mecanismo — por que acontece
Rompimento físico do cabo: caminhão, poda, obra, vandalismo. Remotamente é indistinguível da queda lógica — a suspeita nasce quando o ISP declara que "do lado dele está ok" e o ponto segue mudo. Essa contradição é exatamente o combustível do ping-pong.
Diagnóstico passo a passo
Chamado ao ISP retornou "link OK" com ponto ainda offline → registrar contradição no dossiê
Verificar histórico de obras/ocorrências na via
Despachar campo para inspeção visual do trajeto do cabo no ponto
Ação padrão
Contradição documentada (F4 vs. F5). Na 3ª ocorrência do mesmo ponto: inspeção conjunta obrigatória PAX + ISP no local — única forma de encerrar o "fui lá e do meu lado está ok".
Operadora bloqueando tráfego VPN — queda em lote
vários pontos do mesmo ISPVPN caiu juntodetecção pode seguir OKSeveridade média
Mecanismo — por que acontece
A operadora identifica o túnel MikroTik↔MikroTik como "comunicação estranha" e bloqueia (filtragem de tráfego, CGNAT, política de segurança). Problema conhecido há mais de um ano em outros estados; geralmente não é significativo e muda com o tempo — mas quando ocorre, derruba o acesso remoto de dezenas de pontos de uma vez. Assinatura inconfundível: múltiplos pontos do mesmo provedor perdendo VPN simultaneamente.
Diagnóstico passo a passo
Agrupar os pontos caídos por ISP (painel/F5) — se concentra em um provedor, é lote
Verificar se a detecção continua chegando (se sim, é bloqueio de VPN, não queda de link)
Comparar timestamps: queda simultânea = evento único do lado da operadora
Ação padrão
NÃO despachar técnicos ponto a ponto — é desperdício em escala. Escalonar como incidente único ao contato responsável por VPN/operadoras (Oc), com a lista de pontos afetados.
Prevenção: Monitorar a taxa de VPN caída por ISP no painel: crescimento súbito antecipa o lote antes da percepção manual.
VPN rompida com detecção funcionando — estado Degradado
detecção OKsem ping/VPNcliente atendidoSeveridade média
Mecanismo — por que acontece
A câmera tem dois caminhos independentes: (1) internet comum, que leva as detecções direto à nuvem que o policial usa — não depende de VPN; (2) o túnel VPN MikroTik(campo)↔MikroTik(nuvem PAX/AWS), único caminho para configurar, ver imagem ao vivo ou intervir remotamente. Quando só o túnel cai, o cliente continua atendido, mas a equipe técnica perde completamente o acesso ao ponto — "uma perna não funciona".
Diagnóstico passo a passo
Confirmar que detecções continuam chegando na plataforma
Confirmar falha de ping/acesso via VPN
Verificar se é ponto isolado ou lote do mesmo ISP (se lote, folha anterior)
Classificar formalmente como Degradado — não como offline nem como saudável
Ação padrão
Fila de correção com prioridade média; tratativa com a operadora via Oc. Não gera alarme para o cliente — mas fica visível para a gestão técnica. Ponto degradado é dívida: qualquer necessidade futura de intervenção remota estará bloqueada.
Referência
É exatamente o cenário que os 3 estados da Decisão 1 resolvem: online no GTE, offline no Paraná — o estado Degradado dá a resposta única.
4G instável / ponto sem contrato de fibra
quedas intermitentespinga mas não sustenta acessocoluna de contrato vaziaSeveridade média
Mecanismo — por que acontece
Ponto operando em 4G/Amplimax por falta de fibra contratada. O sinal celular responde ping ("você manda oi e a câmera responde oi"), mas a conexão não sustenta acesso remoto nem fluxo estável — "tem casos que a conexão é muito ruim, você não consegue nem acessar". Não é incidente: é condição estrutural do ponto, e a maior parte do parque está nessa situação.
Diagnóstico passo a passo
Verificar a coluna de contrato (F5): vazia ou 4G = condição estrutural
Analisar padrão de quedas: intermitência recorrente sem causa externa
Não confundir cobertura de ISP na região com contrato — cobertura não é relação contratada
Ação padrão
Não tratar como manutenção — nenhum chamado ou visita resolve. Entra na frente de contratação de conectividade (Onda 3), priorizada por criticidade do ponto.
Prevenção: Indicador dedicado de exposição 4G no painel: é o teto estrutural da disponibilidade do parque.
Chip 4G bloqueado / linha suspensa
ponto 4G totalmente mudoenergia OKsem histórico de instabilidadeSeveridade alta
Mecanismo — por que acontece
A linha celular do ponto foi bloqueada ou suspensa: falta de recarga/pagamento, bloqueio administrativo da operadora, chip desativado por inatividade ou troca de plano corporativo. O ponto morre "do nada" sem nenhuma causa técnica local.
Diagnóstico passo a passo
Confirmar que o ponto é 4G (coluna de contrato F5)
Verificar com a gestão do contrato celular o status da linha/ICCID
Cruzar com outros pontos do mesmo plano: bloqueio administrativo costuma vir em lote
Ação padrão
Regularizar a linha junto à operadora/gestão de contrato; se recorrente, revisar a gestão do parque de chips (inventário de ICCID por ponto).
Prevenção: Inventário de linhas 4G por ponto com alerta de vencimento/consumo — a linha é um ativo do ponto, como o IP.
Sinal 4G fraco / antena desalinhada
ping intermitente com latência altapiora em horário de picoacesso não sustentaSeveridade média
Mecanismo — por que acontece
O Amplimax depende de alinhamento com a torre da operadora: antena desalinhada (vento, pancada, instalação ruim) ou área de sombra deixam o sinal no limite. O ponto "vive no talo": pinga às vezes, nunca sustenta acesso ou fluxo.
Diagnóstico passo a passo
Analisar padrão: latência alta e perda de pacote constantes, piora em horário de pico
Comparar com outros pontos 4G da mesma região (célula congestionada afeta todos)
Histórico: o ponto já foi estável? Desalinhamento tem data (vento forte, visita anterior)
Ação padrão
Visita para realinhamento da antena e medição de sinal; avaliar troca de operadora no ponto ou antecipação da fibra.
Prevenção: Registrar nível de sinal na instalação (baseline) — queda futura vira evidência de desalinhamento.
MikroTik com configuração corrompida/errada
MikroTik pingacâmera não alcança a nuvempós-reset ou pós-visitaSeveridade média
Mecanismo — por que acontece
O roteador responde, mas NAT, firewall ou rotas estão errados — típico depois de um reset mal restaurado (sequela do cluster 3) ou intervenção manual sem padrão. A câmera fica ilhada: rede local viva, mundo externo inalcançável.
Diagnóstico passo a passo
MikroTik responde ping mas a câmera não envia detecção nem fecha VPN
Verificar histórico: houve reset ou visita recente?
Auditar a config contra o template padrão via VPN (quando acessível)
Ação padrão
Reaplicar o template de configuração padrão; se inacessível remotamente, visita com config assistida pela triagem.
Prevenção: Template de configuração versionado e restauração padronizada — reset em campo sempre seguido de reprovisionamento completo, nunca configuração manual.
Cabo ethernet / PoE degradado
câmera some e voltaMikroTik estáveloxidação/conector expostoSeveridade média
Mecanismo — por que acontece
O elo câmera↔MikroTik degrada: conector RJ45 oxidado, cabo ressecado pelo sol, injetor PoE defeituoso. O roteador segue saudável enquanto a câmera flapeia ou morre — falha silenciosa porque metade do ponto continua respondendo.
Diagnóstico passo a passo
MikroTik OK + câmera instável ou muda = problema no segmento local
Cruzar com clima (chuva piora oxidação) e idade da instalação
Em ponto de 2 câmeras: uma OK e outra não descarta energia e uplink
Ação padrão
Visita para substituição de cabo/conector/injetor PoE com material adequado para exposição externa.
Prevenção: Especificação de material outdoor (cabo blindado, conector vedado) no padrão de instalação + inspeção na preventiva T3.
3 · Cadastro & dadosInstaladora / Interno
IP duplicado ou fora da faixa de rede
ponto não sobedados estranhosIP em sub-rede diferente do MikroTikSeveridade alta
Mecanismo — por que acontece
Na instalação, o instalador digita o IP errado no aplicativo ou confunde qual ponto físico está cadastrando. A rede tem lógica rígida: a câmera vive na sub-rede do MikroTik do próprio ponto (MikroTik em X.183.241 → câmeras em X.183.245/.246). IP numa faixa totalmente diferente (ex.: 170.x) "é impossível, é outra rede" — certeza de erro de cadastro. Volume histórico: 300+ IPs corrigidos manualmente, trabalho que ninguém percebeu.
Diagnóstico passo a passo
Aplicar a lógica de faixa: o IP da câmera pertence à sub-rede do MikroTik do ponto?
Rodar consulta em lote de IPs duplicados na base (não checar um a um)
Caso de dois pontos vizinhos com o mesmo IP (ex.: 610181/610182): impossível saber qual é o certo sem campo
Visita: o IP no roteador físico "é o real, não tem como mentir ali"
Ação padrão
Técnico confirma o IP real em campo → correção manual na plataforma. Institucionalizar a consulta em lote como rotina semanal (hoje é ferramenta pessoal do especialista).
Prevenção: Etiquetagem física (Decisão 8) + validação automática de faixa no cadastro: IP fora da sub-rede do MikroTik deveria ser rejeitado na origem.
Referência
Dor D8 · Causa C5. Teste automatizado de faixa já é regra no pipeline de dados do painel.
Pontos vizinhos trocados + automação de senha
dois pontos próximos quebram juntossenha "maluca" no equipamentoSeveridade alta
Mecanismo — por que acontece
Cadeia completa do estrago: (1) dois postes próximos sem identificação física; (2) instalador cadastra o 18 como 19 e vice-versa; (3) a automação de troca periódica de senha roda e aplica a senha do 19 no equipamento do 18 — quebrando os dois simultaneamente; (4) no dia seguinte, um técnico encontra uma senha aleatória ("A, B, C, X"), não conhece a causa raiz e reseta câmera e MikroTik; (5) o reset apaga a senha real de vez e "estraga ainda mais o cadastro". Frequência observada: 4–6 casos — poucos, mas ilustram como uma automação bem-intencionada amplifica erro humano de campo.
Diagnóstico passo a passo
Dois pontos geograficamente próximos falhando no mesmo período = suspeitar de troca
Verificar histórico da automação de senha na janela da falha
Conferir posições contra o blueprint original
NUNCA resetar em campo sem antes verificar esta hipótese — o reset destrói a evidência e piora o cadastro
Ação padrão
Reset físico controlado e coordenado: campo e plataforma sincronizados, cadastro corrigido no mesmo ato. A troca automática de senha está suspensa até o saneamento — manter assim.
Prevenção: Etiquetagem física dos postes elimina a causa na origem; automação de senha só religa após o mutirão de saneamento (Decisão 6).
Ticket duplicado no Odoo (mesmo ponto físico, dois cadastros)
câmera nunca criada na plataformadois números de ponto para o mesmo localSeveridade média
Mecanismo — por que acontece
Dois números de ponto (ex.: 640131 e 640133) foram cadastrados para o mesmo local físico. A plataforma detecta a duplicidade e cria apenas um — o "vencedor" por critério interno que nem o especialista conhece. O outro fica órfão: instalado no mundo real, inexistente no sistema.
Diagnóstico passo a passo
Buscar cadastros com coordenadas/endereço coincidentes
Comparar as informações dos dois tickets — em ~3 de vários casos revisados, deu para identificar o dono real só pelo Odoo (ex.: o dono era o 23, não o 27)
Se inconclusivo: "pega escadinha, sobe nos dois e acha o real" — visita inevitável
Ação padrão
Identificar o ponto real (remoto quando possível, campo quando não), unificar o cadastro e eliminar o duplicado.
Prevenção: Validação de duplicidade por coordenada no momento do cadastro — rejeitar segundo ponto a menos de X metros sem justificativa.
Odoo desatualizado — cadastro ≠ estado atual
Odoo diz fibra/energia OKplataforma mostra offline há diasSeveridade média
Mecanismo — por que acontece
"O Odoo não muda depois que você instala — a gente não atualiza daqui pra lá." O sistema reflete o que foi registrado na instalação e nunca mais é tocado: pode indicar fibra em ponto que virou 4G, energia em ponto cortado há meses. Todo diagnóstico que parte do Odoo parte de premissa potencialmente falsa.
Diagnóstico passo a passo
Em qualquer triagem: tratar o Odoo como registro de origem, nunca como estado
Estado atual = plataforma + ping direto
Divergência Odoo vs. plataforma não é conflito — é atraso esperado do cadastro
Ação padrão
Regra institucional: plataforma é fonte de estado; Odoo é fonte de cadastro. Reconciliação periódica entre as duas já roda no painel (achados de contradição).
Prevenção: Atualização de cadastro como item obrigatório do checklist de toda visita — o técnico que constata a divergência corrige na hora.
Blueprint não seguido — pontos instalados muito próximos
confusão recorrente na mesma regiãoinstalador/técnico/Equatorial erram o pontoSeveridade média
Mecanismo — por que acontece
O padrão original (1 poste = 2 câmeras, bem espaçados) não foi seguido em parte do GTE: postes e câmeras ficaram próximos demais, fugindo do blueprint. Efeito cascata: instaladores confundem cadastro (alimenta IP errado e troca de pontos), técnicos visitam o poste errado, e até a Equatorial confunde qual ponto liga. A liderança já orientou não repetir o padrão — mas o passivo existe: "vai ter muita coisa que a gente vai se assustar".
Diagnóstico passo a passo
Mapear regiões com pontos a menos de X metros entre si
Comparar caso a caso com o blueprint original — alguns próximos são legítimos (um cobre calçada, outro faixa de pedestre)
Cruzar com histórico de falhas de cadastro da região: proximidade + reincidência = prioridade de etiquetagem
Ação padrão
Etiquetagem física prioritária nas regiões de maior densidade; validação de todo ponto novo contra o blueprint antes do aceite.
Prevenção: Gate de aceite inclui verificação de aderência ao blueprint — desvio exige aprovação explícita, não silêncio.
Coordenadas GPS erradas no cadastro
técnico não encontra o pontomapa aponta local erradoSeveridade média
Mecanismo — por que acontece
O instalador registrou o ponto com coordenadas erradas (GPS impreciso, cadastro feito longe do poste, inversão de pontos próximos). Todo o despacho é contaminado: o técnico roda até o lugar errado, a análise geográfica (RISP, cobertura) sai distorcida.
Diagnóstico passo a passo
Comparar coordenadas do cadastro com o endereço/descrição do ponto
Cruzar com o blueprint original da região
Relatos de campo do tipo "não achei o ponto" são o sintoma clássico
Ação padrão
Correção das coordenadas com posição real confirmada em campo (foto + GPS do técnico no local).
Prevenção: Validação na instalação: cadastro só fecha com GPS capturado no pé do poste, batendo com o blueprint por raio de tolerância.
Ponto associado a município/RISP errado
relatórios regionais não fechamdespacho para equipe da região erradaSeveridade baixa
Mecanismo — por que acontece
O ponto foi vinculado ao município ou à RISP errada no cadastro. Não derruba a câmera, mas contamina relatórios ao cliente, distribui o despacho para a equipe errada e distorce os indicadores regionais de disponibilidade.
Diagnóstico passo a passo
Cruzar município/RISP do cadastro com as coordenadas reais
Auditoria em lote: pontos cujas coordenadas caem fora do polígono do município cadastrado
Ação padrão
Correção em lote na base master; revisão dos relatórios regionais afetados.
Prevenção: Validação automática coordenada×polígono no pipeline de dados do painel.
Identificador/serial trocado entre câmeras do poste
LPR e FR "invertidas" no sistemaconfig aplicada na câmera erradaSeveridade média
Mecanismo — por que acontece
Num poste com duas câmeras, os seriais foram cadastrados invertidos: o sistema acha que a LPR é a FR e vice-versa. Configurações, expectativas de detecção e diagnósticos passam a mirar o equipamento errado — um caso irmão da troca de pontos vizinhos, dentro do mesmo poste.
Diagnóstico passo a passo
Detecções incompatíveis com o tipo esperado (FR "lendo placa", LPR "sem rosto")
Conferir serial físico vs. cadastro na visita
Verificar histórico de instalação/substituição do ponto
Ação padrão
Correção do vínculo serial↔posição na plataforma; validação das configs de cada câmera após a troca.
Prevenção: Checklist de instalação: foto da etiqueta de serial de cada câmera na posição instalada, anexada ao cadastro.
4 · Equipamento & configuraçãoCampo / Interno
Câmera pinga mas não envia detecção
ping OKVPN OKzero detecções facial/placaSeveridade alta
Mecanismo — por que acontece
Rede completamente saudável — o MikroTik responde, o túnel funciona — mas a câmera não envia nenhuma detecção. A causa é configuração da própria câmera (parâmetros de detecção, destino de envio, agenda), não rede. O perigo é a invisibilidade: como aparece "online" no sistema, ninguém olha para esses casos — o cliente fica sem o serviço enquanto todos os painéis mostram verde.
Diagnóstico passo a passo
Confirmar ping e VPN OK (elimina clusters 1–2)
Verificar última detecção enviada: quanto tempo faz?
Distinguir de local de baixo movimento: câmera "olhando pro nada" pode ter zero detecção legítima — comparar com histórico do próprio ponto
Acessar a configuração da câmera via VPN e validar parâmetros de detecção e envio
Ação padrão
Roteiro de verificação de configuração remota; correção via VPN quando acessível, visita quando não. Incluir varredura periódica de "online sem detecção há X dias" na rotina diária — é a única forma de capturar este modo de falha.
Prevenção: Auditoria amostral contínua: pontos online sem detecção recente entram automaticamente na fila de triagem.
Senha perdida — sequela de automação + reset indevido
acesso negado ao equipamentosenha fora do padrão esperadoSeveridade média
Mecanismo — por que acontece
Sequela direta do cluster 3: a automação aplicou senha no ponto trocado, o técnico encontrou credencial irreconhecível e resetou o equipamento sem investigar. Resultado: a senha real se perdeu de vez, o cadastro na plataforma não corresponde a nada, e o ponto exige intervenção física completa.
Diagnóstico passo a passo
Tentar credenciais do cadastro e do padrão da automação
Verificar histórico: houve troca automática + reset em campo na linha do tempo?
Confirmar se o ponto par (vizinho) também foi afetado
Ação padrão
Reset físico controlado com atualização simultânea na plataforma — campo e sistema no mesmo ato, nunca separados.
Prevenção: Instrução permanente ao campo: senha estranha NUNCA justifica reset imediato — primeiro reportar à triagem, que verifica a hipótese de troca de pontos.
Bootstrap nunca concluído — configuração incompleta
preso em Need to Bootstrapping histórico existeSeveridade alta
Mecanismo — por que acontece
A câmera foi criada na plataforma mas o processo automático (configs sequenciais + múltiplos reinícios + formatação do cartão) nunca terminou. Dois mecanismos completamente diferentes com o mesmo sintoma: interrupção por energia (cluster 1) ou bug do software da plataforma (cluster 5). Separá-los é o primeiro passo de qualquer tratamento — as soluções não se parecem em nada.
Diagnóstico passo a passo
Listar todos os pontos em "Need to Bootstrap" (consulta em lote)
Para cada um: energia concluída? Se não → cluster 1 (campo)
Se energia OK e travado mesmo assim → candidato a bug → cluster 5 (plataforma)
Quantificar os dois grupos — pergunta em aberto do diagnóstico que o mutirão responde
Ação padrão
Fila dupla no mutirão de saneamento (Decisão 6): grupo energia vai para campo com a Equatorial; grupo bug vai como chamado formal ao time de plataforma com o lote identificado.
Equipamento danificado (câmera ou MikroTik)
comportamento erráticonão responde mesmo após resetenergia e link confirmadosSeveridade média
Mecanismo — por que acontece
Falha de hardware: câmera ou roteador degradado por surto, umidade, temperatura ou defeito de fabricação. Diagnóstico por eliminação — só se chega aqui depois de descartar energia, conectividade, cadastro e configuração.
Diagnóstico passo a passo
Confirmar energia OK, link OK, cadastro correto e configuração válida
Verificar histórico do ponto: reincidência sem causa externa identificada
Testar reset físico assistido: se o comportamento errático persiste, é hardware
Ação padrão
Substituição em campo com retorno do equipamento para análise. Registrar padrão por lote/modelo/fornecedor de hardware — reincidência concentrada num lote é conversa de garantia, não de manutenção.
Prevenção: Rastrear taxa de falha por lote de compra no histórico do painel.
Cartão de memória cheio ou corrompido
gravação falhareinícios espontâneosalertas de storageSeveridade média
Mecanismo — por que acontece
O cartão SD da câmera lota ou corrompe (ciclos de gravação contínua, calor, queda de energia durante escrita — parente direto do bootstrap interrompido, que formata o cartão). Gravação local para de funcionar e, em casos piores, a câmera trava ou reinicia em ciclo.
Diagnóstico passo a passo
Verificar alertas de storage/gravação na plataforma
Histórico de quedas de energia do ponto (corrupção acompanha)
Câmera que reinicia sem causa elétrica → suspeitar do cartão
Ação padrão
Formatação remota quando acessível; substituição do cartão em campo quando corrompido. Registrar marca/lote dos cartões que falham.
Prevenção: Formatação preventiva na T3 + especificação de cartão industrial (ciclo de escrita alto) no padrão de compra.
Firmware desatualizado ou incompatível
recursos falham após atualização da plataformacomportamento diverge entre câmeras iguaisSeveridade baixa
Mecanismo — por que acontece
O parque acumula versões diferentes de firmware. Quando a plataforma evolui, câmeras em versão antiga perdem compatibilidade em recursos específicos (protocolo de envio, formato de detecção) — falhas seletivas difíceis de correlacionar.
Diagnóstico passo a passo
Comparar versão de firmware entre câmeras com e sem o problema
Cruzar o início do sintoma com datas de atualização da plataforma
Confirmar com o time de plataforma a matriz de compatibilidade
Ação padrão
Atualização de firmware remota via VPN (em janela controlada); inventário de versões no painel.
Prevenção: Política de versão mínima por modelo + atualização em ondas com validação amostral antes do parque inteiro.
Alimentação PoE insuficiente — loop de reboot
câmera reinicia sob cargapior à noite (IR ligado)MikroTik OKSeveridade média
Mecanismo — por que acontece
O orçamento de energia PoE não sustenta o pico de consumo da câmera — tipicamente à noite, quando o IR liga. A câmera funciona de dia e entra em loop de reboot à noite: assinatura horária inconfundível.
Diagnóstico passo a passo
Cruzar horários das quedas com o ciclo dia/noite (IR)
Confirmar injetor/porta PoE e classe de potência vs. especificação da câmera
Testar com IR forçado desligado (se acessível): estabilizou = confirmado
Ação padrão
Substituição do injetor/fonte por classe adequada; revisão do dimensionamento elétrico do ponto.
Prevenção: Especificação de PoE por modelo de câmera no padrão de instalação (classe com folga para IR + inverno).
Relógio/NTP errado — timestamps inválidos
detecções com horário deslocadoeventos "no futuro" ou "no passado"Severidade alta
Mecanismo — por que acontece
A câmera perde sincronização de horário (NTP inacessível — sequela comum de VPN/rota quebrada — ou bateria interna). As detecções continuam fluindo, mas com timestamp errado: para uso policial e como evidência, um evento com horário inválido perde valor probatório. Severidade alta com aparência de detalhe.
Diagnóstico passo a passo
Comparar timestamp das detecções com o horário real de eventos conhecidos
Verificar acessibilidade do servidor NTP a partir do ponto (depende de rota/VPN saudável)
Auditoria amostral de deriva de relógio no parque
Ação padrão
Restabelecer sincronização NTP; corrigir rota se a causa for rede; validar a deriva após correção.
Prevenção: Checagem de deriva de relógio como item da rotina de auditoria — e como validação obrigatória pós-correção de VPN.
5 · Plataforma & softwareTime de plataforma
Bug do software da plataforma
lote preso em bootstrapnenhum erro de campo identificávelSeveridade alta
Mecanismo — por que acontece
Investigação real do passado: parte de um lote de câmeras presas em "Need to Bootstrap" não tinha erro de cadastro nem de energia — era bug do software da equipe de plataforma. Parte foi corrigida pelo próprio time; outra parte segue sem solução conhecida. Lição estrutural: nem todo problema de câmera tem causa de campo, e essa fatia só o time de dados consegue investigar.
Diagnóstico passo a passo
Chegar aqui por eliminação: energia OK, cadastro OK, configuração iniciada e mesmo assim travada
Agrupar os casos: bug costuma afetar lotes com padrão comum (mesma época, mesmo modelo, mesmo fluxo)
Documentar o lote com evidências antes de escalar
Ação padrão
Chamado formal ao time de plataforma com o lote identificado e evidência. Acompanhar como pendência com prazo — não deixar voltar ao limbo do "sem solução conhecida".
Falso-positivo de detecção na plataforma
plataforma diz que envia dadosMikroTik nem detecta a câmeraSeveridade média
Mecanismo — por que acontece
Suspeita registrada pelo especialista e não resolvida: uma regra da plataforma faria câmeras faciais aparecerem como "enviando dados" mesmo sem detecção real — "como é que ela tá mandando se o MikroTik nem detecta ela?". Ele próprio declarou não confiar 100% no dado nesse cenário. Consequência: o indicador de detecção pode estar inflando a disponibilidade real.
Diagnóstico passo a passo
Cruzar detecções reportadas pela plataforma com o tráfego real do MikroTik do ponto
Amostrar câmeras FR "ativas" sem eventos recentes plausíveis
Comparar com padrão de movimento esperado do local
Ação padrão
Auditoria amostral formal + investigação pelo time de plataforma. Enquanto não resolvido: tratar o status de detecção de FR com ceticismo documentado nos relatórios.
Hex/dashboard com atraso de dados
status divergente entre Hex e plataformadecisão tomada sobre dado velhoSeveridade baixa
Mecanismo — por que acontece
O Hex é alimentado pelo Odoo com atraso e não reflete tempo real — é ferramenta de análise agregada, não de operação. Usá-lo para triagem de incidente induz erro: o ponto pode ter caído (ou voltado) horas atrás.
Diagnóstico passo a passo
Em divergência Hex vs. plataforma: a plataforma vence, sempre
Verificar a idade do dado antes de qualquer decisão baseada no Hex
Ação padrão
Convenção institucional: Hex para análise e tendência; plataforma + ping direto para triagem e incidente.
Ferramentas sem filtros/exportação persistentes
cruzamento manual repetido diariamenteconhecimento preso em planilha pessoalSeveridade baixa
Mecanismo — por que acontece
As melhorias já foram pedidas e aceitas em princípio (filtros e colunas persistentes na visão compartilhada, botão de exportação CSV para reconciliação automática), mas o time de plataforma "não tem braço". Resultado: o cruzamento que poderia ser automático é refeito manualmente todo dia, numa planilha pessoal que cruza plataforma com ping da máquina do especialista.
Diagnóstico passo a passo
Inventariar o trabalho manual recorrente e seu custo em horas
Especificar as 2–3 melhorias de maior alavancagem (filtros, exportação, visão de bootstrap)
Ação padrão
Decisão 5 do alinhamento: repriorizar o time, terceirizar o pacote ou adiar com data registrada — qualquer resposta é melhor que o limbo. O painel v11 já cobre parte do gap de cruzamento no curto prazo.
Atraso na fila de ingestão de detecções
detecções chegam com horas de atrasocâmera parece muda mas está enviandoSeveridade média
Mecanismo — por que acontece
A plataforma acumula fila no processamento: as detecções foram capturadas e enviadas, mas aparecem com atraso. Na triagem, o ponto parece ter parado de detectar — despachar campo aqui é perseguir um fantasma.
Diagnóstico passo a passo
Comparar horário de captura vs. horário de disponibilização na plataforma
Verificar se o atraso é generalizado (vários pontos) — fila é sistêmica, não local
Confirmar com o time de plataforma o estado do pipeline de ingestão
Ação padrão
Incidente do time de plataforma; comunicar a operação para congelar triagens baseadas em "última detecção" até normalizar.
Prevenção: Indicador de latência de ingestão exposto no painel — a operação precisa saber quando o dado que ela olha está atrasado.
Expiração de credencial/certificado do túnel
VPN de muitos pontos cai na mesma data/horadetecção segue OKSeveridade alta
Mecanismo — por que acontece
Certificados ou credenciais do túnel VPN têm validade. Quando expiram sem renovação, a VPN de todos os pontos que compartilham a credencial cai simultaneamente — um lote com timestamp idêntico, sem nenhuma causa de campo ou operadora.
Diagnóstico passo a passo
Queda de VPN em massa com horário exato idêntico = suspeitar de expiração antes de acionar operadoras
Verificar validade das credenciais/certificados com o time de plataforma
Descartar bloqueio de operadora (o lote de expiração cruza ISPs diferentes; o de operadora, não)
Ação padrão
Renovação da credencial/certificado e reestabelecimento do túnel; post-mortem para calendário de renovação.
Prevenção: Calendário de expiração com alerta antecipado — renovação nunca deveria ser descoberta pela queda.
6 · Segurança físicaCampo / Polícia
Furto de equipamento
duas câmeras do mesmo poste caem em horários DIFERENTESSeveridade alta
Mecanismo — por que acontece
A assinatura é temporal: queda de rede ou energia derruba as duas câmeras do poste no mesmo instante. Se caem em momentos distintos (caso real: 2h06 e depois 2h40), a explicação mais provável é remoção física, uma de cada vez. Fator de risco agravante: câmera FR em local pouco iluminado e exposto à noite — "parece um lugar bem tranquilo de roubar uma câmera".
Diagnóstico passo a passo
Comparar timestamps de queda das câmeras do mesmo poste: simultâneo = rede/energia; defasado = suspeita de furto
Avaliar o perfil do local: iluminação, exposição, histórico da região
Verificar se energia e link do ponto seguem ativos (MikroTik vivo com câmeras mortas reforça a suspeita)
Limite honesto do remoto: não há como CONFIRMAR furto à distância — só levantar suspeita para priorizar a visita
Ação padrão
Visita prioritária para confirmação; registro formal (B.O.) com evidências; avaliação de blindagem, altura ou reposicionamento do ponto.
Prevenção: Mapear pontos de alto risco (FR + local escuro + exposto) e priorizá-los em rondas e reforço físico.
Vandalismo / dano físico
queda abruptasem causa elétrica ou de redeárea com históricoSeveridade média
Mecanismo — por que acontece
Dano intencional ou acidental ao equipamento ou cabeamento exposto. Só confirmável em campo; a suspeita nasce por eliminação somada ao perfil da região.
Diagnóstico passo a passo
Eliminar energia (cluster 1) e conectividade (cluster 2) remotamente
Cruzar com histórico de ocorrências da região
Verificar se o dano coincide com evento local (protesto, obra, evento)
Ação padrão
Visita com registro fotográfico completo; acionamento de seguro/reposição; avaliação de proteção física adicional.
Poste removido ou derrubado
ponto desaparece por completoobra ou acidente na viaSeveridade média
Mecanismo — por que acontece
Causa clássica do processo antigo: caminhão derruba o poste, ou prefeitura/concessionária remove/realoca sem avisar a PAX. O ponto simplesmente deixa de existir fisicamente — às vezes "carregado embora" com equipamento e tudo.
Diagnóstico passo a passo
Queda total sem retorno + sem ocorrência de energia/link na região
Verificar com a Equatorial se houve intervenção na estrutura
Confirmar em campo a existência física do poste
Ação padrão
Confirmação em campo; recuperação do equipamento quando possível; reinstalação coordenada com a Equatorial; replanejamento do ponto se a posição original não existir mais.
Prevenção: Canal formal com a Equatorial para aviso prévio de intervenções em postes com equipamento PAX.
Colisão veicular no poste
queda abrupta totalvia de tráfego pesadoocorrência de trânsito na regiãoSeveridade média
Mecanismo — por que acontece
Veículo atinge o poste: equipamento danificado ou desalinhado, energia rompida, às vezes o poste inteiro vai ao chão. A Equatorial pode substituir o poste sem reinstalar o equipamento PAX — o ponto "volta" para a rede elétrica mas a câmera fica órfã.
Diagnóstico passo a passo
Queda total abrupta + ocorrência de trânsito conhecida na via
Confirmar com a Equatorial se houve substituição de poste no local
Visita para avaliação do equipamento (dano, desalinhamento, sobrevivência)
Ação padrão
Visita de avaliação; acionamento de seguro/reposição; reinstalação coordenada com a Equatorial no poste novo.
Prevenção: Acordo com a Equatorial: aviso obrigatório antes de substituir poste com equipamento PAX (mesma pauta do desligamento programado).
Alagamento / infiltração / corrosão na caixa
falhas que começam após chuva fortedegradação progressivaregião baixaSeveridade média
Mecanismo — por que acontece
Água entra na caixa de equipamentos: vedação ruim, prensa-cabo mal instalado, caixa em cota baixa. O dano é progressivo — oxidação e curtos intermitentes que pioram a cada chuva até a falha definitiva.
Diagnóstico passo a passo
Cruzar início/agravamento dos sintomas com eventos de chuva
Histórico do ponto: falhas recorrentes sempre pós-chuva
Inspeção visual da caixa na visita (marca d\u2019água, oxidação, vedação)
Ação padrão
Visita para secagem, tratamento de oxidação e refazimento da vedação; substituir componentes corroídos; reposicionar a caixa se a cota for o problema.
Prevenção: Inspeção de vedação na preventiva T3 + padrão de instalação com prensa-cabos e drenagem corretos.
Obstrução da lente ou do campo de visão
câmera onlinedetecções caem a zero ou ficam inúteisimagem bloqueadaSeveridade média
Mecanismo — por que acontece
Algo físico bloqueia a visão: vegetação que cresceu, teia de aranha/ninho de inseto sobre a lente (atrai IR à noite), pichação, adesivo, banner instalado na frente. A câmera está perfeita para o sistema — e inútil para o cliente.
Diagnóstico passo a passo
Ponto online com queda abrupta ou gradual de detecções sem mudança de movimento na via
Verificar imagem ao vivo via VPN: obstrução é visível de imediato
Sazonalidade: vegetação cresce, teias voltam — reincidência é esperada
Ação padrão
Limpeza/poda na visita; se recorrente, tratar a causa (poda programada, repelente de insetos na carenagem).
Prevenção: Verificação de imagem ao vivo como item da preventiva T3 e da validação de encerramento de qualquer visita.
7 · Processo & organizaçãoGestão (Manutenção)
Queda invisível — sem alerta, sem ticket
ponto offline dias sem registroSeveridade alta
Mecanismo — por que acontece
A falha-mãe operacional: nenhum evento é gerado quando um ponto cai. ~64 câmeras offline sem ticket existem porque a detecção depende de alguém olhar dashboards manualmente — "a gente não tem equipamento que reporta remotamente, eu só vou saber quando eu chegar lá".
Diagnóstico passo a passo
Varredura diária no painel: F2 (offline) vs. F1 (tickets) — todo offline sem ticket vira ticket na hora
Medir a idade do gap: há quanto tempo cada ponto está invisível?
Ação padrão
Curto prazo: varredura diária com dono nomeado (rotina de 15 min). Médio prazo: alerta automático aos 30 min (Onda 3, condicionado à Decisão 5). Meta permanente: zero offline sem ticket.
Referência
Dor D1 · Causa C1.
Encerramento sem validação
ticket fechadoponto segue offlineSeveridade alta
Mecanismo — por que acontece
~122 casos documentados: a visita resolve o sintoma reportado, o ticket fecha, e ninguém confere se o ponto voltou de fato à plataforma. O sistema registra sucesso enquanto o cliente segue sem o serviço.
Diagnóstico passo a passo
Cruzamento F3 (concluídos) vs. F5 (conectividade real): todo fechado-offline é encerramento falso
Auditar o passivo e reabrir com prioridade
Ação padrão
Etapa 6 do macroprocesso: encerramento só com o ponto comprovadamente online (detecção + VPN conforme a definição única). KPI permanente de encerramento falso com meta zero.
Referência
Dor D2 · Causa C3.
Acionamento informal de fornecedor
chamado por WhatsAppsem número, sem prazo, sem evidênciaSeveridade média
Mecanismo — por que acontece
O acionamento real acontece por mensagem ("Linke, vai lá pra mim ver esse ponto") e depende da boa vontade da parceria — tecnicamente não é um chamado. Sem registro não há SLA a cobrar, não há trilha para o ping-pong, não há histórico para negociar contrato.
Diagnóstico passo a passo
Cruzamento F1 (tickets) vs. F4 (chamados ISP): ticket de conectividade sem chamado formal = gap
Medir % de formalização por fornecedor
Ação padrão
Chamado formal no Odoo obrigatório para todo acionamento + protocolo de 5 regras. O WhatsApp continua como canal de agilidade — mas o registro oficial é o sistema.
Referência
Dores D3/D4 · Causa C4.
Conhecimento de diagnóstico em uma pessoa
triagem para quando o especialista não estáSeveridade alta
Mecanismo — por que acontece
O método de diagnóstico, as consultas em lote e a planilha que cruza plataforma com ping vivem na máquina e na cabeça de um consultor externo (Peers) sobrecarregado, com 50 outras demandas, que declarou ter largado parte do processo — e cujo trabalho é invisível para a liderança.
Diagnóstico passo a passo
Inventariar cada ferramenta pessoal e o processo que ela sustenta
Mapear o que para se ele parar (teste do ônibus)
Ação padrão
Transferência estruturada em 60 dias: 10 runbooks documentados + shadowing semanal + institucionalização das ferramentas. Com reconhecimento formal do trabalho já feito — condição prática de engajamento (Decisão 3).
Referência
Dor D7 · Causa C2.
Critérios divergentes de "online" entre projetos
mesmo cenário: online no GTE, offline no ParanáSeveridade média
Mecanismo — por que acontece
O time de plataforma considera LPR online só por mandar detecção (mesmo sem ping); o Paraná trata o mesmo cenário como offline. A divergência não foi "consertada" por decisão consciente — corrigir geraria alarme desnecessário no GTE. Resultado: nenhum indicador é comparável entre projetos e a disputa de versões contamina relatórios.
Diagnóstico passo a passo
Levantar quantos pontos do parque estão exatamente na zona de divergência (detecção sem VPN)
Simular o indicador de disponibilidade nos dois critérios e mostrar a diferença à liderança
Ação padrão
Ratificar os 3 estados (pleno / degradado / indisponível) como definição única — Decisão 1, a primeira do alinhamento, pré-requisito de todos os KPIs.
Referência
Dor D5 · Causa C2.
Falta de estoque de peças de reposição
visita agendada sem materialMTTR explode aguardando peçaSeveridade média
Mecanismo — por que acontece
O técnico chega ao ponto, diagnostica, e não tem a peça: câmera, MikroTik, injetor PoE, cartão, cabo. A visita vira diagnóstico caro e o ponto espera uma segunda viagem — dobrando custo e tempo de restauração.
Diagnóstico passo a passo
Medir quantas visitas terminam em "aguardando material"
Inventariar o estoque mínimo por item crítico vs. taxa de consumo real
Ação padrão
Estoque mínimo regional dimensionado pela taxa de falha do histórico; kit padrão no veículo do técnico (cabo, conectores, cartão, injetor).
Prevenção: KPI de visitas frustradas por falta de material — alimenta o dimensionamento do estoque.
Contatos e responsáveis de fornecedores desatualizados
chamado enviado não chega a ninguémescalada emperra num nome que saiuSeveridade baixa
Mecanismo — por que acontece
O acionamento depende de pessoas: o contato do ISP mudou, o responsável da Equatorial trocou de área, o grupo de WhatsApp morreu. O chamado formal existe, mas cai no vazio — e a janela de 4 h expira sem ninguém do outro lado saber.
Diagnóstico passo a passo
Auditar a taxa de chamados sem resposta por fornecedor: silêncio total sugere contato morto, não má vontade
Validar a matriz de contatos em cada reunião quinzenal
Ação padrão
Matriz de acionamento por fornecedor (contato primário, backup, escalada) validada quinzenalmente como item fixo de pauta.
Prevenção: A reunião quinzenal com dossiê é o mecanismo natural de manutenção da matriz — sem custo adicional.
8 · Qualidade de captura & detecçãoCampo / Interno
Lente suja, embaçada ou desfocada
câmera onlinetaxa de leitura LPR despencaimagem degradadaSeveridade alta
Mecanismo — por que acontece
Poeira, maresia, chuva com barro, condensação interna ou perda de foco degradam a imagem. A LPR continua "detectando", mas não lê placa — e a FR não reconhece rosto. Para todos os sistemas o ponto está saudável; para o cliente, o serviço não existe. É o modo de falha mais invisível do catálogo.
Diagnóstico passo a passo
Monitorar taxa de leitura válida (placas lidas ÷ detecções) por ponto — queda gradual = sujeira/foco
Verificar imagem ao vivo via VPN
Cruzar com clima e sazonalidade da região (poeira de seca, maresia)
Ação padrão
Limpeza e ajuste de foco em campo; validação por imagem ao vivo + taxa de leitura pós-visita.
Prevenção: Limpeza de lente como item obrigatório da preventiva T3; alerta de queda de taxa de leitura no painel.
Enquadramento alterado — câmera apontando errado
detecções caem após vento/pancadaimagem mostra outro cenárioSeveridade alta
Mecanismo — por que acontece
Vento forte, colisão leve no poste ou toque acidental em visita giram a câmera: ela deixa de cobrir a faixa/calçada planejada. Tecnicamente perfeita, operacionalmente cega para o objetivo do ponto — o blueprint definia o que ela deveria ver.
Diagnóstico passo a passo
Queda abrupta de detecções com ponto online após evento físico (vento, ocorrência, visita)
Comparar imagem ao vivo com o enquadramento de referência da instalação
Verificar se houve visita recente (toque acidental é causa comum)
Ação padrão
Reposicionamento em campo com validação por imagem contra a referência; conferir firmeza do suporte.
Prevenção: Foto de enquadramento de referência anexada ao cadastro na instalação — sem referência, ninguém sabe como "deveria" estar.
Iluminação/IR noturno falho
detecção normal de diazero detecção à noiteSeveridade média
Mecanismo — por que acontece
O iluminador IR queimou ou degradou: de dia tudo funciona, à noite a cena fica escura demais para detecção. Assinatura horária limpa — o gêmeo invertido do loop de reboot por PoE (que também segue o ciclo do IR, mas derrubando a câmera).
Diagnóstico passo a passo
Comparar taxa de detecção dia vs. noite do ponto
Verificar imagem ao vivo noturna via VPN
Distinguir do loop de PoE: aqui a câmera segue online à noite, só não detecta
Ação padrão
Substituição/reparo do IR em campo; validação noturna pós-visita.
Prevenção: Teste de imagem noturna na preventiva T3 (amostral) e na ativação de todo ponto novo.
Qualidade de imagem nunca aprovada formalmente
ponto "online" desde a ativaçãoimagem imprestável para o objetivoSeveridade média
Mecanismo — por que acontece
O ponto subiu, pinga, detecta — mas ninguém validou formalmente se a imagem serve ao propósito (ângulo, distância, altura, obstáculos). Existe processo de aprovação de qualidade de imagem em outro projeto (Fortaleza); no GTE, não é etapa formal do aceite.
Diagnóstico passo a passo
Levantar quais pontos do parque passaram por validação formal de imagem
Auditoria amostral por região com critérios objetivos (legibilidade de placa à distância-alvo, enquadramento vs. blueprint)
Ação padrão
Incluir a aprovação de qualidade de imagem como item do gate de aceite implantação → manutenção; auditar o passivo por amostragem no mutirão.
Prevenção: Nenhum ponto novo aceito sem validação de imagem — o gate é o lugar natural dessa etapa.
Referência
Processo análogo já praticado no projeto Fortaleza — aproveitar o critério existente.
Como usar na triagem: a assinatura (chips) identifica o cluster em segundos — "vários pontos da mesma operadora sem VPN" nunca é caso de despachar técnico (cluster 2, incidente de lote); "duas câmeras do mesmo poste caindo em horários diferentes" é visita prioritária (cluster 6); "pingou uma vez e nunca saiu de bootstrap" exige separar energia de bug antes de qualquer ação (clusters 1 e 5). Clusters 1–6 são causas técnicas com responsável de acionamento; o cluster 7 são as falhas do próprio processo — as que esta estruturação elimina; o cluster 8 é a fronteira seguinte da maturidade: pontos "online" cujo serviço real está degradado — invisíveis para qualquer métrica de conectividade.
5 Decisão nº 1 — definição única de "ponto operacional"
Hoje coexistem dois critérios (GTE vs. Paraná). A proposta de 3 estados reconhece o cliente atendido sem esconder a perda de acesso técnico.
Operacional pleno
Envia detecção e responde ping/VPN.
Nenhuma ação.
Degradado
Envia detecção, mas sem VPN — o cliente é atendido, a equipe técnica não acessa o ponto.
Fila de correção, prioridade média. Conta como online para o cliente, offline para a gestão técnica.
Indisponível
Sem detecção (com ou sem ping).
Fila prioritária. Conta contra a disponibilidade contratual.
6 Macroprocesso da área — 7 etapas
Do sinal de queda ao aprendizado. O passo 6 elimina o erro mais caro de hoje: ticket fechado ≠ ponto online.
01
DetectarVarredura diária no painel; alvo futuro: alerta automático aos 30 min
02
TriarClassificar contra o catálogo de 10 causas-raiz antes de qualquer despacho
03
DiagnosticarChecagens remotas: ping, VPN, detecção, faixa de IP, bootstrap, energia
04
AcionarChamado formal no Odoo — ISP, Equatorial, técnico ou plataforma
05
ResolverVisita com checklist completo do ponto, não só do sintoma
06
ValidarEncerra somente com o ponto comprovadamente online na plataforma
07
AprenderRecorrência alimenta o catálogo e o dossiê de cada parceiro
Gate de aceite72 h estáveis + checklist elétrico separam implantação de manutenção
Janela de 4 hFibra sem resposta em 4 h libera o despacho — silêncio não bloqueia a operação
Teto de 2 visitasNa 3ª necessidade, inspeção conjunta obrigatória com o fornecedor
Verdade contratualColuna de contrato define conectividade contratada; cobertura ≠ contrato
7 Protocolo anti-ping-pong com fornecedores
O ciclo "fui lá e do meu lado está ok" só se quebra com evidência confrontável e regra de tempo.
Hoje
Chamado por WhatsApp, sem número, sem SLA
Cada parte declara que seu serviço funciona
Visitas repetidas sem confronto de versões
Escalada depende de boa vontade pessoal
Com o protocolo
Todo acionamento formal no Odoo, com evidência anexa
Contradição registrada no dossiê e confrontada com dado
3ª ocorrência = inspeção conjunta obrigatória no local
Reunião quinzenal por parceiro, baseada no dossiê
1
Chamado formalWhatsApp segue como canal de agilidade; o registro oficial é o Odoo, com hora e evidência.
2
Evidência antes de opinião"Funciona" vs. offline na plataforma vira contradição documentada — discute-se dado, não versão.
3
Janela de 4 hSem resposta do provedor de fibra, o despacho é liberado e o custo entra no dossiê do parceiro.
4
Inspeção conjuntaPonto que volta pela 3ª vez exige PAX + fornecedor(es) simultaneamente no local.
5
Queda em loteVários pontos da mesma operadora caindo juntos = problema da operadora; escala direto, sem visitas ponto a ponto.
8 Agenda do alinhamento — 3 horas
Cada bloco termina com um resultado concreto. Os blocos marcados produzem decisão formal.
Horário
Bloco
Resultado
0:00 – 0:20
Contexto: mudança de fase do contrato + números do gap + árvore de problemas
Alinhamento sobre o problema central
0:20 – 0:50
Definição única de "ponto operacional" (3 estados)
Decisão 1 critério ratificado
0:50 – 1:30
Macroprocesso, papéis (RACI) e gate de aceite
Decisões 2–3 dono do processo + transferência do especialista
1:30 – 2:00
Protocolo de fornecedores
Decisão 4 patrocínio da liderança + quem comunica cada parceiro
2:00 – 2:30
Controles, rituais e metas iniciais
Metas dos 3 primeiros indicadores
2:30 – 3:00
Roadmap em 3 ondas, riscos e próximos passos
Decisões 5–8 + donos e prazos da Onda 1
9 As 8 decisões da estruturação
O documento propõe; a liderança decide. Nada abaixo está fechado — é exatamente o que esta sessão de alinhamento existe para definir.
Decisão 1
Critério único de "ponto operacional"Ratificar os 3 estados (pleno / degradado / indisponível) para todos os projetos?
Por que importa
Hoje o GTE considera online uma câmera que manda detecção mesmo sem ping/VPN; o Paraná trata o mesmo cenário como offline. Enquanto coexistirem dois critérios, nenhum número de disponibilidade é confiável — e disponibilidade é o indicador que sustenta a receita do contrato.
Proposta
Adotar 3 estados: Pleno (detecção + VPN), Degradado (detecção sem VPN — cliente atendido, gestão técnica sem acesso) e Indisponível (sem detecção). O estado Degradado reconhece os dois lados: não gera alarme falso para o cliente nem esconde a perda de acesso técnico.
Alternativas e trade-offs
Adotar o critério do GTE (detecção = online): protege o número, mas esconde pontos inacessíveis à equipe técnica
Adotar o critério do Paraná (sem VPN = offline): tecnicamente rigoroso, mas derruba o indicador com pontos que estão atendendo o cliente
Modelo de 3 estados (proposto): mais granular, exige ajuste de relatórios, mas encerra a disputa de versões
O que a liderança decide: ratificar (ou ajustar) a definição e determinar que ela vale para relatórios internos, painel e comunicação com a GTE a partir de uma data.
Decisão 2
Dono formal do processoQuem responde pela manutenção do GTE, e o Analista de Diagnóstico vira posição dedicada?
Por que importa
Hoje a manutenção é uma extensão informal do trabalho de um consultor externo sobrecarregado. Sem dono nomeado, cada melhoria depende de boa vontade e nada sobrevive à saída de uma pessoa.
Proposta
Nomear a coordenação de Manutenção (Matheus) como dona do processo fim a fim, com a função de Analista de Diagnóstico formalizada — inicialmente em transferência com o especialista, depois como capacidade interna.
Alternativas e trade-offs
Posição interna dedicada: garante continuidade, tem custo de headcount
Manter no consultor externo com contrato ampliado: rápido, mas perpetua a dependência e o risco de saída
Distribuir entre a equipe atual: sem custo novo, mas diagnóstico exige especialização que hoje ninguém interno tem
O que a liderança decide: nomear o dono do processo e definir se a função de diagnóstico vira posição dedicada, com que perfil e a partir de quando.
Decisão 3
Transferência de conhecimentoPrazo e formato do shadowing + runbooks com o especialista; reconhecimento do trabalho já feito.
Por que importa
O especialista declarou ter "largado" parte do processo por sobrecarga e relata que seu trabalho é invisível para a liderança (300+ IPs corrigidos à mão sem registro). Se ele sair antes da transferência, o GTE perde a única capacidade de diagnóstico remoto que possui.
Proposta
Programa de transferência com prazo definido (sugestão: 60 dias): documentação dos 10 runbooks do catálogo + shadowing semanal + institucionalização das ferramentas pessoais (planilha de status, consultas de IP em lote). Acompanhado de reconhecimento formal do trabalho já realizado — condição prática de engajamento.
Alternativas e trade-offs
Transferência estruturada com prazo (proposta): exige dedicação dele e nossa, mas fecha o risco
Contratar substituto e treinar do zero: independe do especialista, mas perde 1+ ano de conhecimento acumulado
Não fazer nada: custo zero hoje, risco total amanhã
O que a liderança decide: aprovar o formato, o prazo, quem acompanha do lado PAX e como o reconhecimento será feito (inclusive junto à Peers).
Decisão 4
Patrocínio do protocolo de fornecedoresLiderança comunica formalmente a cada parceiro a janela de 4 h, inspeção conjunta e chamado obrigatório?
Por que importa
O protocolo anti-ping-pong só funciona se os parceiros o receberem como regra do contrato, não como pedido da operação. Sem patrocínio da liderança, vira mais uma planilha que os fornecedores ignoram.
Proposta
Comunicação formal da liderança PAX a cada parceiro (IBNet, LinQ, Ragtek, Vivo, Equatorial, Portaryah) apresentando as 5 regras: chamado formal obrigatório, evidência antes de opinião, janela de 4 h, inspeção conjunta na 3ª ocorrência e tratamento de quedas em lote.
Alternativas e trade-offs
Comunicação top-down pela liderança (proposta): dá peso institucional; exige alinhamento prévio interno
Operação comunica diretamente: mais rápido, menos autoridade — risco de o parceiro testar o limite
Formalizar via aditivo contratual: máxima força, mas prazo jurídico longo — pode ser fase 2
O que a liderança decide: patrocinar a comunicação, definir quem assina/apresenta a cada parceiro e se haverá formalização contratual na sequência.
Decisão 5
Capacidade do time de plataformaAlertas automáticos e melhorias de ferramenta: repriorizar, terceirizar ou adiar com data?
Por que importa
A detecção automática de queda (30 min) e as melhorias de ferramenta (filtros persistentes, exportação) já foram pedidas e aceitas em princípio — mas o time de dados "não tem braço". Sem decisão explícita, o tema fica eternamente concordado e nunca feito.
Proposta
Levar à liderança a escolha explícita entre repriorizar o backlog do time de plataforma, contratar desenvolvimento externo pontual, ou adiar formalmente com data de revisão — qualquer resposta é melhor que o limbo atual.
Alternativas e trade-offs
Repriorizar o time interno: sem custo novo, mas desloca outras entregas
Terceirizar o pacote de alertas/exportação: rápido, custo direto, exige acesso à plataforma
Adiar com data: mantém a Onda 1 operando no manual, mas com compromisso de revisão registrado
O que a liderança decide: escolher o caminho, nomear o responsável e registrar prazo — inclusive se a decisão for adiar.
Decisão 6
Mutirão de saneamento do passivoForça-tarefa única para bootstrap travado, IPs e cadastros duplicados antes do gate de aceite?
Por que importa
A área de manutenção não pode nascer herdando pontos que nunca terminaram a configuração (bootstrap travado), IPs duplicados e cadastros em dobro. Sem saneamento, o gate de aceite vira ficção e os KPIs nascem contaminados.
Proposta
Força-tarefa única e delimitada (sugestão: dentro da Onda 2): levantar o passivo por categoria via painel + consultas em lote, despachar visitas de correção com checklist completo e só então ativar o gate para o parque legado.
Alternativas e trade-offs
Mutirão concentrado (proposta): resolve rápido, exige pico de campo e coordenação com fornecedores
Saneamento gradual dentro da rotina: sem pico de custo, mas contamina os indicadores por meses
Sanear só o que virar ticket: menor esforço, perpetua os ~64 invisíveis
O que a liderança decide: aprovar o mutirão, seu orçamento de campo e o critério de priorização (criticidade do ponto para o cliente).
Decisão 7
"Resolver tudo numa visita"Reconsiderar a abordagem de visita completa para pontos com histórico de retornos repetidos?
Por que importa
Há pontos com 5 a 8 visitas sem resolução definitiva — cada visita resolve o sintoma reportado e ignora o resto do ponto. A proposta de visita completa já foi feita pelo especialista e rejeitada; o padrão de retornos sugere reavaliar.
Proposta
Para pontos com 2+ retornos, a visita passa a executar o checklist completo do ponto (energia, no-break, cabos, IP, VPN, câmeras, etiquetagem) independentemente do sintoma que motivou o despacho.
Alternativas e trade-offs
Checklist completo para reincidentes (proposta): visita mais longa, menos retornos — custo total menor
Checklist completo para toda visita: máxima qualidade, mas encarece visitas simples de energia
Manter visita por sintoma: visita mais curta, perpetua o ciclo de retornos
O que a liderança decide: aprovar o critério (a partir de quantos retornos) e o conteúdo do checklist completo.
Decisão 8
Etiquetagem física de postesTornar padrão obrigatório — ataca 3 causas-raiz do catálogo de uma vez (IPs, pontos trocados, blueprint)?
Por que importa
Pontos vizinhos sem identificação física alimentam pelo menos 3 causas-raiz: IP cadastrado no ponto errado, pares de pontos quebrados pela automação de senha e confusão da própria Equatorial. É a correção de maior alavancagem por real investido.
Proposta
Etiquetar fisicamente postes e câmeras com o código do ponto, começando pelas regiões com maior densidade de pontos próximos, e incluir a etiquetagem no checklist de instalação de todo ponto novo (responsabilidade da instaladora).
Alternativas e trade-offs
Etiquetar todo o parque: cobertura total, custo e logística maiores
Priorizar regiões críticas + pontos novos (proposta): 80% do benefício com fração do custo
Só pontos novos: barato, não resolve o passivo que gera os erros de hoje
O que a liderança decide: aprovar o padrão, o escopo inicial e de quem é o custo (PAX ou instaladora, para pontos novos).
10 Roadmap — setembro a dezembro/2026
Três ondas encadeadas, fechando com a entrega formal da operação de manutenção estruturada à GTE em dezembro. Grade em quinzenas.
Set
Out
Nov
Dez
Onda 1 · Estancar
◆ Sessão de alinhamento + 8 decisões
Publicar definição única de "ponto operacional"
Varredura diária — zerar ~64 offline sem ticket
Chamado formal no Odoo obrigatório
Runbooks + shadowing com o especialista (60 dias)
Auditar e reabrir ~122 encerramentos falsos
Onda 2 · Estruturar
◆ Gate de aceite ativo (72 h + checklist) p/ ponto novo
Mutirão de saneamento do passivo
Reuniões quinzenais com fornecedores (dossiê)
Comunicação formal do protocolo aos parceiros
Etiquetagem física — regiões críticas
Onda 3 · Escalar
Alertas automáticos de queda (30 min)
SLA segmentado por geografia e criticidade
Metas de disponibilidade acordadas com a GTE
Frente de conectividade contratada (reduzir 4G)
◆ Entrega formal: operação de manutenção estruturada
Onda 1 · EstancarOnda 2 · EstruturarOnda 3 · EscalarMarcoEntrega final · Dez/2026
Mapa de Processos BPMN — Manutenção PAX · Contrato GTE/Goiás (v5). Documento completo incorporado: panorama, arquitetura, fluxos BPMN, SLA, RACI, rotinas, checklists, indicadores, riscos e roadmap. Navegue pelo menu interno.