Toda empresa tem alguém que “sabe onde está tudo”.
Sabe qual notebook foi para manutenção.
Lembra qual fornecedor atende mais rápido.
Conhece a senha daquele sistema antigo.
Sabe qual carregador serve em determinado modelo.
Lembra quem ficou com qual equipamento.
Tem o contato do técnico.
Sabe onde está a nota fiscal.
E conhece de cabeça os atalhos que mantêm a operação funcionando.
Enquanto essa pessoa está presente, tudo parece normal.
O problema aparece quando ela:
- tira férias;
- fica afastada;
- muda de função;
- pede demissão;
- sai da empresa;
- simplesmente não está disponível no momento crítico.
Nesse instante, a empresa percebe que boa parte da operação tecnológica não estava realmente documentada.
Estava concentrada na memória de uma única pessoa.
Isso cria um dos riscos mais subestimados na gestão de TI: a dependência excessiva de conhecimento informal.
Conhecimento centralizado parece eficiência até deixar de estar disponível
Em empresas pequenas e médias, é comum que a TI cresça de forma orgânica.
Uma pessoa começa a cuidar dos notebooks.
Depois passa a administrar fornecedores.
Em seguida assume acessos.
Depois entra no onboarding.
Mais tarde, manutenção, inventário, compras, garantia e suporte.
Com o tempo, aquela pessoa passa a concentrar um volume enorme de informação.
Isso pode parecer eficiência.
Afinal, ela resolve tudo rapidamente.
Mas existe uma fragilidade escondida.
Se o processo depende da presença de alguém específico para funcionar, então o processo não está realmente estruturado.
O risco não está apenas nas senhas
Quando se fala em dependência de uma pessoa da TI, muita gente pensa imediatamente em senhas.
E elas realmente são importantes.
Mas a concentração de conhecimento costuma ser muito maior.
Pode envolver:
- credenciais;
- históricos de manutenção;
- contatos de fornecedores;
- contratos;
- rotinas de backup;
- configurações;
- modelos homologados;
- acessos administrativos;
- localização de equipamentos;
- procedimentos de onboarding;
- procedimentos de desligamento;
- regras de compra;
- exceções;
- procedimentos emergenciais.
Ou seja, o risco está no conjunto.
“Só fulano sabe” é um alerta
Algumas frases deveriam acender um sinal imediatamente.
“Só o João sabe essa senha.”
“Só a Ana sabe como configurar esse sistema.”
“Só o Carlos sabe qual fornecedor chamar.”
“Só a TI sabe onde estão os notebooks.”
“Essa planilha fica no computador dele.”
“Ele resolve quando voltar.”
Quando essas frases aparecem com frequência, existe um problema de continuidade.
O parque tecnológico também precisa de documentação operacional
Empresas costumam documentar processos comerciais, financeiros e administrativos.
Mas a operação dos notebooks muitas vezes fica informal.
Quem recebe equipamento novo?
Quem registra o ativo?
Onde fica o número de série?
Como se controla a garantia?
Quem aprova reparo?
Qual fornecedor pode atender?
Como funciona a logística?
Como um notebook devolvido é preparado para outro usuário?
Sem respostas documentadas, cada movimentação depende de conhecimento individual.
O inventário precisa sobreviver à pessoa
Um bom controle de parque deveria permitir que outra pessoa consiga responder, sem depender de memória:
- quantos notebooks existem;
- quem está com cada um;
- quais estão em manutenção;
- quais estão disponíveis;
- quais estão em garantia;
- quais possuem histórico de reparo;
- quais podem receber upgrade;
- quais estão próximos da renovação.
Se o inventário está apenas na cabeça da equipe, ele não é um inventário.
É memória.
Senhas precisam sair de planilhas pessoais e mensagens
Outro risco é a forma como credenciais são armazenadas.
Planilhas locais.
Bloco de notas.
WhatsApp.
E-mails antigos.
Arquivos sem controle.
Além de aumentar o risco de segurança, esse modelo cria dependência.
Credenciais críticas deveriam ser armazenadas em soluções adequadas, com controle de acesso e possibilidade de gestão por mais de uma pessoa autorizada.
O objetivo não é compartilhar tudo com todos.
É evitar que informações essenciais desapareçam com um único usuário.
O histórico técnico também precisa ser preservado
Imagine um notebook que apresenta falha recorrente.
A pessoa da TI lembra:
“Esse equipamento já teve problema na placa.”
Mas isso nunca foi registrado.
Se ela sair, o próximo técnico começa do zero.
O mesmo vale para:
- troca de bateria;
- reparo de tela;
- upgrade;
- falha de carregamento;
- substituição de SSD;
- histórico de usuário;
- dano físico.
Quando o histórico acompanha o ativo, o conhecimento deixa de depender de pessoas.
Fornecedores também fazem parte do risco
Em algumas empresas, todo o relacionamento com fornecedores está concentrado em uma pessoa.
Ela sabe:
quem chama;
quem responde rápido;
quem atende Mac;
quem atende Dell;
quem retira;
quem fatura;
quem dá prazo.
Mas esses dados precisam estar documentados.
Contato.
Escopo.
Condições.
SLA.
Procedimento de acionamento.
Histórico.
Sem isso, uma simples ausência pode atrasar bastante um incidente.
Onboarding é outro ponto crítico
Uma contratação nova deveria seguir um fluxo previsível.
Mas, em ambientes muito dependentes de uma pessoa, o processo costuma ser:
“Fala com o fulano da TI.”
Se ele não está, ninguém sabe exatamente:
qual notebook entregar;
qual configuração instalar;
quais acessos criar;
quais licenças liberar;
qual termo assinar;
qual carregador entregar.
O onboarding vira dependência pessoal.
O mesmo vale para desligamento
E esse é ainda mais sensível.
Quando alguém sai da empresa, o processo pode envolver:
- bloqueio de acessos;
- recuperação do notebook;
- conferência de carregador;
- backup;
- sanitização;
- redefinição;
- inventário;
- realocação.
Se apenas uma pessoa sabe executar esse fluxo, existe risco operacional e de segurança.
Férias são um bom teste de maturidade
Uma pergunta simples:
a operação de TI consegue funcionar normalmente durante duas semanas de férias do responsável principal?
Se a resposta for não, existe dependência excessiva.
Não significa que ninguém precise daquele profissional.
Significa que tarefas críticas deveriam continuar funcionando sem ele.
Documentação não precisa ser burocrática
Esse é um erro comum.
Quando se fala em documentar, algumas empresas imaginam manuais enormes que ninguém lê.
Não precisa ser assim.
Documentação útil pode ser curta.
Por exemplo:
Procedimento: notebook com falha
- Abrir chamado.
- Verificar garantia.
- Disponibilizar reserva.
- Registrar retirada.
- Encaminhar fornecedor.
- Registrar diagnóstico.
- Aprovar reparo.
- Atualizar histórico.
- Devolver.
- Encerrar chamado.
Simples.
Objetivo.
Executável por outra pessoa.
Crie uma base de conhecimento
Uma estrutura mínima pode conter:
Ativos
Inventário e histórico.
Procedimentos
Onboarding, desligamento, manutenção, devolução, descarte.
Fornecedores
Contatos, escopo, SLA e condições.
Configurações
Modelos homologados, BIOS, docks, carregadores.
Acessos
Onde e como credenciais são administradas.
Contingência
O que fazer em falhas críticas.
Isso reduz o risco de conhecimento desaparecer.
Delegar também faz parte da solução
Documentar é importante, mas não basta.
Se só uma pessoa executa tudo, o conhecimento continua concentrado.
Vale criar redundância.
Outra pessoa precisa saber:
como abrir fornecedor;
como localizar ativo;
como liberar um reserva;
como acompanhar garantia;
como encontrar a documentação.
Não precisa ter o mesmo nível técnico.
Mas precisa conseguir manter o processo básico funcionando.
Crie níveis de acesso e responsabilidade
Evitar dependência não significa espalhar acesso indiscriminadamente.
O ideal é definir:
quem pode consultar;
quem pode alterar;
quem pode aprovar;
quem pode acessar credenciais críticas.
Assim, a empresa ganha redundância sem perder governança.
O risco cresce junto com o parque
Com 20 notebooks, uma pessoa consegue lembrar de muita coisa.
Com 100, começa a ficar difícil.
Com 300, confiar em memória individual se torna inviável.
Quanto maior o parque, mais importante ter:
- inventário;
- processos;
- histórico;
- responsabilidades;
- documentação;
- redundância.
A saída de uma pessoa não deveria reiniciar a TI
Esse é talvez o melhor teste.
Se alguém importante sai hoje, o próximo responsável deveria conseguir assumir a operação com base em:
documentação;
acessos estruturados;
inventário;
histórico;
processos.
Ele naturalmente precisará de adaptação.
Mas não deveria precisar reconstruir toda a operação.
O conhecimento precisa pertencer à empresa
Pessoas acumulam experiência.
Isso é valioso.
Mas o conhecimento crítico da operação não deveria existir apenas na cabeça de alguém.
A empresa precisa transformar conhecimento individual em conhecimento organizacional.
Isso protege:
- continuidade;
- segurança;
- produtividade;
- governança;
- capacidade de crescimento.
No fim, a pergunta é simples:
Se a pessoa que mais conhece seu parque tecnológico não estiver disponível amanhã, sua operação continua funcionando?
Se a resposta for não, o maior risco talvez não esteja nos notebooks.
Esteja na forma como o conhecimento sobre eles é administrado.
