1ªEtapa – Diagnóstico de visibilidade e maturidade do ambiente de dados
Documento único consolidado — contém o enunciado completo da 1ª etapa, os três entregáveis (Diagnóstico, Tabela Comparativa e Parecer) e o checklist final de validação.
Enunciado
Descrição do projeto
A Hermex Log é uma empresa de logística de médio porte que cresceu por aquisições de transportadoras regionais, resultando em quatro sistemas herdados e desconectados: comercial (contratos e clientes), financeiro (faturamento e contas a receber), operações (entregas e rotas) e RH (folha e motoristas).
A diretoria identificou problemas recorrentes:
- Entregas em endereços errados
- Divergência de clientes ativos entre comercial e financeiro
- Duplicidade de cadastros de motoristas
- Ausência de consentimento LGPD para dados pessoais de clientes
- Acessos indevidos a planilhas salariais em pastas de rede sem restrição
A equipe de governança de dados recém-criada foi encarregada de um diagnóstico completo e um plano de ação cobrindo cinco frentes: catálogo de dados, qualidade, priorização de dados críticos, segurança e gestão de dados mestres — ao longo de quatro etapas, culminando na comunicação das recomendações à liderança.
Pergunta-chave
“Qual é o nível de visibilidade e maturidade do ambiente de dados da Hermex Log, e quais são os fatores que contribuem para a invisibilidade dos dados?”
Missões da 1ª etapa
- Analise o cenário descrito e identifique os fatores que contribuem para a falta de visibilidade dos dados na Hermex Log (considere silos de informação, ausência de metadados contextualizados e falta de processos de governança).
- Utilize o ChatGPT como copiloto: elabore um prompt estruturado pedindo que a IA organize os problemas identificados em categorias (técnicos vs. de negócio) e sugira quais perguntas o catálogo de dados deveria responder neste contexto. Revise criticamente a resposta da IA, ajustando o que não se aplica ao cenário.
- Avalie em qual estágio de maturidade a Hermex Log se encontra em relação a catálogos de dados (considerando as gerações de catálogos e a sequência inventário → catálogo → Data Marketplace) e justifique sua avaliação.
- Proponha qual perfil de ferramenta de catálogo seria mais adequado para o momento da empresa (plataforma de governança corporativa estruturada, ferramenta com foco em adoção e colaboração, plataforma integrada de dados ou solução de código aberto), argumentando pelo problema a resolver — e não pela marca.
Entregáveis sugeridos
- Documento de diagnóstico com mapeamento dos fatores de invisibilidade e suas consequências.
- Tabela comparativa distinguindo problemas técnicos (inventário) de problemas de negócio (catálogo/glossário).
- Parecer sobre maturidade e recomendação de perfil de ferramenta, com justificativa baseada no contexto da empresa.
O que caracteriza uma boa análise
- Distingue claramente falta de dados de falta de visibilidade, demonstrando compreensão de que o problema não é ausência de informação, mas ausência de contexto.
- Relaciona os fatores de invisibilidade a consequências concretas para o negócio da Hermex Log (retrabalho, decisões conflitantes, entregas erradas).
- Justifica a recomendação de ferramenta pelo problema real da empresa, não pela liderança de mercado.
Ferramentas sugeridas: ChatGPT, Excel, draw.io ou Lucidchart
Dicas para a análise da 1ª etapa:
- Pense na analogia do restaurante: a Hermex Log tem os ingredientes na cozinha, mas tem cardápio? Tem prato pronto para servir? Isso ajuda a posicionar a maturidade.
- Ao usar o ChatGPT, não aceite a primeira resposta como definitiva. Peça que a IA justifique cada categorização e questione se algum item foi classificado incorretamente.
- Considere que a empresa cresceu por aquisições — isso tem implicações diretas sobre a origem dos silos e a heterogeneidade dos sistemas.
1 Documento de Diagnóstico — Fatores de Invisibilidade e Consequências
1.1 Sumário Executivo
A Hermex Log possui dados em abundância — distribuídos em quatro sistemas herdados e inúmeras planilhas paralelas — mas carece de visibilidade sobre eles. O problema central não é a ausência de informação, e sim a ausência de contexto, padronização e responsabilização. Este diagnóstico mapeia os fatores que geram essa invisibilidade e suas consequências concretas para o negócio.
1.2 Contexto
A Hermex Log é uma empresa de logística de médio porte que cresceu por aquisições de transportadoras regionais. Esse histórico resultou em:
- Quatro sistemas herdados e desconectados: comercial (contratos e clientes), financeiro (faturamento e contas a receber), operações (entregas e rotas) e RH (folha e motoristas).
- Planilhas auxiliares mantidas por cada área, sem integração.
- Ausência de documentação centralizada sobre significado de campos, responsáveis por dados ou confiabilidade das informações.
- Vocabulários divergentes: o mesmo conceito (cliente) recebe nomes diferentes em cada sistema —
COD_CLI(comercial),ID_CLIENTE(financeiro) eCLIENTE_COD(operações). - Nenhuma fonte oficial definida: ninguém sabe ao certo qual base é a autoritativa.
1.3 Fatores de Invisibilidade Identificados
1.3.1 Silos de Informação
Evidências no cenário:
- Quatro sistemas herdados e desconectados, um por área.
- Crescimento por aquisições — cada transportadora trouxe seus próprios sistemas e vocabulários.
- Cada área mantém suas próprias planilhas auxiliares.
- Nenhuma integração entre sistemas ou áreas.
Consequências para o negócio:
- Divergência de clientes ativos entre comercial e financeiro.
- Duplicidade de cadastros de motoristas.
- Retrabalho operacional constante.
- Decisões conflitantes entre áreas que deveriam trabalhar com a mesma informação.
1.3.2 Ausência de Metadados Contextualizados
Evidências no cenário:
- O comercial usa
COD_CLI, o financeiro usaID_CLIENTEe operações registraCLIENTE_COD— sem que se saiba se representam a mesma coisa. - Não há documentação centralizada sobre o significado dos campos.
- Não há glossário de dados nem definição de termos de negócio.
- Ninguém sabe qual base é a “oficial”.
Consequências para o negócio:
- Entregas realizadas em endereços errados.
- Impossibilidade de cruzar dados entre áreas.
- Decisões baseadas em informações inconsistentes.
- Perda de confiança no dado como insumo para decisão.
1.3.3 Falta de Processos de Governança
Evidências no cenário:
- Não há responsável definido por cada dado (sem data owners).
- Ausência de consentimento LGPD para dados pessoais de clientes.
- Acessos indevidos a planilhas salariais em pastas de rede sem restrição.
- Equipe de governança de dados recém-criada, ainda sem processos estabelecidos.
Consequências para o negócio:
- Risco legal e exposição a multas por violação da LGPD.
- Vazamento de informações sensíveis (salários).
- Exposição indevida de dados pessoais de clientes e motoristas.
- Falta de accountability sobre a qualidade dos dados.
1.4 Quadro-Resumo dos Fatores e Consequências
| Eixo | Evidência no cenário | Consequência para o negócio |
|---|---|---|
| Silos de informação | 4 sistemas desconectados; planilhas paralelas por área; crescimento por aquisições | Divergência de clientes ativos; duplicidade de motoristas; retrabalho; decisões conflitantes |
| Ausência de metadados contextualizados | COD_CLI vs ID_CLIENTE vs CLIENTE_COD; sem glossário; sem base oficial |
Entregas em endereços errados; impossibilidade de cruzar dados; decisões inconsistentes; perda de confiança |
| Falta de processos de governança | Sem data owners; sem consentimento LGPD; planilhas salariais expostas | Risco legal; vazamento de dados; exposição indevida; falta de accountability |
1.5 Ponto-Chave do Diagnóstico
⚠️ O problema não é falta de dados. Os dados existem — estão nos quatro sistemas, nas planilhas, nos cadastros. O problema é falta de contexto, padronização e responsabilização.
🍳 Analogia do restaurante:
- 🍳 A Hermex tem os ingredientes (dados brutos nos sistemas e planilhas).
- 📋 Mas não tem cardápio (catálogo/glossário que explica o que cada dado significa).
- 🍽️ E não tem prato pronto (dado confiável e padronizado para decisão).
1.6 Conclusão do Diagnóstico
A Hermex Log apresenta um cenário de invisibilidade generalizada dos dados, causada por três fatores interdependentes:
- Silos de informação — consequência direta do crescimento por aquisições, sem esforço de integração semântica posterior.
- Ausência de metadados contextualizados — campos com nomes divergentes e sem documentação de significado.
- Falta de processos de governança — sem responsáveis, sem políticas, sem conformidade LGPD.
Esses fatores se reforçam mutuamente: os silos geram vocabulários divergentes, que por sua vez impedem a criação de metadados unificados, que por sua vez inviabilizam qualquer processo de governança. O resultado é um ambiente onde os dados existem, mas não são confiáveis, compreensíveis ou gerenciáveis.
O primeiro passo para reverter esse cenário não é tecnológico, mas semântico e cultural: construir o inventário de dados, padronizar o vocabulário de negócio e definir responsáveis — tudo isso com engajamento das áreas.
2 Tabela Comparativa — Problemas Técnicos vs. de Negócio
2.1 Critério de Classificação
| Categoria | Foco | Pergunta que responde | Exemplo |
|---|---|---|---|
| Técnico (Inventário) | O que existe, onde está, quem acessa | “O que temos?” | Sistemas, campos, planilhas, acessos |
| Negócio (Catálogo/Glossário) | O que significa, qual é a fonte oficial, quem é o dono | “O que significa?” | Termos, definições, regras, responsáveis |
💡 Insight-chave: o inventário mapeia a existência; o catálogo mapeia o significado. Um não substitui o outro — são complementares.
2.2 Tabela Comparativa Principal
| # | Problema identificado | Categoria | Justificativa |
|---|---|---|---|
| 1 | Quatro sistemas herdados e desconectados | Técnico | Falta de inventário/integração — não se sabe o que existe em cada sistema nem como se relacionam |
| 2 | Planilhas auxiliares mantidas por cada área, sem controle | Técnico | Dados fora dos sistemas oficiais, não inventariados nem rastreados |
| 3 | COD_CLI vs ID_CLIENTE vs CLIENTE_COD |
Negócio | Falta de glossário e padronização semântica — o mesmo conceito recebe nomes diferentes |
| 4 | Ninguém sabe qual base é a “oficial” | Negócio | Falta de definição de fonte autoritativa (data owner) e de regra de precedência |
| 5 | Divergência de clientes ativos entre comercial e financeiro | Negócio | Falta de definição do que é “cliente ativo” — regra de negócio não documentada |
| 6 | Duplicidade de cadastros de motoristas | Ambos ⚠️ | Técnico (deduplicação, chaves de identificação) + Negócio (definição de dados mestres e regras de unicidade) |
| 7 | Entregas em endereços errados | Negócio | Dado de cliente inconsistente entre sistemas — falta de fonte oficial de endereço |
| 8 | Ausência de consentimento LGPD para dados pessoais | Negócio | Falta de processo de governança e accountability sobre dados pessoais |
| 9 | Acessos indevidos a planilhas salariais | Ambos ⚠️ | Técnico (controle de acesso, permissões) + Negócio (política de segurança e classificação de dados) |
| 10 | Ausência de documentação sobre significado dos campos | Negócio | Falta de glossário e metadados de negócio |
| 11 | Ausência de responsáveis definidos por dado (data owners) | Negócio | Falta de accountability — papel organizacional, não técnico |
| 12 | Falta de integração entre sistemas | Técnico | Problema de arquitetura e inventário — os sistemas não se comunicam |
2.3 Itens Ambíguos — Análise Detalhada
🔸 Duplicidade de cadastros de motoristas
| Ângulo | Categoria | Explicação |
|---|---|---|
| Técnico | Inventário | Existem registros duplicados que precisam ser identificados e deduplicados; é preciso mapear chaves de identificação |
| Negócio | Catálogo | É preciso definir o que caracteriza um motorista único (CPF? CNH? matrícula?) e qual é a fonte oficial |
Conclusão: o problema é técnico na execução, mas de negócio na definição. Sem a regra de negócio, a deduplicação técnica não resolve.
🔸 Acessos indevidos a planilhas salariais
| Ângulo | Categoria | Explicação |
|---|---|---|
| Técnico | Inventário | Falta controle de acesso, permissões e inventário de onde estão os dados sensíveis |
| Negócio | Catálogo | Falta política de classificação de dados e definição de quem pode acessar o quê |
Conclusão: a solução técnica (controle de acesso) depende de uma definição de negócio (política de classificação e acesso). Ambos são necessários.
2.4 Quadro-Resumo por Categoria
| Categoria | Quantidade de itens | Principais exemplos |
|---|---|---|
| Técnico (Inventário) | 3 itens exclusivos | Sistemas desconectados; planilhas paralelas; falta de integração |
| Negócio (Catálogo/Glossário) | 7 itens exclusivos | Vocabulários divergentes; fonte oficial indefinida; LGPD; data owners |
| Ambos (Ambíguos) | 2 itens | Duplicidade de motoristas; acessos a planilhas salariais |
📊 Leitura do quadro: a maioria dos problemas é de negócio (7 de 12). Isso reforça o diagnóstico de que o gargalo da Hermex não é tecnológico — é semântico e cultural.
2.5 Perguntas que o Catálogo de Dados Deveria Responder
2.5.1 Categoria Técnica (Inventário)
| # | Pergunta |
|---|---|
| 1 | Quais sistemas contêm dados de clientes, motoristas e contratos? |
| 2 | Onde estão armazenadas as planilhas auxiliares de cada área? |
| 3 | Qual a frequência de atualização de cada base? |
| 4 | Quem tem acesso a cada sistema e planilha? |
| 5 | Existem campos duplicados ou redundantes entre sistemas? |
2.5.2 Categoria de Negócio (Catálogo/Glossário)
| # | Pergunta |
|---|---|
| 1 | O que significa “cliente ativo” para a Hermex? |
| 2 | COD_CLI, ID_CLIENTE e CLIENTE_COD representam a mesma coisa? |
| 3 | Qual é a fonte oficial (autoritativa) para cada dado mestre? |
| 4 | Quem é o responsável (data owner) por cada domínio de dados? |
| 5 | Quais dados pessoais exigem consentimento LGPD e como ele é registrado? |
3 Parecer sobre a maturidade com recomendação de ferramenta e justificativa
3.1 Objetivo do Parecer
Este parecer tem dois propósitos:
- Avaliar o estágio de maturidade da Hermex Log em relação a catálogos de dados, considerando as gerações de catálogos e a sequência Inventário → Catálogo → Data Marketplace.
- Recomendar o perfil de ferramenta mais adequado ao momento da empresa, argumentando pelo problema a resolver — e não pela marca ou liderança de mercado.
3.2 Avaliação de Maturidade
3.2.1 A sequência de maturidade
| Estágio | O que caracteriza | Pergunta que responde |
|---|---|---|
| 1. Inventário | Saber quais dados existem, onde estão, quem é o dono | “O que temos?” |
| 2. Catálogo | Saber o que significam, padronizar campos, glossário, fonte oficial | “O que significa?” |
| 3. Data Marketplace | Dados curados, descobertos e consumidos com autosserviço | “Como consumir com confiança?” |
3.2.2 Onde a Hermex está
Diagnóstico: Nível 0 — abaixo do estágio de Inventário.
| Critério do Inventário | Hermex atende? | Evidência no cenário |
|---|---|---|
| Saber quais dados existem? | ❌ Não | Não há documentação centralizada |
| Saber onde estão? | ⚠️ Parcial | Sabe-se que estão em 4 sistemas, mas há planilhas paralelas não mapeadas |
| Saber quem é o dono? | ❌ Não | Não há responsável definido por dado |
| Saber o que significa? | ❌ Não | COD_CLI vs ID_CLIENTE vs CLIENTE_COD sem padronização |
| Saber qual é a fonte oficial? | ❌ Não | “Ninguém sabe ao certo qual base é a oficial” |
Conclusão: a Hermex tem dados, mas não tem nem o inventário básico. Está no nível 0 de maturidade — ou, na melhor das hipóteses, em uma transição embrionária para o inventário.
3.2.3 Posicionamento nas gerações de catálogos
| Geração | Característica | Hermex está aqui? |
|---|---|---|
| Geração 0 — Pré-inventário | Não há inventário formal; dados dispersos e sem documentação | ✅ SIM |
| 1ª geração — Inventário manual | Planilhas manuais listando dados, donos e localizações | ❌ Não |
| 2ª geração — Catálogo técnico | Ferramenta que varre metadados técnicos automaticamente | ❌ Não |
| 3ª geração — Catálogo de negócio | Glossário, termos de negócio, colaboração entre áreas | ❌ Não |
| 4ª geração — Data Marketplace | Autosserviço, curadoria, descoberta ativa | ❌ Não |
3.2.4 Justificativa da avaliação
abaixo do estágio de inventário. Isso se evidencia por:1. Ausência de inventário formal: não há documentação centralizada sobre
quais dados existem, onde estão ou quem é o responsável.2. Ausência de padronização semântica: o mesmo conceito (cliente) recebe
três nomes diferentes (COD_CLI, ID_CLIENTE, CLIENTE_COD) sem que
ninguém saiba qual é a fonte oficial.
3. Ausência de accountability: não há data owners definidos, o que
impede qualquer processo de governança.
4. Consequências visíveis: entregas erradas, divergência de clientes
ativos e duplicidade de motoristas são sintomas de que o problema
não é tecnológico, mas de contexto e responsabilização.
O histórico de aquisições agrava o cenário: cada transportadora trouxe
seus próprios sistemas e vocabulários, sem esforço de integração
semântica posterior.
Portanto, o primeiro passo não é adquirir uma ferramenta sofisticada,
mas construir o inventário e, em paralelo, iniciar a padronização
semântica (catálogo de negócio) com as áreas.
3.2.5 Horizonte de evolução
| Prazo | Estágio-alvo | Ação |
|---|---|---|
| Curto prazo | Inventário | Mapear sistemas, campos, donos e localizações |
| Médio prazo | Catálogo | Glossário de negócio, padronização de campos, fonte oficial |
| Longo prazo | Data Marketplace | Curadoria, autosserviço, descoberta ativa |
💡 Insight: a Hermex pode construir inventário e catálogo em paralelo. Não precisa terminar o inventário para começar o glossário — as duas frentes se alimentam mutuamente.
3.3 Recomendação de Perfil de Ferramenta
3.3.1 Premissa: o problema define a ferramenta
| Dimensão | Situação da Hermex |
|---|---|
| Maturidade | Nível 0 — abaixo do inventário |
| Cultura | Silos por área, crescimento por aquisições, vocabulários divergentes |
| Gargalo principal | Falta de alinhamento semântico e cultural — não é tecnológico |
| Urgência | Precisa engajar áreas para construir inventário e glossário |
| Restrição | Governança recém-criada, sem processos maduros |
⚠️ Conclusão-chave: o gargalo não é tecnológico. É de adoção, colaboração e alinhamento semântico.
3.3.2 Análise dos 4 perfis
| Perfil | Resolve o problema da Hermex? | Justificativa |
|---|---|---|
| Plataforma de governança corporativa estruturada | ❌ Não | Peso excessivo; empresa imatura em governança; imporia processo antes de cultura, gerando rejeição |
| Ferramenta com foco em adoção e colaboração | ✅ Sim | Ataca o gargalo real: alinhamento semântico e cultural; baixa barreira de entrada; engaja áreas |
| Plataforma integrada de dados | ❌ Não | Resolve integração técnica, não contexto semântico; integrar antes de padronizar = automatizar o caos |
| Solução de código aberto | ⚠️ Viável | Exige maturidade técnica e de governança que a empresa não tem; customização vira fardo |
3.3.3 Recomendação final
Perfil recomendado: Ferramenta com foco em adoção e colaboração.
abaixo do estágio de inventário. O problema central não é tecnológico,
mas de alinhamento semântico e cultural entre áreas que cresceram por
aquisições e mantêm vocabulários divergentes (COD_CLI, ID_CLIENTE,
CLIENTE_COD).Nesse contexto, uma plataforma de governança corporativa estruturada
seria subutilizada e imporia processo antes de cultura, gerando rejeição.
Uma plataforma integrada de dados resolveria a conexão técnica, mas não
o significado — automatizaria o caos. Uma solução de código aberto
exigiria maturidade técnica e de governança que a empresa ainda não
possui.A ferramenta com foco em adoção e colaboração é a mais adequada porque:
1. Reduz a barreira de entrada para as áreas participarem.
2. Prioriza o glossário de negócio e o vocabulário comum.
3. Permite construir inventário e catálogo em paralelo, com engajamento.
4. Prepara o terreno para, no futuro, evoluir para estágios mais maduros.
A escolha é guiada pelo problema a resolver — alinhamento semântico e
adoção — e não pela liderança de mercado ou sofisticação da ferramenta.
3.4 Recomendação Técnica Complementar — Uso do PyDeequ
Para operacionalizar a avaliação de maturidade descrita neste parecer, recomenda-se a adoção do PyDeequ como ferramenta de medição objetiva da qualidade dos dados. Diferentemente de uma avaliação puramente qualitativa, o PyDeequ transforma o diagnóstico em evidências quantitativas, permitindo priorizar ações com base em números concretos.
3.4.1 Por que o PyDeequ é adequado ao contexto da Hermex
| Problema da Hermex (diagnóstico) | Como o PyDeequ resolve |
|---|---|
| Ninguém sabe quais campos existem ou o que significam | Profiling automático gera perfis de cada coluna (completude, cardinalidade, tipo, min/max, média, desvio) |
Divergência entre COD_CLI, ID_CLIENTE e CLIENTE_COD |
Análise comparativa de perfis revela se os campos têm a mesma distribuição |
| Duplicidade de cadastros de motoristas | Verificações de unicidade quantificam a duplicidade |
| Entregas em endereços errados | Validação de domínios (UFs, CEPs) e padrões de formato |
| Ausência de consentimento LGPD | Medição de completude em campos de consentimento |
| Acessos indevidos a planilhas salariais | Profiling de dados sensíveis identifica onde estão os dados críticos |
| Falta de data owners | Métricas por coluna geram evidências para justificar responsáveis |
| Maturidade nível 0 | Baseline quantitativo — a “fotografia” inicial que servirá de comparação futura |
3.4.2 O que o PyDeequ pode medir (por dimensão de qualidade)
| Dimensão | O que verifica | Aplicação na Hermex |
|---|---|---|
| Acurácia | Volume de registros dentro do esperado | Comparar contagem de clientes ativos entre comercial e financeiro |
| Validade | Valores em domínios válidos | Validar UFs, CEPs, CNPJs, códigos de cliente |
| Completude | Campos preenchidos | Medir % de clientes sem consentimento LGPD registrado |
| Unicidade | Ausência de duplicidade | Verificar unicidade do CPF do motorista |
| Consistência | Tipos de dados corretos | Garantir CPF, CNPJ, CEP como strings; datas como date |
| Temporalidade | Datas em formato e range válidos | Identificar datas futuras impossíveis ou formatos inconsistentes |
3.4.3 Perfis automáticos — a “radiografia” inicial dos dados
O ColumnProfilerRunner do PyDeequ gera, para cada coluna, um perfil estatístico completo: percentual de valores nulos, quantidade de valores distintos, tipo inferido, valores mínimo e máximo, média e desvio padrão. Isso resolve diretamente o problema “ninguém sabe o que existe nos sistemas”.
3.4.4 Sugestões automáticas de regras
Como a Hermex não tem regras de qualidade definidas (maturidade nível 0), o ConstraintSuggestionRunner do PyDeequ sugere automaticamente um conjunto inicial de regras baseadas no comportamento observado dos dados. Isso acelera a construção do catálogo e do glossário — exatamente o gargalo identificado no diagnóstico.
3.4.5 Como o PyDeequ se conecta ao Parecer de Maturidade
| Estágio de maturidade | Como o PyDeequ ajuda |
|---|---|
| Nível 0 (atual) — sem inventário, sem catálogo | Profiling + sugestões automáticas geram o inventário técnico inicial e as primeiras regras |
| Nível 1 (curto prazo) — inventário construído | Verificações por dimensão validam continuamente a qualidade dos dados inventariados |
| Nível 2 (médio prazo) — catálogo com glossário | Métricas comparativas entre sistemas revelam se os campos representam o mesmo conceito |
| Nível 3 (longo prazo) — Data Marketplace | Verificação contínua garante que os dados publicados mantêm a qualidade |
3.4.6 Proposta de ação concreta
| Fase | Duração | Atividades | Entregável |
|---|---|---|---|
| Fase 1 — Diagnóstico quantitativo | 2–4 semanas | Aplicar profiling em cada um dos 4 sistemas; gerar relatório por coluna; identificar campos com baixa completude; aplicar sugestões automáticas de regras | “Radiografia” quantitativa de cada sistema |
| Fase 2 — Baseline de qualidade | 2–3 semanas | Criar verificações para as 6 dimensões; executar em cada sistema; gerar score de qualidade por sistema e domínio | Baseline numérico — o “antes” para comparação futura |
| Fase 3 — Monitoramento contínuo | Contínuo | Integrar verificações a pipelines de ingestão; alertas automáticos; dashboard com evolução dos indicadores | Governança operacionalizada |
3.4.7 Síntese da recomendação técnica
O PyDeequ não substitui o catálogo nem o glossário de negócio — ele fornece a evidência quantitativa que sustenta as decisões de governança. Sem ele, o diagnóstico permanece qualitativo e difícil de priorizar. Com ele, cada problema da Hermex Log ganha um número: quantos clientes sem consentimento LGPD? Quantos motoristas duplicados? Qual a completude real do endereço de entrega?
A combinação “catálogo de negócio + PyDeequ” é o caminho mais eficiente para a Hermex Log sair do nível 0 e evoluir para os estágios seguintes de maturidade.
3.5 Erros Comuns que Devem Ser Evitados
| Erro | Por que está errado |
|---|---|
| “A Hermex está no estágio de catálogo porque tem 4 sistemas” | Ter sistemas não é ter catálogo. Sistemas armazenam dados; catálogo descreve dados |
| “A Hermex está pronta para Data Marketplace” | Marketplace exige curadoria e confiança — a Hermex não tem nem inventário |
| “O problema é a falta de integração entre sistemas” | Integrar antes de padronizar = automatizar o caos |
| “A Hermex deveria usar uma plataforma corporativa completa” | A empresa não tem maturidade para sustentá-la; seria subutilizada |
| “Código aberto é sempre mais barato” | Exige equipe técnica e maturidade de governança que a Hermex não tem |
| “Vamos escolher a ferramenta X porque é líder de mercado” | O enunciado é explícito: argumente pelo problema, não pela marca |
3.6 Conclusão do Parecer
A Hermex Log está no nível 0 de maturidade em catálogos de dados — abaixo do estágio de inventário. O problema central não é tecnológico, mas de alinhamento semântico e cultural entre áreas que cresceram por aquisições e mantêm vocabulários divergentes.
A recomendação é uma ferramenta com foco em adoção e colaboração, pois:
- Ataca o gargalo real (alinhamento semântico e cultural).
- Reduz a barreira de entrada para as áreas participarem.
- Permite construir inventário e catálogo em paralelo, com engajamento.
- Prepara o terreno para estágios mais maduros no futuro.
Como complemento técnico, recomenda-se a adoção do PyDeequ para transformar o diagnóstico qualitativo em evidências quantitativas, medindo objetivamente a qualidade dos dados e estabelecendo o baseline que servirá de referência para medir a evolução da maturidade.
Saiba mais sobre a biblioteca PyDeequ: https://github.com/Antonino-Marques-Jares/Qualidade-de-Dados-com-Biblioteca-Pydeequ
✅ Checklist Final de Validação — 1ª Etapa
Entregáveis
- Documento de Diagnóstico — distingue falta de dados de falta de visibilidade; relaciona fatores a consequências concretas; cobre os 3 eixos (silos, metadados, governança); considera o histórico de aquisições; usa a analogia do restaurante
- Tabela Comparativa — separa problemas técnicos de problemas de negócio; explicita itens ambíguos com duplo ângulo; justifica cada categorização; lista perguntas que o catálogo deve responder; conecta a análise ao diagnóstico
- Parecer — avalia maturidade com base nas gerações de catálogos; justifica com evidências do cenário; analisa os 4 perfis de ferramenta; recomenda pelo problema, não pela marca; apresenta horizonte de evolução; sugere PyDeequ como complemento técnico
Passos Metodológicos
- Passo 1 — Análise do cenário: identificou fatores de invisibilidade; nomeou os 3 eixos
- Passo 2 — Uso do ChatGPT: prompt estruturado documentado; revisão crítica da resposta da IA; ajustes justificados
- Passo 3 — Avaliação de maturidade: posicionou a Hermex no nível correto; justificou com evidências
- Passo 4 — Recomendação de ferramenta: argumentou pelo problema; justificou a escolha
Validação Crítica (os “erros comuns”)
- Não confundi inventário (o que existe) com catálogo (o que significa)
- Não disse que a Hermex está no estágio de catálogo só porque tem sistemas
- Não recomendei ferramenta pela marca, e sim pelo problema
- Não tratei o problema como tecnológico (é semântico e cultural)
- Não ignorei o histórico de aquisições como causa dos silos
- Não aceitei a primeira resposta da IA sem revisar