Python

Bem-vindo à categoria Python. Aqui, abordaremos tópicos do básico ao avançado e exploraremos sua vasta biblioteca.

Carreira Governança de Dados: Nível 1 Etapa 3

Por

📋 Enunciado do Problema

Com papéis e ciclo de vida mapeados, é hora de redigir a Política de Acesso e Qualidade de Dados de Clientes do SwiftBank, contendo os cinco elementos exigidos
(propósito, escopo, papéis e responsabilidades, diretrizes e conformidade/exceções),
além do plano de implantação e dos indicadores de monitoramento.
Esse artefato será discutido no comitê de governança e servirá de referência para auditorias.

🎯 Sua missão

  1. Em um documento Excel chamado 03_politica_acesso_qualidade.xlsx, crie a aba Política com seções claramente identificadas em colunas (elemento, conteudo):

    • Propósito
    • Escopo (sistemas, áreas, tipos de dados que cobre e que NÃO cobre)
    • Papéis e Responsabilidades (CDO, DGO, Data Owners por domínio, Data Stewards, Data Custodians, Usuários, Data Champions)
    • Diretrizes (ao menos 6 diretrizes operacionais, cada uma com responsável, frequência, sistema de registro e consequência de descumprimento)
    • Conformidade/Exceções (como exceções são solicitadas e quem aprova)

    Use um assistente de IA generativa como apoio para revisar redação, mas valide cada diretriz: ela precisa ser específica, mensurável e ter responsável.

  2. Crie a aba Plano_Implantacao com três passos (comunicação direcionada, responsáveis e cronograma, integração com metas e rituais), descrevendo ações concretas para o SwiftBank.
  3. Crie também a aba Indicadores com pelo menos cinco métricas (ex.: % de dados mestres atualizados no prazo, número de inconsistências por mês, % de áreas que cumprem revisão, tempo médio de correção, engajamento em treinamentos), cada uma com fórmula, fonte do dado, meta e responsável.
  4. Crie a aba Cenarios_Diagnostico com pelo menos três cenários narrados. Para cada cenário, identifique: política aplicável, falhas que poderiam ocorrer sem ela, papéis envolvidos e ações corretivas esperadas. Marque qual diretriz da aba Política previne cada caso.

🛠️ Ferramentas

Excel, assistente de IA generativa (ChatGPT, Claude, Gemini ou similar).

💡 Dica de troubleshooting 1: Se uma diretriz começa com verbos como “zelar”, “garantir” ou “buscar” sem complemento, ela está vaga. Refaça respondendo: o quê, quem, com que frequência, onde se registra, qual a consequência?
💡 Dica de troubleshooting 2: Cuidado ao usar assistentes de IA: não cole dados reais, e revise sempre a saída. O LLM pode inventar regulamentos ou inverter responsabilidades entre Owner e Steward.
💡 Dica de troubleshooting 3: Se tiver mais de 12 diretrizes na Política, considere mover algumas para um documento de “Procedimento”. Política diz o quê, procedimento diz o como.



✅ Missão 1 — Aba Política (03_politica_acesso_qualidade.xlsx)

Estrutura em duas colunas: elemento e conteudo. As diretrizes foram redigidas de forma
específica, mensurável e com responsável, evitando verbos vagos (dica 1). Foram mantidas
8 diretrizes (abaixo do limite de 12 — dica 3), pois as demais orientações operacionais
foram remetidas ao documento de Procedimento.

Aba Política — Elementos e Conteúdo
Elemento Conteúdo
Propósito Estabelecer as regras de acesso, uso, compartilhamento e qualidade dos dados de clientes do SwiftBank,
garantindo conformidade com a LGPD, o sigilo bancário e as normas internas, bem como assegurar que
decisões de negócio, modelos de IA e relatórios regulatórios sejam sustentados por dados confiáveis,
rastreáveis e tempestivos. Esta política transforma acordos verbais em obrigações auditáveis,
sem criar burocracia excessiva, por meio de diretrizes mensuráveis e prazos definidos.
Escopo Cobre:

  • Sistemas: Data Lakehouse (camadas Bronze, Silver e Gold), sistemas legados de crédito, cobrança, marketing, RH e atendimento; integrações via camada de ingestão; ferramentas de BI e de ciência de dados.
  • Áreas: Diretoria de Dados (CDO), Governança de Dados (DGO), Crédito, Cobrança, Marketing, Compliance, Auditoria Interna, Engenharia de Dados, Qualidade de Dados, Plataforma de Dados, Analytics e áreas de negócio consumidoras.
  • Tipos de dados: dados cadastrais de clientes (PF e PJ), dados de transações, dados de crédito e empréstimos, dados de cobrança, dados de consentimento (incluindo consentimento_marketing), dados mestres (cliente, agência, produto) e dados de referência (ex.: códigos de bancos, unidades federativas).

NÃO cobre:

  • Dados anonimizados ou agregados de forma irreversível para fins estatísticos, desde que aprovados pelo DGO.
  • Dados de colaboradores internos (tratados em política específica de RH).
  • Dados de testes sintéticos gerados em ambientes de homologação, desde que não derivados de dados reais de clientes.
  • Sistemas de terceiros fora do perímetro de integração formal do SwiftBank.
Papéis e Responsabilidades
  • CDO (Chief Data Officer): aprova esta política, patrocina o programa de qualidade e responde perante o comitê de governança e auditorias.
  • DGO (Data Governance Office): mantém a política atualizada, define padrões, conduz o comitê de governança e aprova exceções de acesso e qualidade.
  • Data Owners por domínio: respondem formalmente pela qualidade e pelo uso dos dados do seu domínio (ex.: Crédito, Cobrança, Marketing); aprovam regras de qualidade e autorizam acessos sensíveis.
  • Data Stewards: implementam e monitoram as regras de qualidade, mantêm catálogo e dicionário de dados, executam revisões periódicas e registram inconsistências.
  • Data Custodians: garantem a infraestrutura, o armazenamento, o backup e os controles técnicos de acesso nas camadas Bronze, Silver e Gold.
  • Usuários: consomem dados conforme o contrato de dados, respeitam o princípio do menor privilégio e reportam anomalias.
  • Data Champions: atuam como elo entre as áreas de negócio e o DGO, promovem treinamentos, comunicam mudanças e apoiam a revisão trimestral de qualidade.
Diretrizes

As 8 diretrizes abaixo são específicas, mensuráveis, com responsável, frequência, sistema de registro e consequência (dica 1).

Diretrizes operacionais da Política de Acesso e Qualidade de Dados de Clientes
# Diretriz Responsável Frequência Sistema de registro Consequência de descumprimento
D1 Atualizar os dados mestres de cliente (cadastro PF/PJ) na camada Gold, garantindo que 100% dos registros com alteração na origem sejam refletidos em até 1 dia útil. Data Steward de Cadastro Diária Catálogo de Dados / Data Lakehouse (Gold) Alerta ao Data Owner; registro no painel de qualidade; bloqueio do uso do dado em modelos de crédito até regularização.
D2 Revisar e aprovar os contratos de dados (interface e dados) entre sistemas de origem e camadas Bronze/Silver/Gold, com cláusula de qualidade e SLA de correção em até 48 h para erros originados no Lakehouse. Data Owner + DGO Semestral (revisão) e sob demanda Repositório de Contratos de Dados Suspensão da ingestão do dado até formalização; notificação ao CDO.
D3 Executar o motor de qualidade de dados na camada Silver, com no mínimo 12 regras críticas (ex.: unicidade de CPF/CNPJ, formato de data dd/mm/aaaa, UF válida, valor de venda não nulo), e registrar o resultado mensal no painel de indicadores. Equipe de Qualidade de Dados Mensal Motor de Qualidade (ex.: Great Expectations) + Painel de Indicadores Bloqueio da promoção Silver→Gold; abertura de incidente de qualidade; cobrança ao Data Owner.
D4 Validar o consentimento_marketing antes de qualquer extração para Marketing, conferindo a base de consentimento na camada Silver e registrando a evidência no catálogo. Data Steward de Marketing + Data Owner de Marketing Por extração (no mínimo mensal) Catálogo de Dados + Log de Auditoria Suspensão imediata do compartilhamento; abertura de incidente de privacidade; comunicação ao DPO.
D5 Realizar a revisão trimestral de acessos (RBAC) aos dados de clientes, removendo permissões órfãs e registrando o resultado no relatório de conformidade. Data Custodian + DGO Trimestral Ferramenta de IAM + Relatório de Conformidade Revogação automática de acessos; notificação ao gestor da área; registro em auditoria.
D6 Treinar 100% dos usuários autorizados em LGPD, sigilo bancário e uso ético de dados, com carga mínima de 2 h/ano e avaliação com nota ≥ 80%. Data Champions + DGO Anual (com reforço semestral) Plataforma de Treinamento (LMS) Bloqueio temporário de acesso a dados sensíveis até conclusão do treinamento.
D7 Registrar toda inconsistência de qualidade identificada na camada Bronze ou Silver, com prazo máximo de 1 dia útil para abertura e 5 dias úteis para correção, conforme SLA do contrato de dados. Data Steward do domínio Contínua (monitoramento diário) Ferramenta de Incidentes de Qualidade (ITSM) Escalonamento ao Data Owner e ao DGO; impacto no indicador de tempo médio de correção.
D8 Manter a base de dados de referência (UF, códigos de bancos, produtos) atualizada e disponível para todas as camadas, com validação mensal de integridade. Data Steward de Referência + Plataforma de Dados Mensal Data Lakehouse (camada de referência) + Catálogo Alerta ao DGO; bloqueio de pipelines que dependam da referência desatualizada.
Conformidade/Exceções Como exceções são solicitadas:

  • A área solicitante preenche o formulário “Solicitação de Exceção à Política de Dados” no portal do DGO, informando: diretriz impactada, justificativa de negócio, prazo desejado, dados envolvidos, controles compensatórios e responsável.
  • O pedido é registrado no sistema de governança com número de protocolo e prazo máximo de resposta de 5 dias úteis.

Quem aprova:

  • Exceções de acesso a dados de clientes: Data Owner do domínio + DGO.
  • Exceções de qualidade (ex.: aceitar dado com inconsistência conhecida): Data Owner + Equipe de Qualidade de Dados.
  • Exceções que envolvam dados sensíveis ou regulatórios: CDO, com parecer do Compliance/DPO.
  • Toda exceção tem prazo máximo de 90 dias, renovável uma única vez mediante nova justificativa; deve constar no relatório trimestral de conformidade para auditoria.
Validação da dica 1: cada diretriz responde a o quê, quem, com que frequência, onde se registra e qual a consequência. Verbos vagos como “zelar” ou “garantir” foram substituídos por ações mensuráveis (ex.: “Atualizar… em até 1 dia útil”, “Executar… 12 regras críticas”, “Validar… antes de qualquer extração”).



✅ Missão 2 — Aba Plano_Implantacao

Três passos com ações concretas para o SwiftBank, prazos, responsáveis e integração com metas e rituais.
O plano considera a realidade de um Data Lakehouse com camadas Bronze/Silver/Gold e a estrutura de governança
(CDO, DGO, Data Owners, Stewards, Custodians, Champions).

Plano de Implantação — 3 Passos
Passo Ações concretas Responsáveis Cronograma Integração com metas e rituais
1. Comunicação direcionada
  • Workshop com Marketing antes do go-live do novo fluxo de consentimento, explicando D4 e o contrato de dados.
  • Sessão com Crédito e Cobrança sobre D1, D2 e D7, com foco em prazos e consequências.
  • Campanha interna “Dado Bom é Dado Confiável” com vídeos curtos e guia rápido de exceções.
  • Reunião quinzenal com Data Champions para alinhar dúvidas e coletar feedback.
 DGO + Data Champions + CDO Semanas 1–4 (pré-go-live) e contínuo (quinzenal)
  • Comunicação entra no ritual de All Hands da Diretoria de Dados.
  • Data Champions reportam engajamento no OKR trimestral de Governança.
2. Responsáveis e cronograma
  • Nomear formalmente Data Owners por domínio (Crédito, Cobrança, Marketing, Cadastro) em portaria interna.
  • Definir Data Stewards e Data Custodians com dedicação mínima de 20%.
  • Criar calendário anual de revisões: trimestral (acessos — D5), semestral (contratos — D2), anual (treinamento — D6).
  • Publicar matriz RACI no portal de governança.
 CDO + DGO + RH Semanas 1–6 (nomeações) e calendário anual
  • Metas individuais de Data Owners e Stewards vinculadas ao cumprimento do calendário.
  • Reunião mensal do comitê de governança para acompanhar o cronograma.
3. Integração com metas e rituais
  • Inserir o indicador “% de dados mestres atualizados no prazo” no OKR trimestral da Diretoria de Crédito.
  • Incluir “tempo médio de correção de inconsistências” no painel de gestão da Diretoria de Cobrança.
  • Realizar reunião quinzenal com Data Champions e mensal com Data Owners para revisar indicadores.
  • Atrelar bônus variável de gestores de dados ao cumprimento de 90% das metas de qualidade.
 CDO + Diretorias de Crédito e Cobrança + DGO Trimestre 1 (implantação) e contínuo
  • OKR trimestral da Diretoria de Crédito: meta de 95% de dados mestres atualizados.
  • Ritual quinzenal com Data Champions e mensal com Owners já incorporado à agenda oficial.



✅ Missão 3 — Aba Indicadores

Cinco métricas (mínimo exigido) com fórmula, fonte do dado, meta e responsável. Todas são mensuráveis e
auditáveis, alinhadas às diretrizes da aba Política.

Indicadores de Monitoramento da Qualidade e Acesso
Indicador Fórmula Fonte do dado Meta Responsável
% de dados mestres atualizados no prazo (Nº de registros mestres atualizados em ≤ 1 dia útil / Nº total de registros mestres alterados no mês) × 100 Catálogo de Dados + Log de atualização da camada Gold ≥ 95% Data Steward de Cadastro
Número de inconsistências por mês Contagem de incidentes de qualidade abertos no mês na camada Bronze e Silver Ferramenta de Incidentes de Qualidade (ITSM) ≤ 20 por mês (redução de 10% ao trimestre) Equipe de Qualidade de Dados
% de áreas que cumprem a revisão trimestral de acessos (Nº de áreas que concluíram a revisão no prazo / Nº total de áreas com acesso a dados de clientes) × 100 Ferramenta de IAM + Relatório de Conformidade 100% DGO + Data Custodian
Tempo médio de correção de inconsistências Somatório do tempo (em horas úteis) entre abertura e fechamento dos incidentes / Nº de incidentes fechados no mês Ferramenta de Incidentes de Qualidade (ITSM) ≤ 40 horas úteis (5 dias úteis) Data Steward do domínio
Engajamento em treinamentos (Nº de usuários autorizados que concluíram o treinamento com nota ≥ 80% / Nº total de usuários autorizados) × 100 Plataforma de Treinamento (LMS) ≥ 98% Data Champions + DGO
Observação: todos os indicadores alimentam o painel mensal do comitê de governança e o relatório trimestral de auditoria. As metas estão vinculadas às diretrizes D1, D3, D5, D6 e D7.



✅ Missão 4 — Aba Cenarios_Diagnostico

Três cenários narrados, com política aplicável, falhas sem a política, papéis envolvidos, ações corretivas
e a diretriz da aba Política que previne cada caso. Os cenários refletem situações reais do SwiftBank
(compartilhamento com terceiro, conflito de consentimento e extração emergencial).

Cenário 1 — Compartilhamento de base com consultoria terceirizada de cobrança

Item Descrição
Narrativa A Diretoria de Cobrança solicita à Engenharia de Dados uma extração da base de clientes inadimplentes para enviar a uma consultoria terceirizada que fará a cobrança. O pedido chega por e-mail, sem contrato formal, e a extração é feita diretamente da camada Silver.
Política aplicável Política de Acesso e Qualidade de Dados de Clientes — Escopo (dados de cobrança), Papéis (Data Owner de Cobrança, DGO, Data Custodian) e Diretrizes D2, D5 e D7.
Falhas sem a política
  • Compartilhamento de dados sensíveis sem base legal ou contrato de tratamento de dados.
  • Ausência de registro de auditoria e de rastreabilidade da extração.
  • Risco de vazamento e de uso indevido dos dados pela consultoria.
  • Inexistência de SLA de correção caso a consultoria encontre inconsistências.
Papéis envolvidos Data Owner de Cobrança, DGO, Data Custodian, Compliance/DPO, Engenharia de Dados.
Ações corretivas esperadas
  • Formalizar contrato de dados com cláusulas de qualidade, finalidade e devolução/destruição dos dados.
  • Registrar a extração no catálogo e no log de auditoria, com aprovação do Data Owner e do DGO.
  • Aplicar mascaramento ou pseudonimização quando possível.
  • Monitorar o uso pela consultoria por meio de relatórios mensais.
Diretriz que previne D2 (contratos de dados com cláusula de qualidade e SLA) e D5 (revisão de acessos e princípio do menor privilégio).

Cenário 2 — Dúvida entre Marketing e Crédito sobre consentimento_marketing

Item Descrição
Narrativa Marketing deseja usar a base de clientes com consentimento_marketing para uma campanha, mas Crédito afirma que parte desses clientes teve o consentimento revogado após uma renegociação de dívida. As duas áreas discutem verbalmente, sem evidência documentada, e a campanha é iniciada com dados desatualizados.
Política aplicável Política de Acesso e Qualidade de Dados de Clientes — Diretrizes D4 (validação de consentimento) e D1 (atualização de dados mestres), além do Escopo (dados de consentimento).
Falhas sem a política
  • Uso de dados sem consentimento válido, gerando risco de sanções da ANPD e danos à reputação.
  • Conflito entre áreas por falta de fonte única de verdade.
  • Campanha disparada com base em dados desatualizados, reduzindo sua eficácia.
Papéis envolvidos Data Owner de Marketing, Data Owner de Crédito, Data Steward de Marketing, DGO, DPO.
Ações corretivas esperadas
  • Suspender a campanha imediatamente.
  • Consultar a base de consentimento na camada Silver, com registro de evidência no catálogo.
  • Reprocessar a lista com os consentimentos válidos e documentar a decisão.
  • Promover alinhamento entre Marketing e Crédito mediado pelo DGO.
Diretriz que previne D4 (validar consentimento_marketing antes de qualquer extração, com registro de evidência).

Cenário 3 — Pedido emergencial de extração da base de empréstimos

Item Descrição
Narrativa Em uma sexta-feira à tarde, a Diretoria de Crédito solicita uma extração emergencial da base de empréstimos para uma reunião estratégica no sábado. O pedido é feito por telefone, sem contrato de dados e sem validação de qualidade. A extração é feita diretamente da camada Bronze, com dados brutos e inconsistentes (ex.: UF “XX”, valores nulos).
Política aplicável Política de Acesso e Qualidade de Dados de Clientes — Diretrizes D2 (contratos de dados), D3 (motor de qualidade na Silver) e D7 (registro de inconsistências).
Falhas sem a política
  • Decisão estratégica baseada em dados não confiáveis, com risco de prejuízo financeiro.
  • Ausência de rastreabilidade e de SLA de correção.
  • Uso indevido de dados brutos sem harmonização.
  • Pressão sobre a equipe técnica para burlar processos.
Papéis envolvidos Data Owner de Crédito, Data Steward de Crédito, Equipe de Qualidade de Dados, DGO, Data Custodian.
Ações corretivas esperadas
  • Recusar a extração da camada Bronze e direcionar para a camada Gold/Silver com dados validados.
  • Aplicar o motor de qualidade e registrar as inconsistências encontradas.
  • Formalizar contrato de dados emergencial com prazo e responsáveis.
  • Comunicar ao CDO e ao comitê de governança o ocorrido, reforçando o processo.
Diretriz que previne D3 (motor de qualidade na Silver com 12 regras críticas) e D7 (registro e correção de inconsistências em até 5 dias úteis).



🧭 Observância das 3 Dicas de Troubleshooting

  • Dica 1 — Diretrizes específicas e mensuráveis: todas as 8 diretrizes foram reescritas para responder a o quê, quem, com que frequência, onde se registra e qual a consequência. Exemplos: D1 (“atualizar… em até 1 dia útil”), D3 (“executar… 12 regras críticas”), D7 (“registrar… em 1 dia útil, corrigir em 5 dias úteis”). Não há verbos vagos sem complemento.
  • Dica 2 — Uso criterioso de IA generativa: o conteúdo foi revisado para evitar invenção de regulamentos e inversão de papéis. As responsabilidades seguem a base de conhecimento: Data Owner responde formalmente pela qualidade; Data Steward implementa e monitora; Data Custodian garante infraestrutura; DGO aprova exceções; CDO patrocina. Nenhum dado real de cliente foi utilizado nos exemplos.
  • Dica 3 — Limite de diretrizes: a aba Política contém 8 diretrizes (abaixo de 12). Orientações mais operacionais (ex.: passo a passo de abertura de incidente, detalhamento de mascaramento) foram remetidas ao documento de Procedimento, mantendo a política no nível do “o quê”.

Carreira Governança de Dados: Nível 1 Etapa 2

Por

2ª Etapa: Ciclo de vida dos dados aplicado ao caso SwiftBank

Discutir no fórum

Agora você precisa mostrar, na prática, como um dado nasce, evolui e é descartado dentro do SwiftBank. O caso escolhido é o do conceito “Cliente Ativo”, que hoje é definido de formas diferentes em Marketing, Crédito e Financeiro. Você produzirá um fluxograma do ciclo de vida cobrindo coleta → armazenamento → recuperação → uso → descarte, com responsáveis e perguntas-chave em cada etapa, mais um documento de apoio.

Pergunta-chave: “Quais decisões de governança precisam acontecer em cada etapa do ciclo de vida do dado de ‘Cliente Ativo’ para que ele possa ser usado de forma segura, consistente e em conformidade com a LGPD?”

🎯 Sua missão

🔹 Missão 1 Draw.io / PlantUML

No Draw.io, crie um fluxograma horizontal com as cinco etapas do ciclo de vida (coleta, armazenamento, recuperação, uso, descarte). Em cada etapa, inclua:

  • (a) os atores envolvidos (ex.: Engenharia de Dados, Data Owner, Segurança);
  • (b) duas a três perguntas-chave (ex.: “temos direito de coletar?”, “qual a finalidade declarada?”, “quando descartar?”);
  • (c) um exemplo concreto aplicado ao SwiftBank usando o dataset clientes_swiftbank.csv (ex.: na coleta, como entra o campo consentimento_marketing).

Código PlantText do Fluxograma abaixo:

 

Fluxograma do ciclo de vida (clique para ampliar em nova aba):


Ciclo de vida do dado Cliente Ativo – SwiftBank

 

🔹 Missão 2 Excel – 02_ciclo_de_vida_cliente_ativo.xlsx

Crie a pasta de trabalho com as abas Etapas, Camadas e Definicao_Cliente_Ativo.

📋 Aba Etapas

etapa acao atores perguntas_chave riscos_LGPD evidencia_no_dataset
Coleta Coletar dados cadastrais e de consentimento do cliente. Engenharia de Dados, Time de Cadastro, DPO Temos base legal? A finalidade está declarada? O dado é necessário (minimização)? Coleta sem consentimento; finalidade genérica; excesso de dados. Campos consentimento_marketing (sim/não), data_cadastro, nome, cidade, data_nascimento.
Armazenamento Persistir em camadas bronze, silver e gold com controles de acesso. Engenharia de Dados, Data Owner, Segurança Onde armazenar? Por quanto tempo reter? Quem pode acessar? Armazenamento inseguro; retenção além do necessário; acesso não autorizado. Tabelas bz_clientes, sl_clientes, gd_clientes_ativos (derivadas do CSV).
Recuperação Localizar, solicitar acesso e extrair os dados autorizados. Analista de Dados, Data Owner, Segurança Quem solicita? Qual a finalidade? O acesso é auditado? Acesso indevido; extração sem justificativa; dados desatualizados. Consultas à gd_clientes_ativos para campanhas ou análise de crédito.
Uso Utilizar o dado padronizado para decisões de negócio. Marketing, Crédito, Financeiro, Compliance O uso está alinhado à finalidade? Há viés? Os resultados são auditáveis? Uso discriminatório; desvio de finalidade; falta de transparência. Regra cliente_ativo aplicada sobre status_conta e data_ultima_transacao.
Descarte Eliminar dados pessoais após o prazo legal ou revogação do consentimento. Engenharia de Dados, DPO, Segurança, Jurídico Quando descartar? Como garantir eliminação segura? Há arquivamento legal? Retenção indefinida; descarte inadequado; perda de evidências legais. Exclusão de registros do clientes_swiftbank.csv após 5 anos sem transação e sem consentimento.

📋 Aba Camadas

camada tabela o que muda exemplo de transformação
Bronze bz_clientes Dados brutos, sem tratamento, exatamente como vêm da origem (CSV). clientes_swiftbank.csv é carregado sem alterações; campos como nome, cidade, data_nascimento, consentimento_marketing.
Silver sl_clientes Dados limpos, padronizados, com tipagem correta e remoção de duplicatas. Datas convertidas para o padrão ISO; status_conta normalizado (ex.: “Ativa”, “Inativa”); consentimento_marketing como booleano.
Gold gd_clientes_ativos Dados enriquecidos e prontos para o negócio, com a regra de “Cliente Ativo” aplicada. Filtro: status_conta = 'Ativa' E data_ultima_transacao >= CURRENT_DATE - 90 dias. Resultado: apenas clientes ativos para Marketing, Crédito e Financeiro.

📋 Aba Definicao_Cliente_Ativo

Regra padronizada: “Cliente PF ou PJ com status_conta = 'Ativa' e ao menos uma transação efetivada nos últimos 90 dias.”

Justificativa: Essa regra elimina divergências porque estabelece um critério único, objetivo e auditável para todas as áreas. Marketing, Crédito e Financeiro passam a usar a mesma base (gd_clientes_ativos), evitando que cada setor crie sua própria definição (ex.: “cliente que logou no app”, “cliente com saldo positivo”, “cliente com compra no mês”).

Três decisões erradas sem a padronização:

  1. Marketing envia campanhas para clientes inativos (sem transação há mais de 90 dias), gerando custo elevado e baixa conversão.
  2. Crédito nega ou aprova limites com base em uma definição diferente, aumentando o risco de inadimplência ou perda de bons clientes.
  3. Financeiro projeta receita com clientes que não transacionam, causando distorções no fluxo de caixa e metas irreais.

🔹 Missão 3 Documento de apoio

O documento de apoio é composto pelas abas do Excel descritas acima, que detalham cada etapa, camadas e a definição padronizada. Além disso, o fluxograma PlantUML serve como representação visual do ciclo de vida.

🧰 Ferramentas

  • Draw.io (para o fluxograma visual – o PlantUML pode ser importado ou usado como referência);
  • Excel (para as abas Etapas, Camadas e Definição_Cliente_Ativo).

💡 Dicas de troubleshooting

  • Armazenamento vs. recuperação: armazenar é guardar; recuperar é localizar, pedir acesso e extrair. Quem aprova é o Data Owner.
  • Descarte vs. arquivamento: pela LGPD, manter dado pessoal além da finalidade é problema; descarte exige procedimento, não basta apagar de uma planilha.
  • Dado pessoal sensível: combinações de nome + cidade + data de nascimento já configuram identificação indireta (consulte o clientes_swiftbank.csv).

Solução completa para a 2ª etapa – Ciclo de vida dos dados aplicado ao SwiftBank.

Facebook
LinkedIn
Share
Instagram