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

2 comentários sobre “Dashboards e a Modelagem de Dados

  1. Bem, levando em consideração que meu doutrinador original se chama Fábio Salles, isso não foi nenhuma novidade para mim! DW da cabeça!

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s