Entrega completa do case técnico de SQL, modelagem de dados e Power BI, análise de negócio e dashboard executivo. As 10 questões do enunciado estão respondidas com código-fonte auditável (SQL, DAX, TMDL) e um modelo Power BI funcional, além de dois relatórios em HTML que reproduzem o layout do dashboard sem depender de licença/instalação do Power BI.
Como ler este repositório: as seções Parte 1 a Parte 4 abaixo são a resposta direta às 10 questões — é o conteúdo a ser avaliado. Os arquivos em
dashboards/,background_powerbi/epaginas_html/são material de apoio construído em cima da resposta (protótipos visuais, planos de fundo para o Power BI, páginas HTML de documentação) e não a substituem.
- Estrutura do repositório
- Como abrir cada artefato
- Arquitetura de dados e do modelo
- Parte 1 — Análise de Dados e SQL
- Parte 2 — Power BI e Business Intelligence
- Parte 3 — Análise de Negócio
- Parte 4 — Case Prático
- Premissas e decisões técnicas
- Limitações conhecidas
- Índice de cobertura das questões
case_orizon/
├── README.md # este arquivo — respostas, decisões e guia de uso
├── AUDITORIA.md # validação numérica de cada medida (consulta a consulta)
├── GUIA_VISUAIS.md # de-para campo a campo para remontar os visuais no Power BI
├── consultas_sql.sql # Parte 1 (Q1, Q2, Q3) — SQL comentado
├── medidas_dax.dax # Parte 2 (Q6) — DAX comentado
├── medidas_html.dax # export de referência das medidas (paridade com o .pbix)
├── orizon.pbix # modelo + relatório Power BI (abrir no Power BI Desktop)
├── dados/ # CSVs de referência — ver "Arquitetura de dados"
│ ├── Atendimento.csv # base transacional do case (Partes 1 e 2)
│ ├── Custos.csv # custo operacional por unidade (contexto, não usado nas queries)
│ ├── Indicadores_Operacionais.csv # indicadores mensais da Parte 3
│ └── Fato_Indicadores.csv # base Mês × Unidade × Tipo usada no dashboard (Parte 4)
├── modelo_powerbi/tmdl/ # código-fonte do modelo semântico (formato TMDL)
│ ├── database.tmdl model.tmdl relationships.tmdl
│ ├── tables/ # Fato_Atendimentos, Fato_Indicadores, Dim_Unidade,
│ │ # Dim_Tempo, Dim_TipoAtendimento, _Medidas
│ └── cultures/pt-BR.tmdl
├── dashboards/
│ ├── painel_performance_operacional.html # relatório de 6 páginas (abrir no navegador)
│ ├── mapa_conexao_dados.html # diagrama: como as fontes se conectam ao modelo
│ └── storytelling_projeto.html # narrativa visual do projeto
├── paginas_html/ # versões avulsas de cada página do relatório
└── background_powerbi/ # planos de fundo PNG (3840×2160, 16:9) para o .pbix
| Artefato | Como abrir | Observação |
|---|---|---|
orizon.pbix |
Power BI Desktop | Modelo e relatório completos, prontos para uso. |
modelo_powerbi/tmdl/ |
Power BI Desktop (Git integration) ou Tabular Editor | Código-fonte do modelo — permite ver o histórico e revisar cada tabela/medida como texto. |
dashboards/*.html |
Duplo clique — abre em qualquer navegador | Protótipos estáticos (SVG), sem dependência externa. Páginas trocam pelas abas no rodapé. |
consultas_sql.sql |
Qualquer editor de texto ou IDE SQL | Comentado questão a questão. |
medidas_dax.dax |
Qualquer editor de texto | Comentado com o mapa "medida → visual que consome". |
background_powerbi/*.png |
Power BI Desktop → Formatar página → Tela de fundo | Ver instruções detalhadas abaixo. |
Planos de fundo no Power BI: Formatar página → Tela de fundo → Procurar imagem → escolher o PNG da página correspondente → Ajuste de imagem: Ajustar → Transparência: 0%. As áreas de card/gráfico ficam vazias no PNG propositalmente, para você sobrepor os visuais nativos do Power BI por cima.
Resumo: o modelo Power BI não importa os arquivos dados/*.csv via Power Query. As
tabelas de dados do modelo são tabelas calculadas em DAX (DATATABLE(...) para os dados
fixos do case, CALENDAR(...) para o calendário) — os valores estão digitados diretamente na
definição do modelo (TMDL), tornando o .pbix autocontido e independente de qualquer caminho
de arquivo externo. Os CSVs em dados/ são cópias de referência para leitura/auditoria humana
e não participam do refresh do modelo.
Diagrama completo, com o fluxo fim a fim (fontes → tabelas → relacionamentos → medidas →
relatório): dashboards/mapa_conexao_dados.html.
| Tabela | Tipo | Origem dos dados | Grão |
|---|---|---|---|
Fato_Atendimentos |
Fato | Tabela calculada (DATATABLE) |
1 linha por atendimento (Parte 1/2, 5 registros) |
Fato_Indicadores |
Fato | Tabela calculada (DATATABLE + CROSSJOIN) |
1 linha por Mês × Unidade × Tipo (Parte 4) |
Dim_Unidade |
Dimensão | Tabela calculada (DATATABLE) |
Florianópolis, Joinville, Blumenau |
Dim_TipoAtendimento |
Dimensão | Tabela calculada (DATATABLE) |
Consulta, Exame |
Dim_Tempo |
Dimensão (calendário) | Tabela calculada (CALENDAR) |
1 linha por dia, ano de 2025 |
_Medidas |
Tabela de medidas | Placeholder vazio (Power Query "Inserir Dados") | — hospeda as medidas DAX |
Seis relacionamentos, todos 1:N em sentido único, das duas tabelas fato para as três dimensões compartilhadas:
Fato_Atendimentos[Unidade]→Dim_Unidade[Unidade]Fato_Atendimentos[TipoAtendimento]→Dim_TipoAtendimento[TipoAtendimento]Fato_Atendimentos[DataAtendimento]→Dim_Tempo[Data]Fato_Indicadores[Unidade]→Dim_Unidade[Unidade]Fato_Indicadores[Tipo]→Dim_TipoAtendimento[TipoAtendimento]Fato_Indicadores[PrimeiroDiaMes]→Dim_Tempo[Data]
34 medidas DAX na tabela _Medidas, organizadas em pastas por página do relatório (Visão
Estratégica, Visão Analítica, KPIs de mês vigente, Formatação/cores). Mapa completo de qual
medida alimenta qual visual: GUIA_VISUAIS.md. Validação numérica de
cada uma, com os valores conferidos manualmente: AUDITORIA.md.
Consultas completas e comentadas em consultas_sql.sql.
- Q1 — Agregação por unidade (
COUNT+AVG), ordenada por quantidade de atendimentos decrescente. - Q2 — Unidades com tempo médio acima da média geral, via subconsulta no
HAVING. Média geral = 17h (média de todos os atendimentos) → apenas Blumenau (30h) fica acima. Nuance registrada no comentário da query: "média geral" também poderia ser lida como a média das médias por unidade (~19,17h, não ponderada); neste dataset o resultado é o mesmo nas duas leituras, mas a diferença entre ponderar por volume ou não passa a importar em bases maiores/desbalanceadas. - Q3 — Window function:
RANK() OVER (PARTITION BY Unidade ORDER BY TempoResolucaoHoras DESC), com nota sobre a diferença paraROW_NUMBER()quando há empate.
- a) Estrutura: esquema estrela (star schema).
Fato_Atendimentosno grão de um atendimento, ligada aDim_Unidade,Dim_Tempo(calendário contínuo) eDim_TipoAtendimento. - b) Cardinalidade: 1:N de cada dimensão (lado 1) para a fato (lado N), filtro de sentido único (dimensão → fato).
- c) Riscos de performance: relacionamento bidirecional desnecessário, colunas calculadas
pesadas quando uma medida resolveria, modelagem em floco de neve, chaves de texto de alta
cardinalidade em vez de chaves substitutas, ausência de tabela calendário dedicada, e DAX
com iteração linha a linha (
FILTER/SUMXmal escritos) em vez de agregações nativas.
| Objeto | Quando calcula | Ocupa memória | Contexto de avaliação | Exemplo |
|---|---|---|---|---|
| Medida | Em tempo de consulta (query) | Não | Contexto de filtro | Qtd Atendimentos = COUNTROWS(Fato_Atendimentos) |
| Coluna calculada | No refresh, linha a linha | Sim | Contexto de linha | Faixa = IF([TempoResolucaoHoras]>24,"Fora","Dentro") |
| Tabela calculada | No refresh | Sim | — | Dim_Tempo = CALENDAR(DATE(2025,1,1),DATE(2025,12,31)) |
Fonte completa em medidas_dax.dax. As três medidas pedidas, escopadas em
Fato_Atendimentos (a tabela transacional definida no enunciado da Parte 2):
Qtd Atendimentos—COUNTROWS(Fato_Atendimentos)Tempo médio de resolução (h)—AVERAGE(Fato_Atendimentos[TempoResolucaoHoras])Var. Qtd Atendimentos (mês ant.)— variação % vs. mês anterior viaDATEADD
O modelo inclui também Ranking por tempo (unidade) (RANKX) como extensão não obrigatória,
usada no dashboard da Parte 4.
Capacidade que não escalou junto com a demanda (hipótese mais forte); mudança no mix de atendimento (mais casos complexos); gargalo concentrado em uma unidade distorcendo a média; fatores de equipe (rotatividade, absenteísmo, curva de aprendizado); mudança de processo/sistema que adicionou etapas ao fluxo.
Validação: decompor por unidade e tipo, correlacionar volume × tempo, cruzar com dados de capacidade/headcount. Indicadores adicionais: produtividade por profissional, taxa de ocupação, % dentro do SLA, retrabalho e backlog.
Comparação dupla — a unidade contra o próprio histórico e contra as demais no mesmo período; segmentação do tempo por tipo de atendimento, profissional e etapa do processo; dados necessários: atendimentos × mês × tipo, headcount/escala, volume vs. capacidade, retrabalho; apresentação em uma página com achado quantificado, causa-raiz e plano de ação com responsável e prazo.
- Principais achados: volume +41,7% (12.000 → 17.000), SLA −11 p.p. (95% → 84%), satisfação −8 p.p. (90% → 82%) — deterioração contínua, com abril entrando em faixa crítica de SLA.
- Causas prováveis: capacidade operacional subdimensionada frente ao crescimento da demanda; a satisfação acompanha o SLA, indicando percepção direta do cliente.
- Impactos para o negócio: risco de evasão e dano reputacional, exposição contratual por SLA abaixo da meta, pressão de custo por horas extras e retrabalho.
- Recomendações: redistribuir capacidade para unidades/tipos críticos; dimensionar equipe pela demanda projetada; alerta automático de SLA < 90%; acompanhamento quinzenal de Volume × SLA × Satisfação.
Implementado em dashboards/painel_performance_operacional.html
(páginas Visão Estratégica e Visão Analítica), contendo os seis elementos pedidos:
KPIs principais, visão estratégica (diretoria), visão analítica (gestores), indicadores de
tendência, comparativo entre unidades e alertas de desvio de SLA (semáforo por mês).
⚠️ O comparativo entre unidades usa SLA/Satisfação/Volume estimados por unidade — o case forneceu esses três indicadores apenas no total da empresa por mês. Ver detalhe na seção seguinte.
- Indicadores por unidade (Parte 4) são uma estimativa, não um dado do enunciado. O case
fornece SLA, Satisfação e Atendimentos apenas no total da empresa por mês. Para o
dashboard responder ao slicer de Unidade — item "comparativos entre unidades" pedido na
Q10 — esses indicadores foram distribuídos por unidade de forma coerente com o desempenho
real observado na base transacional (Joinville melhor, Florianópolis intermediária,
Blumenau pior — mesma ordem do ranking de tempo de resolução da Parte 1/2). Peso de volume:
Florianópolis 40% · Joinville 35% · Blumenau 25%; peso por tipo: Consulta 60% · Exame 40%.
Os totais/médias da empresa por mês permanecem sempre idênticos ao case
(Jan 12.000/95%/90% … Abr 17.000/84%/82%) — a estimativa só abre esse total por unidade e
tipo, nunca o altera. Ver
Fato_Indicadores.tmdlpara a fórmula exata. - Tabelas calculadas em vez de import de CSV. Ver Arquitetura de dados
— decisão para manter o
.pbixautocontido e portátil. - Calendário (
Dim_Tempo) cobre o ano de 2025 inteiro, para suportar funções de time intelligence (DATEADD) mesmo fora dos meses com dado. - Tabela
_Medidasdedicada, com pastas nomeadas pela página do relatório que consome cada medida — facilita auditoria e reuso. - KPIs de "mês vigente". Os cards do relatório usam uma pasta de medidas separada
(
... (mês vigente), viaLASTNONBLANKVALUE) para sempre mostrar o último mês com dado (ex.: Abril) sem precisar filtrar a página inteira — o que quebraria os gráficos de tendência. Gráficos por mês usam as medidas base.
- RLS (Row-Level Security) não implementado. Os rótulos "perfil Diretoria" / "perfil
Gestores" nas páginas do dashboard são ilustrativos do conceito de segurança por papel;
não há pasta de roles no modelo (
modelo_powerbi/tmdl) nem papéis de segurança configurados. Ficou fora do escopo desta entrega. - Volume de dados é o do enunciado (amostras pequenas, propositalmente). As escolhas de modelagem priorizam demonstrar boas práticas (star schema, tabelas calendário, medidas centralizadas) sobre otimizações que só fariam sentido em volume de produção.
| Questão | Descrição | Onde encontrar |
|---|---|---|
| Q1 | Atendimentos e tempo médio por unidade, ordenado | consultas_sql.sql |
| Q2 | Unidades acima da média geral | consultas_sql.sql |
| Q3 | Ranking por unidade com window function | consultas_sql.sql |
| Q4 | Modelo de dados: estrutura, cardinalidade, riscos | README — Parte 2 |
| Q5 | Medida × Coluna Calculada × Tabela Calculada | README — Parte 2 |
| Q6 | Medidas DAX (quantidade, tempo médio, variação %) | medidas_dax.dax |
| Q7 | Hipóteses para o aumento do tempo médio | README — Parte 3 |
| Q8 | Investigação de unidade com +25% no tempo | README — Parte 3 |
| Q9 | Análise executiva (achados, causas, impactos, ação) | README — Parte 4 |
| Q10 | Dashboard executivo | dashboards/painel_performance_operacional.html |