Qlik Sense e QlikView

Quem tem Qlik raramente quer sair dele.

O Qlik costuma chegar até nós por um de dois caminhos. Ou a empresa investiu nele anos atrás, o consultor que montou tudo saiu, e agora ninguém entende o script de carga que sustenta a operação. Ou o modelo associativo é exatamente o que o negócio precisa, e a discussão é como extrair mais dele.

Nos dois casos o trabalho é o mesmo: entender o que já existe antes de propor qualquer coisa. Qlik mal documentado é um ativo caro que ninguém consegue evoluir e reescrever do zero raramente é a resposta mais barata.

Da extração ao app publicado

O caminho é o mesmo de qualquer projeto sério de BI. O que muda é a ferramenta em cada etapa.

• Script de carga. A camada de ETL do Qlik, escrita para ser lida por outra pessoa depois: seções nomeadas, variáveis no topo, conexões parametrizadas em vez de caminhos fixos espalhados pelo código.
• Camada de QVD. Extração e transformação separadas em estágios, com os dados intermediários persistidos. É o que faz a recarga cair de horas para minutos e deixa de bater no sistema de origem toda vez.
• Modelo de dados. Modelo estrela, chaves sintéticas eliminadas e referências circulares resolvidas. O motor associativo é rápido, mas não perdoa modelo mal montado.
• Expressões e set analysis. Cada indicador definido uma vez, com a regra de negócio registada ao lado. Comparativos de período e recortes que não quebram quando o utilizador filtra outra coisa.
• Construção do app. Um recorte por perfil e uma navegação que aproveita o que o Qlik faz de melhor: seguir o raciocínio de quem investiga, em vez de obrigar a voltar ao começo a cada pergunta.
• Publicação governada. Streams organizados, Section Access por perfil de acesso, recarga agendada e registo compatível com o RGPD.

QlikView e Qlik Sense não são a mesma coisa

QlikView entrega análise guiada: o documento é desenhado por quem constrói, e o utilizador navega dentro do que foi previsto. Qlik Sense é self-service: o utilizador monta as próprias visualizações sobre o modelo publicado.

São filosofias diferentes, e a escolha não é sobre qual é mais novo. Operações com processo fechado e utilizador que precisa de resposta rápida costumam funcionar melhor no formato guiado. Equipas analíticas que exploram dado por conta própria rendem mais no self-service. Atendemos os dois, e quando faz sentido migrar, dizemos e quando não faz, também.

O que fica com você no fim

A entrega termina quando a sua equipa consegue evoluir o que construímos sem depender de nós.

• O script documentado. Comentado seção por seção, com a origem de cada tabela e o motivo de cada transformação.
• O dicionário de métricas. A regra de negócio de cada indicador escrita em português, não só em set analysis.
• Capacitação da equipa. Para criar novas visualizações sobre o modelo existente sem partir o que já está em produção.
• Plano de manutenção. O que fazer quando uma fonte muda de formato ou a recarga começa a demorar demais.

Como conduzimos

Começamos por um diagnóstico do que já está no ar: script, modelo, tempo de recarga e quais apps as pessoas realmente abrem. Em ambiente Qlik antigo esse levantamento costuma revelar metade do trabalho logo de cara e é melhor descobrir antes de assinar. Em seguida desenhamos a arquitetura e apresentamos o escopo para aprovação. A implementação acontece em ciclos curtos, com o primeiro app em produção rápido.

Como medimos o resultado

Os indicadores de sucesso são combinados no início, e são de negócio, não de ferramenta. Nos nossos projetos os mais frequentes são horas de trabalho manual devolvidas à equipa, redução de perda operacional e ganho de margem por recorte de carteira.