O armário cheio de documentos
Imagine uma empresa que possui tudo: manuais, procedimentos, planilhas, relatórios, PDFs, e-mails, tickets, dashboards, sistemas e pastas compartilhadas, acumulando centenas ou milhares de arquivos ao longo dos anos.
Se alguém perguntasse "vocês têm essa informação?", provavelmente a resposta seria:
"Temos. Em algum lugar."
Mas existe uma diferença enorme entre uma informação existir e uma empresa saber utilizá-la. Um arquivo pode estar perfeitamente armazenado e, ainda assim, ser praticamente inútil para quem precisa tomar uma decisão agora. Isso acontece porque guardar informação não é o mesmo que preservar conhecimento.
Informação não é conhecimento
Pense em um procedimento de cinquenta páginas explicando como uma determinada operação deve ser executada. O documento pode estar correto, ter sido escrito por alguém experiente e até ter sido revisado recentemente.
Ainda assim, quando uma pessoa nova encontra um problema que não está descrito exatamente ali, ela provavelmente fará o que todos fazem: perguntará para alguém. E talvez escute:
"Ah, nesse caso é diferente. O manual não está atualizado."
Nesse momento aparece algo importante: o conhecimento necessário para executar o processo não estava no documento, estava na cabeça de alguém. O documento armazenava informação; a pessoa armazenava contexto. E contexto é justamente uma das coisas mais difíceis de preservar.
O conhecimento escondido nas exceções
Processos descritos em documentos geralmente representam o caminho esperado, mas a operação real é feita de exceções: "Se acontecer A, faça B"; "Exceto quando o cliente for desse tipo"; "Se o sistema apresentar esse erro, espere alguns minutos e tente novamente"; "Esse relatório parece mostrar X, mas nesse caso específico você precisa consultar a outra tabela"; "Não faça isso antes das 17h porque o fechamento ainda não terminou".
Muitas dessas regras nunca foram formalmente escritas. Elas foram aprendidas, depois repetidas e finalmente passaram a fazer parte da memória de alguém.
O conhecimento mais importante de uma operação muitas vezes está justamente naquilo que nunca foi documentado.
É por isso que algumas empresas possuem uma quantidade impressionante de documentação e, mesmo assim, continuam dependendo de poucas pessoas para funcionar.
Quando uma pessoa vira parte da infraestrutura
Existe um tipo curioso de dependência dentro das empresas. Não aparece no organograma, no inventário de sistemas nem no orçamento de infraestrutura: é a dependência de uma pessoa específica.
Todo mundo sabe quem procurar quando determinado relatório está errado, quem sabe corrigir aquela integração, quem entende por que determinado campo não pode ser alterado, quem conhece a sequência correta para executar uma rotina ou quem sabe qual das três planilhas é a verdadeira.
Essa pessoa pode ser extremamente competente, e o problema não é ela saber — o problema é o conhecimento existir apenas nela.
Nesse cenário, uma pessoa deixa de ser apenas parte da equipe e começa, na prática, a funcionar como um componente da arquitetura. Se ela não está disponível, a operação perde uma capacidade. Se ela sai da empresa, perde-se uma parte da memória operacional. Muitas vezes, ninguém percebe o tamanho dessa dependência até o dia em que ela deixa de estar disponível.
O problema não é ter pessoas indispensáveis
É importante fazer uma distinção: nenhuma empresa deveria tentar transformar todo conhecimento humano em documentação. Experiência, julgamento, criatividade e capacidade de lidar com situações novas não são simplesmente arquivos que podem ser armazenados em um banco de dados.
O objetivo não é substituir pessoas, mas separar aquilo que depende de experiência e julgamento daquilo que depende apenas de memória e repetição:
- Se uma pessoa precisa lembrar uma regra que poderia estar explicitamente registrada, existe uma oportunidade de melhorar o sistema.
- Se uma pessoa precisa repetir manualmente uma sequência previsível de tarefas, existe uma oportunidade de automação.
- Se uma pessoa precisa responder dez vezes por dia à mesma pergunta porque ninguém sabe onde encontrar a resposta, existe uma oportunidade de organizar o conhecimento.
Se uma situação exige interpretação, negociação ou julgamento diante de algo novo, é exatamente aí que uma pessoa deve continuar envolvida.
Automatizar memória é diferente de automatizar conhecimento.
Uma empresa também precisa de uma memória
É aqui que a questão deixa de ser apenas documental e começa a se aproximar da engenharia. Sistemas possuem estado, bancos possuem dados, pipelines possuem logs, APIs possuem contratos e código possui regras. Uma empresa também possui uma espécie de estado: decisões, processos, responsabilidades, definições, exceções e relações entre as coisas.
Quando essa estrutura não é registrada de maneira acessível, ela precisa ser reconstruída toda vez que alguém precisa entendê-la. E reconstruir conhecimento é caro.
Uma pessoa interrompe outra, uma equipe procura em pastas, alguém abre uma planilha antiga, outra consulta um sistema e depois alguém pergunta no grupo de mensagens. Aos poucos, minutos viram horas. Não porque a resposta seja necessariamente difícil, mas porque o caminho até a resposta não está organizado.
Conhecimento precisa de estrutura
Talvez seja por isso que simplesmente "colocar tudo em um lugar" raramente resolve o problema. Uma pasta com dez mil arquivos não é necessariamente uma base de conhecimento, um data lake cheio de tabelas não é necessariamente governança, e um dashboard cheio de indicadores não é necessariamente compreensão.
Armazenamento resolve a pergunta:
"Onde está o arquivo?"
Já o conhecimento organizado precisa responder perguntas muito mais interessantes:
- O que esta informação significa?
- De onde ela veio?
- Qual processo produz esse dado?
- Quem é responsável por ele?
- Qual regra está por trás desse processo?
- Quando essa regra não se aplica?
- O que depende de quê?
- Onde encontro o detalhe original quando precisar investigar?
A diferença é sutil, mas fundamental: organizar arquivos é organizar armazenamento; organizar conhecimento é organizar significado.
Da memória humana para sistemas compreensíveis
Isso também muda a forma como pensamos sobre sistemas. Um sistema bem projetado não deveria apenas executar uma regra, mas tornar possível entender que a regra existe, de onde ela veio e como se relaciona com o restante da operação.
Uma tabela não deveria ser apenas um conjunto de colunas, um indicador não deveria ser apenas um número, uma API não deveria ser apenas um endpoint e uma automação não deveria ser apenas um processo que roda sozinho. Por trás de cada um desses elementos existe uma pergunta humana:
"O que isso significa?"
É aí que dados, documentação, governança e arquitetura começam a se encontrar — não como disciplinas isoladas, mas como diferentes maneiras de preservar e tornar acessível a estrutura de uma operação.
O teste mais simples
Existe uma forma simples de descobrir se determinado conhecimento está realmente preservado: escolha uma atividade importante da empresa e imagine que a pessoa que normalmente responde por ela não está disponível. Agora faça a pergunta:
"Outra pessoa conseguiria entender o suficiente para executar, investigar ou tomar uma decisão sem precisar reconstruir tudo do zero?"
Se a resposta for não, talvez o problema não seja falta de informação, mas sim falta de estrutura. A empresa possui os pedaços, mas não possui uma representação compreensível do todo.
Conhecimento não é guardar tudo
Existe uma ironia nisso tudo. No artigo anterior, falamos sobre abstração: compreender exige descartar detalhes que não são necessários para determinado propósito. Aqui aparece o outro lado do problema.
Uma empresa precisa abstrair para operar, mas precisa preservar os detalhes certos para investigar. Um bom sistema faz as duas coisas: ele apresenta uma visão simples quando a simplicidade é suficiente, mas não destrói o caminho até a realidade quando alguém precisa investigar.
Um gestor pode precisar apenas de um indicador, um analista pode precisar conhecer sua definição, um engenheiro pode precisar descobrir sua origem e, em uma investigação mais profunda, alguém pode precisar chegar ao registro original que produziu aquele número.
Conhecimento bem estruturado não elimina a complexidade da realidade. Ele organiza o caminho para atravessá-la.
Talvez a verdadeira pergunta seja outra
Quando uma empresa diz que precisa de mais documentação, talvez esteja tentando resolver um problema mais profundo: uma forma melhor de preservar o conhecimento. Quando diz que precisa de um novo dashboard, talvez esteja tentando encontrar uma representação mais compreensível da operação.
Quando diz que precisa de uma IA para responder perguntas internas, talvez esteja tentando tornar encontrável aquilo que hoje está espalhado entre documentos, sistemas e pessoas. E quando diz que precisa automatizar um processo, talvez esteja tentando transformar uma sequência conhecida e repetitiva em uma regra que o sistema possa executar.
Em todos esses casos, a tecnologia pode ser diferente, mas o problema fundamental é o mesmo:
Como transformar o conhecimento necessário para operar em algo que a empresa consiga preservar, compreender e utilizar?
Uma empresa que consegue lembrar sem depender da memória de alguém
Uma das formas mais interessantes de pensar em maturidade operacional é esta:
Quanto daquilo que a empresa precisa saber para funcionar está acessível sem depender da memória de uma pessoa específica?
Isso não significa transformar pessoas em componentes substituíveis, mas sim dar a elas uma infraestrutura de conhecimento que permita que sua experiência seja usada para pensar, decidir e criar — e não apenas para lembrar onde alguma coisa está.
Uma empresa madura não é aquela que documentou tudo, mas sim aquela que sabe o que precisa ser preservado, em que nível de detalhe e como alguém poderá encontrar e compreender isso quando precisar.
O objetivo da governança não é fazer a empresa lembrar de tudo. É garantir que ela não esqueça aquilo que não pode perder.