Canvas ETL & Modelagem

Anamnese do projeto

Onze blocos, quatro fases. Preencha durante a conversa com o cliente — tudo é salvo automaticamente neste navegador.

Autosave ativo
Progresso0 de 11 blocos · 0%

Fase 1 · Descoberta

Entender o problema e o uso

Problema

Descreva a dor concreta que o dashboard precisa resolver — não a solução.

Ex.: O time perde 12h/semana consolidando planilhas e decide reposição com dados de 7 dias atrás.

Aceite: a dor está quantificada em tempo, dinheiro ou risco.

Nível de Decisão

Defina a vocação do relatório inteiro: Estratégico, Analítico ou Operacional, e o público que decide com ele. Isso vale para o dashboard inteiro, não varia por página.

Ex.: Analítico — gerentes de filial investigam desvios de meta semanalmente; diretoria acompanha o consolidado no mesmo relatório.

Aceite: uma opção selecionada e o público decisor nomeado.

Contexto de Uso

Selecione os dispositivos em que o dashboard será consultado. Cada um tem limitações próprias de filtros e complexidade.

Ex.: Computador na reunião comercial e Celular em visita a cliente.

Aceite: ao menos um dispositivo de consulta selecionado.

Fase 2 · Dados

Origens, frequência e horários

Origem dos Dados

Sistemas, arquivos e APIs de origem, com tipo de acesso e responsável por cada um.

Ex.: ERP Protheus (SQL Server, acesso via TI), planilha de metas (SharePoint, dona: Ana), CRM (API).

Aceite: cada fonte tem tipo de acesso e responsável identificados.

Frequência de Atualização

Com que periodicidade os dados são atualizados e em quais dias da semana.

Ex.: Diária, de segunda a sexta.

Aceite: uma frequência escolhida e os dias de execução definidos.

Horários de Atualização

Horários exatos de refresh, considerando a janela de disponibilidade da origem.

Ex.: 06:00 e 13:00; janela do ERP livre entre 5h e 7h.

Aceite: horários não conflitam com a janela de carga dos sistemas de origem.

Fase 3 · Governança

Acesso, riscos e premissas

Regras de Usuários

Segurança por linha (RLS/OLS): quem vê qual dado.

Nota: Todas as páginas do relatório são vistas por todos que acessam o relatório — a segurança é por dado, não por página.

Ex.: Gerente enxerga apenas a própria filial (RLS por e-mail); diretoria enxerga todas as filiais.

Aceite: regra de RLS descrita com o campo-chave e a fonte da relação usuário↔dado.

Riscos

O que pode atrasar ou inviabilizar o projeto, com impacto e responsável.

Ex.: Liberação de acesso ao banco depende de fila da TI (2 semanas) — mitigação: abrir chamado na semana 1.

Aceite: cada risco tem impacto e um responsável por mitigá-lo.

Premissas

O que está sendo assumido como verdadeiro para o projeto funcionar.

Ex.: As metas serão enviadas até o dia 5 de cada mês; o histórico de 24 meses está íntegro no ERP.

Aceite: cada premissa é verificável e tem um dono que a confirma.

Fase 4 · Execução

Cálculos e fundação do projeto

Cálculos

Dicionário único de métricas do projeto. Cada cálculo crítico precisa de definição formal.

Ex.: Margem % = (Receita líquida − CMV) ÷ Receita líquida; devoluções entram como valor negativo no mês da nota original.

Aceite: cada métrica crítica tem fórmula, granularidade e fonte de verdade.

Cronograma & Esforço

Esforço de FUNDAÇÃO do projeto (ETL, modelagem e governança) — datas, horas, responsáveis e status.

Ex.: Início 05/08, entrega 30/08, 64h, responsáveis: Ana (ETL) e Rafael (modelo), status Em Andamento.

Aceite: datas, esforço em horas e responsáveis preenchidos e acordados.