Existem duas formas de começar um programa de governança de dados. Você pode partir de um framework, deduzir quais capacidades faltam e construir um roadmap até um estado-alvo. Ou pode partir das coisas que visivelmente estão custando dinheiro e tempo à organização, resolver algumas delas com governança e deixar o framework se preencher por trás.
A primeira abordagem produz documentos melhores. A segunda produz programas que sobrevivem à primeira revisão de orçamento.
Isto não é um argumento contra frameworks — uso o DAMA DMBOK constantemente, e um modelo de capacidades é a ferramenta certa para planejar o segundo ano. Mas um programa de governança precisa conquistar sua credibilidade antes de poder gastá-la, e a única moeda que alguém de fora do time de dados reconhece é um problema de que já reclamou, agora resolvido.
Então comece pela dor. Veja como encontrá-la e o que a governança pode realmente fazer com cada variedade.
Os seis pontos de dor que justificam um programa
Ao longo de vários trabalhos, quase tudo que as organizações descrevem como "um problema de dados" se resolve em um de seis padrões.
Silos de dados
Departamentos guardam sua própria cópia de informação compartilhada, porque em algum momento obtê-la de forma central foi mais difícil que reconstruí-la localmente. O sintoma visível é o esforço duplicado; o sintoma caro é que as cópias divergem e ninguém sabe dizer qual está certa.
A resposta de governança não é "consolidar tudo" — isso é um programa de plataforma de vários anos, não um ato de governança. É nomear a fonte autoritativa por entidade compartilhada, declarar as outras derivadas e publicar essa decisão em algum lugar localizável. Um catálogo de dados ajuda, mas a decisão importa mais que a ferramenta.
Problemas de qualidade
Registros estão incompletos, defasados, duplicados ou errados. Todo mundo sabe, e esse conhecimento vive em contornos: o analista que sempre filtra as contas de teste, o time de operações que redigita endereços antes de despachar.
A governança contribui com a parte que a engenharia não consegue fornecer: quais atributos importam o bastante para serem medidos, qual tolerância é aceitável, quem aceita o risco quando ela é rompida e quem responde pela correção. Sem essas quatro respostas, as ferramentas de qualidade de dados produzem painéis que medem tudo e não mudam nada.
Falta de propriedade clara
Ninguém responde, então os problemas são discutidos e não resolvidos. É o ponto de dor que mais confiavelmente indica uma lacuna real de governança e não uma técnica, e também o mais barato de atacar: nomear um proprietário de dados por domínio custa uma decisão, não um orçamento.
O teste que uso num primeiro workshop: nomeie o responsável pelos seus cinco principais domínios. Se levar mais de um minuto, ou produzir o nome de um time em vez de uma pessoa, aí está o seu achado.
Definições inconsistentes
Dois times reportam "clientes ativos" e os números diferem em onze por cento, porque um conta um acesso nos últimos 90 dias e o outro conta qualquer conta sem cancelamento. Os dois são defensáveis. Nenhum é autoritativo.
É para isso que existe um glossário de negócio, embora o glossário seja o artefato e não a solução. A solução é que alguém tenha autoridade para aprovar uma definição e que os relatórios sejam alterados para bater com ela.
Dados difíceis de alcançar
O acesso leva três semanas e dois escalonamentos, então as pessoas constroem cópias na sombra. Controles de acesso restritivos sem um fluxo em volta não reduzem risco; eles o transferem para planilhas que ninguém pode auditar.
Aqui o trabalho da governança é um esquema de classificação, uma regra de aprovação permanente por nível e um nível de serviço sobre a decisão. A maior parte do atrito de acesso não é um requisito de segurança: é a ausência de alguém autorizado a dizer sim.
Exposição de conformidade e segurança
Há dados sensíveis em lugares que ninguém mapeou, retidos por mais tempo do que qualquer política permite e copiados para ambientes com controles mais fracos. Isso normalmente é descoberto numa auditoria e não num incidente, que é o desfecho bom.
A governança fornece classificação de dados, regras de retenção com gatilho e um proprietário nomeado para cada domínio com informação pessoal. O trabalho de engenharia deriva dessas decisões e não pode precedê-las.
| Ponto de dor | O que custa a você | O remédio de governança |
|---|---|---|
| Silos de dados | Esforço duplicado, cópias divergentes, disputas sem fim | Fonte autoritativa por entidade, publicada e aplicada |
| Problemas de qualidade | Retrabalho, reconciliação manual, desconfiança no reporting | Lista de elementos críticos, tolerâncias, proprietário responsável |
| Falta de propriedade | Problemas discutidos e nunca encerrados | Uma pessoa responsável por domínio |
| Definições inconsistentes | Números contraditórios na mesma reunião | Definições aprovadas com um árbitro |
| Acesso deficiente | Dados na sombra, análise lenta, cópias não auditáveis | Níveis de classificação com regras de aprovação permanentes |
| Exposição regulatória | Achados de auditoria, multas, projetos de remediação | Classificação, retenção, propriedade nomeada de dados pessoais |
Por que começar pela dor ganha de começar pelo framework
Duas coisas fazem a diferença na prática.
A primeira é que um ponto de dor vem com patrocinador incluído. Alguém já se importa, já escalou e já vai responder por você se aquilo for resolvido. Lacunas de capacidade identificadas a partir de um framework não têm essa clientela: você precisa fabricar o interesse, o que é boa parte da razão pela qual programas de governança passam seus primeiros seis meses em comunicação interna.
A segunda é que o remédio é verificável. "Reduzir o tempo de resolução de uma disputa de definições de três semanas para três dias" aconteceu ou não aconteceu. "Alcançar o nível 3 em gestão de metadados" é uma afirmação que só o time de dados pode avaliar, o que significa que é uma afirmação em que só o time de dados acredita.
Encontrando o seu em duas semanas
Você não precisa de uma avaliação de maturidade para localizar a dor. Precisa de quatro entradas e quinze dias.
Entreviste quem reclama. De dez a quinze conversas, meia hora cada, distribuídas entre perfis de negócio e técnicos. A pergunta que rende melhores respostas não é "quais são seus problemas de dados?", e sim "o que você fez na semana passada que não deveria ter tido de fazer?". As pessoas descrevem contornos com riqueza e problemas em abstrato.
Leia os escalonamentos. O que sua organização usa para incidentes, tickets ou achados de auditoria: puxe os últimos doze meses e classifique. A maioria descobre que quatro ou cinco causas-raiz explicam a maior parte, e que ao menos uma se repete trimestralmente há anos sem que ninguém a assuma.
Amostre os dados. Pegue seus três conjuntos mais usados e rode um perfilamento básico: completude por atributo, taxa de duplicados sobre a chave natural, distribuição de valores contra o esperado, frescor contra o calendário declarado. Dois dias disso convertem "a qualidade é ruim" num número, e número é o que se financia.
Pesquise os consumidores. Curta e quantitativa: quanto você confia neste relatório, quanto tempo leva para obter os dados de que precisa, com que frequência você reconstrói algo que já existe. Dez perguntas, distribuição para o time todo. O valor está na dispersão: um departamento que não confia em nada é um problema diferente de uma organização que confia em tudo igualmente pouco.
Transformando achados em backlog
Desse exercício vão sair quinze problemas, e a tentação é escrever um roadmap que ataque todos. Pontue-os em vez disso, em três eixos:
- Frequência: de quanto em quanto tempo morde. Semanal ganha de anual.
- Custo: o que consome em horas, retrabalho ou risco. Se você não consegue estimar, a calculadora do custo dos dados ruins leva você a uma ordem de magnitude defensável.
- Atacável por governança: se uma decisão resolve ou se é preciso uma migração de plataforma. Seja honesto aqui. A dor que exige dezoito meses de engenharia é real, mas não vai demonstrar nada neste trimestre.
Pegue os dois ou três que pontuam alto nos três eixos e faça-os primeiro. Publique o número do antes e do depois. E use esse resultado para pedir o trabalho estrutural.
Como isso fica quando funciona
Um varejista com dados de produto inconsistentes. Sistemas regionais e a plataforma de e-commerce divergiam em descrições, preços e estoque. Clientes viam preços errados; pedidos eram cancelados depois da compra. O remédio foi gestão de dados mestres de produto — mas o ato de governança que tornou isso possível foi decidir qual sistema era autoritativo para cada atributo e conseguir que o diretor comercial fosse dono dessa decisão. O projeto de MDM havia sido proposto duas vezes antes e falhado nas duas por exatamente essa pergunta.
Uma instituição financeira com dados sensíveis não mapeados. Uma auditoria interna encontrou dados de cliente em sistemas fora do alcance de qualquer controle, sem proprietário responsável. O remédio foi classificação, captura de linhagem e propriedade nomeada do domínio de cliente. O que fez isso pegar foi que o achado de auditoria deu prazo à pergunta de propriedade, que é a única coisa que converte com confiabilidade uma recomendação de governança numa decisão de governança.
A armadilha a evitar
Existe um modo de falha na governança que começa pela dor, e vale nomeá-lo: o ponto de dor de vaidade. Alguém sênior tem uma queixa específica — normalmente sobre um relatório que usa pessoalmente — e ela se torna a primeira iniciativa do programa porque vem com patrocínio.
Às vezes está tudo bem. Muitas vezes é um problema estreito que afeta uma pessoa, e resolvê-lo não ensina nada à organização nem prova nada sobre o valor da governança. Se o tema favorito de um executivo não pontua bem em frequência e custo, resolva discretamente como favor e escolha outra coisa como caso demonstrativo.
Por onde seguir
Diagnostique, pontue, resolva duas coisas, publique o resultado. Esse é um primeiro trimestre que garante o segundo.
Quando você já sabe o que dói e por quê, as perguntas estruturais ficam respondíveis: quais domínios precisam de proprietário, quais decisões precisam de casa e quanta governança sua organização consegue de fato sustentar. Como construir um modelo operacional de governança de dados cobre esse passo seguinte, e Introdução aos fundamentos de um programa de governança de dados expõe os fundamentos em ordem. Se preferir começar com uma leitura estruturada de onde você está nas quatro dimensões, a avaliação de maturidade leva cerca de dez minutos.