Novo Livro: Pentaho na Prática

Nas listas de discussão sempre aparecem novatos perdidos, sem saber por onde começar e invariavelmente nos primeiros posts diz:

Alguém aí tem um livro, ou um tutorial, em português, para indicar?

Bom, finalmente a resposta vai ser sim! Agora existe um livro em português que ensina o Pentaho passo-a-passo!

Foi lançado hoje, dia 20/04/13, no evento Pentaho Day em Fortaleza, o livro Pentaho na Prática, o primeiro livro sobre Pentaho em português na Amazon.com.br (e em todas as outras, aliás:)

http://www.amazon.com.br/Pentaho-na-Prática-ebook/dp/B00CEQFDU0

O Livro

É uma edição Kindle, sem previsão de lançamento em papel, com 12 capítulos e vários apêndices, dedicados a ajudar o leitor a executar um projeto de BI com Pentaho de ponta-a-ponta. Ele inclui da configuração dos programas a dashboards, passando por ETL, relatórios, OLAP, metamodelos etc.

Os três autores ministraram cursos de Pentaho muitas e muitas vezes, e dão plantão no fórum nacional e internacional de Pentaho há anos. Por isso decidimos por uma abordagem que ajudasse o profissional autodidata, que tem disposição para investir no estudo da plataforma. Por isso, ao invés de documentar as principais funcionalidades da plataforma com exemplos, como é feito no grande e pioneiro Pentaho Solutions, decidimos seguir uma trilha de raciocínio, que mostra como atender as necessidades de BI de uma empresa típica, de ponta-a-ponta.

No livro você será apresentado a uma empresa fictícia que precisa ter acesso aos dados de seu sistema transacional para poder alavancar todo seu processo de decisões. A partir dessa premissa vamos mostrar como:

  • Montar rapidamente um protótipo para validação da necessidade;
  • Desenhar um Data Warehouse simples, com…
  • …o passo-a-passo para implementar um processo de ETL;
  • Entregar relatórios pré-fabricados, adhoc e cubos OLAP;
  • E montar um dashboard com CDE.

Isso tudo com instruções detalhadas e testadas, em etapas ricamente ilustradas (eu sempre quis dizer isso :-) .)

O que é isso, Companheiro?

O livro mostra como fazer muita coisa, mas para isso precisa de muita coisa também. Precisa de scripts, bases de dados de exemplos, instalação e configuração de programas acessórios como Java e Postgres etc. Daria para encher outro livro só com os assuntos paralelos.

Para melhorar a experiência de nosso leitor, criamos um site companheiro (do inglês companion site) que já vai trazer o máximo possível de coisas prontas.

No Prelo

Este é um trabalho em finalização, que foi lançado sem todos os capítulos para aproveitar o Pentaho Day que rolou hoje. Quem comprar um exemplar do PnP de hoje até a data de disponibilização da edição completa, 01/07/13, vai receber a atualização sem nenhum custo extra.

Até lá, quem tiver curiosidade de saber como o livro é, pode baixar esta versão de degustação do capítulo 3. A versão final deste capítulo terá ainda o passo-a-passo para traduzir o BI Server, configurar logs e mais algumas coisas.

Dream Team

Esse livro é filho de Fábio de Salles, este que vos fala, de Caio Moreno de Souza, nosso querido Prof. Coruja, e Cesar Domingos, um grande amigo, que eu conheci quando ele ainda trabalhava na IBM do Software Livre, a 4Linux. São dois caras bacanas, gente finíssima e que já quebraram muita pedra com o Pentaho.

Depois de algum tempo ministrando o curso de BI com Pentaho que eu havia criado para a 4Linux, eu pensei em escrever um livro – afinal, já tinha plantado uma árvore e estava no segundo filho. Na verdade, eu já não me lembro mais, mas eu acredito que a idéia do livro veio mesmo foi do Cesar.

O fato é que eu discuti a idéia com ele, que me deu o incentivo fundamental para eu criar coragem de começar o livro. Imagine, justo eu que sabia tão pouco, escrever um livro com coisas óbvias… No final das contas ele me apresentou a uma editora, que já havia publicado livros seus. Eu não conhecia nada desse mercado, e ainda me sentia inseguro. Eu não queria estar sozinho e decidi convidar o Cesar, que sempre foi um cara inteligente e legal, para ser co-autor. Não apenas ele já tinha livros publicados, mas ele sabia coisas de Pentaho que eu não entendia muito bem, como a configuração do Tomcat e do Apache, além de uma renca de outras coisas que no final das contas fazia com que ele visse o Pentaho com olhos bem diferentes dos meus.

Fomos quicando com a editora, tentando negociar algum contrato, até que um dia eu percebi que o Caio precisava fazer parte do projeto. Eu estava coletando material e organizando os capítulos e vi que uma parcela importante do que eu pretendia colocar no papel tinha sido criada, organizada e publicada pelo Caio. Tradução, dashboards, configurações, dicas, macetes etc. etc. etc. O Caio já era parte do livro, de um jeito ou de outro. E trabalhar com ele, quem já trabalhou, sabe, é empolgante. Eu não tive dúvidas: conversei como Cesar e topamos convidar o Caio para se juntar a nós.

Mais do que uma marca na minha vida profissional, mais que uma realização pessoal, trabalhar no livro precisava ser, acima de tudo, uma coisa divertida, motivadora, empolgante, e o Caio e o Cesar eram a parte que faltava. Não esperamos ganhar dinheiro com o livro – afinal, vivemos no Brasil – mas uma coisa nós buscamos e já conseguimos: estamos nos divertindo horrores!! :-)

Espero que vocês gostem. ;-)

Adendo

Estamos desativando o plugin que bloqueava o site companheiro antes do lançamento. Até vocês podem acessar os scripts nestes links:

Anúncios

Como Estragar um Painel

O título é um tanto quanto mal-educado, mas ele tem a virtude de ser claro.

Veja o dashboard abaixo, retirado de um caso real encontrado na Internet:

Como distribuir um controle ruim de forma inadequada.
Como distribuir um controle ruim de forma inadequada.

Eu removi todos os nomes dos dials, apaguei os números e, para não facilitar, eu repliquei um mesmo dial algumas vezes. Eu quero apenas mostrar o layout, não os dados, porque eu não vou citar a fonte. Se o cliente desse painel não reclamou, então quem sou eu para apontar o dedo? E depois, duvido que o autor decida mudar, que o próprio cliente entenda a razão – acho mais provável eu ser atacado que agradecido (ou mesmo ignorado.) Mas a vocês, meus leitores fiéis que buscam algum conhecimento, eu deixo aqui a dica.

Stephen Few, no livro Information Dashboard Design, explica porque o controle de dial (ponteiro) é ruim: ele ocupa muito espaço para mostrar uma informação pequena, e é difícil de comparar. Para se ter uma idéia, todos os dials acima tinham os limites diferentes. A única informação tirada da visualização de quase todos ao mesmo tempo era… nenhuma.

Observe a figura de novo: você conseguiria, em um relance, dizer quais e quantos indicadores ultrapassaram cada meta? NÃO! É preciso olhar um por um, guardando os casos especiais de cabeça, rolar a página e continuar o processo!!! É ridículo! Um painel desses pode ser muito mais útil se colocado em um gráfico de barras! Ao invés de ajudar o cliente, e facilitar tudo, ele dá mais trabalho!

A página inteira tem 13 dials. Stephen Few sugere o uso de outro controle para esse tipo de apresentação: bullet graph. Usando o Gimp e imagens do bullet chart coletadas da Wikipedia, eu refiz o dashboard. Veja abaixo duas opções de como poderia ter sido:

Recuperando um painel estragado: bullets charts na vertical.
Recuperando um painel estragado: bullets charts na vertical.
Recuperando um painel estragado: bullets charts na horizontal.
Recuperando um painel estragado: bullets charts na horizontal.

E agora? Pode me dizer, de um relance, quais e quantos indicadores ultrapassaram as metas? Quais requerem ação? Eu não apenas tornei o painel útil e prático (que são suas funções básicas – ser útil e ser prático), como ainda adicionei informação, enriquecendo a experiência!

E tudo que eu precisei foi deixar de lado uma idéia velha, que nunca funcionou direito. É isso.

Planos para 2013

Com o excelente ano de 2012 acabando – e eu em merecidas férias – é hora de pensar no que fazer em 2013. Essa é uma pequena lista de coias que eu pretendo abordar no ano que vem:

  1. Data Vault: acabei de ler o livro e estou fazendo uns testes. Podem contar como um dos meus próximos tópicos.
  2. Banco colunar: o LuciDB é um banco de dados especial para Data Warehouses, e passou da hora de eu fazer alguns testes nele. Já tenho o post bolado, só preciso implementar e medir os resultados.
  3. PostgreSQL 9.2: ele veio com algumas mudanças interessantes para Data Warehouse. Vou testá-lo e compará-lo com o LuciDB.
  4. Infobright: outro banco colunar dedicado a Data Warehouses, mas derivado do MySQL. Mesma vontade: comparar com Postgres 9.2 e LuciDB.
  5. Bonita: eu mantenho um blog sobre o Bonita Open Solution, uma solução de BPM livre e fantástica – o Pentaho do BPMS. Eu estou trabalhando numa séries de posts para testá-lo e pretendo construir uma solução de BI sobre o meu processo.
  6. Pré-Agregadas: já faz uns anos que eu quero escrever um artigo completo sobre isso. Quem sabe dessa vez vai?

Isso é o que está na minha lista, mas outras coisas devem vir. Por exemplo, quero completar a solução de BI do Apache , li um livro sobre dashboards que me deixou com algumas idéias e estou lendo um livro sobre Data Mining do qual vou testar algumas coisas também. E, é claro, conto com sugestões de vocês sobre quaisquer assuntos relacionados à BI.

Feliz Natal e Próspero Ano Novo!

Até 2013!

Definição de Dashboard

Um dashboard é uma exibição da informação que é a mais importante e necessária para atingir um ou mais objetivos, consolidada e arrumada em uma única tela tal que a informação possa ser monitorada em um relance.

Essa é a definição que Stephen Few dá no livro Information Dashboard Design. O original diz o seguinte:

A dashboard is a visual display of the most important information needed to achieve one or more objectives; consolidated and arranged on a single screen so the information can be monitored at a glance.

Ele publicou isso pela primeira vez na Intelligent Enterprise Magazine, em 17 de março de 2004 (às 14H00min, hehe.)

O mais legal é que ele chegou nessa definição depois de analisar vários exemplos. Ou seja, ao invés de postular o que deve ser um painel de instrumentos de BI e procurar evidências de que ele está correto, ele analisou vários painéis, sob vários assuntos e feito por várias empresas (desde fornecedores aos próprios clientes) e só então sumariou o que viu na definição acima.

Bom, eu não sou ninguém nessa área, como são nossos amigos Pedro Alves e Caio Moreno, mas eu concordo com ele. Primeiro porque ele interpretou o uso dado à tecnologia, capturando a realidade. Segundo, porque a função de um painel de instrumentos é, de uma olhada, captar o estado da máquina e decidir ou não pela ação (e eventualmente qual.)

E qual é a importância disso? Toda e nenhuma (Edu, essa foi por você! ;-) )

Toda, porque se alguém hoje me perguntar “o que é um dashboard?” eu vou saber responder, com uma definição sensata, prática e útil.

Nenhuma, porque se alguém decidir construir um dashboard “analítico”, do tipo que é clicável até na linha de status, que faz tudo e mostra tudo, é polimórfico, animado e tem som, ele vai construir. Quem decidir fazer qualquer coisa que não sirva para, em um relance, assimilar a informação necessária para atingir um ou mais objetivos, vai fazer. O que fica é a sempre a pergunta: serviu ao seu cliente? Entregou o que ele pediu, foi o que você prometeu? Se sim, então as palavras do sr. Few são apenas cócegas no hipotálamo (você já sentiu cócegas lá? Não? Sim? Fez diferença?) ;-)

É isso. Acabou minha hora de almoço. Vamos lá!

Departamento de BI

Empresas são divididas em partes: há uma parte que vende, outra que fabrica, outra que cuida da limpeza, outra que cuida dos computadores etc.

E quem, na empresa, cuida de BI?

A TI? Sério? “Qualé, Fábio, é claro que é a TI! Afinal, BI é um aplicativo/sistema/etc!”

Pois o fato é que BI e TI são água e óleo. Não quero dizer que eles são inimigos, mas sim que a cabeça de um cara que mantém um processo de ETL é diferente da cabeça do que cuida do servidor, um cara que escreve relatórios não necessariamente é um DBA, e assim por diante. Não dá para uma pessoa – ou um departamento – manter essas duas coisas tão distintas na cabeça, e fazer as duas bem (ou a alguém prefere fazer duas coisas mal e porcamente a uma só, bem-feita?)

Mais: quando você precisa de uma extensão da sua solução de BI, você procura o projeto de BI da TI. Já viu o tamanho do “projeto” de sistema operacional, ou de redes? Isso mesmo: não existe um “projeto” em TI que não cuide de TI! O time do ERP pode estar alocado na TI, mas é o time do ERP, não um projeto da TI.

Isso não é um fato óbvio, mas para uma empresa aproveitar tudo que BI pode oferecer ela precisa contar com uma equipe dedicada ao assunto, livre do risco de ser alocado em outras coisas, e com um “balcão” para atender à empresa. Essa não é uma idéia nova, aliás, mas está um pouco fora de moda. Muitas empresas que tentaram criar seu centro de BI fracassaram e desistiram, o que aumentou a rejeição à idéia.

Um centro de BI precisa de umas poucas coisas (fora ferramentas, infra etc.):

  1. Analistas de Negócios, para ser o ponto de contato da área de BI com a empresa. É uma função pública e notória, tal que qualquer um dentro da empresa sabe quem procurar para pedir algo de BI. Tem que ser uma pessoa com experiência na área, com habilidade de atendimento a cliente.
  2. Time de ETL, que monta e mantém os processos de carga dos dados.
  3. Time de Analistas de BI, uma equipe que acumula as funções de manter os auto-serviços da área de BI (a.k.a. tudo que o usuário faça sozinho) e atenda demandas pontuais. Por exemplo, são esses empregados que vão construir um relatório pré-formatado, um dashboard, fazer um projeto de Data Mining etc.
  4. Estatístico. Esse papel pode ser de um empregado, ou tercerizado por demanda. É ele quem realiza as análises mais sofisticadas, que são demandadas pelo time de Analistas de BI. (Um projeto de Data Mining envolve mais coisas que só fazer a análise – preparo dos dados, integração de resultados etc.)

E quando faz sentido montar essa equipe?

Normalmente, demandas de BI – acesso a dados da empresa para apoiar decisões – já são tratadas por departamentos de TI. Então, a menos que você tenha pulado através de uma máquina do tempo, vindo de antes da década de 90, você não precisa começar um projeto de BI já com departamento próprio – com certeza sua empresa já tem ao menos uma parte da TI que atende demandas de BI, mesmo que não tenha esse nome.

Quando essa parte da TI crescer ao ponto de consumir recursos de outras funções do departamento, chegou a hora de separá-la em um departamento só para cuidar de BI.

Também é uma opção a ser testada se a TI recorrentemente desvia os envolvidos nas funções de BI para tarefas do departamento. Como TI tem o mandato de manter a infra-estrutura informatizada da empresa funcionando, ela não pensa duas vezes em sacrificar os envolvidos com BI para manter servidores no ar, a rede íntegra, os sistemas rodando. Nesse cenário, a iniciativa de BI pode viver em eterno estágio de projeto zumbi: não morre de vez, mas também não está vivo. Não poder contar com informações confiáveis sobre seu negócio é um veneno lento – cedo ou tarde uma decisão errada e grande demais vai comprometer os resultados. Para evitar isso, separe o miolo de BI da TI, ou invista em uma equipe nova, à parte.

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.