A Nuvem Negra

Acabaram-se as férias! De volta ao trabalho!

Eu estava lendo um clássico de SciFi chamado The Black Cloud – sim, é daí que eu tirei o nome do post.

Este é uma daquelas histórias que deram a fama ao gênero: com cientistas e perigos intergalácticos, mas contada do ponto de vista da Humanidade, tal como nós a conhecemos. Eis um resumo: em 1963, um estudante de Astronomia detecta uma anomalia no céu [setentrional][setentrional_bitly]. Descobre-se, mais tarde, que essa “anomalia” é uma gigantesca nuvem de gás interestelar, deslocando-se a mais de 100 km/s (cem kilômetros por segundo! Conte 1… cem kilômetros!) em direção ao Sol. Essa nuvem provoca uma violenta catástrofe por aqui e, por muita, muita sorte, não destrói a Terra de uma vez. (Não vou dar spoiler! Leia, é do balacobado!)

Boa Ciência

Pouco depois do começo da história é formado um time de cientistas (físicos em sua imensa maioria) para estudar a Nuvem, a fim de orientar as decisões dos governos do mundo face à novidade. Eles prevêem um certo cenário, mas ele não acontece. Daí outro, e também a coisa não se passa como esperado, e mais um, e outro… Ou seja, erram um monte, pois a tal da Nuvem comportava-se de maneira “errada”. A certa altura, discutindo como interpretar um certo fenômeno impossível (mais um…), um dos cientistas solta o comentário:

Russo rosna...
Russo rosna…

Tradução “limpa”:

“Porcaria de Ciência ruim!”, rosnou Alexandrov. “Obter correlação após fato, Ciência de porcaria. Ciência só prever.”

Alxenadrov, como o nome sugere, é um russo, e por isso ele tem essa forma de expressão… crua, digamos assim. Ao “exclamar” esse comentário, ele contestava o debate, dizendo que adiantava nada achar uma explicação para os fatos. Se quisessem mesmo entender o que está acontecendo na Nuvem, era preciso testar essa explicação: se ela for capaz de prever o comportamento da Nuvem – que é o que mais interessava à eles – então você fez boa Ciência, gerou conhecimento e progrediu. Caso contrário, é uma explicação furada ou imperfeita e precisa ser revista ou melhorada.

Fazer o contrário, adotar uma explicação pós-fato e confiar nela porque explicou o que aconteceu, é o mesmo que apostar numa corrida de cavalos que já acabou (falam exatamente isso para explicar os termos do Alexandrov para as personagens não-cientistas.) Vem daí o “bloody science” do russo, que a educação manda traduzir por porcaria, mas que é melhor representada por outra palavra, também começada com P. :-)

E o que isso tem a ver com BI? Por que esse assunto tão nada a ver logo no começo do ano?

Já, já chego nisso. Antes, uma pequena revisão.

Inteligência de Negócios

No post Paz, Afinal III, eu defini BI pela última vez na minha vida com essa frase:


Inteligência de Negócios é a disciplina de busca da compreensão dos negócios de uma organização mediante a aplicação do Método Científico.


Revendo, acho dá para simplificar:


BI é o uso do Método Científico por uma organização para melhorar sua administração.


Daí, seguindo nesta trilha, no post Full Metal BI Itch eu desenvolvi o argumento de como a aplicação do Método Científico aos dados de uma empresa produzem valor. Eis o trecho relevante:


(…) E se você pudesse voltar um ano? O que faria? Mandaria alguém embora? Cancelaria uma venda ou faria mais pedidos de matéria-prima? Ou faria tudo igual, de novo?

Você há de concordar comigo que, se pudesse mesmo voltar um ano, muito provavelmente faria alguma coisa diferente. Duvido que você não tenha um único arrependimento sequer. Não? Mesmo? E o dólar?

(…) Se pudesse voltar um ano, saberia quando comprar e vender moeda estrangeira e faria uma grana fácil!

Curiosamente, esse poder de “prever o futuro” existe hoje, mas raros usam-no. Quem dá a uma empresa o poder de prever o futuro é justamente Data Mining, em particular, e Inteligência de Negócios, em geral!

Claro que não é possível prever, com exatidão, o valor que o dólar vai ter amanhã, ou semana que vem, ou… Não se trata disso. Se trata de, sabendo como um negócio funciona, bolar uma equação matemática – um modelo matemático – que ajude a calcular as chances de determinadas situações acontecerem.

Daí, baseados nesse modelo, que é a informação tirada dos dados, podemos tomar decisões com chances melhors de sucesso. Evidentemente não é uma decisão garantida, mas entre optar por um caminho ao invés de outro por pura intuição, ou fazer uma escolha embasado no que já aconteceu, obviamente preferimos apostar no que já vimos acontecer. (…)


Resumindo: BI é a aplicação do Método Científico para, a partir da observação de eventos passados, tentar prever (=tomar a melhor decisão) o que vai acontecer.

BI & Ciência

Acho que a relação entre a exclamação do Alexandrov e BI ficou evidente: são a mesma coisa.

Para que iríamos querer olhar os dados que já são passado? Apenas para explicar porque algo aconteceu como aconteceu? Seria muito estéril aplicar tanto esforço por um consolo intelectual.


Ah, fracassamos porque nossa taxa de falhas nos itens da linha de produção número um eram superiores a 1 em 10.000… Que peninha…


Claro que não é para entender, só entender! É para entender o quê levou as coisas a serem como foram, e então evitar que o mesmo problema se repita! Ou que as mesmas oportunidades sejam perdidas! Ou, ou, ou…

Alexandrov colocou de uma forma muito simples, clara e, bom, elegante (numa forma russa de ser, hehe) de se explicar o propósito do ramo da Inteligência de Negócios: fazer boa Ciência (com os dados da empresa!)

Uma Nuvem Negra

Na história, a certa altura, a Terra começa superaquecer (levando à morte milhões de pessoas) porque a Nuvem refletia o Sol e, ao chegar mais perto, mandava mais calor para a Terra.

Depois, quando a nuvem chega, ela obscurece o Sol, e a Terra cai em um inverno profundo, intenso, no qual outros milhões morrem.

IMHO, esses trechos da história também ecoam a realidade da indústria de BI.

Visto de longe, chegando, toda tecnologia associada ao jargão Business Intelligence, parece brilhar com luz própria, anunciando um futuro iluminado, onde nenhuma sombra será vista pairando sobre nosso conhecimento! A chegada das ferramentas de BI na sua organização trará uma nova era de conhecimento, rico e valioso conhecimento!

… Até que tudo é instalado e posto a funcionar e, pouco tempo depois, em muitos dos casos, tudo não parece mais tão claro. Não vou querer esticar esse paralelo ao ponto de dizer que todo projeto de BI acaba em mortes de milhões de inocentes, mas sim, quem já passou por um projeto desses sabe que o mundo real acaba sendo mais sombrio e complicado que a expectativa.

Se já é difícil fazer boa Ciência, imagine em um ambiente que não permite experimentos, como uma empresa.

O truque – que, me parece, cada um precisa aprender sozinho – é saber navegar o dia-a-dia da organização, atingindo expectativas, com um olho no futuro e outro no passado. Até mesmo por isso é que BI é um apoio para a estratégia da empresa. (O que me leva mais uma vez ao argumento contra BI em tempo real. Mas estou digredindo, vamos voltar.)

Bloody Conclusion

Ah, ano novo! Tantos clichês, tão pouco espaço… :-)

Eu queria que o primeiro post do ano trouxesse algo mais fundamental, mais na raiz do sucesso de projetos de BI, seja você da área de negócios ou TI. E, sucesso, é ajudar a organização a crescer e se manter.

BI é valioso. BI cria valor para a organização, e por valor eu quero dizer dinheiro, seja aumentando o faturamento, seja reduzindo custos ou melhorando a produtividade.

Se você quer que sua organização viceje e floresça, então você precisa aplicar o que os dados ensinam. A cultura de BI que experimentamos hoje, tal qual uma nuvem, suaviza os contornos da realidade e dá muita relevância às ferramentas, tendendo a deixar de lado o aspecto científico (=do conhecimento.), que é justamente o como as análises criam valor. E o mais complicado dessa situação é que ela não é óbvia. É preciso dar um passo para trás e tentar ver a bloody big picture para apreender como o conhecimento gerado pela análise de dados está sendo reinjetado na empresa, para melhorar seus resultados.

Quando aplicam-se conclusões que explicaram o passado, mas não foram testadas contra o futuro, BI falha em criar valor e, não raro, pode destruir valor na organização. Esse é o cuidado que temos que ter. Esforce-se em aprender a transformar o conhecimento em valor, através do estudo dos dados.

Isso, bloody comrade, é que é bloody BI. Bloody 2017 para todos nós! :-)

Anúncios

ROI de Projetos de BI

Eu já falei um pouco sobre ROI de BI em dois posts:

O ponto nos dois casos era o mesmo: dinheiro voando pela empresa que foi recuperado com o uso de Inteligência de Negócios, comparado com o custo de cada solução. Como sempre, o ROI de projetos de BI é astronômico, é fora de escala. O primeiro se pagou em algumas semanas, e o outro deu um retorno de dezenas de vezes. Um exagero nos dois casos, não se importa como se examine a questão.

Em 8/8/16 (8+8=16! :-O ) meu grande amigo Rômulo me mandou um SMS:


Perguntas recorrentes: como avaliar o sucesso de uma implantação de ferramentas analíticas (BI); como medir, nesse caso, o ROI?


Eu prometi a ele responder com um post no blog, já que o assunto é extenso, interessante (e relevante) demais para um SMS.

Return On Investment

Em bom português, ROI significa “retorno do investimento”. Via de regra, ROI pode ser definido como, por exemplo, o tempo para um projeto pagar a si próprio ou o impacto do projeto sobre o faturamento ou o lucro anual.

E isso é óbvio, não é?

Toda Estrada Tem um Retorno Invisível

Pare um pouco. Respire, tire os olhos desta tela e olhe ao seu redor. De onde veio tudo que está por aí?

Do retorno esperado.

Por que você come quando está com fome? Porque espera que, em retorno ao seu ato de mastigar e ingerir, desapareça o incômodo da fome.

Por que compramos uma mesa, uma TV, pagamos um curso ou convidamos alguém para sair?

Por que trabalhamos? Por que uma empresa surge? Por que montamos projetos?

Fazemos tudo isso para obtermos um retorno, algo que vai aplacar uma vontade ou atender uma necessidade.

Tudo que fazemos, e por extensão tudo que uma empresa realiza, gera um retorno. É por isso que, às vezes, perceber o retorno de uma determinada ação é muito difícil, especialmente se é algo que pouco afeta sua realidade. Às vezes, o retorno de uma determinada ação só pode ser percebido quando aquela ação deixa de ser feita, como quando perdemos o emprego, ou quebra-se uma linha de produção. Neste momento vemos como é importante ter um salário, ou como uma peça que representam 10% dos custos de uma empresa pode ser responsável por mais da metade do dinheiro que entra.

Uma situação comum em que o ROI não é tão facilmente calculável é justamente a modernização de um recurso ou a manutenção de uma situação. Vamos bolar um cenário para um caso clássico, o ROI de um treinamento, e examinar algumas coisas.

Imagine um banco. Estamos em 2016 e nosso banco é uma empresa já estabelecida, operante. Fazemos uma pesquisa de opinião e descobrimos que nossos atendentes não gozam de boa reputação com a clientela. Ser mal-visto é ruim, e queremos diminuir essa percepção negativa. Decidimos, então, aplicar um treinamento de “atendimento qualidade total”.

Como medimos o ROI desse treinamento? Fácil: rodamos uma nova pesquisa e verificamos se a reputação melhou, certo?

NÃO! Errado!

É de ROI que estamos falando, de DINHEIRO, não de percepção subjetiva do atendimento pessoal.

Uma coisa é observar se o projeto – o treinamento – deu resultado. Outra, bem diferente, é descobrir quanto dinheiro ficou a mais com o banco por causa dessa capacitação!

Pense em outro cenário no mesmo negócio, o banco: um novo sistema interno vai entrar em operação, e a certa altura do roll-out é feito um treinamento no uso desse sistema. Seis meses mais tarde, com 100% dos usuários do novo sistema treinados e aprovados nas avaliações, a capacitação deu resultado? E o ROI, de quanto foi?

Talvez vocês conheçam essa anedota:

Ouvido na conversa entre dois empresários:

- Eu decidi que não vou treinar meu novo empregado. Imagine se eu invisto nele, preparo-o, e ele resolve ir embora?!

Ao que responde o outro empresário:

- É? E o que acontece se você não treiná-lo, e ele decidir ficar?

Vêem onde eu quero chegar?

Certos projetos oferecem uma dificuldade extra para calcular o ROI porque o retorno do projeto serve apenas para manter as coisas como estão, para evitar que piorem. Só conseguimos avaliar o quanto nos custaria não investir, como na anedota. Por extensão, podemos supor que o ROI desse tipo de projeto depende desse custo de não investir, do chamado custo de oportunidade.

Quadridimensional

Lá no começo dissemos que ROI pode ser, por exemplo, o dinheiro que o projeto gerou a mais, e aqui em cima mostramos que esse retorno pode não ser a mais e sim evitar uma perda, evitar um dinheiro “a menos”. Para fechar o assunto vamos apresentar umas equações simples, para ancorar o conceito na Matemática.

Uma das formas de calcular ROI é esta:

 

Definição simples de ROI.
Definição simples de ROI.

 

Aqui considera-se o ganho total de um investimento, contra seu custo. É uma fórmula válida para quando compramos ou vendemos alguma coisa, mas não quando mudamos algo na vida da empresa.

Quando um projeto é conduzido para mudar algo, precisamos considerar o impacto deste projeto ao longo do tempo. Basta pensar um pouco para entender o porquê: ao prevenir a interrupção da produção, por exemplo, você garante que o dinheiro vai continuar entrando. Se o projeto custa mais caro do que, digamos, um mês de produção, o ROI definido acima vai ser negativo se considerarmos o ganho do investimento apenas durante um mês, ou menos. Agora, este mesmo ROI se torna positivo – e cada vez maior – se considerarmos esses números a cada mês, ou dentro de um ano, por exemplo.

O chato de ver a questão sob este ponto de vista é que tudo passa a ter ROI, e não raro um grande ROI:

  • Se eu deixar de pagar meus empregados, eles param de trabalhar e eu paro de faturar. Então há um ROI aqui, que equivale a tudo que eu faturo!
  • Se eu deixar de pagar a eletricidade, ou a água, ou telefone, ou…, ou…, ou…, de novo, o dinheiro não vai entrar. Então, pagar tudo isso tem um ROI que é, de novo, igual a tudo que a empresa ganha!
  • Se eu deixar de investir na melhoria da empresa, meus clientes podem me abandonar, piorando meu faturamento. Logo, investir em melhorias tem ROI!

E asssim por diante. Esse raciocínio vai dar muita confusão se o levarmos adiante e por isso vamos manter o foco apenas nos projetos limitados no tempo. Esses projetos têm início e fim (um custo determinado), e normalmente mudam ou acrescentam algo na empresa (um impacto limitado.)

Ao considerarmos projetos e tempo, definimos o ROI como um retorno dentro de um período. Ou então como o tempo que o projeto leva para se pagar, em função de quanto esse projeto agregou de valor. Sob estas condições, a fórmula fica assim:

 

Definição de ROI com tempo.
Definição de ROI com tempo.

 

Leia: o ROI do projeto é medido em períodos, calculado como a razão entre o custo do projeto e quanto de dinheiro o projeto traz a mais. Se dissermos que período é mês, estamos calculando quantos meses o projeto leva para se pagar.

Essa é a fórmula de ROI que eu usei no post R$20M, e é o que nos interessa para responder a pergunta do Rômulo:


Em “uma implantação de ferramentas analíticas (…) como medir (…) o ROI?”


Ganha um bombom quem percebeu que essa é a fórmula para o famoso “vai levar X anos para se pagar”. ;-)

Só para completar, podemos calcular um percentual de retorno por período, deixando a equação semelhante à definição inicial:

Definição de ROI percentual, com tempo.
Definição de ROI percentual, com tempo.

Projetos de BI

Agora temos uma definição para ROI, e sabemos que o retorno pode ser tanto uma melhoria nos resultados quanto a prevenção de uma piora destes.

Antes de continuarmos, deixe-me esclarecer uma coisa sobre o meu amigo.


O Rômulo mora em uma cidade no estado do Rio de Janeiro e foi aluno meu numa das turmas de BI da 4Linux, à distância. Ele é muito gente fina e um dia, ao vir para um congresso em São Paulo, entrou em contato comigo e marcamos uma pizza. Conversa vai, conversa vem eu percebi que não era um aluno típico de BI. Ele estava terminando o doutorado e precisou de uma ferramenta de integração de dados, de relatórios etc. e por isso foi atrás do Pentaho. Daí optou pelo EAD da 4Linux etc. etc. etc.

Foi um certo choque para mim, quase tão grande quanto ter dado aula para o Prof. Fidelis – que ensina Data Mining há mais de 20 anos – e para o Grimaldi, do BI Com Vatapá, outro gigante nacional. Dar aulas para caras muito mais gabaritados do que eu me dá um tanto de medo, mas enfim.


Então quando o Rômulo faz perguntas, ele coloca a coisa em outro nível. Ele não diz simplesmente “ROI de BI”. Ele é preciso: “ROI da implantação de ferramentas analíticas”. E não faz isso por pedantismo ou para se exibidir – ele é gente fina, lembrem-se! – mas sim porque é precisamente essa a expressão.

O que é um projeto de “implantação de ferramentas analíticas”? É o que popularmente chamamos de “BI”, e mais recentemente de “Data Discovery”: é a disponibilização de dados, para análises ad hoc, por meio de alguma ferramenta de análise multidimensional.

Não BI, Mas Sim Ferramentas Analíticas

Quase lá!!

E o quê um projeto de “implantação de ferramentas analíticas” entrega? O que ele cria na instituição, na empresa? Que retorno ele traz?

Depende.

É isso mesmo que você leu: d-e-p-e-n-d-e. ;-)

Imagine que estivéssemos falando de Data Mining. O que um projeto de Data Mining entrega é um modelo matemático que vai ser usado para tomar decisões automaticamente. Esse tipo de projeto tem uma meta clara desde o começo. São sempre coisas como “aumentar X% as vendas”, “reduzir em 100 clientes/mês de perda por atrito”, “economizar K dinheiro na distribuição” e tals.

Mas e um projeto que coloca, nas mãos dos empregados, uma ferramenta para montar “relatórios”?

Depende: para que eram necessários esses “relatórios”?

Pode ser que sejam usados apenas para substituir um trabalho braçal feito todo mês, como consolidar o balanço da empresa.

Ou talvez o usuário esteja tentando bolar uma estratégia de cobrança para recuperar dinheiro de caloteiros.

Ou talvez para desafogar a TI, que gasta muito tempo só fazendo consultas triviais nas bases, servindo a empresa inteira.

Róidebiai

Esse subtítulo parece “pedro bial”, se lido bem rápido… :-)

O cálculo do retorno do investimento de um projeto de BI, em geral, ou de implantação de ferramentas analíticas, em particular, vai depender muito da clareza de objetivos do gestor que patrocinou o projeto.

Há um sério problema na indústria de BI hoje em dia porque nem todos entendem como usar os dados para gerar valor. Quando entendem do assunto, gestores patrocinam projetos de Data Mining, com metas claras e portanto ROI fácil de se calcular, ou então apoiam projetos que visam equipar a força de trabalho da empresa com um ferramental necessária para o trabalho diário. Neste caso, especificamente, a meta não é aumentar um faturamento, mas sim reduzir o esforço do trabalho como um todo, aliviar uma dificuldade sistêmica, azeitar melhor as engrenagens que mantém a organização eficiente, produtiva.

Calcular um ROI desse tipo de meta não é fácil, isso quando não é impraticável. É exatamente o caso de um projeto que não impacta criando algo novo, mas impedindo que se perca algo que já se tem, ou se tem pouco.

Assim, medir o ROI da implantação de ferramentas analíticas equivale a medir a produtividade dos beneficiados com essas ferramentas. Pode ser a redução do trabalho para gerar informações, pode ser uma maior velocidade na solução de problemas ou qualquer outra melhoria marginal, difusa pela empresa!

E, claro, temos casos pontuais no qual o cálculo do ROI é mais prático. Por exemplo, digamos que a tal ferramenta analítica foi trazida para um conjunto pequeno de profissionais, para resolver um problema pontual. Um projeto desses vai entregar alguma coisa muito definida, que facilita a medida de ROI.

Conclusão

Rômulo, você queria saber, em “uma implantação de ferramentas analíticas (…) como medir (…) o ROI?”

Depende! Que problema essa implantação mirava resolver? Resolveu? Agregou dinheiro ou apenas impediu o desperdício?

Essa é uma regra geral de BI que eu sempre reforço:


Projetos de Inteligência de Negócios resolvem problemas. Se sua instituição não tem um problema para resolver, então você não tem nenhuma necessidade de BI, não importa o que os vendedores de ferramenta digam em contrário.


Implantar recursos de Inteligência de Negócios sem ter claro que problema você vai resolver é uma coisa bem pouco inteligente. Se está muito difícil calcular o ROI do seu projeto de BI, pense duas vezes: precisa mesmo? Para fazer o quê? Para resolver que problema? Pode ser que você esteja no camiho errado!

Até a próxima! :-)

 

 

Servidor Pentaho com Vagrant

Em um post anterior eu resenhei um livro da Packt que ensina como usar o Vagrant para criar ambientes de desenvolvimento. Lá eu comentei sobre como Vagrant é interessante, e até como eu tentei montar um servidor, mas não consegui. Ainda tenho muito que aprender sobre Puppet para fazer a coisa tão bem, mas vou dividir com vocês o que eu fiz. Na pior das hipóteses é um ambiente Pentaho pronto, e pode quebrar um bom galho.


Antes de mais nada eu preciso deixar claro que vou falar sobre o Pentaho por mera conveniência. Dá para aplicar tudo que eu vou falar aqui em qualquer plataforma, com quaisquer softwares de BI. Pentaho é do balacobado, mas cada um é livre para montar seu projeto como achar melhor. Eu gosto de software livre, lembram-se? Isso significa liberdade para usar o software que quiser. ;-)


O primeiro post caiu direto no assunto, e ficou meio “seco”. Por isso vou começar revisando a idéia toda com mais cuidado. Depois eu vou mostrar como fazer e, na conclusão, detono tudo. (Tee-he)

Processos & Ambientes

Desde sempre, e não apenas hoje em dia, qualquer projeto de BI sempre possuiu duas etapas: colher dados e usar dados.

A parte de colher os dados equivale à montagem de um DW, um Armazém de Dados. Já a parte de usar os dados corresponde a um projeto de Data Mining ou a um projeto que expõe os dados aos usuários por meio de ferramentas de análises.

Quando o projeto é pequeno podemos desenvolver na produção e simplesmente lidar com as consequências dessa bagunça, mas quando os projetos são maiores que um certo porte, esse “simplesmente” não se aplica mais. Precisamos de pelo menos dois ambientes: um de desenvolvimento e um de produção.

O problema é que manter dois ambientes separados acaba por originar discrepâncias entre eles, e aos poucos começam a ficar diferentes um do outro. Depois de um tempo as diferenças são tamanhas, e tão irreconciliáveis, que cada nova versão levada para produção gasta um tempo só ajustando o código para as diferenças.

E é neste ponto que a idéia de infraestrutura como código pode nos ajudar: ao invés de mantermos dois ambientes com configurações manuais, descrevemos cada ambiente com um código-fonte, tal qual um software. Desta forma mantemos um controle muito maior sobre cada configuração e, melhor ainda, podemos comparar ambas e evitar as discrepâncias que acabam por atolar o projeto a cada nova versão.

Softwares como Puppet e Chef cuidam para que as definições desse “código” sejam aplicadas e respeitadas. Sempre que um servidor sofre alguma mudança que o desvia de sua configuração “correta”, esses programas, chamados genericamente de provisionadores, forçam a configuração de volta, apagando as coisas erradas e restaurando as configurações definidas pelo projeto.

O Vagrant é um passo na direção de infraestrutura como código: ao invés de construirmos um servidor, simplesmente definimos um servidor virtual. Associado a provisionadores, conseguimos um projeto cuja configuração é uniforme de ponta-a-ponta. Mais: podemos trabalhar em projetos distintos, tendo um ambiente de desenvolvimento finamente ajustado para cada projeto, se um interferir com outro.

Se durante o desenvolvimento descobrimos que precisamos alterar alguma configuração, essa alteração entra no código que descreve o servidor, ao invés de ficar perdida em um manual qualquer. Por meio de um versionador, como Git, esse código de infra-estrutura entra no projeto e é distribuído para todos os envolvidos. Mais ainda, sendo versionado e propagado para a produção! É um mundo perfeito – ou não? ;-)

Vagrant BA Server

Agora eu vou mostrar para vocês a sequência de ações que eu tomei até construir um Pentaho BA Server apto a atender um projeto simples. Não é o resultado final perfeito, que eu gostaria de obter, pois ele não envolve nenhum provisionador – ainda estou batendo cabeça com isso, e não queria demorar para levar isso a vocês. Esse campo ainda está muito cru, e quanto antes essas idéias começarem a se espalhar por aí, melhor.

O processo é relativamente simples:

  1. Instalar o VirtualBox;
  2. Instalar o Vagrant;
  3. Criar um ambiente Vagrant;
  4. Adequar os parâmetros desse ambiente para o BA Server;
  5. Instalar o Pentaho BA Server.

Eu fiz tudo isso em Ubuntu 16.04-64bits, um Linux, mas deve ser possível repetir esses passos com Windows e Mac, já que eles são suportados.

Todas essas ações são tediosamente sem graça em Ubuntu:

  1. Abri um terminal e comandei sudo apt-get update, para atualizar os repositórios de pacotes;
  2. Instalei o VirtualBox comandando sudo apt-get install virtualbox;
  3. Instalei o Vagrant: sudo apt-get install vagrant;

    O site do Vagrant adverte as versões de repositório normlamente estão bem defasadas em relação ao projeto, e que não raro podem acabar apresentando problemas. Por isso, recomendam eles, baixe o instalador do site (aqui) ou compile o projeto do zero.


  4. Criei um ambiente Vagrant:
    1. Em outro terminal criei um diretório para o novo servidor: mkdir AmbienteVagrant;
    2. Entre neste diretório com cd AmbienteVagrant e criei o arquivo inicial: vagrant init precise32 http://files.vagrantup.com/precise32.box;
  5. Configurei esse ambiente para ter 1.5 GB e expor a porta 8080:
    1. No diretório AmbienteVagrant surgiu o arquivo Vagrantfile, que eu abri com o editor de textos;
    2. Entre as linhas que definem a configuração, Vagrant.configure(2) do e end, inseri esses dois trechos: config.vm.provider "virtualbox" do |vb|
      vb.memory = "1536"
      end
      e
      config.vm.network "forwarded_port", guest: 8080, host: 8080

    Isso vai mudar a memória da máquina virtual para 1.5GB ( = 1024 MB * 1.5), suficiente para um BA Server 5.x, e vai fazer um forward da porta 8080 da máquina virtual para a máquina real.

  6. Ainda dentro daquele diretório, subi o servidor Vagrant com o comando vagrant up. Na primeira execução ele baixou um disco virtual configurado com Ubuntu Precise Pangolin (12.04 LTS) para 32 bits, e só então subiu o servidor.

Voi-là! Agora temos uma máquina virtual pronta para ser configurada com o BA Server. O que precisamos fazer é bem simples: adicionar Java 1.7, baixar e descompactar o BA Server 5.4 e configurar o servidor para subi-lo automaticamente. Vamos nessa:

  1. Acessamos o servidor Vagrant rodando com o comando vagrant ssh. Um terminal se abre diretamente no servidor virtual;
  2. Vamos instalar o Java Oracle: é só adicionar o repositório e rodar um apt-get:
    1. Dentro do servidor Vagrant comandamos sudo apt-get update para atualizar a lista de pacotes disponíveis;
    2. Para adicionarmos a chave do repositório Java WebUpd8 precisamos de alguns pacotes. Instale-os com este comando:sudo apt-get install python-software-properties;
    3. Depois disso estamos preparados para adicionar a chave do PPA:sudo add-apt-repository ppa:webupd8team/java. Apenas bata enter para concluir;
    4. Atualize os repositórios novamente, com outro sudo apt-get update;
    5. Finalmente, comande a instalação do Java 7:sudo apt-get install oracle-java7-installer;

      A instalação do Java por meio de repositório no Ubuntu é um truque: a licença da Oracle não permite empacotá-lo no repositório, então o que realmente baixamos é um programa de instalação que coleta, por meio de um prompt, uma anuência com os termos legais da Oracle, para então baixar os arquivos do Java e configurá-lo. Por isso a série de pontinhos, indicando o download – uma coisa que não acontece com o apt-get ordinário.


  3. Ao final teste o java: comande java -version e veja se volta uma mensagem informando a versão;
  4. Vamos precisar de outro programa: unzip. Comande sudo apt-get install unzip para instalá-lo;
  5. Instale o BA Server:
    1. Ainda no SSH do Vagrant, entre sudo mkdir /opt/pentaho para criar o diretório no qual vamos deixar o servidor;
    2. Para facilitar nossa vida, mude esse diretório para “casa da mãe joana”, comandando sudo chmod 777 /opt/pentaho. Isso vai dar permissão de escrita geral no diretório pentaho;
    3. Mude para ele, cd /opt/pentaho, e baixe o Pentaho BA Server 5.4 a partir do SourceForge:wget http://bit.ly/29gb4ak --output-document=biserver-ce-5.4.0.1-130.zip
    4. Depois que ele terminar de baixar, descompacte-o: comande unzip biserver-ce-5.4.0.1-130.zip;
    5. Terminou de descompactar? O zip não é mais necessário, e você pode removê-lo com rm biserver-ce-5.4.0.1-130.zip. Não precisa, já que isso não vai forçar o tamanho do disco virtual para baixo automaticamente.

Ufa! Quase lá! Primeiro deixe o BA Server pronto para atuação automática:

cd biserver-ce
./start-pentaho.sh

Responda com enter à mensagem e aguarde alguns minutos. Daí teste abrindo seu navegador web e apontando para http://localhost:8080. Se tudo deu certo você verá a tela de login do servidor. Não se esqueça de baixar o servidor antes de prosseguir, com um ./stop-pentaho.sh dentro da caixa Vagrant.


É importante você rodar o BA Server ao menos uma vez manualmente, e assim se livrar do prompt de execução inicial. Caso contrário o servidor pode não subir na inicialização automática.


E o que falta? Bom, queremos que o servidor Vagrant fique pronto com um único comando – vagrant up – sem precisar de mais nada. Então é necessário configurar o servidor para subir e baixar sozinho, na inicialização da máquina.

Configurando o BA Server para Início Automático

O procedimento descrito aqui foi retirado do capítulo 3 do livro Pentaho na Prática. Você pode baixá-lo [deste link][pnpcap3_bitly], e ter um gosto do livro.

  1. Primeiro, garanta que o servidor Vagrant esteja no ar emitindo o comando vagrant up dentro do diretório em que criamos o arquivo de configuração Vagrant (/home/USUÁRIO/AmbienteVagrant);
  2. Faça login no servidor Vagrant com vagranta ssh;
  3. Assuma credenciais de root na caixa Vagrant: sudo su;
  4. Mude para o diretório de scripts de serviço: cd /etc/init.d;
  5. Abra um editor para um arquivo novo, neste mesmo diretório, chamado biserver-ce: nano biserver-ce (pode usar o vim, se quiser;)
  6. Agora precisamos do script de inicialização de servidor, para Linux. Abra este link em uma outra aba do seu navegador e procure o item “Script de Inicialização do BI Server para Linux”. Baixe este script, abra-o e copie tudo para dentro do arquivo do item anterior. Salve, pressionando CTRL+O e batendo enter, e depois saia do editor, pressionando CTRL+X;
  7. Por fim ative a execução automática: ainda no terminal Vagrant, como sudo, comande: (atenção! são dois blocos diferentes!)
ln -s /etc/init.d/biserver-ce /etc/rc2.d/S99BAServer
ln -s /etc/init.d/biserver-ce /etc/rc3.d/S99BAServer
ln -s /etc/init.d/biserver-ce /etc/rc4.d/S99BAServer
ln -s /etc/init.d/biserver-ce /etc/rc5.d/S99BAServer
 
ln -s /etc/init.d/biserver-ce /etc/rc0.d/K19BAServer
ln -s /etc/init.d/biserver-ce /etc/rc1.d/K19BAServer
ln -s /etc/init.d/biserver-ce /etc/rc6.d/K19BAServer

É isso. Saia de tudo, pare o servidor Vagrant com vagrant halt e depois reinicie-o com vagrant up. Assim que o prompt voltar, abra um navegador web e aponte para http://localhost:8080/pentaho.


O comando vagrant up pode terminar antes de o servidor Pentaho estar no ar. Dê alguns minutos para tudo acabar de acontecer antes de tentar acessar o BA Server com o navegador web.


Conclusão

Acabei de reler tudo, para fazer a conclusão, e acho que devo um pedido de desculpas: parecia mais fácil na minha cabeça… Se você tiver algum problema, ou dúvida, deixe aqui um comentário, que eu te ajudarei.

Vamos lá, para a conclusão.

Virtualização é uma idéia muito legal. Virtualizar máquinas permite desde jogar antigos arcades a testar sistemas operacionais sem precisar arriscar ferrar a nossa máquina e nossos dados.

No mundo dos desenvolvedores, as coisas ficam cada vez mais complicadas. Uma das complicações mais perniciosas é o duo ambiente de desenvolvimento/produção: a tendência humana em mexer agora e documentar depois acaba bagunçando a situação a tal ponto que cada novo deploy, isto é, a cada entrega de uma nova versão no ambiente de produção, exige muito trabalho para compensar as diferenças entre os ambientes.

Para resolver esse problema surgiram tecnologias englobadas na disciplina DevOps, como os provisionadores, softwares que configuram, e forçam essa configuração em um ambiente, automaticamente. Dois membros desta classe são o Puppet e o Chef, que permitem definir uma infraestrutura como se fosse código, tornando possível até mesmo uma coisa estranha: versionar uma infraestrutura, isto é, guardar todas as configurações que ela já teve ao longo do projeto.

Alguém teve a (óbvia e genial) idéia de combinar essas duas coisas e conseguir uma terceira ainda mais bacana: ambientes de desenvolvimento isolados!

O software Vagrant, sobre o qual a Ed. Packt oferece um livro muito bom, faz exatamente isso: permite a criação de ambientes estanques, configurados ao gosto do projeto. Graças a ele, qualquer equipe pode ter um ambiente de desenvolvimento “limpo” (i.e. exclusivo por projeto), uniforme (igual para todo mundo) e estável (não muda sem querer ou por acidente.)

Em um post anterior eu resenhei o livro da Packt sobre o Vagrant, e hoje eu dei aqui o passo-a-passo para montar um servidor Vagrant para projetos que usem o Pentaho BA Server 5.4.

… ou quase: o ideal teria sido definir a configuração como um script Puppet ou Chef (scref?? kkk) e deixar o provisionador tomar conta. Mas eu ainda tenho muito a aprender e por isso resolvi mostrar o que eu já consegui fazer.

Burning Down the House

Eu seguia feliz da vida estudando o Vagrant, quando, de repente! (kkk), fiz o curso da 4Linux sobre DevOps! Foi quando eu fui obrigado a aprender sobre o [Docker][docker_bitly], algo do que eu vinha escapando deliberadamente (infra não é minha praia.) O Docker leva adiante a idéia de isolamento proposta pela virtualização, mas a um custo de infra menor: enquanto que a virtualização quebra uma máquina real em várias virtuais, o Docker monta várias máquinas “virtuais” compartilhando a mesma infra. Isso tem uma grande vantagens logo de saída: por não virtualizar tudo, mas apenas a parte que interessa, ele é muito mais leve e por isso usa melhor os recursos da máquina. De cara a performance de um container Docker é melhor que a de uma máquina virtual.

Há muita coisa ainda para se evoluir e resolver na tecnologia de containers mas, como colocou o The Register, se virtualização é uma tecnologia importante e valiosa em certos cenários, em outros ela é pesada e ineficiente, e coisas como containers são o futuro.

Uma destas coisas, na minha opinião, é justamente a gestão de ambientes, e não apenas de desenvolvimento! Como um container tem performance nativa, podemos montar servidores reais usando Docker e ainda atingir o grau de isolamento e controle proposto pelo Vagrant. No fundo, é a mesma coisa, mas executada de uma forma diferente.

Por isso eu disse, no começo, que “vou mostrar como fazer e, na conclusão, detono tudo. (Tee-he)”: não sei se vou continuar investindo no Vagrant. Ao menos por um tempo, eu definitivamente vou cair de cabeça no mundo do Docker! Eu até comprei um livro da Packt sobre isso, o Learning Docker. Assim que eu acabar de lê-lo vou fazer sua resenha aqui e depois montar o mesmo ambiente de hoje usando Docker.

Docker

Docker

Docker Docker Docker Docker Docker Docker Docker Docker

Já reparou como é viciante falar Docker? Docker Docker Docker Docker

Até a próxima! ;-)

Projeto de Sucesso

Eu já escrevi um pouco sobre como projetos de BI “acontecem”. Em Cruel Sucesso eu divaguei sobre a eterna sensação de fracasso que algubs projetos de BI experimentam, mesmo que ele esteja indo de vento em popa. No Todos os Caminhos Levam a um DW eu me diverti escrevendo uma história maluca sobre um projeto de BI fictício, que nasce como uma planilha Excel e cresce como mandiopã, até explodir e voltar ao começo. Mudando o foco para requisitos, eu discorri sobre Ágil e BI (De Agilidade e BI), para descaradamente anunciar meu curso de requisitos de BI para gestão ágil.

Quase sempre esses posts vem do nada, motivados por alguma situação pela qual passei. Eu estava com o novo fascículo da série Soluções Clássica quase pronto (Credit Scoring), mas aconteceu de novo: me meti num debate sobre o que era um “bom” projeto de BI.

Bom, eu tenho uma idéia do que deve ser um. Vou dividir com vocês a opinião que eu coloquei no debate, mas já sabem, né?


Disclaimer: o que você vai ler é 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?


Sucesso Não Existe

Primeiro, não existe mundo perfeito. Não adianta sonharmos com a próxima grande ferramenta para resolver nossos problemas, porque o melhor que pode acontecer é resolvermos os problemas atuais e caírmos em novos. O que faz a diferença, na minha humilde opinião, é evitarmos empacar. Se empacamos, o projeto começa a fazer água, e quanto mais tempo demoramos para resolver o problema da vez, menos relevante o projeto de BI se torna, até que um dia todo mundo está se virando sozinho e o projeto é mantido vivo apenas com auxílio de aparelhos.

O que torna um projeto bom, de sucesso, então, é o fato de ele estar sempre em movimento, resolvendo cada problema como um corredor salta obstáculos: pula, corre, pula, corre, pula, corre… Eventualmente, um dia a coisa toda entra em velocidade de cruzeiro, a quantidade de erros cai substancialmente e a empresa desenvolve uma cultura de BI. Esse é o projeto de sucesso: falível, sempre precisando de alguma melhoria, mas que entrega resultados e é acreditado pela organização, sustentado pela cultura de conhecimento da empresa.


Um projeto de BI de sucesso, IMHO, é aquele que resolve um problema atrás do outro, sempre entregando um pouco mais de resultados a cada etapa, capaz de suplanta as próprias limitações e ir ao encontro das expectativas do cliente.


O Caminho para o Sucesso

Ora, dirão vocês, bolas. A definição acima é uma rematada platitude: não diz nada de realmente útil ou prático. Concordo. Vamos escrevê-la ao contrário para ver se fica mais claro:


Fracassa o projeto de BI que persistir em trilhar caminhos sem saída.


Consegui me fazer entender? Quando optamos por este ou aquele caminho, corremos o risco de enveredar por uma rua sem saída. Projetos – de qualquer tipo – que reiteradamente optam por entrar em becos sem saída acabam morrendo porque, cedo ou tarde, a organização se cansa de tanto vai-e-vem! Quer seguir no caminho para o sucesso? Esforce-se por evitar decisões ruins!

Decisões, Decisões, Decisões

Devo ter engolido o grilo falante quando era criança, pois eu sempre escuto uma voz fininha, tirando onda com a minha cara. Desta vez ela disse “Intelijumento! Se soubéssemos que decisão vai dar errado, não a tomaríamos! Dã!”

Óbvio, claro, não se questiona isso. É a própria essência do processo decisório, é a meta personificada de se fazer uma escolha: fazer a escolha certa!

Como saber se uma opção, e não a outra, é a correta? Ah, de muitas formas. Em alguns casos estamos passando pelo mesmo problema uma segunda vez. Se da primeira fizemos a escolha certa, tendemos a repeti-la, e vice-versa: deu errado antes? Vamos tentar outra coisa. Em outros casos não conhecemos, ainda, as consequências de cada caminho, mas podemos avaliá-las com o que estivar à mão – opiniões, análises estatísticas, jogar cara-ou-coroa – e escolher a que parece melhor.


Em último caso, recorra a um taxista: eles sempre sabem o que os outros deviam fazer. ;-)


O Que Funciona?

E aqui chegamos no ponto em que eu queria: o que funciona em um projeto de BI? Como montar um projeto que vai empacar menos?

Armazéns de Dados

Um bom DW é fundamental para qualquer projeto de BI de sucesso. Você pode se virar com dumps, ODFs, Data Lakes, mas esses caminhos são becos sem saída: cedo ou tarde o peso da falta de integração dos dados (dumps e Data Lakes) e das manutenções de modelo e ETL (ODFs e EDW Dimensional) vão afundar seu projeto – mesmo que todo o restante funcione.

Logo, lição número um: monte um bom projeto de DW, capaz de incorporar novas fontes num estalar de dedos e de produzir novas apresentações de dados em dois palitos. Quem acompanha meu blog já sabe o que isso significa: Data Vault.

Equipes

Ferramentas são importantes, mas não são nem metade da solução. Problemas são resolvidos por pessoas com conhecimento e competência para aplicar ferramentas, não pelas ferramentas. E outra: muito ajuda quem pouco atrapalha – gerente bom é gerente quietinho, que serve a equipe, ajudando a remover obstáculos.

Processos

Há dois grupos de processos dentro de um projeto de BI, especificamente:

  • Processos de Desenvolvimento;
  • Processos de Atendimento.

O primeiro é batata: é o processo pelo qual a equipe (parte dela, na verdade) mencionada acima produz os resultados requisitados pelo cliente.

O segundo processo é virtualmente ignorado pela comunidade de praticantes de BI: é o processo pelo qual a outra parte da equipe apóia o cliente. Sim! É o time de “vendedores”, instrutores e tutores, que trabalham com o cliente para entender o que ele precisa e transformar isso em requisitos, que serão tratados pelos desenvolvedores; que ajudam cada novo usuário a aprender a usar as ferramentas e os dados do projeto. O tutor é uma figura inexistente na literatura, mas pode ser visto como um instrutor particular, que vai resolver o problema do usuário uma primeira vez, e ajudar o usuário a repetir esses passos. Ele é diferente do instrutor, que ensina a usar o que está pronto. O tutor cria coisas novas – novas práticas, novos usos dos dados, novos requisitos.

Processo de Desenvolvimento

Não tem segredo: waterfall [bigbang][bigbang_bitly] não funciona, ponto final. A única forma de gestão de projetos que dá certo é Ágil, e neste ponto Scrum é o meu preferido.

Processo de Atendimento

De novo, não tem segredo: um grupo de vendedores (ou evangelistas/analistas de requisitos) e apoiadores (instrutores e tutores) expostos exaustivamente, com uma mensagem clara: Precisa de dados? Me ligue!. Eles interagem com o processo de desenvolvimento alimentando novas histórias no backlog (para os vendedores), com o cliente por meio de chamadas de suporte (tutores/suporte técnico) e com a empresa por meio da capacitação corporativa.

Soluções

Todo projeto de BI usa quatro tipos de soluções:

  • Apresentações;
  • Relatórios;
  • OLAP;
  • Data Mining.

As três primeiras são baseadas em ferramentas, e portanto são resolvidas pela incorporação de profissionais das respectivas ferramentas ao time. Já a última é tratada como uma conjunto de projetos-filhos e raramente é tratada in house. O normal, para soluções que envolvem Data Mining, é contratar uma empresa especializada no assunto desejado.


E os painéis? Painel não é solução de BI, é ferramenta de (tcham-tcham-tcham-tcham-tcham!) apresentação de dados (e não, não é ferramenta de análise! Quem analisa é OLAP e Data Mining.) Logo, você pode ler o primeiro item da lista acima como “dashboards“. Porém, há muitas formas de se apresentar dados e eu evitaria fechar esse escopo prematuramente, jogando tudo na vala comum “painel”.


Um bom projeto de BI precisa incorporar essas categorias, sem exceções. Não precisa oferecer tudo ao mesmo tempo, desde o dia 1, mas deve garantir que o roadmap vai contemplá-las ao longo do caminho. Como conseguir isso? Tente incluir no seu time um generalista de BI, aquele cara que entende um pouco de tudo, e sabe como os assuntos se interconectam, como amadurecem ao longo do ciclo de vida do projeto.

Se você não puder contar com um membro permanente, aceite um membro flutuante, como um coacher, por exemplo. Se não existir na empresa, procure um consultor externo. Raramente um profissional desse cresce durante um projeto de BI, e você só vai achar um na sua empresa, à sua disposição, por pura sorte.

Conclusão

Então vamos lá: um bom projeto de BI é composto por um time multi-disciplinar (especialistas em ferramentas de ETL, apresentação e exploração de dados), com uma equipe voltada para o atendimento do cliente (esqueça a idéia de ter “self-service 100%”) e outra voltada para uma linha de produção de soluções. Na entrada dessa linha está um DW baseado em Data Vault, no meio as áreas de dados para consumo e na ponta as ferramentas de uso dos dados (apresentação, relatórios e OLAP.) Pipocando aqui e ali aparecem os sub-projetos de Data Mining, tocados normalmente por consultorias externas e nascendo de necessidades pontuais. Essa visão geral pode ser melhor organizada por um generalista.

Nenhuma destas idéias é minha, e isso em parte me dá confiança nelas: Bill Inmon chama esse modelo de CIF, o inglês para Fábrica de Informações Corporativas.

Diagrama da Fábrica Corporativa de Informações.
Diagrama da Fábrica Corporativa de Informações.

Outro nome para essa abordagem é BICCBusiness Intelligence Competence Center. Veja este artigo para uma discussão mais detalhada do conceito.

Não é um BICC, mas dá uma idéia de como funciona a tal "linha de produção".
Não é um BICC, mas dá uma idéia de como funciona a tal “linha de produção”.

O restante da minha confiança nesse modelo nasce de eu ter experimentado tudo isso: Data Vault, Scrum, Data Mining, OLAP, Relatórios, equipes proficientes etc. etc. etc. Eu vi projetos de BI fracassarem ao descuidar desses fundamentos, como também vi projetos de BI que estão vivos até hoje, alguns zumbis, outros mancando, mas em operação. Se os que dão certo trazem pistas do que pode ser o mais importante, ou o que dá resultados, os que se arrastam, semi-mortos, são os mais valiosos para entender como e porque as coisas dão errado.

É isso, até a próxima. ;-)

Data Vault – Como Usar

Um dos leitores do blog deixou este comentário em 18/5/16:


Fábio, gostaria de mais instruções sobre o data vault, como aplicar, onde aplicar e como é sua modelagem e arquitetura.


Prometi a ele que o próximo post responderia essa questão. Então aqui está: Data Vault, uma visão geral sobre onde aplicar, como modelar e em que arquitetura colocá-lo.

Do Começo, Por Favor

Data Vault é uma metodologia de desenvolvimento de Armazém de Dados Corporativo (do Inglês EDW), que inclui modelagem e processo de ETL. A versão 1.0 parava aí, já a 2.0 vai adiante, até a camada de apresentação dos dados.

Essa técnica foi inventada e desenvolvida por Daniel Linstedt para um projeto na mítica Lockheed Martin, que faz (fazia?) o mítico Blackbird SR-71, o avião dos X-Men. Baixe a amostra do Building a Scalable Data Warehouse with Data Vault 2.0 e leia o prefácio (do mítico Bill Inmon – isso aqui tá um templo grego de tanto mito!!) para ver essa história.

Perdão, mas eu precisava colocar isso aqui.
Perdão, mas eu precisava colocar isso aqui.

Aplicando Data Vault podemos desenvolver um Armazém de Dados com baixo custo, alta produtividade, baixo retrabalho, com processo de ETL de alta performance e altíssimo MTBF.

Volte Mais!

E porque precisamos de um Armazém de Dados mesmo? Bom, não é o assunto deste post, mas aqui vai, resumidamente:


No fundo, não “precisamos” de DW. Precisamos é armazenar a evolução dos parâmetros da empresa ao longo do tempo. Podemos fazer isso de várias formas: um estagiário anotando valores em um papel de pão, ou uma planilha Excel, ou dumps de bases em um cluster Hadoop. Ocorre que, por acaso, DW é a tecnologia adequada para isso.


Leia meu post Um Ponto Fita o Mundo para ver o argumento inteiro.

Vamos continuar?

Por Quê Adotar DV?

Todo EDW cumpre duas funções básicas:

  • Puxa dados dos vários sistemas da empresa para um repositório central;
  • Integra os dados dos diversos sistemas em uma visão abrangente.

Um EDW precisa puxar os dados de todos os sistemas porque qualquer se não olharmos em todos os dados da empresa nunca teremos a certeza de termos investigado tudo que há para ser examinado. É como perguntar que livro sumiu da biblioteca: só olhando todos vamos saber qual não está lá. Se o gerente financeiro pergunta “quais são todos os gastos da empresa”, precisamos olhar tudo!

Pense: se sua empresa tiver dois sistemas em MySQL, um em SQL Server, um em Postgres e outro em Oracle, como escrever um SQL que percorra todas essas bases? Não dá, não é? Os dados precisam estar em um repositório centralizado por simples limitação das atuais tecnologias de banco de dados: como em geral usamos SQL para fazer essas pesquisas, e um SELECT não consegue consultar – ao menos não de maneira fácil – dois ou três ou mais bancos de tecnologias diferentes ao mesmo tempo.

Os dados precisam estar integrados, o que significa bater os CPFs 012345678-00 com 1234567800. Quando puxamos um relatório do cliente 012.345.678-00 precisamos que ele seja identificado em todos os sistemas, não importando se na origem ele aparece como 1234567800, 012345678-00, 012.345.678-00 ou de qualquer outra forma. Dados não-integrados fornecem respostas erradas. Sem integrar os dados, seu DW não vale o HD no qual está gravado.

Há várias técnicas para construir um DW atendendo essas duas obrigações:

  • Copiar tudo da origem, mantendo os mesmos modelos, e integrar na hora de fazer a consulta. Frágil, trabalhoso e pesado (consome muita máquina;)
  • Copiar tudo da origem, gravando em um novo modelo na Terceira Forma Normal. Mais robusto e de melhor performance que o anterior, mas de evolução e manutenção tão difícil que beira o insano;
  • Copiar a origem em um novo modelo, como no item anterior, mas em um Modelo Dimensional. Não tão robusto, mas de boa performance, com evolução e manutenção práticas e simples no começo, mas tendendo à impossibilidade de manutenção e evolução com o tempo.

E finalmente, o Data Vault, que não sofre de nenhum destes problemas e tem todas as vantagens. Resumindo em figuras:

Os impactos das mudanças na arquitetura tradicional.
Os impactos das mudanças na arquitetura tradicional.
Os impactos das mudanças, agora no arquitetura com DV.
Os impactos das mudanças, agora no arquitetura com DV.

Só para ficar claro: por “nenhum impacto aqui”, no último quadro da figura acima, eu quero dizer “nenhum impacto de manutenção”, já que, obviamente, pode ser preciso criar algo novo. Não haverá impacto no que existe, não será necessário mudar nada.


Adotar Data Vault como metodologia para desenvolvimento de um DW vai evitar os problemas que costuma comprometer os DWs da 3FN e Dimensionais.


Hoje vamos deixar só com essa afirmação, porque este é um post de visão geral, mas você pode seguir os links apresentados até agora para ler o (extenso) argumento explicando porque é assim.

Como Aplicar?

De fato, não há segredo na aplicação de Data Vault. A técnica meio que se resume em:

  • Quebrar o trabalho em “histórias”: quero medir isso, quero analisar aquilo;
  • Daí, para cada uma:
    • Identificar as tabelas na origem que respondem essas perguntas
    • Expandir o modelo de dados do DV com hubs, links e satélites;
    • Gerar automaticamente ETL de carga do DV;
    • Desenhar o ETL para a área de apresentação.

Existem padrões e técnicas para cada atividade, e a metodologia casa-se como uma luva à gestão ágil. Meu método preferido é o Scrum, e chega a ser surpreendente ver como DV adequa-se tão perfeitamente ao Scrum.


Veja meu post De Agilidade e BI para alguns comentários sobre o levantamento de requisitos para projetos ágeis.


Como É a Arquitetura?

Você já deve ter intuido a forma geral da arquitetura em uma das figuras anteriores. Reorganizando e renomeando as partes daquela figura temos uma visão mais clara:

Arquitetura Data Vault.
Arquitetura Data Vault.

Ou seja:

  1. Um ETL (gerado automaticamente) traz os dados de cada origem;
  2. Um banco de dados (preferencialmente relacional, mas um Hadoop does too) recebe e, graças ao modelo de dados do DV, integra tudo “na entrada”;
  3. A partir deste banco um segundo processo de ETL popula as soluções;
  4. Essas soluções podem ser de todo tipo: análises multidimensionais (OLAP), Data Mining (CRM etc.), painéis, relatórios etc. etc. etc.

Cada uma destas soluções após o segundo ETL têm suas arquiteturas particulares. No fundo a arquitetura de um DV são dois ETLs com um banco com modelo de dados DV no meio, mais nada. A partir daí, tudo fica igual à qualquer outro projeto de BI.

Modelagem

A modelagem de um Data Vault é relativamente simples, e você pode ler um pouco mais sobre ela neste post. Grosso modo, porém, resume-se ao seguinte:

  • Identificar chaves de negócio e criar hubs;
  • Encontrar relacionamentos entre chaves de negócio e criar links;
  • Escolher os atributos de hubs e links e criar os satélites.

Hubs

Hubs são tabelas que guardam conceitos, ou chaves, de negócios. Uma chave de negócio é um conceito importante para a empresa: cliente, produto, pedido, posição no call center, empregado, etc.

Tabelas hub possuem as seguintes colunas, nem uma a mais nem a menos:

  • Business Key: chave primária, um inteiro sequencial;
  • Load Date/Timestamp: data e hora da inserção do registro;
  • Record Source: fonte da chave de negócios;
  • Source business key: chave de negócio no sistema de origem.
Uma tabela hub.
Uma tabela hub.

Não há grandes segredos aqui: tabelas hubs acumulam as chaves de negócio, que são a espinha dorsal do modelo. A chave primária é a BK. A cada carga insere-se apenas as novas chaves de negócio dos sistemas de origem. Se a chave já existe, nada é feito. Se a mesma chave existe em vários sistemas, apenas a primeira que chegar é inserida.

Links tão tabelas que guardam o relacionamento entre dois hubs. Uma tabela link que relaciona os hubs 1, 2, … , n possuem as seguintes colunas, nem mais, nem menos:

  • Link Key: chave primária, um inteiro sequencial;
  • Load Date/Timestamp: data e hora da inserção do registro;
  • Record Source: fonte do relacionamento;
  • BK1: business key do hub 1;
  • BK2: business key do hub 2;
  • BKn: business key do hub n.
Uma tabela link.
Uma tabela link.

Ela também não sofrem atualização: novos relacionamentos são inseridos, antigos são ignorados. Se um relacionamento já registrado não é mais detectado, ele não é apagado.

Satélites

Satélites são como tabelas de dimensão: guardam os contextos de hubs e links. Uma tabelas satélite de um hub/link que guarda os atributos A1, A2, … , An de um hub/link X possui as seguintes colunas, nem mais, nem menos:

  • Business Key/Link key: chave primária do hub/link
  • Load Date/Timestamp: data e hora da inserção do registro;
  • Load End Date/Timestamp: data e hora do fim da validade daquele registro (default é NULO);
  • Record Source: fonte dos atributos;
  • A1: atributo 1;
  • A2: atributo 2;
  • An: atributo n.
Uma tabela satélite.
Uma tabela satélite.

Modelo Completo

A coleção dessas tabelas e seus relacionamentos dão o modelo completo:

As tabelas combinadas no modelo.
As tabelas combinadas no modelo.

A etapa seguinte é construir o ETL para dentro do DV, e depois do DV para a camada de apresentação/consumo de dados.

ETL

Um DV possui duas vantagens “matadoras”: integração dos dados no modelo, ao invés de no ETL como é o mais comum, e um ETL padronizado. Graças à essa padronização o ETL de um DV inteiro pode ser gerado automaticamente: a partir de alguns gabaritos de SQL podemos construir o processo que lê e grava todos os hubs, links e satélites.

Eu sempre uso o Pentaho Data Integration (PDI) para processos de ETL, e meu curso de DV entrega ao aluno um gabarito de projeto completo – é só tirar da caixa e usar. A última versão dele traz até os SQLs para criar as tabelas no Data Vault.

Isso para o primeiro ETL, para dentro do DV. O segundo ETL, saindo do DV para a camada de apresentação, é mais particular, e não há como automatizar sua geração. Por outro lado, como todos os pontos de partida não são mais os sistemas de origem mas sim o DV, a “forma” geral desse segundo processo é mais uniforme, e alguns padrões acabam por facilitar seu desenvolvimento.

Por exemplo, dimensões são quase sempre construídas a partir de um hub e seus satélites, e tabelas fatos originam-se de links. Construídos os SQLs que lêem isso no DV (e nisso eles seguem um padrão de JOINs bem cadenciado), o passo seguinte é fazer trocas de chaves naturais por delegadas e, em caso de necessidade, limpar os dados.

Conclusão

Adoro quando um leitor pede algo, pois escolher o tema do próximo post, para mim, é como escolher roupa para sair: muito, muito difícil – e se não gostarem? e se ficar ruim? e se eu falar besteira por saber pouco? E se?…

Vimos que um Data Vault é uma metodologia que habilita a realização da visão de Bill Inmon, a Corporate Information Factory. A [CIF][cif_bitly] (até o advento do DV, outro mito) é como uma linha de produção, que ingere todos os dados da empresa e “fabrica” produtos de dados conforme as necessidades vão surgindo.

Data Vault é uma metodologia composta por uma modelagem, um processo de geração automática de ETL e outros elementos (como padrões e nomenclaturas.) O EDW se completa com um segundo processo de extração, que leva os dados para as áreas de apresentação, em formato dimensional ou não. Tudo em um processo de desenvolvimento que nasceu para ser tocado com gestão ágil (Scrum, na minha preferência), boa parte automatizada e com baixo ou nenhum retrabalho.


Não deixe de ver o post As Vantagens do Data Vault para mais sobre como um DV pode ajudar seu projeto de EDW.


É claro que nada é 100% a prova de falhas, defeitos ou problemas e eu mesmo já enfrentei minha cota de surpresas, dificuldades e maluquices nesse caminho que venho trilhando há alguns anos. Mesmo assim, hoje em dia, um Data Vault é a coisa que mais se aproxima de um método perfeito.

Fora essa babação no final, acredito que era isso. ;-)

As Vantagens do Data Vault

Semana passada, 6/5/16, eu assisti uma palestra sobre uma empresa chamada Attunity, e suas ferramentas para Business Intelligence. Vendo as promessas do representante brasileiro eu me dei conta de que já escrevi bastante sobre DV, mas nunca escrevi especificamente sobre as vantagens trazidas pela adotação de Data Vault. Vamos corrigir isso hoje, partindo desta apresentação.


Você pode pular direto para a lista de vantagens clicando aqui.


Uma Nova Categoria

Estamos em 2016 e já lá se vão cerca de 40-50 anos desde que Bill Inmon começou o debate sobre Armazéns de Dados, e 24 anos desde seu livro Building the Data Warehouse. Muita água passou embaixo da ponte e todas suas idéias estão sedimentadas, firmes, sobre as quais se assenta a moderna indústria de DW. Um destes conceitos é a Corporate Information Factory, que agrupa as fontes de dados e seus consumidores como uma linha de produção.

Diagrama da Fábrica Corporativa de Informações.
Diagrama da Fábrica Corporativa de Informações.

Tal qual a revolução industrial fez com a manufatura, graus de automação sucessivamente maiores estão acelerando e simplificando o desenvolvimento, manutenção e gerenciamento de Data Warehouses. Instrumental para essa revolução foram tecnologias aparentemente irrelevantes, como modelos de dados e metodologias de desenvolvimento.

Metodologias como Scrum, Continuous Integrations e DevOps agem para diminuir a intervenção e variabilidade da ação humana, enquanto que outras, como Modelagem Dimensional e Data Vault, domam a confusão dos sistemas OLTP e permitem a criação de algoritmos. E é justamente essa criação de algoritmos que permite automatizar o processo de desenho, desenvolvimento e manutenção de DWs.

Uma nova categoria de ferramentas brotou desse fértil ambiente: ferramentas de automação de gestão de DW. Ainda não vi esse ramo ser tratado por um acrônimo, nem mesmo ter um nome mais comum, mas acho que, em Inglês, seria algo Data Warehouse Management Solutions, ou DWMS. Já sabem: se virem por aí, apareceu no GeekBI primeiro. ;-)

Continuando, essa categoria já tem alguns nomes internacionais:

Fazia tempo que eu não visitava o BI Ready, empresa de Ian Nicholson com quem já troquei umas idéias no LinkedIn. Surpresa! Ela foi adquirida pela Attunity e agora são um nome só. Não é à toa que, na apresentação, a Attunity declarou pertencer a essa turma – ela comprou “metade” das empresas dessa área!

Esse é o Ian Nicholson, fundador da BI Ready, fazendo a mesma cara que eu faria se tirasse essa foto.
Esse é o Ian Nicholson, fundador da BI Ready, fazendo a mesma cara que eu faria se tirasse essa foto.

Processos e Problemas

Um projeto de DW que hoje é chamado de “tradicional” (i.e., feito com metodologias de mais de 15 anos atrás) envolvia as seguintes etapas:

  1. Levantar os requisitos;
  2. Estudar os dados de origem;
  3. Desenhar o modelo dimensional;
  4. Desenhar o processo de ETL;
  5. Colocar em produção;
  6. Dar manutenção: propagar as mudanças dos sistemas de origem e adequar às novas necessidades do cliente.

Esse projeto em geral era tocado dentro de uma moldura PMI (a.k.a. Waterfall). Era um método tão certeiro e determinístico que até hoje todo mundo sabe que, feito assim, sempre falha.

Os problemas de um DW 'clássico'.
Os problemas de um DW ‘clássico’.

DW feito por cópia dos bancos de origem é a pior escolha possível, a menos que seja para uma padaria, uma farmácia, uma banca de jornais etc. ;-) Veja que não estou falando de palco (stage), mas de montar o DW como uma coleção de réplicas. Um modelo dimensional é o mínimo necessário para sobreviver aos problemas que serão apresentados ao final desta seção.


Com o advento do Manifesto Ágil e Data Vault, um projeto de DW moderno é tocado assim:

  1. Levantar os requisitos da próxima entrega (30 dias;)
  2. Estudar os dados de origem até encontrar o estritamente necessário para próxima entrega;
  3. Desenhar o DV;
  4. Gerar automaticamente o processo de ETL;
  5. Derivar dados para apresentação;
  6. Colocar em produção e reiniciar o ciclo.

A manutenção é incorporada nas sprints.

Veja que, grosso modo, o processo em si não mudou muito: de projeto waterfall passamos para Scrum, de modelo Dimensional no miolo do DW passamos para um Data Vault e o ETL principal é gerado automaticamente.

Os problemas que existem (existiam e vão continuar existindo) são:

  1. Integração: sem integrar e limpar 100% dos dados, todas as respostas são suspeitas. Ou você confiaria nos números sabendo que algo pode ter ficado de fora?
  2. Historiamento: não adianta montar um armazém que não guarda histórico. Fazer isso é cuidar de dados operacionais e jogar a água fora com o bebê – o maior valor dos dados está no histórico;
  3. Mudanças na origem: sistemas transacionais representam os processos que a empresa executa. Se a empresa muda, forçosamente os OLTPs precisam mudar, e o DW vai ter que ser adequado, sempre;
  4. Performance de ETL: a menos que a empresa esteja definhando, ela sempre vai crescer, sempre vai querer mais dados. O hardware para ETL sempre acaba ficando obsoleto, por um motivo ou outro, cedo ou tarde. O truque é extrair tudo que ele pode dar, e não desperdiçar nada;
  5. Velocidade de mudança: por fim, em cima de todos os problemas apresentados, temos o fato de que as coisas não estão ficando mais calmas, mais lentas, e sim mais rápidas, com mais demandas e mais complexidade.

Ferramentas…

As novas ferramentas de automação de DW se propõem a resolver esses problemas.

O Attunity propõe resolver um DW em dois passos:

  1. Usando o Attunity Replicate os dados são trazidos de diversas fontes de dados para um repositório centralizado;
  2. Daí, com o Attunity Compose, um DW é desenhado e carregado automaticamente.

Há um bom grau de magia negra envolvida (=coisas que acontecem sem entendermos claramente como), mas tudo faz um bom sentido. O Replicate se conecta aos bancos de dados de origem e fazem uma engenharia reversa total. Com essas informações ele vai ao banco de destino e recria o banco de origem, respeitando as diferenças de tecnologias. Por exemplo, ele pode replicar bancos MS SQL Server e Oracle para dentro de um único Postgres. Depois ele faz uma transferência inicial, em que replica as origem(ns) inteira(s) no(s) destino(s). A partir do final desta carga, o Attunity Replicate passa a ler o log de commits dos bancos de origem e replicar no destino, em tempo real.

Quem leu meu post Analítico ou Operacional? sabe que essa replicação não é um DW, e que fazer isso “não é BI”.

A Attunity também sabe, e dá o passo final em direção ao DW através do Compose. O que essa ferramenta faz é mais magia negra que a outra:

  1. Através de engenharia reversa e algoritmos especiais, o Compose “descobre” os relacionamentos entre as várias colunas de todas as tabelas das origens;
  2. Usando esse conhecimento, a ferramenta monta um DW – desenha um modelo de dados – automaticamente;
  3. Em seguida constrói (sempre automaticamente) o ETL para esse DW;
  4. Na última etapa ele monta uma área de apresentação de dados, seguindo indicações de que dados o cliente quer explorar.

A ferramenta ainda permite customizações e correções feitas pelo time de DW, de modo que qualquer interpretação incorreta pode ser ajustada.

Ou seja, ele automatizou 100% do processo moderno de desenvolvimento de DWs!!!! E digo mais: !!!!. Mas não pára por aí:

  • Esse DW guarda histórico;
  • A área de apresentação pode expor estrelas multidimensionais, com até mesmo SCDs tipo 2;
  • Ele detecta mudanças nas origens e ajusta o DW e o ETL;
  • Todas essas ferramentas são clusterizáveis, ou seja, podem ser escalonadas horizontalmente.

Isso são coisas que ouvi ou que perguntei durante a apresentação. Há coisas que eu não perguntei, mas presumo que também estejam no pacote, como tratamento de erros de ETL e monitoramentos diversos. Aliás, a parte de monitoramento é muito bacana, também – aprendi um negócio chamado “hot data, cold data”, sobre o qual vou fazer uns experimentos e, eventualmente, vou postar sobre.

… e Soluções

E como o Data Vault se encaixa nesse cenário? Simples: ele oferece tudo que as ferramentas oferecem, sem o custo monetário. Digo monetário explicitamente porque não existe almoço grátis, sempre precisamos pagar por algo. Se não é em dinheiro, vai ser em treinamento e capacitação, por exemplo, ou simplesmente mais trabalho.

DW 'moderno', re-organizado segundo DV.
DW ‘moderno’, re-organizado segundo DV.

Eis a lista de vantagens (ou problemas resolvidos) trazidos pela adoção de Data Vault no miolo do EDW:

  1. Velocidade de desenvolvimento: usar DV corta o tempo necessário para desenvolver e entregar em algumas ordens de grandeza. Por exemplo, coisas que levariam meses saem em dias;
    1. Modelo de dados: o diagrama de dados do Data Vault é construído através de regras simples, que capturam o negócio no modelo. Assim, uma vez que tenhamos a lista de esquemas, tabelas e colunas do sistema de origem, o ato de desenhar um DV é trivial e leva algumas horas, contra algumas semanas de outros formatos;
    2. Processo de ETL: usando o Pentaho Data Integration, o processo de ETL é gerado automaticamente, a partir do modelo elaborado anteriormente. Ainda é preciso juntar as partes (as diversas transformações) dentro de um job (pré-fabricado), mas isso é uma tarefa de minutos. O ETL inteiro sai em menos de um dia;
  2. Integração: o modelo de dados do Data Vault já arquiva os dados de maneira integrada. Ou seja, a integração ocorre via modelo, no momento em que os dados aterrisam no DV;
  3. Historiamento: 100% dos dados de um DV são historiados, automaticamente e por definição;
  4. Mudanças na origem: evidentemente não são tratadas automaticamente – um software pode fazer isso, não uma metodologia. Entretanto, esse impacto é mínimo:
    1. Qualquer mudança na origem não quebra o processo de ETL, ao contrário de DWs baseados em outros modelos;
    2. Mudanças na origem são resolvidas por um algoritmo simples, e qualquer manutenção leva praticamente o mesmo tempo de repetir o desenvolvimento (horas ao invés de semanas, portanto;)
    3. Nenhuma mudança na origem quebra a área de apresentação. A área de apresentação é reformada apenas em casos que afetem-na. Graças a esse fato, o impacto sobre a área de apresentação causada por mudanças nas origens é de mínimo a inexistente;
  5. Performance de ETL: várias vantagens ao usar um DV;
    1. Alta velocidade: por tratar apenas deltas (i.e., as diferenças) por meio de comparações simples, o processo é muito rápido;
    2. Paralelização: graças ao formato do ETL, todas as operações podem ser maciçamente paralelizadas, possibilitanto uso de hardware barato (COTS;)
    3. Resistente a erros: o ETL de um DV é auto-reinicializável por definição, e só é interrompido por falhas graves (hardware ou dados muito corrompidos;)
  6. Velocidade de mudança: é a mesma da velocidade de desenvolvimento – muito rápida.

Como vantagem extra, pelo fato de DV permitir atacar o problema por pedaços, ele se presta à:

  1. Modularização em sprints;
  2. Paralelização do desenvolvimento.

Por ser baseado em processos automatizados e algoritmos, a quantidade de erros é substancialmente menor, gerando projetos de qualidade maior, e mais padronizado.

Conclusão

Já há alguns anos a indústria de BI vem incorporando tecnologias que habilitam novas soluções de problemas complexos, como a construção, gerenciamento e manutenção de Armazéns de Dados. Essas tecnologias surgem como técnicas/metodologias e softwares.

Um software representante desta nova categoria é o Attunity, especificamente os módulos Replicate e Compose. O primeiro copia dados de diversas origens para um mesmo (ou vários) destino(s). O segundo modela um DW e cria o processo de ETL automaticamente a partir da réplica. Não sei com que qualidade, precisão e velovidade o Attunity entrega os resultados, mas a promessa é fantástica, para dizer o mínimo.

Esse produto é resultado de evoluções anteriores. Uma destas é a metodologia Data Vault, que oferece essa lista de vantagens:

  1. Alta velocidade de desenvolvimento: entrega em dia o que levava meses;
  2. Processo de ETL gerado automaticamente – maior velocidade, qualidade e padronização, com menos erros;
  3. Integração: dados são integrados na entrada;
  4. Historiamento: 100% dos dados de um DV são historiados;
  5. Mudanças: resiliente a mudanças na origem, processo de ETL não pára e impacto global (tanto ETL quanto usuários) é de mínimo a irrisório;
  6. ETL de alta performance, imune à erros, restartável e 100% paralelizável (é possível executar simultaneamente todas as etapas da carga do DV;)
  7. Adequado à processos de desenvolvimento ágil;
  8. Desenvolvimento do modelo (dada ferramenta adequada) e do ETL paralelizável.

Com um Data Vault podemos obter os mesmos resultados prometidos pelo Attunity, com menos automação, e com um custo diferente (menor?)

Clicando aqui você vê a lista dos meus posts marcados com Data Vault. Eis links para alguns do meus posts sobre o assunto:

E se você quiser ler sobre o assunto, o livro é este:

Livro sobre Data Vault.
Livro sobre Data Vault.

Só para não deixar vocês pendurados: eu ofereço os dois cursos, Requisitos Ágeis e Data Vault. Fazer essa propaganda dá impressão que eu montei um post para me auto-promover, mas juro que não é o caso deste aqui. Acredito no valor que esses cursos agregam e sentiria que estaria prejudicando você, meu leitor, ao evitar contar que eles existem. Quem me acompanha sabe que quando eu vou vender algo aqui, eu aviso no começo. ;-)


Até a próxima!

Develop Like a Hero

Já reparam como, em todo filme de super-herói tipo gênio (Homem de Ferro, Homem-Aranha, Quarteto Fant, eles sempre produzem as traquitanas mais loucas e complexas da noite para o dia? Na boa, meus amigos, eu já construí robôs do zero, e posso garantir que não tem nada de fácil! Desde desenhar o circuito eletrônico, calculando todas as especificações, até codificar o programa de controle, passando por simplesmente tudo – desenhar a placa de circuito impresso, corroê-la, furá-la, comprar os componentes, soldar, montar a parte mecânica, calibrar, interfacear…

Não é nem remotamente fácil.

Mas tudo bem, certo? Afinal, é só fantasia, ficção, filmes.

Essas histórias contam com uma coisa chamada suspension of disbelief. Sem isso, veríamos a história na tela e pensaríamos “que bobagem!” Com a “suspensão da descrença” podemos ver o Tony Stark construir uma armadura voadora, e não achar mada demais. Mas tudo tem limites, mesmo uma coisa tão poderosa como esse sentimento de faz-de-conta. Se a história for muito sem pé-nem-cabeça, muito forçada, a coisa perde a graça. Você talvez já tenha assistido alguma destas comédias que tiram sarro dessas situações. Eu lembro de ter visto uma – não me lembro o nome – em que o cara passa por um mega-treinamento e aprende a fazer tudo. No final daquela cena que, normalmente, é um condensado de meses no tempo do filme, percebemos que passou-se apenas o tempo de tela, ou seja, alguns minutos. Bom, esses casos “forçam a barra”.

Para manter alguma credibilidade, esses filmes tentam mostrar como a coisa seria se fosse real, mesmo que apelando para outra coisa quase tão inverossímel quanto a primeira.

Quer um exemplo? Ainda no Homem de Ferro, o mesmo Tony Stark desenvolve a armadura e testa os vários subsistemas até chegar em um protótipo. Depois ele passa uma revisão no projeto e manda o Jarvis construir e montar a versão final. O que vemos é um cara designado como gênio usando ferramentas avançadas – incluindo um computador com a personalidade do Máximo e um braço mecânico com a inteligência do Babão – para apoiá-lo no processo. Essas ferramentas são tão inverossímeis quanto a própria armadura, mas aceitamos que, de posse delas, a possibilidade de uma super-roupa voadora é algo concreto.

Existe algo de muito valioso nessa massaroca fantasiosa: o conceito de automação no desenvolvimento.

Seja Preguiçoso

Como é seu processo de desenvolvimento? O tema do blog é BI, mas pode estender a pergunta a qualquer assunto: código, web design, marcenaria – o que for.

Muita gente faz tudo na mão, pelo menos as pessoas que eu tenho visto. A maioria sequer usa um repositório para versionar os artefatos, menos ainda qualquer outro recurso. Testes, então, espere o cliente reclamar. Não veio reclamação? Comita e era isso! :-)

Eu sempre digo que sou preguiçoso, er, prático. Eu prefiro dedicar minha energia a coisas que computadores não conseguem fazer, ainda, e deixar para eles coisas para os quais estão preparados, como tarefas repetitivas.

Quem já se envolveu em um projeto de Software Livre sabe como é que a banda toca (em geral): um repositório central de código é monitorado por vários sistemas de apoio. Há sistemas que partes do sistema sempre que um novo trecho de código é comissionado (commited, ou na corruptela “comitado”), e que periodicamente compilam o sistema inteiro (em geral à noite, gerando os tais nightly builds). Outros que, após a compilação parcial ou completa, rodam testes contra os resultados, e automaticamente registram os bugs encontrados, ou atestam o sucesso do build e assim por diante.

Até hoje eu não vi coisa equivalente para BI. Porquê? Não sei ao certo.

Existem três divisões principais que uma iniciativa de BI executa:

  • DW: processo de modelagem e ETL;
  • Bancada: é o termo genérico para descrever as interfaces de exploração de dados. Por exemplo, um esquema Mondrian para o Pentaho, um [projeto MicroStrategy][projetomicrost_bitly], um [universo do Business Object][bouniverse_bitly];
  • Data Mining: processos de organização, limpeza e análise de dados em busca de padrões.

Provavelmente não existe muita automação em projetos de BI porque esses três aspectos são difíceis de automatizar. Como automatizar, por exemplo, a construção de uma bancada MicroStrategy (só para sair um pouco fora do confortável mundo do Pentaho)? Como montar um teste para validar esse mapeamento?

Difícil…

tivas Tarefas Repetitivas Tarefas Repeti

… mas não impossível. Se observarmos o nosso trabalho diário de desenvolvedores de soluções de BI, vamos acabar percebendo tarefas que executamos várias vezes.


Vou usar o universo de coisas do Pentaho porque posso falar dele com mais propriedade, mas existem equivalentes em todas as outras ferramentas.


  • Rodar uma transformação, para ver se dá pau ou não;
  • Rodar o job de refresh, para saber se vai até o final, ou se pára em algum ponto;
  • Truncar ou dropar/recriar tabelas;
  • Subir a nova versão do esquema Mondrian/Metamodelo no servidor;
  • Testar essas novas versões, primeiro rodando uma consulta simples, para ver se tudo continua funcionando e depois uma coisa mais complexa, para testar os mapeamentos;
  • Medir os tempos de várias atividades e comparar com as médias das medidas anteriores, em busca de problemas de performance;
  • Subir o servidor, baixar o servidor;
  • Atualizar a produção com as novidades desenvolvidas.

E se estamos trabalhando em dois projetos mais ou menos ao mesmo tempo, a coisa fica ainda pior. Raramente projetos diferentes possuem as mesmas configurações, o que nos obriga a reconfigurar o ambiente de desenvolvimento para tratar cada projeto.

O fato é que muitas destas atividades, que levamos a cabo corriqueiramente, sem pensar duas vezes ou se importar com seu “custo”, podem ser automatizadas.

“E daí?”, perguntar-me-ão vocês. Que vantagem haveria em automatizar coisas tão simples ou rápidas? E daí que preciso de dois ambientes (representados em dois BI Servers) diferentemente configurados?

A resposta não é simples. Mas pense em como você fazia as coisas há uma década atrás. Lembra-se do barulho do modem? E hoje? Lembra-se dos clientes de e-mail? E hoje? Essas coisas não mudaram à toa. Ferramentas novas surgiram, novas formas de fazer as coisas vieram à luz. Ninguém pensaria por um segundo em voltar a viver como dez anos atrás.

E essa é a vantagem de você se preocupar com esses pequenos detalhes dos projetos, com as pequenas vantagens que podemos conquistar ao investir um esforço em fazer algo de forma diferente.

Ecossistema de Ferramentas

Existem diversas ferramentas que podem incrementar algum aspecto de projetos de BI. De novo eu vou recorrer ao Pentaho, para estudo de caso, mas reforço que qualquer ferramenta de BI pode ser tratada por essas técnicas.

Eis aqui duas idéias de como melhorar o desenvolvimento de projetos de Business Intelligence.

Servidores

O recurso de desenvolvimento mais trivial para um projeto de BI com Pentaho é o BA Server. O segundo recurso mais trivial é um banco de dados, que funciona como Data Warehouse. Cada projeto de BI com Pentaho requer um banco como DW e um servidor configurado particularmente.

A ferramenta Vagrant foi criada para melhorar a gestão de ambientes de desenvolvimento. Construída em cima de um hipervisor, como VirtualBox ou VMWare, podemos programar um ambiente de desenvolvimento, e ativá-lo/baixá-lo com um comando tão simples quanto vagrant up.

Podemos montar ambientes mono- ou multi-servidores. Com software livre ou proprietário, com qualquer combinação de programas e parâmetros. Podemos compartilhar uma configuração Vagrant via repositório, que pode ser recuperada por qualquer membro do projeto e ter exatamente a mesma configuração para QUALQUER membro do projeto.

Ainda melhor, podemos usar essa mesma configuração para provisionar servidores em produção.

Já pensou? Ambiente de produção 100% igual ao de desenvolvimento? Mais ainda: versionável?

Não é pouca coisa, vocês hão de convir.

Integração

Sempre que um pedaço do projeto é alterado, há um risco de algo se quebrar. Sempre que uma nova transformação é incluída no job de refresh do DW, algo pode espocar ali no meio – da memória da JVM à janela de ETL. Por isso sempre precisamos re-executar tanto os pedaços quanto o todo do processo.

Um Software Livre chamado Hudson pode nos ajudar com algo muito útil. Grosso modo ele monitora um repositório como Git ou SVN e, periodicamente, puxa todas as atualizações do repositório e executa operações sobre elas. Por exemplo, executa algum script ou compila algum código-fonte.

Ao invés de testar os jobs e transformações manualmente, deixamos que aplicativos como o Hudson, chamados de servidores de integração contínua ou CIS. Essa categoria de produtos pode não apenas gerar relatórios sobre a qualidade dos testes, mas também disparar avisos por e-mail para os donos das peças problemáticas.

Conclusão

Não é fácil olhar o que fazemos e enxergar como poderia ser feito melhor, pois sofremos de “vício”. É como escrever um texto e revisá-lo: podemos pegar algumas falhas, pois há coisas que são erros óbvio, mas raramente vamos pegar todos ou quase todos os problemas. Ficamos “cegos” para alguns erros ou escolhas ruins. É importante mantermos o canal de autocrítica aberto, pois só assim estaremos aptos a desencavar oportunidades de melhorias.

Uma área ainda inexplorada em projetos de BI é o desenvolvimento com apoio de automação (AAD? Automation Aided Development? Isso existe?) É prática comum em desenvolvimento de sofwares, mas pelo que eu testemunhei em várias empresas, não existe em BI.

E porque precisamos nos preocupar com isso?


Dê-me seis horas para cortar uma árvore, e eu passarei as quatro primeiras afiando o machado. Abrahan Lincoln


Não acredito que seja preciso responder essa pergunta, mas outra forma de colocá-la é entender que se você foca só no desenvolvimento, full steam ahead, e nunca cuida dos seus instrumentos e ferramentas, então sua produtividade vai cair, não aumentar. Se você quer estar em projeto que entrega valor, em grande velocidade, então trabalhe como o Homem de Ferro, e deixe os computadores fazerem o que eles fazem melhor. ;-)

O campo da automação no desenvolvimento de BI é, praticamente, virgem. Quem tiver uma boa idéia, ou mesmo só uma idéia, vai sair na frente e fazer escola.

Não trabalhe como um noob. Develop like a hero! ;-)

As Soluções Clássicas – CRM

Semana passada começamos a nova série no GeekBI: As Soluções Clássicas. Clique aqui para acessar aquele post.

Hoje veremos a primeira destas soluções: Gerenciamento do Relacionamento com o Cliente, ou em inglês Customer Relationship Management. Sim, você leu corretamente: C R M. O bom e velho, famigerado CRM.


Boa parte do que eu vou trazer aqui pode ser visto no livro Data Mining Techniques, seminal sobre CRM e Data Mining em geral. Se você quer estudar o assunto, esse é o livro.


Relacionamento com o Cliente

Direto ao ponto: antigamente todo mundo comprava tudo – comida, roupa e outras coisas – ao vivo. Ia-se a uma loja, apontava-se o produto, dava-se o dinheiro e saia com ele pela porta. Simples assim. Olhávamos todos uns nas caras dos outros. Íamos a uma loja e não na vizinha porque gostávamos mais desta que da outra. Víamos o dono por ali, conhecíamos os atendentes, confiávamos na procedência dos produtos.

Essa convivência acabava por criar um relacionamento. Você sabe, aquela coisa que sua cara-metade discute ocasionalmente contigo, em uma sessão DR. ;-)

Aos poucos o fornecedor passava a conhecer os gostos do cliente, e este passava a confiar no fornecedor. Esse relacionamento trazia vantagens para ambos: o cliente recebia um atendimento melhor, personalizado, e o fornecedor fidelizava o cliente, tendo mais facilidade para planejar seu negócio e mais oportunidades de vendas. Resumindo, o cliente podia contar com o fornecedor para suprir suas vontades, e o fornecedor via seu faturamento e sua lucratividade aumentar graças à fidelidade do cliente.

Lembram-se como falava-se (ainda se fala?) em fidelizar o cliente? Em atendimento personalizado?

Aos poucos o mercado cresceu e sofisticou-se, e a distância entre o consumidor e o fornecedor foi aumentando. A quantidade de clientes ficou maior, a variedade dos gostos aumentou e a complexidade da linha de produtos acompanhou essa tendência.

Décadas atrás isso era um problema: mesmo na década de 80, o mero volume de clientes e a efemeridade do seu contato eram tamanhos que ficou difícil saber quem era esse cliente, e como atendê-lo melhor. Pense um supermercado, uma padaria, um posto de gasolina etc. São negócios que envolvem um volume considerável de clientes, que recebem um atendimento rápido: pega-se o produto, enche-se o tanque, paga-se e vai-se embora. Não raro esses negócios – que são apenas um exemplo – têm mais de um caixa. É muito difícil para um gerente conhecer os seus clientes nesse ambiente. Não temos mais tempo para jogar conversa fora, ou demorar muito escolhendo os produtos. É vapt-vupt.

Agora pense em redes de supermercados, padarias e postos de combustíveis. Jogue nisso tudo a Internet e a explosão do comércio eletrônico. Se antes o contato com cliente era fugaz, ao menos era físico. Com o e-commerce (precedido pelas onda das vendas por catálogos), o cliente nem mesmo aparecia mais na loja. Nem sequer temos mais uma “loja” no sentido de coisa de tijolos e cimentos!

Como construir um relacionamento com um ser quase mítico, que para todos os efeitos é invisível e que se move à velocidade da luz?

Customer Relationship

Com Data Mining.

Antes de continuar vamos abrir um parênteses sobre a terminologia.

A idéia de “gerenciar” o relacionamento é usar o conhecimento sobre a clientela para tornar cada contato uma nova oportunidade de aumentar a proximidade/fidelidade do cliente, de fazê-lo consumir de você e não do seu concorrente, ao menos na maior parte das vezes.

O conceito de “gerenciamento de relacionamento” não é trivial. Pense no gerenciamento de recursos humanos: atribuir tarefas a pessoas, deslocar e direcionar times para as atividades da empresa e tudo mais. Troque “recursos humanos” por “relacionamento com o cliente” e estamos falando de reforçar um tipo de contato (por e-mail, chat, telefone) ou enfraquecer outro, de injetar dinheiro para propaganda neste e naquele segmento sobre este e aquele produto, ao invés de abrir um comercial na TV. De usar uma oportunidade de contato para incrementar as vendas ou a satisfação do cliente conosco.

Ou forma de pensar que ajuda a entender o termo é “alavancar”: através do gerenciamento dos relacionamentos com os clientes podemos alavancar (ajudar, empurrar) o crescimento da empresa. Usamos as interações para criar ações que movem a organização para mais próximo dos seus objetivos, da sua visão.

Depois de um tempo a frase parece fazer sentido, mas só com um pouco de familiariedade com uma grande operação voltada ao consumidor é que podemos abarcar completamente o conceito.


Continue pensando, uma hora sai! ;-)


Se você entendeu a idéia na seção anterior, que era aprender sobre o cliente para atendê-lo melhor, e com isso maximizar suas vendas, basta transpor isso para o mundo do cliente sem rosto, mas que interage com a empresa. Cada interação é uma oportunidade de conhecer melhor quem está do outro lado do balcão.

CRM = Data Mining

Vejamos: temos muitos clientes, muitos produtos e, mesmo que não individualmente falando, muitos contatos de clientes. O que são esses contatos?

  • Uma compra;
  • Uma re-compra (o cliente voltou para mais;)
  • Uma reclamação;
  • Um pedido de serviço;
  • Etc.

Cada vez que um cliente interage com a empresa, ele deixa um pouco dos seus dados – identificação, localização, interesses, valores, etc. São esses dados que, agregados e acumulados, dá uma montanha de dados que esconde um ouro. Ouro esse que pode ser desencavado com Data Mining. (Mais cliché impossível.)

E Aí?

Que resultados nos traz uma solução de CRM? O que ela consome?

Insumos

Uma solução de CRM analisa dados de todos os sistemas da empresa que tenham alguma interação com o cliente – e mesmo alguns que não têm. Os mais valiosos são aqueles que dão informação direta sobre o cliente: caixas (por isso é importante pedir o CPF, já que permite saber quem é o cliente), reclamações, trocas. Canais de atendimento, como call centers, também são valiosos (por isso que a maioria pede alguma identificação de quem liga.)

Os dados não precisam ser coletados em um DW – surpresa! – mas ajuda muito fazê-lo. Coletar dados históricos, integrá-los e limpá-los são os primeiros passos de qualquer projeto de Data Mining, e por isso mesmo são os primeiros passos do projeto de CRM. Se a empresa decide por uma iniciativa de coleta de dados isolada, estanque, descartando um DW, desperdiça boas oportunidades e gera alguns problemas:

  • DW é uma tecnologia estável, e projetos profissionais de DW consomem menos recursos, com melhores resultados. Nem preciso dizer que projetos amadores, de qualquer coisa, sempre dão dor-de-cabeça, né?
  • Gera retrabalho/duplicação de esforços: se apenas o projeto de CRM coleta e organiza os dados dos clientes, qualquer um que queira usar esses mesmos dados na empresa precisa atrapalhar o projeto de CRM, ou duplicar o trabalho em outro lugar;
  • Seria mais caro: a idéia de evitar o DW é – imagino – poupar o gasto com profissionais “do ramo” e ambientes especiais. Trocar um projeto profissional por outro amador tende a causar atrasos e dificuldades;
  • CRM é uma boa âncora para DWs corporativos. Como DWs podem ser usados pela empresa inteira, ter um bom argumento a favor de um DW – como o CRM – é um bom argumento para vender a idéia do DW;
  • CRMs tendem a dar bons resultados e ajudam a melhorar a imagem de todas as tecnologias de BI na empresa, facilitando a mudança de cultura necessária (um dia aborarei isso.)

E isso é parte do ponto de vista da tecnologia. A outra parte deste lado seriam as máquinas, que podem ser muito grandes em função dos volumes de dados envolvidos, e os softwares, que podem ser Software Livre ou proprietário, mas definitivamente são escolhas secundárias.

Olhando para o lado dos recursos humanos, um projeto de CRM requer um Analista de Data Mining com experiência em CRM. Como esse profissional é um bocado caro para ter na folha de pagamentos (primeiro pela especialização, segundo pelo uso relativamente limitado de suas maiores habilidades), o mais comum é recorrer a uma boutique de Data Mining para trazer esse especialista para o projeto, temporariamente. O time do projeto é completado, via de regra, por gente da casa, com membros da TI para ajudar na parte de coleta e tratamento dos dados, e gente do negócio para ajudar na priorização e construção dos modelos.

Entregáveis

Eu adoro dizer que o entregável de um projeto de Data Mining é dinheiro, muito dinheiro!!, mas isso costuma não colar. Pena. :-) A próxima melhor definição dos resultados entregues por uma solução de CRM é “incrementar o valor do cliente”, que é feito através de ações planejadas com o auxílio da inteligência obtida da análise dos dados. Mas com o que se parece, o que é essa “inteligência”? Qual é, concretamente, o entregável do projeto, qual é o produto?

Como eu já coloquei em outro post, o entregável de um projeto de Data Mining são modelos matemáticos. Cada um destes modelos automatiza o processo de decisão em relação à próxima interação com o cliente. Há tantos modelos possíveis que eles são agrupados em várias categorias: Sales Promotion, Survival Analysis, Churn Prevention etc. etc. etc. Vamos ver alguns dos modelos mais famosos.

Para começar, um dos modelos mais interessantes é o Lifetime Value do cliente, que é uma estimativa do valor do cliente por todo seu relacionamento ao longo do tempo, ou dentro de um horizonte, como alguns meses ou anos. De posse dessa estimativa podemos avaliar com mais clareza se vale a pena ou não manter um determinado freguês. Suponha que certo cliente peça um desconto. Vale a pena dar esse desconto para ele? Se fôssemos o dono da loja, sabendo tudo de tudo, seria fácil decidir:

  • Cliente novo?
    • Sim. Parece do tipo que dá lucro?
      • Sim: dê o desconto;
      • Não: recuse o pedido;
    • Não. Cliente valioso?
      • Sim: dê o desconto;
      • Não: ofereça um desconto menor.

Agora, como ajudar a moça do call center da Americanas.com a decidir? Montando o mesmo script baseado no Lifetime Value!

A saída dessa ação pode ser encaixada com os resultados dados por outros modelos, como os que atuam no incremento das vendas. Imagine se ao invés de recusar o desconto, ou simplesmente concedê-lo, a tal atendente ainda tenha no script ramificações para:

  • Up-selling: vender algo mais caro ou mais valioso (com maior lucratividade;)
  • Cross-selling: fazer o cliente comprar alguma outra coisa, não aparentemente relacionada;
  • Recomendações: recomendar algo mais do mesmo tipo, para aproveitar o desconto.

Cada uma destas ideias é um modelo que o CRM pode gerar.

E que estratégia a organização deve perseguir? Adquirir clientes, ou se esforçar para aumentar a lealdade dos já existentes? (Pegadinha: clientes novos custam muito mais caro que os já adquiridos, por isso é sempre importante investir na manutenção da sua clientela.) Um projeto de CRM ajuda a desenhar estratégias oferecendo modelos para:

  • Campanhas de retenção, para evitar perder o cliente para a concorrência;
  • Estímulo de uso, para fazer o cliente se lembrar que possui um serviço, ou se lembrar de voltar a nos procurar;
  • Programas de fidelidade, que estimulam o cliente a decidir por nós ao invés de pela concorrência;
  • Redução de atrito: já é difícil segurar o freguês, então pelo menos vamos tentar não empurrá-lo para longe, que é o objetivo deste modelo, de Churn Reduction.

E mesmo quando temos alguns desertores, há modelos que apoiam iniciativas reparadoras. Uma dessas chama-se Customer Reactivation que, como o nome mesmo diz, tenta motivar um freguês que não nos procura a voltar a entrar em contato. Um modelo mostra que cliente é mais propenso a ser recuperado por esta ou aquela ação.

Falando em problemas como clientes, outro conjunto de modelos lidam com o risco que um cliente representa e como manter baixo esse risco. Coisas que o departamento financeiro sempre quer saber como quem tem tantos porcento de falhar no pagamento? Dos clientes que estão atrasando ou deixando de pagar, quais têm maior propensão a pagar alguma coisa, e quanto?


Sempre que eu menciono um destes exemplos você pode tentar imaginar o que estaria acontecendo na proverbial lojinha. A reativação, por exemplo, pode ser uma visita ao cliente, só para bater papo, ou para levar algo que ele gosta. Um pouco de tato pode evitar vender fiado para quem sabemos que vai dar trabalho, e a redução de atrito pode ser um pedido de desculpas por uma burrada. E o estímulo ao uso? Que tal um brinde, que ele aproveitaria melhor se comprasse algo? Não estou brincando: o programa Cliente Mais do Pão-de-Açúcar me deu, uma vez, uma tigela para comer cereal. Fofo, não? (Deu certo, só para constar – por algum tempo eu passei a comprar cereais com mais regularidade.)


Não é Para o Meu Bico

Uma espécie de regra geral para projetos de Data Mining é “precisa de grandes volumes de dados”. Ainda que grande seja uma coisa relativa, hoje em dia nunca é menos de milhões de linhas – milhões de linhas de vendas, de interações com clientes, de produtos, de acessos etc. Isso é uma coisa natural, por que a maioria desses métodos são de inferência: fazem estimativas a partir de um comportamento observado. É como o caso da moeda: não dá para saber se ela é viciada com apenas um arremesso. Precisamos de uma quantidade que mostre a tendência para sair mais cara ou mais coroa, ou então termos uma certeza razoável de que é uma moeda “normal”. Quanto mais dados, menor ou mais delimitado é o erro em relação a uma estimativa. Inversamente, quanto menos dados, maior a incerteza da estimativa.

Essa necessidade de um certo volume de dados não é motivo para barrar análises com menos dados. O erro será maior, mas alguma informação sempre é melhor que nenhuma. Projetos de Data Mining, em geral, e de CRM em particular, podem ser encetados por sua organização mesmo que você não disponha de montanhas e montanhas de dados. Apenas seja mais precavido em relação às iniciativas que vão usar os resultados para alavancar o crescimento da empresa.

Para demonstrar isso, eu deixo vocês com um caso real. Há vários anos, numa das minhas turmas da 4Linux, tive um aluno dono de um supermercado, de São Carlos. Ele queria dispor de relatórios e análises sobre seus dados (principalmente dos caixas) e, como era muito caro contratar um projeto, decidiu fazer tudo ele mesmo. Eu fiquei impressionado, afinal ele era o dono do supermercado (acho que tinha algum sócio, não me lembro), que não era uma loja pequena. Assumir um projeto técnico com uma empresa inteira para tocar, não importa quão pequena, é um desafio e tanto. Bom, ele terminou o curso, e voltou para São Carlos.

No começo de 2015, estimulada pelo Caio Moreno, o Prof. Coruja, a comunidade de Pentaho de São Paulo se juntou para um Meetup. Qual não foi minha surpresa ao reencontrar esse empresário lá?! Já fiquei impressionado de vê-lo se deslocar para um encontro num final de dia, começo de noite, de uma quarta-feira em São Paulo, mas eu fiquei de queixo caído quando ele falou o que estava fazendo: não apenas implantou BI no supermercado, como agora estava atrás de Data Mining para fazer CRM!!! :-O A meta dele era simples, modesta até, mas mesmo assim seria capaz de melhorar a rentabilidade do negócio: se eu não me engano, ele queria reduzir perdas por vendas a prazo. O simples fato de passar da administração do risco de manual para automática já teria impacto positivo no negócio dele.

Nunca mais falei com ele, infelizmente, mas não tenho a menor dúvida que conseguiu, e que hoje deve estar fazendo mais alguma coisa surpreendente e inteligente.

Customer Intelligence

CRM é um termo que ficou meio desgastado – sabe, como OLAP, metadados e o próprio BI. Como o conceito de “gerenciamento do relacionamento” não é algo transparente, imediatamente apreensível, muitas empresas se apoderaram dele para usar em qualquer coisa e surfar a onda do mercado (de novo.) Daí hoje em dia temos CRM que maneja envio de e-mails (mala-direta), CRM que recebe/dispara teleatendimentos (call center), CRM que monitora redes sociais (social-thingamajig) blá blá blá. Nenhum destes casos responde pela “coisa”. Para se livrar desses mal-entendidos, a empresa líder de BI, o SAS, renomeou o campo como Customer Intelligence (“excelente” abreviação: SAS CI – entenderam? Sasci, Saci. Kkkk…)


Bom, o SAS já renomeou quase tudo de BI (incluindo BI, que virou BA), por isso não há nenhuma novidade aqui. Para mim, porém, o termo Customer Intelligence é tão opaco quanto Customer Relationship Management, o que sempre me conduz à mesma conclusão: a ideia não é ajudar, é ser dono exclusivo de buzzwords. SAS, SAS, tsc, tsc… Adiante.


A solução SAS é completa, com planejamento, estratégia, gerenciamento de campanhas, medida de eficiências etc. Não vou entrar nela porque o post é sobre CRM e não sobre o SAS e seus produtos, mas vale a pena conhecê-la. Se quiser ver um pouco mais da cara do resultado de um projeto de Data Mining, que fica por trás de um projeto de CRM, pode ler um pouco sobre o SAS/Enterprise Miner.

Conclusão

Uma forma de entender a disciplina BI é como uma ferramenta de apoio à decisão, ou de automação da decisão. Neste sentido, projetos de Data Mining produzem recursos empregados na automação das decisões de uma empresa, melhorando a precisão dessas decisões e aumentando a velocidade com que são tomadas. Em uma empresa moderna, que dependa de computadores no seu métier diário, minguém consegue manter tudo dentro da cabeça para conseguir entender o que precisa ser feito, e como. Só BI consegue isso, através de Data Mining, em geral, e CRM, em especial, no aspecto da clientela.

Gerenciamento do Relacionamento com Clientes, ou CRM, é um projeto que busca entender o Cliente para melhor atendê-lo.

Um projeto de CRM entrega modelos matemáticos que alimentam desde o planejamento estratégico até a implementação de iniciativas e ações na empresa, sempre com o objetivo de maximizar o valor do cliente, enquanto ajuda a organização a prestar um serviço de maior qualidade. Em outras palavras:


Um projeto de CRM dá ao cliente um atendimento melhor, personalizado, e ao fornecedor a maximização do valor de cada cliente.

Projetos de CRM são ganha-ganha.


Porque tão poucas empresas investem em Data Mining, para mim, é um mistério. Que quase nenhuma tenha um projeto de CRM, então, é um mistério envolto em um enigna.

No próximo post (que não será semana que vem): Credit Scoring. Até lá! ;-)

Relatórios com Metamodelos

Hora de uma pausa na série de artigos sobre conceitos, e ver um pouco de Pentaho. Hoje vou mostrar uma coisa que já me pediram algumas vezes: como criar um relatório usando um metamodelo como fonte de dados.

Sério? Relatórios??

Sim, sério!! Relatórios são o solo fértil no qual germinam as primeiras idéias e hipóteses em BI. É com uma listagem simples que podemos fazer os primeiros testes, sem contar que, bem construídos, são uma excelente ferramenta de apresentação e acompanhamentos.

Um bom relatório tem o peso de um bom argumento. Não há motivo técnico para prescindir de um relatório se ele for o suficiente para seu propósito.

O Pentaho Report Designer

O Pentaho Report Designer (PRD) oferece uma vasta gama de recursos para criar relatórios visualmente atraentes e versáteis. A figura abaixo, por exemplo, mostra um relatório que lista o estoque de uma empresa.

Relatório de estoque, que buscas fotos do produto no Google.
Relatório de estoque, que buscas fotos do produto no Google.

Neste relatório:

  • Cada item é apresentado com seu nome, código de barra e outros atributos;
  • Uma barra colorida, abaixo do item, mostra a quantidade em estoque através do seu tamanho e de um número;
  • A cor da barra, e o fundo da coluna On Hand, indicam por cores se a quantidade em estoque é adequada (verde ou amarelo), ou se é preciso reabastecer com um novo pedido para o fornecedor (vermelho;)
  • As colunas SKU e Name são URLs. Clicar em um deles leva a um outro relatório ou a algo mais. Clicando no item na coluna Name, por exemplo, dispara uma consulta por imagens no Google, abrindo o navegador web padrão para mostrar imagens do produto;
  • A imagem não mostra, mas o relatório possui um filtro por linha de produtos. Veja no canto superior esquerdo o filtro ativo: Line: Classic Cars.

Figuras, fontes, funções, fórmulas, prompts, saída em HTML, Excel, CSV ou PDF…. o PRD tem tudo, incluindo a pia da cozinha e mais um pouco. E como ele é parte da Suite Pentaho, podemos publicar os relatórios no Pentaho BA Server, onde os usuários conseguem acessá-los, agendá-los ou executá-los em background.

E ainda tem o lado das fontes de dados: o PRD consegue ler desde bancos de dados relacionais a Hadoop, de uma tabela hardcoded no relatório a resultados de scripts em Groovy ou JavaScript, de MDX (consultas OLAP) a SQLs gerados em tempo real com scripts, sem contar transformações, que por si só também permitem ler de qualquer coisa.

Uma destas fontes de dados é o metamodelo, um padrão definido por um consórcio de empresas de BI. A ferramenta da Suite Pentaho que gera esse arquivo é Metadata Editor (PME.)

Pentaho Metadata Editor.
Pentaho Metadata Editor.

Relatórios são construídos, em sua maioria, com SQL, que até que é uma linguagem bem prática. O que quase sempre complica as consultas é o modelo de dados. Raramente podemos deixar nosso cliente construir seus próprios relatórios por dois motivos:

  1. Falta de conhecimento em SQL;
  2. Desconhecimento do modelo de dados.

Se o primeiro item dificulta a construção da consulta em si, o segundo compromete o resultado. Pois mesmo que o cliente consiga montar o SQL que traga a listagem desejada, apenas um conhecimento íntimo dos dados, das tabelas e dos relacionamentos é que pode garantir que a consulta trará o resultado correto. E mesmo conhecendo bem os dados, o risco de uma consulta trazer dados inconsistentes ou incorretos nunca é zero.

Tanto é assim que a principal justificativa para construção de um [Data Mart][datamart_bitly] em formato dimensional (ou [esquema estrela][modim_bitly]) é justamente reduzir a complexidade do modelo on-line a ponto de permitir a exploração dos dados por um profissional não-técnico, que nem domina SQL nem conhece em profundidade o modelo de dados transacional.


Na minha opinião, essa é a única justificativa para construirmos um modelo dimensional.


Outro caminho para superar essas dificuldades é deixar que o computador resolva as consultas para você, algo muito em moda hoje em dia com a onda das ferramentas de Data Discovery.

E esse é justamente o propósito do metamodelo: esconder a complexidade da base de dados e permitir a construção de consultas por usuários de negócio, que sabem pouco ou nada de SQL, e menos ainda de modelos de dados, relacionamentos, chaves estrangeiras etc. etc. etc.

Meta… Meta… Meta…

Criado em 2003, o Commom Warehouse Metamodel é uma proposta para eliminar a complexidade de consultas a bancos de dados por meio de uma camada de relacionamentos (camada de negócio) que senta entre a camada física (bancos de dados) e a camada de apresentação (interface de usuário.)

As camadas de um metamodelo CWM.
As camadas de um metamodelo CWM.

A forma mais comum de consumir esses dados é usando um aplicativo que até pouco tempo atrás vinha embutido no Pentaho BA Server, o Web Ad Hoc Query and Reporting, ou WAQR:

Usando o WAQR para construir um relatório a partir de um metamodelo.
Usando o WAQR para construir um relatório a partir de um metamodelo.

O WAQR ainda está disponível, mas como um plugin sem suporte. A falta de manutenção, aliás, está começando a mostrar seus efeitos – já não é mais possível editar relatórios salvos, por exemplo.


Entre vários recursos incorporados por um CWM, ou um metamodelo, estão o controle de acesso aos dados. Um CWM pode, por exemplo, bloquear o acesso de um determinado usário a um conjunto de tabelas, ou que um grupo de usuários (um papel) veja essas tabelas, mas apenas parte do conteúdo (controle de acesso no nível de linha.) Veja essa página para saber um pouco mais sobre segurança em metamodelos do Pentaho Infocenter.

PRD com Metamodelos

Lembra-se dos motivos para um usuário de negócio não construir seus próprios relatórios? Bom, ao usar um metamodelo como fonte de dados para um relatório, ambas somem!

  1. Falta de conhecimento em SQL: ao contrário de um modelo de dados em banco relacional, que usa SQL, a construção de uma consulta com metamodelo é feita por uma interface gráfica amigável, sem comandos técnicos – escolha os campos, as agregações, ordenações e filtros e pronto! O engine do PRD vai usar o metamodelo para construir a consulta SQL sozinho;
  2. Desconhecimento do modelo de dados: como o metamodelo embute as regras de negócio, uma consulta construída sobre o metamodelo elimina a necessidade de o autor do relatório conhecer e entender bem o modelo e os relacionamentos entre as tabelas. O risco de consultas erradas ou mal-feitas vai virtualmente a zero.

Mas não pára por aí! Ainda teremos:

  • Controle de acesso: todas as regras de acesso implementadas no metamodelo são aplicadas automaticamente nos relatórios do PRD;
  • Padrão de formatação: um metamodelo impõe, e o PRD respeita, um padrão de formatação para a camada de apresentação. Ou seja, se um campo monetário for definido como “Arial-12, Itálico, Verde-Água”, então todos as vezes que esse campo for usado em um relatório ele vai aparecer em Arial itálico, tamanho 12, verde-água, mesmo que o autor do relatório altere o elemento! (Dá para contornar, e não é acidentalmente – é preciso ter a intenção de sair do padrão.)

E você não perde (quase) nenhuma vantagem do PRD: continua podendo usar parâmetros (prompts), gráficos, sub-relatórios, fontes, funções, scripts etc. etc. etc.


Aparentemente, existem duas limitações em consultas MQL (Metadata Query Language) parametrizadas: o controle de calendário não funciona 100% e não é possível filtrar consultas com parâmetros que retornam listas. Eu li en passant sobre isso em uma thread do fórum internacional, mas não achei evidência. Vou testar e voltarei ao assunto quanto tiver informação concreta.


Como Fazer

É simples, muito simples: registre seu metamodelo como uma fonte de dados no PRD, e use-a para construir as consultas. Pré-requisitos:

  • O PRD instalado e funcionando e, é claro, saber usar o básico para construir um relatório;
  • Uma base de dados, com o respectivo servidor de banco de dados no ar, e todas as informações para conexão (string de conexão, IP, usuário e senha;)
  • Um metamodelo sobre a base acima, construído com o Metadata Editor (PME), exportado para um arquivo XMI.

Instalar PRD e PME

Para instalar o PRD e o PME clique aqui, baixe e leia o capítulo de degustação do Pentaho na Prática. Ele foi feito para a baseline 4.8 do Pentaho, mas ainda serve para a série 5 ou 6: troque o Java de 1.6 para 1.7 (baseline 5.x) ou 1.8 (série 6) e fique atento para as diferenças entre as telas.

Base de Dados: Beltrano S/A

Se você não tiver uma base contra a qual construir o seu metamodelo, consulte este post para baixar e instalar a Beltrano S/A. Artigo completo, incluindo instruções para instalar o Postgres no Windows (livro gratuito!) e Linux.

Diagrama de tabelas do sistema transacional (OLTP) da Beltrano S/A.
Diagrama de tabelas do sistema transacional (OLTP) da Beltrano S/A.

Metamodelo Beltrano OLTP

Com um pouco de trabalho construímos um metamodelo a partir do diagrama anterior. A figura abaixo mostra a cara do metamodelo que eu vou usar no exemplo:

Metamodelo sobre banco de dados transacional (OLTP) da Beltrano S/A.
Metamodelo sobre banco de dados transacional (OLTP) da Beltrano S/A.

Daí, usando o comando File -> Export to XMI File no menu do PME, eu gerei o arquivo XMI necessário para o PRD.

Não veremos como montar o metamodelo inteiro, pois é muita coisa. Você pode usar algum que já possua, ou clicar aqui e baixar o metamodelo do Beltrano S/A.


Deixe um comentário se não conseguir ou se tiver alguma dúvida. Faz tempo que eu montei esses arquivos e algo pode estar desregulado.


Registrar Metamodelo como Fonte de Dados

Abra o PRD e crie um relatório vazio. No lado direito da interface há duas abas: Structure e Data. Selecione a aba Data e clique com o botão da direita sobre o cilindro amarelo. Escolha Metadata no menu que vai aparecer.

Criando uma fonte de dados para metamodelo.
Criando uma fonte de dados para metamodelo.

Vai aparecer a janela abaixo. Use o botão Browse ao lado do campo XMI File para localizar e selecionar o arquivo XMI do metamodelo. Informe um nome para domínio (campo Domain Id/BI-Server Solution Name.)

(A consulta que aparece na imagem é resultado do exercício. Já, já mostro como ela apareceu.)

Fonte de dados baseada em metamodelo registrada.
Fonte de dados baseada em metamodelo registrada.

Se você prentende publicar os relatórios em um BA Server, certifique-se de usar o mesmo nome de domínio no PRD e no BA Server (isso é feito no momento da publicação via PME ou na importação em Manage Data Sources no BA Server.) Caso sejam diferentes, executar o relatório no BA Server vai gerar uma mensagem de erro sobre “fonte de dados inexistente”.


Pronto! A fonte de dados está configurada e, a partir daí, vida normal: crie uma consulta e desenhe um relatório.

Criando uma Consulta MQL

A figura anterior mostra uma consulta já criada. Eis como chegaremos até ali:

  1. Clique no botão + (verde) que fica ao lado do texto “Avaliable Queries” na janela de conexão;
  2. Aparecerá uma Query 1 na lista de consultas. Clique nela para selecioná-la;
  3. Clique no ícone de lápis (destacado por uma seta vermelha) para abrir a janela de construção de consultas. Consulte esta página do Infocenter para mais informações sobre o “construtor de consultas de metadados”;
  4. Veja a figura a seguir: cada um dos campos desejados no relatório foi selecionado e transferido para a seção Selected Columns clicando-se na primeira seta verde, de cima para baixo;
  5. Um filtro foi definido transferindo-se para a segunda seção, Conditions, o campo que filtrará os dados. Usamos a Comparison (comparação) “contains” (contém) e Alexandre na coluna Value;
  6. Finalmente definimos a ordem de listagem desses dados: por Vendedor, por Curso, ambos em ordem alfabética crescente (ASC), na seção Order By.

Ao clicar no Ok volta-se para a janela anterior, e consulta aparece na seção Static Query. Neste ponto você pode testá-la, clicando em Preview, ou só clicar em Ok e voltar para o relatório.

Construir uma consulta em MQL é muito fácil e simples!
Construir uma consulta em MQL é muito fácil e simples!

Note que acabamos de cumprir as duas promessas: criamos uma consulta sem saber nada de SQL ou do modelo de dados.

Montando um Relatório

O relatório é desenhado da mesma forma que se usássemos uma consulta SQL: inclua os elementos que deseja (como títulos e gráficos), arraste os campos da consulta para a lona, posicione-os, configure os detalhe e salve.

Um relatório baseado em metamodelo pode ter qualquer recurso.
Um relatório baseado em metamodelo pode ter qualquer recurso.

Pressione o ícone de olho ou o botão de play para renderizar seu relatório. O meu ficou assim:

Vendas do Alexandre Costa, Beltrano S/A.
Vendas do Alexandre Costa, Beltrano S/A.

Uma última dica! O PRD vai aplicar, aos campos trazidos da consulta, as regras de formatação definidas no metamodelo e você não vai conseguir alterá-las na mão, no PRD. Se você quiser forçar a formatação de um campo, use um elemento do tipo Message ao invés do tipo padrão que o PRD escolher para o campo. A forma mais fácil de entender como funciona esse tipo de campo é arrastar da consulta um campo qualquer para a lona, selecioná-lo e, no menu Format do PRD, acionar a opção Morph -> message-field. A partir daí o campo vai aceitar qualquer formatação que você aplicar.

Conclusão

Sentiu a facilidade da coisa? Uma vez que um metamodelo seja criado, usá-lo para construir um relatório é muito fácil e, muito importante, tem altíssima produtividade, já que todo trabalho de escrever e testar a consulta SQL foi passado para o motor de metadados.

Indo um pouco além, suponha que seu banco de dados, que serve de fonte para o metamodelo, sofreu alguma alteração. O usuário não precisa saber de nada: apenas atualize o metamodelo e distribua a nova versão. Se não houver acontecido nenhuma mudança drástica, tudo que existia continuará funcionando e ainda terá consistência com as alterações da base!

Até a próxima! :-)

OI vs BI – O Treinamento e o Rendimento

Há duas semanas eu coloquei minha interpretação do conflito entre as necessidades operacionais e estratégicas na exploração dos dados de uma empresa. Um dia antes de eu publicar aquele post, com ele já praticamente completo, me ligou um amigo de uma firma de grande porte, com um problema muito interessante: como medir o impacto de um treinamento sobre a empresa? Como saber que esta ou aquela iniciativa de educação corporativo deu algum resultado? Como descobrir de quanto foi esse resultado?

Que sorte! Sempre que eu começo a teorizar demais eu fico receoso de estar viajando na maionese e procuro evidências que corroborem ou neguem as minhas hipóteses, e esse caso vem bem à calhar porque demonstra claramente a diferença entre OI e BI.

Cenário

Eis o caso:


Companhia de grande porte espalhada pelo território nacional, com gestão de projetos tradicional (cascata), entendeu que precisava adotar práticas de gestão ágil. Um plano corporativo de educação foi desenhado e aplicado, e agora o alto escalão da empresa quer descobrir se deu certo, e quão certo deu.


Vale a pena notar, antes de começarmos, que essa empresa conseguiria medir o impacto do treinamento mais facilmente se tivesse estabelecido quais seriam os resultados pretendidos de antemão. Seria mais fácil se, ainda no planejamento da capacitção, tivessem declarado quais aspectos do negócio deveriam ser impactados, de que forma esperar-se-ia esse impacto, como ele seria medido etc. etc. etc. Não consigo atinar como alguém faz o [roll-out][rollout_bitly] de um projeto desse porte sem estabelecer metas, mas enfim, adiante.

Eu e meu amigo trocamos algumas idéias e no final a minha sugestão foi:


Oras, se a intenção era melhorar a gestão de projetos adotando Scrum, então basta você comparar os indicadores de qualidade de projeto antes e depois dos treinamentos (veja o comentário 1 abaixo.) Se houver uma certeza estatística de variação nesses indicadores (comentário 2), você terá uma evidência relativamente forte de que a capacitação foi a causa (comentário 3.)


Comentários:

  1. Como essa é uma das medidas a ser acompanhada em um caso desses de qualquer forma, a falha de planejamento não comprometeu a análise dos resultados – pelo menos não para esta métrica;
  2. O mundo real é dinâmico, e as coisas mudam com alguma aleatoriedade. Ao montar esse “experimento” o analista precisa se preocupar em não detectar “artefatos”, resultados que parecem legítimos e autênticos, mas no fundo não passam de um sinal transiente, ruído, problema metodológico ou puro e simples erro de medida;
  3. Um experimento precisa controlar todas as variáveis, para saber qual está causando a diferença nos resultados. Ele só pode confiar nos dados dele se, durante o período de transição, a empresa tiver levado uma vida normal, como levou em todos os anos anteriores. Se acontecer alguma coisa anormal, como uma fusão ou uma crise das brabas no seu mercado, a relação entre o treinamento (causa) e as mudanças dos indicadores de qualidades (efeito) ficará nublada.

Fazendo Ciência

Já temos material para um TCC e ainda nem chegamos aos dados ou às ferramentas! Foi esse padrão de problemas de BI que acabou a me levando à minha definição particular de BI, e há algumas semanas me levou ao caso da Inteligência Operacional (alguém por favor invente um nome melhor!!)

Meu amigo então me explicou como os projetos são registrados e tratados, e a partir daí identificamos os parâmetros que comporiam as métricas. Eis os pontos do fluxo de trabalho da empresa que são importantes para a análise:

  • Os projetos são registrados em um sistema informatizado (um software de gestão de portfólio e projetos), que coleta datas (inicial prevista/realizada, final prevista/realizada) de cada etapa (demanda, desenvolvimento, homologação e entrega;)
  • O tamanho e duração de cada projeto são estimados por meio de fórmulas e fatores históricos. A troca da técnica de gestão alterou essas fórmulas, mas o processo em si permaneceu quase inalterado: o projeto é avaliado, dimensionado e encaixado em um cronograma. A partir daí ele faz parte da vida da equipe;
  • Todos os parâmetros do projeto são editáveis a qualquer momento. Ou seja, o gerente do projeto pode alterar datas e estimativas a qualquer instante;
  • Os membros de cada equipe possuem alguma mobilidade, e podem mudar de equipe ao longo do ano;
  • Cada equipe executa vários projetos simultaneamente (um equívoco clássico.)

Os indicadores de qualidade dele são meio complicados e por isso eu vou – de novo – simplificar para facilitar a discussão.

Grosso modo, a qualidade é entendida como promessas mantidas com os clientes. Sempre que uma promessa é mantida, o projeto é avaliado como de boa qualidade. Quando uma promessa é quebrada, a avaliação é que o projeto teve baixa qualidade. E como medimos uma promessa? Simples: se prometemos entregar o projeto em certa data, com certo custo, dizemos que a promessa foi mantida se o projeto foi entregue naquela data, com aquele custo. Se não, então a promessa foi quebrada.

Partindo disso, as métricas relacionadas à qualidade de um projeto são os deltas, ou diferenças, de um parâmetro no início e no fim do projeto:

  • Delta de datas: diferença, em dias, entre uma data planejada (prometida) e a data realizada;
  • Delta de esforços: diferença, em Pontos de Função (PFs), entre o esforço planejado (prometido) e o esforço gasto no projeto (realizado.)

Evidentemente não estamos falando de projetos em andamento, mas apenas dos que já chegaram ao fim.

Um exemplo dos dados no sistema daquela empresa estão nesta tabela:

ID Projeto Data Início Prevista Data Início Realizada Data Conclusão Prevista Data Conclusão Realizada Esforço Previsto (PF) Esforço Realizado (PF)
1 22/08/15 12/09/15 17/10/15 24/10/15 92 90
2 27/04/15 07/05/15 21/05/15 25/05/15 95 86
3 14/03/15 23/03/15 04/04/15 05/04/15 48 58
4 10/08/15 08/08/15 05/09/15 04/09/15 61 69
5 13/04/15 17/04/15 25/05/15 20/05/15 100 98
6 22/05/15 18/05/15 11/07/15 15/07/15 64 60
7 22/11/15 19/11/15 09/01/16 19/01/16 27 28
8 27/02/15 31/03/15 07/04/15 08/04/15 79 69
9 01/09/15 22/09/15 03/10/15 29/09/15 36 35
10 13/01/15 17/01/15 24/02/15 09/03/15 79 89

Calculamos os deltas entre cada par de parâmetros (datas e tamanho), e chegamos a uma tabela assim:

ID Projeto Delta Início (Dias) Delta Fim (Dias) Delta Esforço (PF)
1 21 7 -2
2 10 4 -9
3 9 1 10
4 -2 -1 8
5 4 -5 -2
6 -4 4 -4
7 -3 10 1
8 32 1 -10
9 21 -4 -1
10 4 13 10

Esses números são, então, usados para calcular a média e o desvio-padrão de cada delta. Fazendo estas contas nas linhas da figura acima teríamos o seguinte resultado:

Medida Delta Início (Dias) Delta Fim (Dias) Delta Esforço (PF)
Média 9,2 3,0 0,1
Desvio Padrão 11,4 5,5 6,9

A interpretação desses resultados é feita assim:

  • Em média, um projeto começa com um atraso de 9 dias, e termina com um atraso de 3 dias;
  • Em média, a estimativa de esforço está subestimando o tamanho do projeto em 7 pontos de função;
  • Pela Desigualdade de Chebyshev, há 75% de chance de um projeto começar entre 2 dias adiantado e 20 dias atrasado (2 desvios-padrão.)

Por favor, releve qualquer erro que encontrar neste último item. Interpretar desvio-padrão em distribuições não-normais é um treco trucoso e talvez nem sequer seja uma análise apropriada. Uso-o apenas por conta de ser uma medida comum, fácil de calcular e porque vai servir para demonstrar meu ponto.

Analisando a Eficácia

Até aqui eu expliquei o problema (medir eficácia do treinamento) e como resovê-lo (comparar métricas de qualidade antes e depois.) Agora vamos aplicar essa solução a um conjunto de dados para ver como ela mostraria a eficácia – ou falta de – do treinamento. Como eu obviamente não posso usar os dados da empresa, eu gerei um conjunto de dados – e isso significa que eles conterão qualquer verdade que eu queira. Prometo não forçar a barra. ;-)

Vamos dizer que, em 2015, a empresa realizou 100 projetos, e que a capacitação ocorreu durante junho. Vamos analisar os dados agrupados mês a mês e comparar antes de junho com depois de junho. Por exemplo, pegaremos todos os projetos que tinham previsão de começar em janeiro de 2015 e calcularemos o erro de previsão para data de início de cada projeto, depois calcularemos a média de erros e finalmente o desvio-padrão dessa média. Colocaremos esses dados em uma tabela e passaremos para fevereiro, depois março e assim por diante até dezembro de 2015.

Eis a lista dos projetos que tinham previsão para começar em janeiro de 2015, tirados da minha massa de dados artificiais:

ID Projeto Data Início Prevista Delta Início
12 04/01/15 11
10 13/01/15 4
33 17/01/15 15
92 17/01/15 -9
34 18/01/15 48
72 20/01/15 4
78 22/01/15 41
88 22/01/15 6
49 26/01/15 0

A média de erros de estimativa em janeiro é (11 + 4 + 15 – 9 + 48 + 4 + 41 + 6 + 0) / 9 = 13 dias (positivo), significando que os projetos em janeiro de 2015 atrasaram, em média, 13 dias, ou quase duas semanas. O desvio padrão dessa população é de 18 dias, indicando uma dispersão relativamente grande. Ou seja, a média de atrasos pode não ter sido tão grande – quase duas semanas – mas a dispersão foi, indicando que há projetos que erram por muito mais que a média. Vê-se facilmente isso: há dois projetos que se atrasaram mais de 40 dias, enquanto que existe só um que se adiantou (projeto 92, 9 dias), e os outros ficam entre menos que uma e até duas semanas de atraso.

Se o treinamento tiver surtido efeito, então os líderes de projeto farão melhores estimativas e, consequentemente, a média e o desvio-padrão serão menores para projetos começados depois do treinamento. Se não mudarem muito, então o treinamento não causou o efeito desejado. Se tiver piorado, bom, então a capacitação foi uma catástrofe completa.

Eis as métricas para o erro da data de início de projetos (Delta Início) para o ano de 2015 inteiro (dados artificiais, não se esqueça!):

Mês Média Desvio Padrão
1 13 18
2 10 13
3 24 10
4 7 8
5 24 18
6 33 13
7 20 19
8 20 20
9 14 20
10 14 14
11 14 16
12 14 13

Como ninguém é de ferro, vamos traçar um gráfico com estes números: colocaremos a média como um histograma e o desvio-padrão como uma linha, com os meses no eixo X:

Média dos erros de estimativa do início do projeto, com os respectivos desvios-padrão.
Média dos erros de estimativa do início do projeto, com os respectivos desvios-padrão.

De cara vemos um gráfico conspicuamente aleatório: essas curvas não tem “cara” de nada. Se o treinamento tivesse funcionado, os cinco ou seis últimos pontos seriam mais parecidos entre si, com tendência a cair. Claro: se um dos impactos do Scrum é melhorar as estimativas, então o erro entre o previsto e realizado deve diminuir ao longo do tempo, até que passe a oscilar em torno de zero, significando que as promessas de datas estão sendo cumpridas com mais seriedade.

Olhando com um pouco de boa-vontade, até parece que algo aconteceu: de setembro em diante o erro teve um período de estabilidade em 14 dias. É um começo.

Se essa for uma tendência causada pelo treinamento, é razoável supor que o desvio-padrão também deve mostrar uma tendência de queda, ou no mínimo ter atingido algum patamar. Mais: se a precisão de estimativa está melhorando por causa do treinamento, então essa melhoria deve acontecer para todos os projetos criados depois de junho.

Antes de voltar ao desvio-padrão, vamos olhar a média de novo. A olho nú não notamos, no gráfico anterior, nenhuma tendência expressiva ou indubitável. Já que olhar não está ajudando, vamos partir para a Matemática: uma hipótese razoável é que se a média estiver melhorando, se estiver caindo, então uma simples regressão linear nestes pontos deve apresentar um coeficiente angular negativo (valores caem com o avanço do tempo.)

Eis o gráfico da regressão linear sobre as médias para o ano inteiro:

Regressão linear da média de erros ao longo de 2015: levemente negativa.
Regressão linear da média de erros ao longo de 2015: levemente negativa.

Ora! Levemente negativa? É pouco, mas pelo menos não é positiva! Como dizem no Mythbusters, o experimento está indo bem.

Como também não distinguimos a olho nu uma tendência no desvio-padrão, vamos aplicar-lhe a mesma técnica – regressão linear. A hipótese, de novo, é que se o treinamento tiver surtido efeito, então a dispersão dos pontos ao redor da média está caindo, o que seria evidenciado por um coeficiente angular negativo.

Regressão linear do desvio-padrão dos erros ao longo de 2015: positiva.
Regressão linear do desvio-padrão dos erros ao longo de 2015: positiva.

Positivo! Ou seja, conforme o tempo passa, o desvio-padrão tende a aumentar. Isso é ruim! Significa que as previsões estão ficando mais aleatórias, com erros cada vez mais irregulares.

Só que há um erro metodológico na conclusão acima – um artefato. O correto é aplicar uma regressão antes e outra depois do treinamento, já que em princípio devem haver comportamentos diferentes em cada lado. Ficaria assim:

Regressão linear para média e sigma (desvio-padrão) antes e depois da capacitação.
Regressão linear para média e sigma (desvio-padrão) antes e depois da capacitação.

Ah-HÁ! Agora estão claras as tendências! Ou no mínimo menos ambíguas:

  • Antes do treinamento a empresa tinha uma tendência a errar cada vez mais, mas todo mundo junto (dispersão diminuindo;)
  • Depois do treinamento, a tendência da média do erro mudou de sinal e ficou negativa, indicando que o erro de estimativa começou a diminuir – e a dispersão passou a diminuir mais rapidamente.

E, finalmente, a mágica: resolvendo a equação para Média < 1 e Sigma < 1 descobrimos quantos meses até a empresa cair para um erro de estimativa menor que um dia.

Erro médio:

    Erro Médio em Dias = -1,35 * meses + 28,81 dias
    1 > -1,35 * meses + 28,81
    1 - 28,81 > -1,35 meses
    1,35 meses > 27,91
    meses > 20,7

Ou seja, contando de julho de 2015, se nada mais mudasse e tudo seguisse no mesmo ritmo, a empresa atingiria erro menor que um dia mais ou menos 21 meses depois, em abril de 2017. E coisa de um mês depois, em maio/17, atingiria uma dispersão menor que um dia:

    Desvio Padrão em Dias = -1,35 * meses + 29,91 dias
    1 > -1,35 * meses + 29,91
    1,35 meses > 28,91
    meses > 21,5

Agora Sim: OI vs. BI

Usando os dados disponíveis no sistema transacional da empresa pudemos avaliar a qualidade dos projetos antes e depois da aplicação do treinamento.

Suponha que aquele primeiro gráfico vá parar em um painel, e fique à disposição da diretoria. No primeiro dia os diretores olham o painel e está lá o gráfico:

Média dos erros de estimativa do início do projeto, com os respectivos desvios-padrão.
Média dos erros de estimativa do início do projeto, com os respectivos desvios-padrão.

Justamente por não ter forma nenhuma é que podemos entender que nada mudou – as coisas não parecem melhores depois do treinamento. Alarmados, eles começam a cutucar todo mundo: como assim o treinamento não surtiu efeito?

Se a análise tivesse sido feita comparando-se as tendências antes e depois, os diretores veriam imediatamente que surtiu efeito, e quanto. Mas os dados não foram analisados, eles foram colocados em um gráfico e contemplados a olho nu, meramente.

Bom, não dá outra, no dia seguinte o gráfico está assim:

Inclinações dos indicadores no dia seguinte: negativa!
Inclinações dos indicadores no dia seguinte: negativa!

Lembram-se que o sistema de gestão daquela empresa não trava nada? Lá no começo está anotado:

  • Todos os parâmetros do projeto são editáveis a qualquer momento. Ou seja, o gerente do projeto pode alterar datas e estimativas a qualquer instante.

Bastou um dia de rádio-corredor e os dados, que passaram um ano estáticos, mudaram como se nunca houvessem sido diferentes.

E tem mais! Ao longo de um projeto, um gerente super-zeloso pode entender que certos ajustes são necessários e – legitimamente – realizar esses ajustes. Como é um sistema transacional, e tipicamente esse tipo de sistema não arquiva histórico, uma vez que os parâmetros tenham sido ajustados, os valores anteriores se perderam! Logo, de um dia para outro, literalmente, o projeto passou de muito atrasado para pouco atrasado, de tamanho grande para tamanho médio, ou qualquer outra mudança.

Pense: se os dados que rolam pela organização são maleáveis, e eles deveriam refletir a realidade, então a realidade é maleável e muda ao sabor das opiniões! Por puro e simples contato com a dura realidade sabemos que isso não é verdade!

Note que eu não estou afirmando que se alguém puder forjar fatos para ficar melhor na fita, esse alguém adulterá-los. Não estou afirmando que olhar dados operacionais, correntes, é um risco porque o caráter humano, falho, de todos nós fatalmente vai nos levar a fraudar os dados. Longe disso!

Estou afirmando que, feita sobre dados vivos, a análise certeira de hoje vira o mico corporativo de amanhã e a falha estratégica de depois de amanhã. (Nesse ritmo, a organização vai à falência até a semana que vem.)

Primeira Diferença: Técnica de Análise

Nós começamos com uma tabela listando os vários parâmetros de todos os projetos de um ano inteiro, e terminamos com quatro funções lineares. Repare que, até o final, olhar o gráfico não contou nenhuma história. Ou melhor, contou sim: que não dava para entender nada só olhando. Contrário ao mantra das ferramentas de visualização de dados, que formam o miolo da Inteligência Operacional, “ver” os dados não criou nenhum valor. E quando os dados foram divididos em dois períodos, quando pudemos acreditar que havia uma inflexão na tendência dos indicadores, foi necessário aplicar uma regressão para poder extrair alguma conclusão melhor que “o treinamento surtiu efeito”. Responder quanto de melhoria foi obtida e poder estimar quanto tempo até zerar os erros partiu de uma análise trivial, mas nem um pouco gráfica.

Em que pese o fato de os dados terem sido gerados aleatoriamente (o resultado acima foi uma feliz coincidência, eu não entrei nada manualmente!), a realidade não é diferente. Na verdade, é ainda pior: eu isolei o problema em UMA variável (data de início do projeto) e DUAS métricas. Imagine analisar um problema com três ou quatro variáveis, cada qual com meia-dúzia de métricas? Só a estatística descritiva univariada já cobre isso: média, mediana, desvio-padrão, variância, moda e esperança.


Em última análise, nossa capacidade está limitada pela capacidade das ferramentas. Escolher a ferramenta adequada e saber manuseá-la representam metade da solução de qualquer problema.


Segunda Diferença: OLTP <> Histórico

E outra: demos sorte que o sistema dele registra esse monte de parâmetros. E se fosse um outro problema, um em que o sistema não registre esses milestones? Pense em um sistema que controla o estado de – digamos – um ticket de atendimento, mas não registra as datas dos estágios pelo qual o ticket passou. Como é que poderíamos saber se algum assunto vai-e-volta, se tudo que podemos olhar é o aqui e agora, se não podemos ver o histórico das mudanças?


Sem dados históricos não há análises estratégicas. Como não é parte da responsabilidade de sistemas transacionais acumular histórico, não podemos confiar nos dados vivos para conduzir análises estratégicas.


Terceira Diferença: Consistência

Neste exemplo, ao olharmos os dados de um ano para trás, estamos vendo o que aconteceu naquela época? Ou estamos vendo o resultado de ajustes feitos na melhor das boas intenções? Os dados mudaram ao longo do tempo?


As coisas mudam, e olhar dados vivos trazem riscos inerentes à esse fato. Não se pode analisar dados dinâmicos mais do que podemos mirar em um alvo que se desloca erraticamente: se não temos certeza do caminho que ele percorre, só vamos acertá-lo por pura sorte.


Conclusão

Uma organização faz perguntas sobre si própria continuamente. Ora é preciso saber o que está acontecendo agora, neste instante, ora é preciso entender como as coisas estão funcionando, aonde se está indo. O primeiro caso é a essência da “Inteligência Operacional”, enquanto que o segundo é “Inteligência de Negócios”. A importância em se distinguir as duas coisas resume-se aqui:

  • Desenhar um gráfico com pontos pode contar uma história invisível aos olhos, mas visível sob o microscópio da Matemática e da Estatística: aprenda a escolher a ferramenta adequada e a manuseá-la, ou você poderá acabar com as mãos vazias na melhor das hipóteses. Na pior, pode ser levado a acreditar em algo incorreto;
  • Aqueles que ignoram o passado estão condenados a repeti-lo: não se fie nos sistemas transacionais para guardar o histórico de dados, pois essa não é a função deles. Cuide você de arquivar os dados importantes;
  • As coisas mudam, os dados mudam. Analisar dados vivos, dinâmicos, é garantia de não se poder garantir nada;

Retomando o post que deu origem à série, olhemos a tabela que separava OI 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

Em qual coluna se encaixa o caso mostrado? Vejamos:

  • Ciclo de vida dos dados: o estudo dos indicadores de qualidade consumiu dados históricos, que idealmente deveriam ser estáveis;
  • Origem dos dados: por sorte o transacional arquivava os atributos importantes, como as datas de cada etapa do projeto, e as estimativas iniciais. Sem isso, a única forma de se dispor desses dados teria sido um DW;
  • Velocidade de manuseio dos dados: irrelevante, ou não-crítica, pois meu amigo tinha alguns dias para conseguir uma resposta, e o volume de dados é pequeno;
  • Funcionalidade mais importante: descrição estatística dos dados, o que não chega a ser Data Mining, mas é bem mais que só um gráfico. A mera visualização gerou apenas dúvidas.

Logo, esse caso clasifica-se (pela minha régua, claro!) como um caso de BI e não de OI.

Tente imaginar em que situação esse caso teria sido classificado como OI:

  • Se os dados necessários fossem os dados do OLTP, vivos;
  • Se quiséssemos comparar valores ou percentuais do total – ideal para ser feito por gráficos;
  • Se o volume de dados afetasse negativamente a navegação deles, deixando o processo de análise lento para uma demanda de resposta rápida.

Perguntas da cepa “estamos no segundo dia de treinamento; a frequência está boa? Tem muita gente faltando?” e assim por diante, se encaixam mais no paradigma de dados operacionais. Para começo de conversa, descartaríamos um DW logo de cara.

Espero que tenha deixado tudo mais claro.

Até a próxima! ;-)