Dashboards e a Modelagem de Dados

Como você coleta os indicadores que seu cliente quer ver num dashboard? Você faz um modelo dimensional, coleta os indicadores diretamente no sistema transacional ou guarda o histórico das métricas em uma tabela plana?

Vejamos uma história sobre esse dilema.

Beltrano e-Commerce

O presidente de uma empresa de varejo eletrônico (e-commerce) concluiu que se os clientes ficarem satisfeitos, as vendas aumentarão. Tendo ouvido falar sobre dashboards, ele encomenda um projeto de dashboard. Ele ver quer o seguinte:

Dashboard $$$ vs. :-)

A satisfação é medida por um e-mail enviado depois que o pedido foi entregue. O e-mail pergunta “você ficou satisfeito por comprar conosco?” e dá dois links: Sim e Não. Depois de uma semana sem resposta, assume-se como negativa.

A empresa contratada monta o projeto, com uma consulta (diária) direto sobre a base da empresa, que atualiza o painel. Fácil, simples, direto. Bom.

Bom?

Vendas vs. TI

O presidente expõe o painel para toda diretoria e delega o acompanhamento desse painel ao diretor de vendas, com a missão de fazer crescer a satisfação para assim conseguir fazer crescer o faturamento.

O diretor de vendas olha o ponteirinho de vendas no amarelo, indo para o vermelho, vê a satisfação também no amarelo e decide agir: começa a pestear TI com um monte de pedido de relatórios para tentar entender o que está acontecendo com a satisfação, e como tentar resolver isso. Depois de algum sofrimento, ele liga para empresa de BI e pede uma coisa nova: gráficos.

A consultoria de BI estabelece uma rotina que pega os índices diários e guarda-os em uma tabela à parte. Com essa tabela e mais a consulta do indicador diário, o dashboard é atualizado e passa a mostrar isso:

Indicadores, agora com histórico.

“Beleza”, ele pensa, “dá para ver que o faturamento não tem nada a ver com a satisfação – ainda.” Mas o que está causando essa variabilidade na insatisfação?

TIrceira Guerra Departamental

É claro que a resposta tem que estar nos dados da empresa. O que faz nosso audaz diretor? O que qualquer um faria: arranjar um estagiário da TI para tirar relatório sobre relatório – e dane-se o impacto no on-line, o trabalho do estagiário etc.

Uma semana de dores e um pouco de sangue nas paredes mais tarde, o diretor – já sem saber o que olhar – ouve uma conversa de corredor: “ai, menina, outro e-mail de cliente reclamando de pedido atrasado! Só hoje já são três!”

“Opa! Prazo! Como eu não pensei nisso antes? Aqueles folgados do meu departamento não dão conta da bucha!” Toca chamar a consultoria de BI outra vez: agora para adicionar mais um par ponteiro-histograma medindo o prazo de entrega. A consultoria expande a tabela que media a satisfação e, nem uma semana depois, entrega o resultado:

Prazo em vermelho na nova versão do poderoso painel.

Bombando

Animadíssimo, (finalmente!) equipado para medir e controlar o desempenho de sua equipe, ele convoca uma reunião com o presidente e a diretoria e cava a própria cova sem saber: “a origem da insatisfação de nossos clientes”, anuncia ele, “é a demora em nosso processo de vendas. Para resolver isso já encomendei a extensão de CRM para o módulo de vendas ao fornecedor de nosso ERP, incluindo capacitação para black belts de processo com vistas a reengenheirar nosso foco em customer satisfaction blá blá blá…”

Claro que ele se deu mal.

Processo de Negócio

Nosso diretor falhou pelo motivo óbvio, e raro no mundo real: não conhecia seu próprio negócio. Se ele conhecesse, teria visto que o processo de venda não acaba na sala dos vendedores, nem tampouco no estoque. Bastava ele ter testado o próprio serviço que entenderia o processo de venda:

Página da Beltrano e-Commerce pela qual o cliente acompanha a compra.
  1. O cliente coloca o pedido via Internet.
  2. O financeiro processa o pagamento.
  3. Com o pagamento liberado, o estoque prepara o pedido e entrega para a transportadora.
  4. A transportadora entrega.

Esse processo ainda pode ser refinado. Por exemplo, o pagamento pode ser processado via cartão, boleto ou débito em conta, e cada opção dessas gera mais informação.

Para o analista de negócio descobrir se seu processo está impactando as vendas ele precisa, antes de mais nada, medi-lo. E é por isso que a primeira pergunta feita no método de modelagem estabelecido por Ralph Kimball é “Qual é o processo de negócio?” Sem divisar e medir esse processo, não há como entender o funcionamento da empresa, nem como entender seu próprio negócio.

Modelagem Dimensional Relida

Ralph Kimball define processo de negócio como:

“Um processo de negócio é uma operação importante na organização do cliente, suportada por um sistema legado (ou sistemas), de onde é possível extrair dados para o data warehouse.” (tradução minha)

Kimball, Ralph; Caserta, Joe. The Data Warehouse ETL Toolkit. 1ª edição. EUA: Wiley Publishing Inc. 2004.

Ele prossegue nessa linha comentando que ele não se refere a departamentos ou funções, e que um processo de negócio pode varar as divisórias corporativas. No fundo, o truque está nesta frase:

(…)uma operação importante (…) suportada por um sistema(…)

Não é raro quem desenha modelos dimensionais deixar escapar a importância desse paradigma. Por quê isso é tão importante? Simples: por qualquer organização vive montada em processos. O funcionamento do negócio é intimamente relacionado aos processos que a empresa executa.

Dashboard Reloaded

Se você medir apenas algumas pontas, como a entrada e a saída, ou um valor agregado no tempo, não terá dados suficientes para entender a origem de seus problemas. E foi exatamente isso que aconteceu com o nosso intrépido e inocente diretor. Ele acreditou 1) que a relação proposta pelo presidente era real 2) que esse problema estava contido em poucas variáveis. Claro que ninguém, em 2012, tem mais essa inocência, mas por incrível que pareça, é muito comum essa inocência aflorar quando o assunto é BI, dashboards, DWs e que tais. Rapidamente esquecemos que os “indicadores” são exatamente isso: indicam o que se passa, mas não são suficientes para decisões. Para se melhorar os indicadores é preciso entender o negócio, e isso só pode ser feito se o processo que governa esse negócio for estudado.

Usando a figura mostrada como base para nosso processo, temos o seguinte modelo:

Estrela (modelo dimensional) para o processo de vendas da Beltrano e-Commerce

A partir desse modelo podemos tentar achar a causa da insatisfação dos clientes. Compare a quantidade de informações disponíveis para um analista nesse modelo com o que a empresa de BI havia entregado (compare apenas com a tabela fato, para sermos mais justos):

Dados para o dashboard original.

Não dava para saber nem quem era o cliente!

Conclusão

Em essência, o painel montado no exemplo está correto e atende à necessidade da empresa de monitorar duas variáveis que de fato estão relacionadas: vendas e satisfação do cliente (ninguém precisa de uma justificativa matemática para isso, não é?)

Ele é insuficiente, porém, para causar impacto no faturamento da empresa. Não é possível entender uma empresa sem um modelo dimensional adequado.

O que faltou, portanto, foi:

  1. Montar um Modelo Dimensional do processo de negócios que se deseja entender.
  2. Coletar os indicadores a partir desse modelo dimensional.
  3. Disponibilizar uma visão OLAP a partir dos indicadores. Essa funcionalidade permitiria, por exemplo, descer até os registros com insatisfação e permitir relacionar à essa insatisfação o prazo de entrega (a là BSC.)
  4. Um projeto sério de análise desses dados. Poderia ser manual, se o volume de dados ou a complexidade do processo for pequenos, ou um projeto de Data Mining que buscasse resposta às perguntas “insatisfação impacta em lucratividade?”, “qual a mais provável causa da insatisfação de meus clientes estão insatisfeitos?”, “qual é o impacto da insatisfação na minha lucratividade?”, “quanto estamos perdendo em pedidos de clientes que não voltam?”, “como evitar essa perda?” etc.

O Modelo Dimensional liga os dados da empresa à inteligência de negócio. Coletar métricas esparsas, ligadas apenas intuitivamente, não trará o poder de entedimento que uma representação dimensional traz, nem será um firme apoio à tomada de decisões.

Portanto, na próxima vez que te pedirem um dashboard (ou que você pensar em requisitar um), negocie entregar um modelo dimensional por trás. Seu cliente vai te agradecer mais tarde.

É isso.

Anúncios

Estimando Projetos de ETL

Eu estimo a duração e o esforço necessários em projetos de BI baseado na minha experiência. Eu fiz uma auto-análise e redigi abaixo os passos que eu sigo mentalmente para chegar em um número inicial.

Coletando os Parâmetros

A minha mecânica para estimar o trabalho de desenvolvimento do ETL de um DW é relativamente simples. Eu procuro descubrir os seguintes números:

  1. Quantos analistas você terá dedicados integralmente a construir o ETL. (Além dos analistas você vai precisar de um gerente.)
  2. Quantas origens de dados você terá que tratar. Fonte de dados é tudo que possa vir a alimentar o DW: bancos relacionais de sistemas transacionais, files Adabas, arquivos texto/excel, páginas web etc.
  3. Quantas fatos e quantas dimensões o MD deve ter. É impossível responder essa pergunta com precisão antes de o MD ser efetivamente construído, mas você pode estimar esse número:
    1. Qual é a quantidade de processos automatizados pelo seu sistema transacional? Cada um equivale grosso modo a uma fato.
    2. Quais são os parâmetros que provavelmente filtrarão as análises? Daí conte o número de atributos que têm a resolução mais fina. Por exemplo, se você vai filtrar por ano, mês e dia, a maior resolução é obtida com dia. Ignore os outros atributos e conte um atributo só. Se as análises serão feitas contra bairro, cidade, estado, o atributo que dá a maior resolução é bairro. Como cidade e estado são do mesmo tipo (geográfica), conte mais um atributo. No final você vai ter uma lista inicial de dimensões.
    3. Exemplo: se quisermos analisar o tempo de atendimento de balcão, você precisará medir a data e hora inicial (DHi), a data e hora final (DHf), posto (cidade-bairro-posto), atendente (sexo-idade-escolaridade-nome-cpf-etc.), demanda, resolução (resolvido/pendente), tipo (reclamação/elogio/pagamento/negociação/etc.), cliente (PF ou PJ, cada qual com sua lista de atributos). Temos uma fato (atendimento) e 8 dimensões (se cliente virar uma tabela só, ou 9 se for em duas.)
  4. Volume de dados. Pode ser o tamanho de todas as bases em bytes e quanto ela cresce por tempo (dia ou mês), ou (preferível) quantidade de linhas iniciais adicionadas regularmente (dia ou mês) às fontes de dados.
  5. Os dados de origem estão limpos ou sujos, do ponto de vista do domínio de cada coluna/campo.
  6. Os dados de origem estão limpos ou sujos, do ponto de vista do relacionamento entre as fontes. Por exemplo: os dados do cliente estão divididos entre duas fontes (CPF, RG e nome numa, RG, endereço e estado civil em outra; ela é suja se houver lacunas ou diferenças de formato na chave, o RG.)

Definindo o Processo de Estimativa

Daí eu apela para a minha experiência. Supondo que um desenvolvedor seja capaz de entregar 4-5H de trabalho por dia: (alta produtividade!)

  1. Um desenvolvedor PDI proficiente leva de uma a duas semanas para cada dimensão ou fato.
  2. A medida que essa experiência cai, o tempo aumenta. Uma dimensão pode levar até mesmo um mês para ficar pronta se o analista começar o projeto sem conhecimento da ferramenta (ou mesmo com um curso.) Isso ocorre por que cada processo demanda um conjunto de truques particular, e o analista leva um tempo para internalizar a ferramenta e desenvolver seu repertório de macetes – como em qualquer outra ferramenta, aliás. Como passar do tempo esse número melhora, graças ao acúmulo de experiência do analista.
  3. A quantidade de fontes de dados acrescenta mais alguns dias nesse número: de nada a alguns dias (até uma semana) a mais por fonte de dados. Isso ocorre por que pode ser necessário algum estudo para integrar as origens (pior caso) ou apenas um join pode ser suficiente (melhor caso.)
  4. Volume de incremento no tempo: mais dois ou três dias para desenhar uma mecânica de tratamento de incrementos, que pode ser aplicada em todas as cargas. Esse tempo tende a sumir, diluído entre todos os processos de carga de dimensões e fato.

Sujeira: esse é o fator mais selvagem. Ele pode até dobrar o tempo de encerramento do desenvolvimento, a depender da quantidade de erros e sujeiras na base, e a capacidade do cliente em lidar com erros no DW (às vezes a sujeira não afeta a análise, às vezes a torna impossível.) Normalmente o impacto da limpeza de dados só vai ser conhecido no primeiro teste do processo e por isso não é usado para estimativas.

Estimando…

Então, para nosso exemplo com 8 dimensões, uma fato, com um banco relacional como única origem, dados 100% limpos e dois analistas (mais um gerente) você tem:

9 x 1 semana (cinco dias) / 2 analistas = 22,5 dias (~3 semanas).

É seguro triplicar esse número, para incluir todas as dificuldades não-previstas e adicionar um mês de overhead no início do projeto. Então temos 9 semanas + 1 mês = 13 semanas, o que dá uns três meses, mais ou menos, até a primeira versão beta do processo. Leva-se mais um ou dois meses entre ajustar o processo para produção e homologá-lo (controle de qualidade.)

Lembre-se que você vai precisar, também, estimar o tamanho da plataforma para entregar o refresh na latência requisitada por seu cliente.

Escrevendo na Pedra

Isso é só um parâmetro inicial, descontado o levantamento de requisitos, documentação etc. Com esse número em mãos eu reviso tudo que eu sei sobre o projeto antes de ele começar e uso minha intuição para ajustá-lo. Não raro eu entrevisto os analistas para entender o fator tarimba de cada um e verificar se eu fui otimista ou pessimista. Porém, esse número nunca é uma medida, mas sim apenas um chute elaborado (ou em bom inglês, um educated guess)  – variáveis desconhecidas podem mudar tudo completamente.

Quem é do ramo já deve ter percebido que o volume de variáveis desconhecidas e incertezas sugerem o uso de Scrum para gerenciar o projeto. Como o tamanho de uma transformação é de duas ou três semanas,  possivelmente eu adotaria isso como tamanho inicial das sprints, para fazer com que cada uma equivalha a entrega de uma transformação por analista. Após uma ou duas sprints a precisão desse número pode melhorar bastante.

O que você achou? Bate com o que você faz? Deixe seu comentário!