Resposta direta
A tabela precisa de um dono nomeado e de um registro de uso antes de qualquer alteração. O diagnóstico começa por separar quem consulta, quem altera e quais rotinas param quando o registro falha. Sem esse mapa, a ausência de dono é confundida com baixo uso, e a desativação pode interromper processos que não aparecem na documentação. O dono não precisa ser quem digita os valores; precisa responder pelo critério, pela atualização e pelas exceções. Quando ninguém assume, o caminho é congelar mudanças, documentar os campos, indicar um substituto e só então decidir entre manter, incorporar a outro cadastro ou encerrar.
- Objetivo
- Diagnosticar
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Separa tabela órfã de tabela apenas pouco documentada por uso comprovado, impacto operacional e responsabilidade definida.
O uso que aparece no sistema
O primeiro indício não é a opinião das áreas, mas o rastro deixado pela tabela. Consultas registradas, rotinas agendadas, exportações recorrentes e cópias em planilhas mostram quem consome o dado. Quando não há log, a verificação passa por entrevistas e por busca de termos nos relatórios e nos jobs. Cada uso encontrado deve ser associado a um processo e a uma pessoa que sente a falha.
Uso não é o mesmo que importância. Uma tabela pode ter poucos acessos e alimentar uma regra usada por muitas operações. Também pode ter muitos acessos e não sustentar decisão alguma. A distinção vem do que deixa de funcionar quando o dado está ausente, atrasado ou incorreto, e não da frequência de consulta.
Quem responde pelo conteúdo
Um dono de tabela de apoio responde por três coisas: o significado dos campos, a regra de atualização e a decisão sobre exceções. Não é necessariamente quem opera a planilha nem quem pediu o cadastro. A indicação precisa ser registrada com nome e com o processo sob responsabilidade, para que a ausência não volte na próxima mudança.
Quando a tabela serve a mais de uma área, a responsabilidade pode ser compartilhada na definição e única na aprovação. O arranjo funciona melhor com um responsável pelo dado e outro pelo uso. Sem essa separação, qualquer alteração vira negociação entre áreas e o registro envelhece por falta de decisão.
O que o levantamento não resolve
Encontrar usos e nomear responsáveis não corrige o conteúdo da tabela. Campos sem padrão, valores vencidos e regras informais continuam existindo. O diagnóstico também não cria autoridade: se a pessoa indicada não pode recusar mudanças ou interromper uma rotina, o dono existe apenas no papel.
Em tabelas usadas por uma única pessoa, com baixo impacto e substituto evidente, o esforço de formalizar pode ser maior que o risco. O mesmo vale quando o dado é histórico e não alimenta decisão corrente. Nesses casos, o limite é reconhecer que a tabela pode ser encerrada, e não transformá-la em projeto de governança.
Recurso prático
Índice de dependência operacional
ID = (RF ÷ RT) × 100
- RF
- rotinas
- Rotinas críticas que falham ou produzem dado incorreto quando a tabela está indisponível ou desatualizada.
- RT
- rotinas
- Rotinas que consultam, copiam ou exportam a tabela, incluindo as automatizadas e as manuais.
Acesso não é dependência: uma tabela com poucas consultas pode ser a única fonte de uma regra usada por rotina automatizada. Se RT for zero, a ausência de registro não prova que a tabela pode ser desligada.
Sobre o que está escrito aqui
Conceitos relacionados: tabela de domínio · responsável pelo dado · regra de atualização · dependência operacional · rastro de uso. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Projeto de implementação, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- Integrações, sistemas e qualidade de dados — Página central do tema
- Migração de dados: o que conferir antes e depois — migração sem conferência
- APIs e integração: o que perguntar antes de c… — sistema sem integração
Páginas relacionadas
O mesmo problema em outro objetivo
- Tabela de apoio sem dono: como atribuir responsabilidade — Organizar um processo
- Tabela de apoio sem dono: como comparar alternativas — Comparar alternativas
- Tabela de apoio sem dono: como medir o que ninguém acompanha — Explicar medição
- Tabela de apoio sem dono: como implantar com responsabilidade — Orientar implementação
- Tabela de apoio sem dono: o que exigir no contrato — Orientar avaliação e contratação
Outras leituras em Integrações, sistemas e qualidade de dados
- Sistema antigo só de histórico: o que sai da operação — O que ainda precisa rodar no sistema antigo, o que passa a ser consulta histórica e quem responde pela leitura de cada dado.
- Cliente duplicado entre áreas: quando vale contratar solução — O que avaliar antes de contratar solução para cliente duplicado entre áreas, o que é decisão de dado e o que é decisão de responsabilidade.
- Planilhas paralelas: sinais de dependência na rotina — Critérios para identificar planilhas que substituíram o sistema oficial, avaliar riscos operacionais e mapear a dependência de pessoas específicas.
- Dados desatualizados: o que precisa estar em dia — A regra das três colunas — dado, frequência aceitável, responsável — e o erro de tratar tudo como crítico.
- Campo obrigatório sem uso: manter, remover ou treinar — O que verificar quando um campo obrigatório é criado e ninguém preenche: origem, responsável, uso real e critério para manter, remover ou treinar.