Todo provedor de internet começa pequeno. No início, uma pessoa sabe onde fica cada OLT, cada CTO, cada emenda: o cadastro de OLT e o mapa de rede moram só na cabeça de quem monta a rede, e ninguém escreve nada porque não precisa.

O problema aparece depois. Quando o provedor cresce, contrata mais técnicos, abre outro bairro ou entra em outra cidade, aquilo que funcionava como jeito de trabalhar vira um obstáculo. A rede continua sendo a mesma rede. O que quebrou foi a forma como o cadastro de OLT e o mapa de rede são registrados.

O crescimento que expõe o caos que já existia

Numa rede pequena, o improviso não aparece como problema. O dono do provedor ou o técnico mais antigo sabe de cor onde cada equipamento está instalado, qual OLT atende qual rua, qual porta da CTO está livre. O cadastro, quando existe, é uma planilha pessoal, um caderno ou a própria memória de quem construiu a rede.

Esse jeito de trabalhar não é um erro enquanto a operação é pequena. O problema é que ele não escala. Assim que o provedor cresce, seja abrindo um novo bairro, contratando uma segunda equipe de campo ou expandindo para uma cidade vizinha, o improviso que sustentava o dia a dia começa a falhar.

Cada equipe passa a registrar a rede de um jeito diferente. Um técnico chama de “OLT 1” o que outro chama de “OLT Centro”. Uma CTO ganha um nome numa planilha e outro nome na cabeça de quem instalou. O resultado não é falta de informação: é excesso de informações que não conversam entre si.

Padronização não é sobre marca de equipamento

Quando um gestor ouve a palavra “padronização”, o primeiro pensamento costuma ser sobre hardware: comprar sempre a mesma marca de OLT, o mesmo modelo de CTO, o mesmo fornecedor de cabo. Faz sentido pensar assim, mas esse não é o núcleo do problema.

Uma rede pode ter equipamentos de fabricantes diferentes, comprados em momentos diferentes, e ainda assim ser perfeitamente organizada. O que realmente padroniza uma rede é o processo de cadastro: um jeito único de nomear, registrar e localizar cada elemento, seguido por todas as equipes, em qualquer bairro ou cidade onde o provedor atue.

Padronizar é definir, por exemplo, que todo cadastro de OLT segue a mesma estrutura de nome, que toda CTO tem um identificador único e que o mapa de rede é atualizado sempre no mesmo lugar, pela mesma lógica. A marca do equipamento não importa. O que importa é que qualquer técnico, mesmo alguém que nunca pisou naquele bairro, consiga ler o cadastro e entender exatamente o que está vendo.

Os três custos escondidos da falta de padrão

A falta de padronização raramente aparece como uma crise única. Ela se manifesta como um conjunto de pequenos atritos que, somados, custam tempo, dinheiro e previsibilidade.

1. 1
   O caos de cadastro entre equipes: quando cada equipe registra a rede à sua maneira, o cadastro deixa de ser uma fonte confiável de informação. Um técnico não sabe se pode confiar no nome que está na planilha, porque já viu aquele nome não bater com o que encontrou em campo. Aos poucos, o cadastro vira algo que se consulta por obrigação, não porque ajuda.
2. 2
   A dependência do conhecimento tribal: em muitos provedores, existem uma ou duas pessoas que sabem, de cor, onde está cada coisa. Elas se tornaram a memória viva da rede. O problema é que esse conhecimento não está escrito em lugar nenhum: está apenas na cabeça delas. Isso é confortável até o dia em que essa pessoa tira férias, muda de função ou sai da empresa. Nesse momento, o provedor descobre que boa parte da sua infraestrutura não estava documentada. Estava apenas memorizada.
3. 3
   O custo de tempo em campo e o atraso de SLA: todo minuto que um técnico passa tentando decifrar a rede em campo, procurando uma OLT mal identificada ou confirmando por telefone onde fica determinada CTO, é um minuto que deveria estar sendo usado para resolver o chamado do cliente. Esse tempo perdido se acumula. Ele aparece como retrabalho, como deslocamento desnecessário e, no fim da cadeia, como atraso no SLA prometido ao cliente. Um problema que parecia ser apenas “falta de organização interna” se transforma em um problema visível para quem paga a mensalidade.

Do “só fulano sabe” ao mapa de rede vivo

A alternativa ao conhecimento tribal não é pedir para as pessoas decorarem melhor a rede. É tirar esse conhecimento da cabeça de poucos e colocá-lo em um lugar que qualquer técnico autorizado possa consultar: um mapa de rede vivo e centralizado.

Um mapa de rede vivo é diferente de um desenho estático, feito uma vez e esquecido em uma pasta. Ele é atualizado conforme a rede cresce, reflete o cadastro real de cada elemento (OLT, CTO, caixa de emenda, splitter) e pode ser consultado por qualquer pessoa da equipe, no escritório ou em campo, sem depender de perguntar para quem “sabe de cor”.

Quando o mapa de rede passa a ser a fonte única de verdade, o conhecimento deixa de pertencer a uma pessoa e passa a pertencer à empresa. Isso muda completamente o risco associado à saída, à promoção ou até a um dia de folga do técnico mais experiente.

Cadastro de OLT e projeto de rede: padronizar desde o primeiro dia

Resolver o caos de cadastro custa bem menos quando ele não chega a se acumular. Isso significa levar o padrão para dentro do projeto de rede, antes mesmo de o primeiro cliente ser conectado.

Na prática, padronizar desde o projeto envolve algumas decisões simples, tomadas uma única vez e repetidas sempre:

1. 1
   Nomenclatura única: definir uma nomenclatura única para cadastro de OLT, válida para todas as equipes e todas as regiões atendidas.
2. 2
   Identificação padrão: estabelecer um padrão de identificação para CTOs, caixas de emenda e splitters, sem depender de apelidos informais.
3. 3
   Mapa como parte do projeto: tratar o mapa de rede como parte do projeto de rede, e não como uma tarefa para organizar depois.
4. 4
   Documentação em tempo real: documentar cada novo trecho de rede no momento em que ele é instalado, e não semanas depois, de memória.

Quanto mais tarde a padronização é aplicada, mais caro fica o processo de corrigir o que já foi cadastrado sem padrão. Provedores que crescem rápido sentem isso com mais intensidade: cada bairro novo, cada cidade nova e cada equipe nova aumentam o volume de cadastro que precisará ser corrigido depois, em vez de ser feito corretamente uma única vez.

Um cenário comum: duas formas de crescer

Para entender o efeito prático da padronização, vale imaginar dois provedores parecidos, do mesmo porte, crescendo ao mesmo tempo. Este é um cenário ilustrativo, e não um case específico, mas representa um padrão de comportamento comum entre provedores em crescimento.

No primeiro provedor, cada equipe de campo registra a rede à sua maneira. Quando chega um chamado num bairro novo, o técnico designado não conhece aquela região e precisa ligar para quem instalou a OLT, tentar decifrar uma planilha desatualizada ou percorrer a rua procurando uma CTO mal identificada. O chamado demora mais do que deveria, e o cliente sente esse atraso.

No segundo provedor, o cadastro segue um padrão único desde o início. Qualquer técnico, mesmo em um bairro que nunca visitou, abre o mapa de rede, encontra a OLT pelo nome correto, identifica a CTO e a porta livre, e resolve o chamado sem depender de ninguém.

A rede tem a mesma complexidade nos dois casos. A diferença inteira está em como ela foi cadastrada.

Perguntas frequentes