Dashboards em Power BI para indicadores sociais

Um dashboard útil responde perguntas não apenas exibe gráficos. Em projetos sociais, a diferença entre um painel decorativo e um painel acionável está em começar pelas decisões que gestores, conselheiros e financiadores precisam tomar, e desenhar a visualização de trás para frente. Nesta versão ampliada, detalhamos o caminho completo que aplicamos em pesquisas de campo: da exportação dos microdados do KoboToolbox à publicação de dashboards com atualização automática, segurança em nível de linha e camadas de governança compatíveis com editais e prestação de contas.

1. Comece pelas perguntas, não pelos gráficos

Antes de abrir o Power BI, escrevemos com o cliente uma lista de perguntas de decisão: “quantas famílias em risco alimentar estão sem acompanhamento há mais de 60 dias?”, “qual território concentra a maior taxa de evasão do programa?”, “o custo por beneficiário atendido cabe no orçamento remanescente?”. Cada pergunta vira um bloco visual um KPI, um mapa, uma tabela — e nada que não responda a uma pergunta entra na primeira versão. Essa disciplina reduz a poluição visual e torna o painel legível em reuniões de conselho, onde o tempo de atenção é curto.

2. Pipeline desde o KoboToolbox

A ponte entre o campo e o Power BI é o ponto mais frágil do processo. Fazemos a extração via API REST do KoboToolbox (endpoint /api/v2/assets/{uid}/data) autenticando com token pessoal, o que permite atualização programada sem baixar CSV manualmente. No Power Query, aplicamos tipagem explícita a cada coluna, tratamos select_multiple como colunas booleanas separadas e criamos uma coluna data_ref derivada do _submission_time. O resultado é um dataset versionado, previsível e auditável.

3. Modelagem em estrela: performance e clareza

O erro mais comum em painéis sociais é modelar tudo em uma tabela única e larga. Isso funciona no piloto e colapsa quando o banco passa de algumas dezenas de milhares de linhas. Adotamos o esquema em estrela: uma tabela-fato central (fato_respostas) com uma linha por questionário e chaves numéricas para dimensões (dim_tempo, dim_localidade, dim_perfil, dim_programa). Além de acelerar filtros e cálculos DAX em uma ordem de grandeza, essa separação torna as medidas legíveis e reaproveitáveis entre projetos.

Tabela	Tipo	Exemplos de colunas
fato_respostas	Fato	id_questionario, id_tempo, id_local, id_perfil, valor
dim_tempo	Dimensão	data, ano, trimestre, mês, semana ISO
dim_localidade	Dimensão	UF, município, IBGE, território, latitude, longitude
dim_perfil	Dimensão	faixa etária, sexo, raça/cor, escolaridade

4. Medidas DAX que gestores realmente usam

Medidas DAX bem escritas separam o painel “bonitinho” do painel útil. Priorizamos indicadores comparáveis no tempo e com contexto:

• Cobertura territorial: DIVIDE(DISTINCTCOUNT(fato[id_local]), [total_locais_previstos]).
• Variação mês a mês: [atual] - CALCULATE([atual], DATEADD(dim_tempo[data], -1, MONTH)).
• Meta acumulada: compara execução com metas pactuadas no plano de trabalho essencial em prestação de contas para editais.
• Custo por beneficiário: integra a fato-financeira e viabiliza análises de eficiência exigidas por financiadores.

Um dashboard que não deixa clara a distância entre execução e meta é um dashboard mudo. Toda página deve responder, em cinco segundos: “estamos no caminho ou não?”.

5. Governança: RLS, documentação e atualização

Painéis com dados sensíveis, famílias em vulnerabilidade, informações de saúde, dados de crianças e adolescentes exigem controles reais, não apenas login. Configuramos Row-Level Security (RLS) por território ou por programa, de modo que cada coordenador enxergue apenas o recorte pelo qual é responsável. As medidas DAX são documentadas em um dicionário público do projeto, com fórmula, unidade e responsável pela definição. E a atualização incremental é agendada no Power BI Service para reprocessar apenas os últimos 30 dias de dados, mantendo o histórico intacto e o consumo de gateway sob controle.

6. Design que respeita o tempo do decisor

Adotamos três regras visuais inegociáveis: (i) no máximo 5 a 7 indicadores por página, sempre com título em linguagem natural; (ii) paleta consistente com identidade do projeto, evitando arco‑íris e vermelho decorativo vermelho só quando algo exige ação; (iii) cada gráfico acompanhado de uma frase-resposta curta (“cobertura caiu 8 p.p. no último trimestre”) gerada por medida DAX condicional. Esse conjunto transforma o painel em uma ferramenta de leitura rápida, útil tanto em reuniões técnicas quanto em audiências públicas.

7. Checklist final antes de publicar

• [ ] Todas as perguntas de decisão têm ao menos um visual que as responde.
• [ ] Modelo em estrela, sem relações bidirecionais desnecessárias.
• [ ] RLS testado com pelo menos dois perfis distintos.
• [ ] Atualização agendada e alerta de falha configurado.
• [ ] Dicionário de medidas DAX versionado junto ao arquivo .pbix.
• [ ] Acessibilidade: contraste mínimo AA e ordem de leitura definida.

Quando essas camadas convivem, o dashboard deixa de ser um artefato de fim de projeto e passa a ser infraestrutura de decisão a mesma tela que o financiador consulta na quinta-feira é a que orienta o coordenador de campo na segunda. É essa continuidade entre coleta, análise e ação que diferencia dados sociais bem tratados de relatórios que envelhecem na gaveta.