Cheiro de Data Mining

Em 31/12/2016 eu passei na Droga Raia da Alfonso Bovero, que fica em frente ao Pão de Açucar. Estamos na Zona Oeste de São Paulo, um bairro classe média.

Essa é a dita cuja que lançou a moda.

Peguei o que fui buscar e passei no caixa. Lá, a atendente me recepcionou:

– Informe seu CPF, por favor.

Não notou nada?

Claro que não, que cabeça a minha! Deixe-me contextualizar melhor.

O governo estadual de São Paulo instituiu um programa de rebate de impostos. De maneira resumida, funciona assim: ao fazer qualquer compra, você registra o cupom fiscal no seu CPF. Quando esse cupom é processado pela Secretaria da Fazenda do Estado, um pouco dos impostos dessa nota são computados para você. Daí, em certas épocas do ano você pode sacar esse crédito e levar o dinheiro embora, para usar como bem entender.

A coisa se espalhou e agora outros estados e até cidades adotaram uma prática semelhante. Eu sei que existe um programa análogo, por exemplo, na cidade do Rio de Janeiro, na prefeitura de São Paulo, em Brasília e no Paraná.

Vai daí que, pela cidade inteira, o tempo todo, ouvimos os caixas perguntando:

  • Deseja informar seu CPF?

O que aconteceu naquela véspera de ano novo foi uma sutil mas perceptiva mudança na pergunta. Até então era dito:

  • Deseja informar seu CPF?

Naquele dia me disseram:

  • Informe seu CPF, por favor.

Ali! Notaram? Eles trocaram o deseja? por informe!.

Isso significa que passaram a forçar a coleta do CPF. Eu não tinha mais a opção, não queriam saber se eu queria ou não: informe!

Como eu já sou macaco velho de BI, que entre outras coisas testemunhou o nascimento do Cartão Mais, do Pão de Açucar, eu fiquei de orelhas em pé na hora que o verbo habitual não deu as caras.

Só que além de macaco velho, eu sou um cientista, com o péssimo hábito de só acreditar em fatos confirmados.

E eu confirmei isso: perguntei à caixa se ela havia recebido uma orientação, recentemente, para requisitar o CPF do cliente, ao invés de simplesmente perguntar se ele desejava informar o CPF para nota. A reação foi inesperada: com um sorriso de satisfação (porque alguém notou que ela estava fazendo algo novo ou certo?), ela afirmou que sim, que agora eles estavam registrando o CPF de todos os clientes, mesmo os que não queriam reembolso de impostos.

Ah, era muito para mim! Eu precisava saber mais!

“Porquê?”, eu perguntei. “Para contar quantos clientes passam na loja todo dia.”, foi a resposta. “Afinal”, ela continuou, “não dá para contar a quantidade de visitantes apenas pela quantidade de vendas, pois um cliente pode voltar várias vezes no mesmo dia.”

Eita preula! A mulher sabia mais de BI que muita gente da área!

Traduzindo: não apenas pediram a ela para fazer isso, e obviamente deram a fórmula – quais palavras usar, a frase exata – mas também explicaram a ela o por quê disso.

Venda por Cliente, por Dia, por Loja…

Te lembra alguma coisa?

Fa-Fe-Fi-Fo-Fum! Sinto Cheiro de Data Minum!

Tá, não rimou, mas vocês lembraram da música do gigante Willie, do Mickey e o Pé de Feijão. :-)

Fifi? Eu não conheço nenhuma Fifi…

Apenas se uma empresa ignorar o valor dessa informação é que ela vai deixar de coletar esses dados. Qualquer empresa que se preocupe em crescer e/ou faturar mais vai querer conhecer melhor sua clientela, como ela se comporta e o que pode ser feito para fidelizá-la, para fazer com que ela prefira ir comprar ali e não do outro lado da rua.


Esse é, talvez, o caso mais clássico de BI. Eu escrevi um post sobre ele, que você pode conhecer clicando aqui.


Conclusão obrigatória: tem que haver ali um trabalho de BI em andamento, já sendo implantando.

O que me leva a concluir isso é que eu não fiz uma pergunta fechada, do tipo que ela poderia ter respondido com sim ou não, e boas. Eu perguntei porquê e ela foi exata: para contar quantos clientes passam pela loja, por dia. Se fosse por algum outro motivo, fiscal por exemplo, dificilmente teriam dito algo a ela.


Eu escrevi o rascunho desse post em janeiro de 2017. Eu achei muita nóia minha, que eu estava vendo coisas, e resolvi botar o assunto para dormir enquanto tentava conseguir mais informações, algo que corroborasse minhas pirações.

Bom, eu decidi completar este post justamente por que eu consegui. Melhor dizendo, eu não consegui: conseguiram para mim. De uma hora para outra começaram a pulular situações iguais por todo canto: na hora de pagar não me perguntavam mais se eu queria, mas sim me pediam meu CPF. E não apenas em outras lojas da Droga Raia, mas em outras cadeias de farmácias e de outros tipos de loja!

O melhor de todos foi o que eu ouvi em uma Kalunga: “porque estamos pedindo o CPF? Ah, meu chefe falou que é porque senão não podemos efetuar trocas”. Não é, não.. Só que o chefe deve ter achado tão difícil explicar que deixou por isso mesmo. :-D

Conclusão

De repente, virou moda pedir o CPF. Aliás, pelo que este artigo de maio de 2016 fala, parece que virou um traço cultural. Talvez os lojistas nem estejam usando ou entendendo o que está acontecendo direito, mas sabem que é importante fazê-lo.

Eu vejo dois aspectos positivos nessa tendência:

  • O serviço que nos é prestado por todas essas empresas tende a ficar melhor. Ao longo do tempo, os esforços em sabermos quem somos e como nos atender melhor vai redundar em maior qualidade na nossa experiência de compra, em nossas interações comerciais. Isso é bom para nós, consumidores;
  • Até hoje ainda é difícil falar de BI em qualquer empresa e escapar da dobradinha base de dadosferramenta de visualização. Uma mudança cultural, que perpasse a nossa sociedade, vai abrir espaço para conversar sobre assuntos mais especializados, sobre temas mais sofisticados. Isso é excelente, porque atua para expandir o mercado de BI e as oportunidades. Uma coisa obrigatória que vem com a identificação do cliente é um Armazém de Dados. Se alguém estava em dúvida sobre sua necessidade, isso vai ajudar a reduzi-las, quiçá eliminá-las.
1: Pão de Açucar, 2: Drogaria São Paulo, 3: Droga Raia.

E cá entre nós, já não era sem tempo de isso começar a acontecer! Afinal, levou uns 15 anos para o conceito do Cartão Mais atravessar a rua e chegar na farmácia! Como é que ainda existe quem não se preocupe com sua clientela?!

;-) Até a próxima!

Ladyvaulk – O Feitiço de Dataváulquila

Faz uns dois anos, e começou assim: minha mão estava coçando para testar Data Vault. Eu tinha feito alguns experimentos, tinha implementado um caso pequeno, mas ainda queria explorar mais. Queria um volume maior, mais complexidade, algo mais difícil.


Cuidado com o que você deseja, porque pode conseguir.


E eu consegui. Quem mandou desejar? Um dos softwares que o SERPRO usa é o Zabbix. Resumidamente, ele server para monitorar ativos, como roteadores, servidores e hubs, coletar métricas do parque informatizado e assim por diante. Consulte a página do projeto Zabbix para saber mais.

Como o SERPRO é uma coisa imensa, tudo está sempre no limite, no máximo, no maior volume, no mais complicado. São milhares de máquinas, dezenas, se não centenas de redes e sub-redes, kilômetros de cabos e tudo mais. Não vou entrar em detalhes técnicos para não correr o risco de falar besteira mas, resumidamente, o povo super-criativo conseguiu botar o esquema todo para a funcionar dentro do que era possível e desejável. Há um vídeo com uma apresentação sobre esse assunto neste link, feita por um dos empregados do SERPRO.

Uma das soluções adotadas passava por uma concentração de dados, que era atualizada periodicamente e servia para apresentar certos dados coletados pelo Zabbix.

Enter Linstedtman!

A pessoa responsável por essa necessidade foi aluna em um dos meus treinamentos de Pentaho, e veio me procurar imaginando se o PDI não poderia ajudar nesse caso. Afinal, consolidar dados é justamente a função dele.

As atualizações precisavam ocorrer a cada 30 minutos, no máximo, ou idealmente a cada 5 minutos ou menos. Apesar do grande espalhamento do sistema, como o volume dos dados capturados era, em si, até modesto, a baixa latência do refresh não era um problema.

O que realmente dava trabalho era a integração dos dados. Poderíamos, por exemplo, modelar os dados em uma estrela dimensional, definindo os atributos de interesse como dimensões e adotar uma fato artificial para correlacionar os dados entre si. Daria certo mas, depois de algumas mudanças nas fontes dos dados, as tabelas dimensionais acabariam ficando complicadas demais. Ou seja, logo no início do projeto daríamos de cara justamente com o ponto fraco da metodologia – a dificuldade de manutenção. Não era uma opção.

Poderíamos simplesmente replicar o layout de origem, mas isso implicaria em capturar os dados em uma granularidade confusa e, de novo, na primeira alteração na origem, quebraria todo histórico.

Não havia alternativa. Eu não queria admitir que estava usando os problemas como justificativa, mas no final, os problemas justificaram mesmo a escolha óbvia.

Usar um Data Vault. :-)

The Curse

Como havia uma certa urgência, trabalhamos em equipe: eu analisava os sistemas de origem para desenhar o Data Vault, e ia tirando dúvidas sobre os conceitos de negócio com os especialistas. Em pouco tempo (duas semanas, se não me falha a memória), foi montado o diagrama de tabelas, os modelos de transformação PDI e, com isso, um processo de ETL completo, de cabo a rabo, saiu do nada.

Como não era um grande volume de dados, a primeira carga levou coisa de uns trinta minutos, um pouco menos que isso. A partir da segunda carga, o processo de ETL terminava em menos de um minuto, graças ao fato de o DV usar CDC para tudo. Quando a rede está muito lenta, leva quase três minutos. Finalmente, por garantia, decidiu-se manter uma latência de 30 minutos (i.e. meia-hora), que dá uma boa margem para falha e recuperação, e ainda atende a necessidade.

E isso tem funcionado nesses últimos dois anos, sem parar, sem falhas, sem soluços, liso como gelo. De vez em quando aparece uma situação nova, e toca lá eu ir atrás de entender como usar Data Vault para resolver.

Um dia destes, batendo-papo e conversando sobre o projeto, a minha ficha caiu.

Sabe, eu não implementei esse lance – eu apenas desenhei um template, um gabarito de transformações para hubs, links, satélites e satélites de links. Nem tampouco desenhei o diagrama de dados: passei as regras de modelagem para a pessoa e deixei-a desenhar sozinha. Eu revisava tudo e corrigia os erros cometidos, mas eu mesmo não pus um dedo no processo de ETL!

É verdade que eu montei a configuração do PDI, configurei a captura de logs de cada transformação, e ainda montei um job que chama tudo. Mas de novo: montei na minha máquina, mandei para o projeto, expliquei como instalar no servidor e não fiz mais nada.

E tudo ia crescendo, ganhando tabelas, coletando dados… E a coisa rodando, e o monstro ficando maior, e maior e novos problemas aparecendo e eu só dizendo o que fazer. No máximo eu examinava os dados remotamente, para descobrir porque isso ou aquilo não estava dando certo, diagnosticava e, quando muito, corrigia os templates. A pessoa do projeto regerava as transformações problemáticas e tudo ia em frente.

Vocês não perceberam ainda né? Eu também demorei:


O projeto foi completamente, totalmente, 100%-mente construído, implementado e está sendo gerenciado por um profissional que não criou nada daquilo.

O projeto foi completamente, totalmente, 100%-mente construído, desenhado e planejado por um profissional que não implementou uma única transformação!


Sacaram? Eu não repeti a mesma frase duas vezes, leiam de novo.

Vou escrever ao contrário e vamos ver se fica mais claro:


O grau de automação do desenvolvimento foi tão grande, e em nível tão detalhado e profundo que a construção do modelo de dados e processo de ETL foi feito por um profissional que ignorava quase que completamente a técnica (DV) por trás.

E mais: a flexibilidade e resiliência da Metodologia de Data Vault é tão grande que foi possível desenvolver tudo – modelo e ETL – entendendo quase nada do negócio!


Nossa ignorância mútua dos problemas um do outro só não era total porque aos poucos fomos pegando partes da coisa – eu entendendo um pouco de Zabbix e o outro lado um pouco de DV e PDI. Mas nunca precisamos explicar nada sobre os detalhes de nada um ao outro!!!!!!!

:-O

Conclusão

Na esbórnia cultural que foi a década de 80, um dos filmes mais aclamados foi Ladyhawk, que contava a história de um casal amaldiçoado por um sacerdote malévolo. A maldição jogada nos dois fazia com que nunca se vissem, a não ser por uns breves segundos ao anoitecer e ao raiar do dia. Esse era o tal “Feitiço de Áquila”, que o nome do lugar: durante o dia a mulher era um gavião, e durante a noite, quando ela voltava à forma humana, o cara virava um lobo.

Preciso pedir perdão a vocẽs, porque foi mais forte que eu. Não deu para resistir.

Eu tive que brincar com isso.

A narrativa épica de um projeto de sucesso na era ágil! Quem projetou o ETL não implementou, e não sabia nada do negócio, enquanto que quem entendia tudo do negócio não sabia nada nem do modelo de dados, nem do ETL que estava  implementando com as próprias mãos (e um monte de processos automatizados!)

Uma equipe que nunca se vê, um projeto conhecido metade por cada um, que ninguém sabe por inteiro! Essa é a história de…

Ladyvaulk – O Feitiço de Dataváulquila!!!

Preciso concluir?? Não é à toa que existem, hoje, ferramentas como Wherescape e Attunity! Data Vault é uma coisa tão bombástica que um só “arquiteto”, como eu, pode cuidar de muitos projetos ao mesmo tempo, cada qual com UM – permita-me frisar: UM! – profissional de dados do outro lado.

AI MEUS SAIS!
AI MEUS SAIS!

Traduzindo: uma equipe de arquiteto mais alguns implementadores pode cuidar de muitos Data Vaults. É uma eficiência simplesmente impensável em qualquer outra metodologia!!

Claro que a realidade não é tão rósea. Para começo de conversa, os dados precisam ser extraídos do Data Vault, preparados e só então consumidos. Isso dá trabalho, mas mesmo assim nem de longe é o mesmo trabalho que dá construir um ETL para um modelo dimensional carregado diretamente a partir da fonte.

É isso. Até a próxima! :-)


Eu rio toda vez que falo Dataváulquila em voz alta. Vamos, tentem! Não me deixem pagando este mico sozinho!… :-D

Autopublicação na Prática – Lançamento Oficial

O Autopublicação na Prática está oficialmente lançado!

Capa do Autopublicação na Prática. Esse aí sou eu fazendo o PnP...
Capa do Autopublicação na Prática. Esse aí sou eu fazendo o PnP…

Se você veio aqui aproveitar a tradicional promoção de lançamento e não quer perder tempo com blá-blá-blá, clique aqui e seja feliz!


Agora, se você vai encarar o blá-blá-blá… Pegou o café? :-)

Meu primeiro livro foi escrito em 2013, justamente o Pentaho na Prática. Eu não sabia nada sobre escrever livros, muito menos sobre escrever livros eletrônicos, e cometi minha cota de erros e mais um pouco. Claro, vários clientes reclamaram de uma série de probleminhas (e alguns problemões), a própria Amazon encontrou várias falhas… Eu fiz tudo que era possível para salvar aquele trabalho, aquele original, mas não foi o suficiente. Independentemente do conteúdo, o produto, o livro eletrônico, não estava à altura da qualidade da Amazon.com, e ele foi tirado do ar.

Depois de um tempo eu percebi que o livro havia sido aprovado pelos leitores. Ele era mesmo útil para várias pessoas(!), e muitos queriam tê-lo, tanto que recebi várias consultas sobre quando ele voltaria ao ar. Comecei a considerar reescrevê-lo inteiramente, mas desta vez fazendo tudo certo.

Foi quando me bateu a sensação de que existe demanda reprimida por conhecimento. Imaginem, um livro sobre Pentaho e estava vendendo! Pentaho é um nicho de nicho de nicho, e tem demanda por material sobre ele – no Brasil! Imagine quanta demanda reprimida existe por aí – e no Brasil?!

Daí o resto é história: entre ufanismo envergonhado, vaidade desenfreada e ideologia desatinada, eu decidi que antes de retornar com o PnP eu publicaria um livro sobre o easybook, o Software Livre que eu precisei aprender a usar para refazer o Pentaho na Prática. Mais: como meu negócio é entregar resultado, eu montei um gabarito e incluí um capítulo de tutorial (Capítulo 2) para que meu leitor possa criar em minutos um novo livro tão bom quanto qualquer obra profissional.

É isso. Se você sabe fazer algo que mais ninguém sabe, se você é um bom contador de histórias, vá buscar seu exemplar gratuito do Autopublicação na Prática e adicione sua contribuição ao mercado literário brasileiro. Se não for caro, quem sabe eu não viro seu leitor? ;-)


Você pode ler o livro em qualquer dispositivo – não é necessário possuir um Kindle!


Compre! ;-)

Analítico ou Operacional?

Quem acompanha o blog sabe que eu tenho uma divergência conceitual com partes do mercado de ferramentas de BI. Em geral eu questiono a idéia de analisar dados operacionais. Mais especificamente, eu venho cutucando o conceito de Data Discovery.

Acredito que finalmente entendi a confusão e vou dividir com vocês a minha opinião. Como sempre, vale o disclaimer: é a minha opinião, logo você não é obrigado a gostar dela ou concordar. Terei prazer em ouvir críticas ou outras opiniões, mas no final – como diz o Homer Simpson – a opinião é minha e faço com ela o que quiser, certo?

Fundamentação

Primeiro vamos estabelecer o terreno no qual eu colocarei meu argumento. Esse “terreno” é o uso que BI tem para uma empresa, uma organização. Como eu sempre digo, a definição de BI varia selvagemente e que o único consenso é que não há consenso sobre o que é BI. Porém, todas as técnicas e ferramentas da indústria de BI compartilham mais ou menos o mesmo discurso, a mesma promessa de valor: analisar os dados da organização para melhorar seu desempenho. Esse, então, é o chão do meu argumento:


BI trata de gerar valor a partir dos dados de uma organização.


Se concordarmos com isso – e você não é obrigado a concordar, lembre-se – então a próxima questão é “como isso acontece?” Olhemos para o mundo real: em que situações ter conhecimento dos dados gera valor para a empresa?

Empresas como uma Net ou uma Americanas.com vendem algo. A Net vende serviços e a Americanas.com é uma loja de comércio eletrônico. Algo em comum a ambas é o processo de reclamações: sempre que um dos clientes dessas empresas tem um problema, esse cliente aciona a empresa e registra uma demanda. Essa demanda é tratada, indo e voltando dentro da empresa, até que ser resolvida.

Uma forma de os dados nestas organizações serem usados para gerar valor é responder perguntas da gerência desse departamento. Por exemplo:

  • Quantas demandas temos em aberto, agora?
  • Que porcentagem dessas são urgentes?
  • Qual é o tempo médio de resolução de demandas?
  • Quais são as dez (ou vinte ou quantas você quiser) demandas mais antigas?

E assim por diante.

Outra maneira gerar valor para a empresa com esses dados é responder a estas perguntas:

  • O número de demandas em aberto está aumentando ao longo do tempo?
  • Como está variando a porcentagem de demandas urgentes em relação ao total, ao longo do tempo?
  • A “idade” das nossas demandas tem aumentado ou diminuído?

Uma Coisa é Uma Coisa, Outra Coisa é Outra Coisa!

O primeiro grupo de perguntas gera valor para a empresa porque está dando pistas sobre que ações tomar a seguir:

  • Quantas demandas temos em aberto, agora? Se sabemos qual é nossa capacidade de atendimento, sabemos imediatamente se estamos enrascados;
  • Que porcentagem dessas são urgentes? Caso haja um número excessivo de demandas urgentes, as urgentes delongam o atendimento das normais, que viram atrasadas e depois urgentes, gerando um círculo vicioso até o caos total;
  • Qual é o tempo médio de resolução de demandas? Se estiver fora da meta, precisamos nos mexer para voltar a ela;
  • Quais são as dez (ou vinte ou quantas você quiser) demandas mais antigas? Traduzindo: quem precisamos resolver antes?

As perguntas deste tipo estão voltadas para o aqui e agora. Elas são instrumentos para ações operacionais, ações que cuidam do dia-a-dia da empresa. Mesmo assim, essas perguntas dependem de um conjunto maior de conhecimentos para poder ajudar de verdade. Quer um exemplo?

  • Quantas demandas temos em aberto, agora? Inútil saber isso se não sabemos qual é nossa capacidade;
  • Que porcentagem dessas são urgentes? Em que ponto temos demandas urgentes em excesso?
  • Qual é o tempo médio de resolução de demandas? Qual é a meta?
  • Quais são as dez (ou vinte ou quantas você quiser) demandas mais antigas? Precisamos resolver antes quem está aberto há mais tempo ou quem tem um valor maior envolvido? Ou combinação desses dois parâmetros e mais alguns outros?

Enfim, tomar decisões operacionais a partir dos dados do momento dependem de conhecimento sobre o negócio. Os dados, por si só, não trazem esse conhecimento.

Já o segundo grupo está olhando o negócio ao longo do tempo, para ajudar a decidir que rumo tomar. São perguntas que refletem um anseio de melhorar a gestão, de evitar riscos e ter mais segurança nas ações. Cada pergunta daquelas nasceu de uma vontade de evitar problemas e melhorar o rendimento (fazer mais gastando menos) da empresa. Veja:

  • O número de demandas em aberto está aumentando ao longo do tempo? Traduzindo: se tudo está bem e estamos atendendo bem ao nosso cliente, então o número de demandas abertas deve estar caindo de um período (semana, mês etc.) para outro. Está? Se a quantidade de demandas está aumentando ao longo do tempo, o que está causando esse aumento?
  • Como está variando a porcentagem de demandas urgentes em relação ao total, ao longo do tempo? Tradução: nossa equipe, processos e ferramentas estão adequados para nossa realidade? Em que ponto perderemos o controle?
  • O gerente perguntou “A ‘idade’ das nossas demandas tem aumentado ou diminuído?” mas ele queria ter perguntado “Nossos clientes nos vêem como eficazes?”, ou talvez “Vamos perder algum cliente por atrito com o atendimento”?

Acredito que, a esta altura, meu argumento se auto-evidenciou:


Existem duas demandas distintas por análises de dados dentro uma organização: operacional e estratégico.


E Daí?

O berro que eu acredito ter ouvido de vocês é “descobriu a América, tontão! Todo mundo sabe disso!”

É mesmo?

Se todo mundo sabe que existem duas demandas distintas por dados, então porque é que ambas são chamadas pelo mesmo nome?

Toda e qualquer análise de dados, de qualquer tipo, em qualquer situação, tem respondindo por apenas um nome nestes últimos 20, 30 anos: Inteligência de Negócios.

Bom, se João é Pedro, então tanto faz chamá-lo de Pedro ou João. Agora, se João é diferente de Pedro, então João não é Pedro e por isso não podemos chamar João e Pedro pelo mesmo nome.

Deixe-me traduzir: eu não posso usar o mesmo nome para duas coisas distintas, ou não seriam distintas!

Admito que isso acontece em muitas situações na nossa vida, mas vocês hão de convir que, quando isso acontece, em geral sabemos que temos mais de um significado em jogo, e também sabemos a qual destes significados estamos nos referindo. Tem um exemplo no seu bolso, ou em cima da sua mesa: olhe ali, seu celular.

Não sacou?

Oras, celular é o que o seu avô usava. O nome correto destes novos aparelhos de telefonia móvel é smartphone! Chamamos tudo de celular porque é mais fácil, todo mundo entende e, bom, quem ainda usa um celular das antigas? E que diferença faria usar o nome certo? Os antigos aparelhos estão sumindo…


Eu estudei piano por um tempo e, apesar de ter um em casa, meu acabou me presenteando com um teclado da Casio. Chamei meus amigos (músicos, boa parte deles) para mostrar a novidade e tasquei: “olha só, o orgão que meu pai me trouxe!” Meu amigos caíram na gargalhada e eu, goiaba que só, não entendi nada. “Cara”, um deles falou, “orgão é seu *****, isso aí é um teclado eletrônico!!!”


Voltando à vaca fria, ao considerar que duas coisas distintas são a mesma, quando não são, estamos abrindo a porta para uma confusão danada. Essa confusão tem causado consequências problemáticas, que nem sempre são claras.

E, olha só!, produtos que se auto-categorizam como “de Data Discovery” são voltados precisamente para o exame de dados operacionais. Se não, vejamos:

  • Prometem acessar o dado diretamente nos sistemas de origem;
  • Prometem dispensar um DW, descartando com isso o exame de dados ao longo do tempo;
  • Oferecem uma vasta gama de opções de visualização de dados;
  • Focam em “velocidade de análise”.

Conclusão

Toda empresa depende de uma série de projetos de TI (e Negócios) para se manter viva. Projetos como ERP, BPMS e BI são o feijão-com-arroz para qualquer organização no século XXI, e o sucesso da execução destes e de vários outros projetos tem um impacto direto na saúde da organização.

Basta olharmos para a propaganda de empresas do espaço de Data Discovery para notar que seus produtos são voltados a atender necessidades de acesso e manuseio de dados operacionais. Percebemos que são projetos de TI distintos ao compararmos alguns aspectos entre produtos de Data Discovery e de BI:

Aspecto Estratégico Operacional
Ciclo de vida dos dados Histórico Vivos, quase tempo-real
Origem dos dados Armazém de Dados Sistema de origem
Velocidade de manuseio dos dados Não é crítica Crítica
Funcionalidade mais importante Data Mining Formas de visualizar os dados

É perigoso, se não cabalmente daninho para uma empresa, adotar como solução de um problema o produto adequado a outro. Você teria coragem de assinar a compra de um ERP para montar uma solução de workflow? Não, né? E olhe que há uma semelhança razoável entre ERP e BPMS para nos tentar a usar só o ERP para as duas coisas!

Solucionar as necessidades de dados operacionais com um projeto de BI é contraproducente:

  • Sai mais caro, já que embute pelo menos um projeto extra, o de DW
  • Frustra os usuários:
    • Se vêem forçados a usar ferramentas inadequadas à sua necessidade;
    • São obrigado a viver em um ciclo de projeto mais longo do que o necessário, pois embute a revisão do DW quando uma simples mudança na camada de apresentação já teria sido suficiente.

Da mesma fora é danoso à empresa adotar ferramentas de DD para necessidades de BI: descartar o histórico dos dados compromete as análises de causa e efeito, anulando a capacidade de compreensão e planejamento.


É uma sutileza, mas o usuário de BI também se frustra com ferramentas para manuseio de dados operacionais, pois as ferramentas voltadas para análises operacionais não são o mesmo que ferramentas OLAP.


Se temos duas necessidades claramente distintas, com público-alvo, premissas e técnicas diferentes uma da outra, e uma delas chama-se BI, a outra não pode ser BI. Por falta de um nome melhor, chamerei o não-BI de Inteligência Operacional, OI.

Não gostei muito de OI, mas a alternativa me soa ainda pior: Não é BI!
Não gostei muito de OI, mas a alternativa me soa ainda pior: Não é BI!

Ter claro em mente que existem demandas distintas é fundamental para atender ambas corretamente. Mesmo que compartilhem algo, como máquinas e alguns tipos de software, a simples diferença de público-alvo já justifica um atendimento em separado – no mínimo com relação aos dados que cada projeto usa. O preço de atender cada projeto com a solução errada vai de um mero desconforto entre os usuários a consequências severas para a organização.

Até a próxima! ;-)

De Agilidade e BI

Como capturar e documentar requisitos para projetos de BI gerenciados por métodos ágeis?

Ágil, Não Rápido

Quando Kent Beck, Martin Fowler, Ken Schwaber, Jeff Sutherland e toda patota declararam o Manifesto Ágil, eles não estavam preocupados com a velocidade do desenvolvendo de software, mas sim com a dificuldade cada vez maior em escrever bons produtos. Até início dos anos 2000, o paradigma de desenvolvimento de software era espelhado no paradigma de construção civil: ninguém assentava um tijolo até tudo estar absolutamente calculado e verificado.

É o mesmo que dizer que Romeu e Julieta foi escrito de uma vez, em algumas semanas, depois de Shakespeare passar alguns anos detalhando os personagens e a história. Não que eu seja especialista no processo criativo shakespeareano, longe disso! O que eu quero dizer é que construir paredes e escrever algo são atividades muito diferentes. Meu melhor exemplo são meus posts como exemplo: eu reescrevo cada post – inteirinho – pelo menos uma vez.

Imagine construir e derrubar uma parede até ela ficar perfeita. Imaginou? Bom, vá além: imagine construir e demolir uma casa inteira, até ficar como você quer. Ou pior: construir e vê-la desabar sobre o próprio peso vezes sem conta, até acertar a posição das vigas e conseguir que a centésima vigésima terceira encarnação da casa não caia só porque alguém bateu a porta da frente com força.

É ruim, hein! :-P


O cerne do conceito de desenvolvimento ágil não é a velocidade, mas a melhoria contínua.


Por isso no manifesto eles dizem que vêem valor em “processos, ferramentas, documentos etc.”, mas que vêem ainda mais valor em “indivíduos, colaboração, resultados etc.” Está lá, com todas as letras: trabalhar para obter um bom resultado é o que interessa. E não adianta trabalhar a toque de caixa, fazendo tudo nas coxas, só para chegar rapidamente ao final. O que interessa é avançar, melhorando continuamente e sem comprometer o futuro com decisões apressadas ou serviço mal-feito.

Inteligência de Negócios Ágil?

E como você trabalha melhoria contínua em Inteligência de Negócios? Como casamos BI com Ágil?

Eu venho estudando essa questão, meio que sem querer, já há alguns anos. Como sempre, tudo começou porque eu queria aplicar Scrum de qualquer maneira, custasse o que custasse! Eu havia acabado de ler Agile Project Management with Scrum, do Ken Schwaber, e estava louco para pôr em prática aquelas idéias. Era tudo tão simples, tão elegante, tão poderoso que eu precisava tocar um projeto com Scrum.

Tive uma sorte danada: havia acabado de receber um projeto e ele servia como uma luva em todas aquelas idéias. Aprendi tudo de Scrum, botei em prática, e o projeto funcionou muito bem.

Quer dizer, praticamente. Algums detalhes não deram muito certo:

  1. Automação de Testes: como você testa um ETL ou um relatório, continuamente? Como montar testes de regressão em um modelo dimensional?
  2. Histórias: como eu transformo a necessidade do cliente em uma história, e depois mapeio isso nas atividades típicas de um projeto de BI, como desenhar o modelo dimensional, desenvolver o ETL e construir um relatório ou painel?
  3. Refactoring: sério, refatorar um banco de dados?? Freaking how??

Ainda não encontrei uma resposta satisfatória para os testes. Já refatorar bases de dados, por incrível que pareça, é um problema que já foi resolvido: o livro Refactoring Databases disseca o assunto completamente. Estou lendo esse livro agora mas, pelo pouco que eu já li, posso dizer que ele é essencial para qualquer DBA que seja membro de uma equipe de desenvolvimento de software – ou BI – contemporânea. Leia!

Senta que Lá Vem História…

O que nos deixa no assunto deste post: levantamento de requisitos ágeis para Inteligência de Negócios.

Existem várias técnicas de levantamento de requisitos para projetos ágeis. A mais famosa, provavelmente, é o conceito de História: o cliente e a equipe de desenvolvimento constroem uma narrativa que incorpora a necessidade do cliente na forma de uma ação, de uma história. Por exemplo: “como gerente de vendas, eu quero poder ver as vendas deste mês dia-a-dia, quebradas por vendedor, produto e cliente”.

Essa foi a minha abordagem para aquele projeto. Funcionou, no sentido em que permitiu organizar o trabalho, quebrá-lo em partes e controlar a entrega. Por outro lado criou outros problemas. Exemplo? O tamanho, para começar. Quem já está acostumado com projetos de BI vê imediatamente que o cliente precisa de 1) um cubo OLAP com três dimensões, de vários níveis cada, ligadas a uma fato, tudo isso carregado por 2) um processo de ETL que leva os dados da origem a um 3) modelo dimensiona. Ou seja, uma única história dá origem a um Data Mart inteiro! É muito grande!

Outro problema é o que a própria história conta: há tantas formas de construir a apresentar esses dados que umas poucas linhas de texto é um canal muito “estreito” para enfeixar tantas possibilidades. Como adicionar detalhes? Escrevendo mais? E como fazer o cliente entender o que foi prometido e o que está sendo desenvolvido?

Eu cheguei a escrever sobre um problema relacionado à essa imprecisão: Cruel Sucesso. Para te poupar do esforço de lê-lo, resumidamente, quando você acerta na mosca, o cliente muda a demanda. Depois de algumas iterações acontecendo isso, o cliente desenvolve a sensação contrária, e passa a acreditar que o projeto nunca acerta! E, na minha opinião, isso acontece porque ele só entende claramente o que pediu quando recebe. E é neste momento que ele reavalia sua necessidade a refina. Entendeu? Não? Bom, então leia aquele post antes de continuar, hehe. :-)

Requisitos Para Gestão Ágil

Enquanto eu batia cabeça com isso eu tomei contato com outra técnica fantástica: Data Vault. Se você acompanha meu blog sabe o quanto eu sou apaixonado por DV.

De novo, louco para construir um DV e testar todas aquelas idéias, eu consegui um projeto perfeito. Não apenas pude aplicar Data Vault, mas o fiz com Scrum, o que foi duplamente satisfatório aliás. O resultado desta experiência virou o Primeiro Curso de Data Vault do Brasil. Estou evoluindo aquele material e em 2016 eu espero lançar uma versão definitiva, completa.

E foi deste material que eu puxei uma coisa muito interessante: uma técnica para levantamento de requisitos para projetos de BI. Não apenas qualquer projeto de BI, mas principalmente projetos gerenciados com alguma técnica Ágil, como Scrum ou Kanban.

Funciona assim: ao invés de escrevermos uma história, e depois quebrá-la em modelo de dados, ETL, apresentação etc., começamos anotando cruamente o que o cliente diz que precisa. Essas anotações são transformadas em protótipos que são revisados pelo cliente e ajustadas e revisadas e ajustadas etc. etc. … Em algum momento o cliente vai se dar por satisfeito e o último protótipo vira o requisito! Daí o resto é história: montar um documento que combine protótipo e a demanda do cliente em uma forma que ajuda a equipe de desenvolvimento e comunica claramente a expectativa do cliente.

150827_DAEBI_004

4Shot Agile BI com Pentaho

Eu contei para vocês que eu comprei um apartamento? ;-) Agora eu tenho uma dívida de quarenta anos, e preciso fazer caixa. Por isso, quando uns meses atrás a 4Linux me apresentou o conceito de Shot e me perguntou se eu tinha alguma proposta, na hora eu apresentei a idéia acima.

150827_DAEBI_001Um Shot é um curso de curta duração (tipicamente um dia), focado sobre um único assunto e, em geral, voltado para um público específico. A 4Linux é, com certeza, o maior fornecedor de treinamentos em Software Livre e eu tenho a honra de ter produzido o treinamento Pentaho que eles oferecem (e de vez em quando ministro uma turma.)

Eu produzi um vídeo explicando melhor a idéia.

150827_DAEBI_002

Semana que vem, dias 1, 2 e 3 de Setembro de 2015, ocorrerá a primeira turma deste Shot. As vagas são muito limitadas porque as turmas são propositalmente pequenas, de no máximo oito alunos. A idéia é oferecer um curso reforçado, intenso, e uma turma maior não permitiria isso. Também não é um assunto para principiantes. Não é nada esotérico, mas se esse vai ser seu primeiro curso em BI, bom, se prepare. ;-)

Máquina virtual pré-fabricada, pronta para os exercícios.
Máquina virtual pré-fabricada, pronta para os exercícios.

O curso inclui apostila e dois DVDs, com uma máquina virtual preparada para os exercícios, os exercícios resolvidos, templates, SQLs, backup de bancos e cópias de todos os softwares usados e mais alguns. E apesar de a propaganda dizer que ele é 80% prático, eu acabei fazendo um pouco mais – você não vai ter folga! Mas nem tudo será suor e teclados massacrados: como serão turmas presenciais, teremos o famoso coffee-break da 4Linux. :-)


Os leitores do blog que desejarem se inscrever terão um preço especial: R$199,00 contra R$299,00 do site. Para isso você precisa entrar em contato diretamente com Daniela Araújo (e-mail daniela.araujo@4linux.com.br) e contar que descobriu sobre o Shot no blog Geek BI.


Compre! :-D

Inteligência de Negócios à Serviço da Educação

Mês passado (julho/2015) a Editora Packt conduziu uma pesquisa entre profissionais de TI para tentar entender como o conhecimento e habilidades desses profissionais influenciaram o sucesso em suas carreiras e seus salários. Receberam mais de 20.000 participações.


Isso é tanta gente que bateu todas as outras pesquisas do genêro. Para você ter uma idéia, se pegarmos só os respondentes dos Estados Unidos já dá mais participantes que a mesma pesquisa feita pela StackOverflow algum tempo antes. Uau!


E o que a Packt fez com isso? Lembre-se: eles não são uma instituição de caridade, eles querem é vender mais. ;-) Bom, eles analisaram todos esses dados e chegaram à some fascinating findings. Baseado nas conclusões das pesquisas, às quais você pode ter acesso por este link, a Packt montou pacotes de livros pensados para trazer ao leitor justamente os conhecimentos que podem gerar maior vantagem profissional nos próximos anos!

Falassério!!! Genial!!!

A empresa usa seu alcançe com leitores de todos os países e ramos da TI para pesquisar o que está fazendo diferença na vida deles. Daí estuda esses dados e monta uma campanha para ajudar seus leitores a escolher seus livros!

“Ah, Fábio, como você é inocente! Eles estão fazendo isso para ganhar mais dinheiro!”

SIM!! Ou você acha que o Pão de Açúcar faz promoção de queijos e vinhos apenas para o nosso deleite? Pense: nós, leitores, estamos ganhando com o conhecimento deles, já que nada nos impede de buscar livros de outras editoras.

A idéia não seria ruim, até, se não fosse pela segunda metade do pacote: neste link você tem acesso aos pacotes que eles montaram para vários tipos de profissionais. Por exemplo:

Aprendendo e dominando processamento de dados com Hadoop ("BigData".)
Aprendendo e dominando processamento de dados com Hadoop (“BigData”.)
Data Mining ("Data Science" - pfff, buzzwords...) com R e Python, trilha completa.
Data Mining (“Data Science” – pfff, buzzwords…) com R e Python, trilha completa.
Hoje nada é completo sem "mobile": eis um pacote para desenvolvimento Android.
Hoje nada é completo sem “mobile”: eis um pacote para desenvolvimento Android.

E como isso se isso não fosse o bastante, a Packt deu um passo além: se você quiser montar um pacote específico, que você entenda como útil na sua carreira, você pode: escolhendo qualquer conjunto de 5 livros, você paga apenas US$25,00 por eles!!

Falassério, Parte 2!!!

Ah, você não achou 5 livros? Quer um ou dois? Ou apenas um vídeo para completar seus conhecimentos? Fácil: até o final da promoção, que é em 7 de agosto, todos os livros e vídeos estão por US$10,00 cada!

É isso. Quer saber o que nossos colegas de TI estudam, e que conhecimentos eles acham que vai ser importante nos próximos anos? Acesse a pesquisa. Acha que precisa estudar um pouco mais, sobre alguma coisa? Até 7 de agosto, neste link você pode montar um pacote de até 5 livros por US$25,00 – ou comprar qualquer livro ou vídeo por US$10,00.


E qual é o meu interesse em fazer essa pusta propaganda no meu blog?

  1. Meu amigo da Packt me pediu ajuda para divulgar a campanha. Só o afago no meu ego já seria o bastante (a Packt acha que eu sou importante? Uau!)
  2. Francamente, é uma promoção boa demais para não divulgar. Em um país com tanta necessidade de conhecimento e educação, qualquer oportunidade de aprender a um custo menor é muito valiosa para manter segredo.

Normalmente eu ganho um livro ou dois por ajudar a divulgar uma promoção ou fazer uma resenha. Só que desta vez isso não vai me fazer diferença: eu já ganhei tantos livros em troca de resenhas e divulgação que eu simplesmente não tenho mais o que pedir…

Boas compras! :-)

CIJun Contrata para Pentaho

Ora, quem diria? A Companhia de Informática de Jundiaí, empresa de TI da prefeitura (de Jundiaí, evidentemente), abriu edital para contratar um monte de gente, incluindo especialistas em GIS com salário de mais de sete mil reais. No meio deste povo todo, está lá:

Trecho do edital da CIJun com os requisitos do Analista de BI.
Trecho do edital da CIJun com os requisitos do Analista de BI.

Destaque para os conhecimentos específicos: Suite Pentaho, CE e EE. Legal. :-)

Interessado? Acesse o site do concurso.

ERP BI Solutions

E esse é o mundo de hoje: quando você pensa em fazer algo, alguém já fez. Conheçam ERP BI Solutions, primo do OpenBI Solutions:

ERP BI Solutions provides business intelligence solutions for popular open source ERP systems including PostBooks and XTuple ERP. Solutions are designed using data warehousing best practices and are built on best-of-breed open source BI technology giving you cost effective, innovative business intelligence.

Assim como o OpenBI Solutions oferece soluções de BI para softwares comuns (como o atual Apache) e de treinamento (Beltrano S/A), o ERP BI Solutions oferece soluções de BI com Pentaho para ERPs Open Source. A última publicação é de janeiro de 2014 e atende aos ERPs PostBooks e XTuple. Imagino que a coisa ande devagar, pois mais difícil que criar esses projetos é mantê-los em par com os respectivos ERPs.

Packt Pub. Celebrates 10 Years with US$10 Campaign!

Packt Publisher, the “We got IT covered” company, is celebrating 10 years this July 2014 with an offering on their site: every e-book and video on sale for US$10,00!

Packt slogan sounds like a weak pun, but in fact summarizes the truth: Think about a software – there are big chances Pack has a book on it. Not software, but hardware? Ok, they have it too! What about a supercluster with a thousand Raspberry Pis for a weekend project? (They have so many titles on so many things it is kind of ludicrous… Really! They’ve got a title blending Minecraft – yeah, the game – with hardware!!)

So, if you are in need of learning something about a software (be it Free or Proprietary) or hardware, give a look at Packt until tomorrow (July 5) to take advantage of a good offer. I bet you won’t regret it!

Packt Comemora 10 Anos com tudo a US$10!

Em julho a Editora Packt  completou 10 anos e lançou uma campanha: todos vídeos e e-books no site por US$10,00!

Imagine que você precisa aprender algo novo – seja por trabalho, por interesse particular, por qualquer motivo. Como fazemos hoje? Google! Tutorial, Passo-a-Passo, blogs, fóruns etc. etc. etc.

Bom, a Packt oferece centenas de livros para novatos e profissionais que precisem aprender algo sobre uma determinada tecnologia. Não é brincadeira: valem por um curso! Quer exemplos?

  • Vídeo Building a Data Mart with PDI: em um conjunto de vídeos com excelente qualidade de som e imagem você aprende como montar um Data Mart dimensional. Autor? Ninguém menos que o Diethard Steiner, um dos grandes profissionais Pentaho no mundo;
  • Livro Pentaho Data Integration Cookbook (2nd. Ed): a arca do tesouro do PDI!! Imperdível!
  • Livro Hadoop Beginner’s Guide: eu consegui montar um servidor Hadoop seguindo as orientações desse livro, que não apenas é muito bom, mas é gostoso de ler!
  • Livro HP Vertica Essentials: de novo, eu saí do zero e completei um servidor Vertica sozinho, sem precisar de Internet nem nada! Outra pérola!
  • Livro QlikView 11 for Developers: tudo que você sempre quis saber sobre o QV, mas não tinha na Internet! Finalmente consegui entender como o QV funciona (e desmistificar aquele “qualquer data, de qualquer lugar”! QV dá tanto trabalho quanto qualquer ferramenta!)
  • Livro Bonita Open Solution 5.x Essentials: outro caso de muita informação de qualidade e valor.
  • Data Mining (RapidMiner, R), Zabbix, Postgres, MySQL, Minecraft (!!!), Apache, Oracle, SQL Server, Closure, HTML5, PenTesting, jQuery, Spark, Lumion 3D, Raspberry Pi, OpenStack …

Putz… Acho que faz tempo que não leio nada que não venha da Packt (e olha que eu sou fã da Wiley!)

Enfim, você está trabalhando com TI? Precisa aprender a mexer com alguma tecnologia (hardware, software – livre _E_ proprietário), ou precisa melhorar? Está curioso e quer brincar com robôs ou automação do lar? A Packt tem – e é bom!

A promoção acaba amanhã, 5 de julho, mas ainda dá tempo: dê um passeio no site deles, você não vai se arrepender.