Quanto vale uma informação que você não consegue encontrar?
Não estou falando de dados que não existem. Estou falando de dados que existem em três lugares diferentes, com três versões diferentes, e ninguém sabe qual é a verdadeira.
Se você já abriu uma planilha de clientes e encontrou o mesmo nome escrito de dois jeitos, com dois telefones diferentes e uma coluna "observações" que diz "ver com a Patrícia" — você sabe do que estou falando.
Esse é o sintoma mais comum de uma empresa sem Dados modelados. E é exatamente onde a Ontologia Operacional começa.
O Que São Dados na Ontologia Operacional
No artigo anterior, apresentamos a Tríade D+L+A — os três componentes atômicos de qualquer operação. Dados são a primeira camada. Sem ela, as outras duas não funcionam.
Mas quando dizemos "dados", não estamos falando de planilhas, tabelas ou bancos de dados. Estamos falando de algo mais fundamental: a representação estruturada da realidade do seu negócio.
Essa representação tem três componentes:
Entidades — O Que Existe
Uma entidade é qualquer objeto relevante para a sua operação. Cliente. Pedido. Fornecedor. Contrato. Produto. Conta bancária. Transação.
Parece óbvio. Mas a pergunta real é: quais são as entidades críticas do seu negócio?
Críticas. Não todas. Não as que você gostaria de ter. As que, se você não mapear, a operação trava.
Uma representante comercial precisa de: Clientes, Pedidos, Fornecedores e Títulos a Receber. Não precisa de "Campanhas de Marketing" nem de "Segmentos de Mercado". Esses podem existir um dia — mas não são o que faz a operação girar hoje.
A maioria das empresas erra aqui por excesso, não por falta. Criam dezenas de categorias, campos e classificações que ninguém preenche. E aí culpam a equipe por "não alimentar o sistema".
O sistema não é alimentado porque pediu informação demais. A culpa é do sistema, não da equipe.
Atributos — Como É
Cada entidade tem propriedades que a descrevem. Um Cliente tem nome, telefone, segmento, status. Um Pedido tem data, valor, itens, forma de pagamento.
Aqui mora outra armadilha clássica: campos opcionais demais. Quando tudo é opcional, nada é confiável. Se o campo "segmento" do cliente está vazio em 70% dos registros, ele não é um atributo — é uma decoração.
A regra é simples: se o atributo não é usado para tomar decisão ou gerar ação, ele não deveria existir.
Um campo que ninguém preenche consome mais do que espaço em disco. Ele consome confiança. Cada campo vazio é um sinal de que o sistema não é levado a sério. E quando o sistema não é levado a sério, as pessoas voltam para o WhatsApp e a planilha paralela.
Fatos — O Que Aconteceu
Fatos são ocorrências datadas e rastreáveis. O cliente comprou em 15/03. O pagamento atrasou 8 dias. A proposta foi aceita após 3 follow-ups.
Fatos são diferentes de atributos. O atributo diz como algo é agora. O fato diz o que aconteceu quando. Um é foto. O outro é filme.
Sem fatos registrados, você não tem história. Sem história, você não tem padrão. Sem padrão, cada decisão é tomada do zero — como se fosse a primeira vez.
É por isso que o vendedor com 15 anos de casa "sabe" que o cliente X sempre atrasa. Ele tem os fatos na memória. Mas quando ele sai, o fato vai junto.
O Problema Real: Não É Falta de Dados
A maioria das PMEs não sofre de escassez de dados. Sofre de dispersão.
Os dados existem. Estão no CRM que ninguém atualiza, na planilha que o gerente criou por conta própria, nas mensagens do WhatsApp que só uma pessoa tem acesso, no caderno que fica na gaveta da recepção.
Cada cópia cria uma versão. Cada versão diverge. E quando você precisa de uma resposta, o caminho mais rápido é perguntar para alguém que "sabe de cabeça" — o que funciona até essa pessoa estar de férias, doente ou desligada.
Esse cenário tem um nome técnico: ausência de Single Source of Truth (fonte única de verdade). E tem uma consequência prática: toda decisão baseada nesses dados carrega um risco invisível de estar errada.
Como a Ontologia Resolve Isso
O mapeamento ontológico faz três coisas:
Primeiro, nomeia. Identifica quais são as entidades reais do negócio. Não as que você acha que deveria ter — as que existem de fato na operação. Se você não tem processo de follow-up, não crie a entidade "Follow-up". Mapeie o que é, não o que você gostaria que fosse.
Segundo, estrutura. Define quais atributos cada entidade precisa ter — e quais não precisa. Cada campo deve justificar sua existência respondendo: "que decisão ou ação depende desse campo?" Se a resposta for "nenhuma", o campo sai.
Terceiro, unifica. Estabelece uma fonte única de verdade. Não importa se o dado entra pelo WhatsApp, pelo dashboard ou por uma planilha importada. Ele converge para o mesmo lugar, com o mesmo formato, validado pelas mesmas regras.
Isso é o que chamamos de Closed World Assumption: se não está no sistema, não existe. Pode parecer radical, mas é o que torna possível construir qualquer automação confiável em cima.
Um Exemplo Real
Um cliente nosso queria organizar suas finanças pessoais. Casal, gastos separados e compartilhados, múltiplas fontes de dados — extrato bancário, notas fiscais, gastos do dia a dia.
Antes de escrever uma linha de código, mapeamos as entidades:
- Transação — valor, data, categoria, método de pagamento, origem, proprietário
- Categoria — hierárquica (alimentação/supermercado, transporte/combustível)
- Proprietário — quem registrou (identificado automaticamente pelo número de WhatsApp)
- Estabelecimento — mapeamento que aprende: "GERÔNIMO SP" = padaria, "VIVO-SP" = assinatura
Quatro entidades. Não quarenta. O sistema inteiro roda sobre isso.
No primeiro dia, o casal registrou 23 transações — por texto, por voz, por foto de nota fiscal e por PDF de extrato bancário. Quatro canais diferentes, uma fonte de verdade. A esposa começou a usar sem nenhum treinamento.
Mas o detalhe que importa: quando o marido importou o extrato do banco, o sistema já sabia classificar os estabelecimentos que apareceram — porque cada transação registrada manualmente havia ensinado o mapeamento. Quanto mais dados entram, menos trabalho manual existe.
Isso não é mágica. É o efeito de dados bem modelados.
O Teste dos Dados
Quer saber se os Dados do seu negócio estão modelados? Responda três perguntas:
- Você consegue listar as 5 entidades mais importantes da sua operação em 30 segundos? Se não consegue, elas não estão claras nem pra você.
- Existe um lugar único onde cada entidade é a versão verdadeira? Se o CRM diz uma coisa e a planilha diz outra, você não tem fonte de verdade — tem duas fontes de dúvida.
- Os dados que entram no sistema são usados para tomar decisão? Se você coleta dados que ninguém consulta, está pagando o custo sem colher o benefício.
Se respondeu "não" para qualquer uma, a primeira camada da sua operação tem uma fissura. E tudo que você construir em cima — regras, automações, IA — vai herdar essa fragilidade.
Próximo Artigo
Dados são a fundação. Mas fundação sem estrutura é só um terreno. No próximo texto da série, vamos falar sobre Lógica — a gramática do negócio: como as regras que existem na sua cabeça se tornam regras que o sistema executa.
Se você leu até aqui e percebeu que seus dados estão dispersos em três planilhas e dois WhatsApp — esse é exatamente o problema que resolvemos. Em uma sessão de diagnóstico, mapeamos as entidades críticas do seu negócio e mostramos onde a dispersão está custando dinheiro.
