Coletânea GeekBI 2016 a Caminho & Pesquisa

Quem ouviu as notícias do final do dia, hoje, talvez tenha ficado sabendo que as nuvens sobre São Paulo tiveram um episódio de… piriri hídrico, digamos assim, por falta de um termo mais educado, parando a cidade, inundando tudo. Resultado? Sentei para escrever o post de hoje e são 22:22.

Ohhh, a hora mais legal do dia!

Enfim, não deu para terminar o post que eu comecei para hoje. Para não desperdiçar sua viagem até aqui, que tal responder uma pesquisa rápida? ;-)

Conte-me Tudo, Não me Esconda Nada

O tema do post desta semana era (e vai ser, semana que vem) a transformação do acrônimo BI em algo diferente do que ele designava quando foi criado, na década de 50 e a minha resistência em aderir a essa… evolução.

Por isso, já que eu não consegui terminá-lo hoje, queria saber, eu pouquíssimas palavras, o que você acha?

Dá para escolher até duas respostas, se você achar uma só limitante demais.

Mantenha seu cadastro em dia

Eu sempre quis dizer isso, hehe.

O livro com a coletânea dos posts de 2016 já está na Amazon, e vou lançá-lo. Como eu prometi, meus leitores terão um descontaço (de graça!) para levá-lo, mas para isso eu preciso me comunicar diretamente com eles – com você. Como eu vou usar uma ferramenta de mala-direta para fazer esse (e outros) contato, precisarei confirmar os dados de vocês.

Você, que fez o cadastro no blog, vai receber um e-mail para confirmar esses dados. Se você preferir saber das novidades apenas pelo aviso-padrão do WordPress (a ferramenta que gerencia o blog), basta ignorar o contato.

Quem confirmar vai ficar em uma lista prioritária, e ser avisado antes de todos.

Estou tentando, mas reescrevi esse trecho dez vezes e ainda estou parecendo/me sentindo uma propaganda da Polishop… Desculpa aí, ó.

Dica: se você comprou o livro Pentaho na Prática, e atualizou, não deixe de ler o final, depois da biografia!!

Finalmente, se você se cadastrou como um outro blog, considere adicionar seu e-mail também, já que eu não consigo contatá-los apenas por esse vínculo.

Por hoje é só isso mesmo. Até semana que vem! :-)

A Culpa é do Cubo!

Em 12 de janeiro de 2017 eu estive no evento DBTalk Liderança Ágil, tocado pelo meu ídolo agilista Jorge “Kotick” Audy. Foi uma hora e meia sendo soterrado por avalanche atrás de avalanche de assunto sobre liderança, Ágil, organizações, modelos, psicologia…

Como todo bom evento, semelhante a um boi, nada se perdeu, tudo se aproveitou. Depois de tudo que veio na palestra, ainda tive chance de bater papo com ele e muitas outras figuraças que estavam por ali.


É sério, não percam esse evento, que ocorre frequentemente em Porto Alegre, sede da empresa, e com alguma frequência aqui em São Paulo. É do balacobaco.


Uma dessas conversas foi o espanto geral de que há pouco, em termos de Ágil, sendo feito em Inteligência de Negócios. Na verdade é pior que isso: o pouco que eles viram fui eu que levou – um zé ruela qualquer. Fora o que este vosso humilde servo-zé-ruela fez, eles mesmos confirmaram que nunca viram nada.

E porquê? Por que tão pouco existe sobre BI, com Ágil?

Eu descobri essa resposta há muito tempo, mas só ali a minha “Guernica” 1 BI-Ágil ficou completa, só ali é que a última peça fez clique no lugar.

Por causa do cubo.

Adoro Kimball, tanto que fiquei muito triste ao saber que se aposentou – acabou-se minha chance ter aulas com ele. Mas o enorme sucesso de suas idéias acabou levando a uma absurda prevalência da Modelagem Dimensional em projetos de dados para BI. Como em geral são projetos de DWs ou data marts, acabamos sendo levados a pensar tudo em termos de cubos.

Estão acompanhando? Atrelada a projetos de BI existe uma forte cultura de modelagem de dados à moda do Kimball. Assim, nos acostumamos a “pensar” os dados de projetos de BI como organizados em cubos multidimensionais.

E – na minha humilde opinião – esse é O problema. É esse o motivo para existir tão pouca coisa de Ágil para Inteligência de Negócios.

Não sei se vou conseguir passar, aqui, por escrito, a minha percepção do problema e como intuí a resposta, mas vamos tentar.

O Mundo Não é um Quadrado em 3D

Para começar, há muitas necessidades em BI para as quais um cubo é uma abordagem inadequada, quando não atravancadora.

Um exemplo fácil é Data Mining

Resumidamente, Data Mining ou Garimpagem de Dados na minha tradução favorita, é um processo que parte de uma questão de negócios, como o que fazer para aumentar as vendas em 5%? ou como decidir quanto crédito fornecer a cada cliente, e usa Matemática sobre os dados disponíveis para construir um modelo da realidade. Realidade esta que não se apresenta clara, límpida e cristalina nos bancos de dados da empresa, mas sim como uma massa bagunçada e suja de dados oriundos de inúmeras fontes – sistemas transacionais, pesquisas, bases externas, canais diversos etc.


O resultado do processo de garimpagem é um modelo matemático que descreve a realidade, e a realidade é suja.


Para fornecer um resultado com algum grau de confiabilidade, Data Mining precisa de dados crús.

Por outro lado, dados limpos, como os necessários para análises multidimensionais típica, não refletem a realidade completamente. Erros, vazios, nulos, tudo isso é descartado para levar ao cliente uma estrutura com dados claros, que permitam interpretação sobre o que sabemos, já que não adianta especular sobre o que não foi capturado.

Na melhor das hipóteses, dados sujos são disponibilizados para análise com alguma marcação, como “Não preenchido”, “Inválido” etc. Empresas que sofrem com qualidade de dados fazem isso porque assim conseguem um mínimo de certeza em suas respostas. E alguma informação é melhor que nenhuma, sempre.

Outro exemplo? Claro: painéis.

“Como assim!”, exclamarão vocês, “painéis se dão muito bem com cubos!”

É, não posso negar que se dão bem, vocês quase têm razão.

Quase.

Como é mesmo aquilo que dizemos sobre martelos? “Para um martelo, todo mundo é prego.” Se você quer montar um modelo de dados dimensional, para tudo, vai estar condicionando tudo a uma visão dimensão vs. fatos.

Painéis tendem a aglomerar diferentes visões sobre um dado aspecto da sua organização. Logo, não raro temos em um único painel widgets apontando para diferentes fontes de dados. Diferentes origens.

Diferentes cubos.

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


Preparar dados para um painel usando um único cubo requer a consolidação de diferentes grãos em um único, que sirva para tudo.

Caso isso não seja possível, precisaremos de mais de um cubo.


Logo, uma visão de cubos te obriga a transformar toda sua realidade, em que as relações são mais complexas que as relações de um modelo dimensional, em vários pedaços. Isso acaba destruindo a produtividade porque para cada pedaço você precisa passar por todo processo de desenvolvimento de modelo dimensional!

É isso que redime o setor de Data Discovery, meu eternamente incômodo e aborrecido setor de ferramentas para Data Discovery.


Não tenho nada contra ferramenta nenhuma! Mas tenho contra argumentos frágeis e superficiais! Leia aqui!


O que está no centro de uma ferramenta de Data Discovery não é a capacidade de produzir resultado sem precisar de um DW. Caramba, uma ferramenta de DD não tem nada que uma de BI não tenha! São absolutamente iguais!

O que destaca DD da prática tradicional de BI é que Data Discovery prescinde do processo de modelar um cubo como intermediário para análise! Você nunca pode se livrar de um DW porque o Tempo é a variável mais importante de todas, mas em nenhum lugar está dito que é obrigatório ter um cubo para historiar dados! O que no fundo DD faz é abrir mão de um horizonte de tempo maior em prol de maior velocidade na geração de valor!

Worlds Collide!

Eis aqui o Manifesto Ágil:


Manifesto para o desenvolvimento ágil de software

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:

> Indivíduos e interações mais que processos e ferramentas

> Software em funcionamento mais que documentação abrangente

> Colaboração com o cliente mais que negociação de contratos

> Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.


Esse é precisamente o ponto:

Indivíduos e interações mais que processos e ferramentas

O que é que acontece quando colocamos um cubo à frente de qualquer resultado? Resposta: estamos valorizando o processo e a ferramenta!!

Por que é que temos tão pouco de Ágil em BI?

Que tal analisar o que existe de Ágil para BI listando os livros que tocam no assunto?

Entrei na Amazon.com e coloquei BI e Agile. Deu nisso:

Ágil e BI na Amazon: livros sobre... DW?
Ágil e BI na Amazon: livros sobre… DW?

Depois do terceiro resultado tudo ficava mais ou menos confuso – ou tinha pouco/nada a ver com BI ou com Ágil ou com ambos. Fechei a busca, e coloquei Data Warehouse e Agile:

  • Agile Data Warehouse Design: Collaborative Dimensional Modeling, from Whiteboard to Star SchemaNov 24, 2011
  • Agile Data Warehousing for the Enterprise: A Guide for Solution Architects and Project LeadersOct 8, 2015
  • Better Data Modeling: An Introduction to Agile Data Engineering Using Data Vault 2.0Nov 21, 2015
  • Super Charge Your Data Warehouse: Invaluable Data Modeling Rules to Implement Your Data Vault (Data Warehouse…May 20, 2012
  • The Official Data Vault Standards Document (Version 1.0) (Data Warehouse Architecture)Sep 27, 2012
  • Data Architecture: A Primer for the Data Scientist: Big Data, Data Warehouse and Data VaultNov 26, 2014
  • Agile Data Warehousing Project Management: Business Intelligence Systems Using ScrumSep 28, 2012
  • Growing Business Intelligence: An Agile Approach to Leveraging Data and Analytics for Maximum Business ValueSep 21, 2016
  • Growing Business Intelligence: An Agile Approach to Leveraging Data and Analytics for Maximum Business ValueSep 19, 2016
  • Extreme Scoping: An Agile Approach to Enterprise Data Warehousing and Business IntelligenceAug 15, 2013
  • Agile Data Warehousing: Delivering World-Class Business Intelligence Systems Using Scrum and XPAug 5, 2008
  • Test-Driven Database Development: Unlocking Agility (Net Objectives Lean-Agile Series)Feb 21, 2013
  • Lean Analytics: Use Data to Build a Better Startup Faster (Lean Series)Mar 21, 2013

Ou seja: muita coisa sobre DW e Ágil, mas pouca sobre BI e Ágil.

Ora, bolas, é a Amazon! Eles vendem, e isso enviesa tudo. Vamos procurar uma coisa mais abrangente, mais neutra: o Google!

Ágil e BI, segundo o Google: ferramentas?!...
Ágil e BI, segundo o Google: ferramentas?!…

(Claro que eu sei que o Google também enviesa os resultados. Na verdade, enviesa tanto que eu precisei remover a renca de anúncios que vinha antes do quadro acima. Mas é mais aberto que a Amazon.com, não resta duvida.)

De novo, foco em ferramentas! Ou quase. Se seguimos o link para a Wikipédia, achamos algo mais próximo de Ágil:


Agile Business Intelligence (BI) refers to the use of the agile software development methodology for BI projects to reduce the time-to-value of traditional BI and helps in quickly adapting to changing business needs.(…)


Opa, agora sim! “Ágil BI refere-se ao uso da metodologia de desenvolvimento de software ágil para projetos de BI, para reduzir o tempo-até-valor”! Eles até citam a “metodologia” que nasceu para resolver problemas de desenvolvimento de software, mas focam no que é importante: rápida geração de valor para a organização.

Curiosamente, essa mesma definição tem como referência produtos de software para “fazer BI Ágil”, um tal de Consensus e outro, Logix – nunca havia ouvido falar de nenhum dos dois, o que para mim é suficiente para colocar esse artigo em quarentena. Vou lê-lo e estudar essas ferramentas com mais calma e decidir se é mais algum fornecedor querendo surfar hype, ou se me parece válido, sólido.

Vamos refazer nossa pergunta: por que é que temos tão pouco de Ágil em BI?

Resposta: não sei. Mas se eu precisasse chutar algo, diria que é porque todo mundo entende que o tratamento de dados vem no centro de todo projeto de BI, que por sua vez está perpetuamente voltado para o modelo dimensional.

Colocando de outra forma:


IMHO, temos pouco de Ágil para BI porque quem se dedica a este assunto acaba preso na questão de produzir dados e não de solucionar problemas.

E eu acredito que, também IMHO, isso acontece porque o enorme sucesso da Metodologia de Modelagem Dimensional, de Ralph Kimball, criou em nós uma associação automática entre BI e Cubo.


Conclusão?

Dificilmente isto aqui é uma conclusão, pois eu ainda não cheguei nela. O que eu tenho, por enquanto, é a forte sensação de que o problema de produzir dados para projetos de BI está polarizando a aplicação de técnicas ágeis para BI, causando foco excessivo no desenvolvimento de cubos, ou seja, de modelos multidimensionais.

Eu ainda não achei uma evidência forte de que isso bloqueia o desenvolvimento ágil, ou de como esse bloqueio atuaria, se existir. Intuitivamente eu percebo que um modelo dimensional não é algo muito difícil de ser atacado com métodos ágeis, e até por isso mesmo há tanto material sobre esse assunto. Me parece que o fato de termos um modelo dimensional no meio do caminho entre a necessidade de negócio e a solução de BI é que atravanca as coisas, que por sua vez é justamente a causa aparente do sucesso do Data Discovery. E não podemos ignorar a frequência de fracassos de projetos de DW.

Por exemplo, se um DW cresce pela colagem de um cubo em outro através de dimensões comuns ou conformadas – a tal Bus Matrix – então cada nova necessidade acaba criando algum retrabalho ou uma nova expansão do DW. Eu estou começando a achar que o Modelo Dimensional permite muito pouco reaproveitamento. Quase como se, a cada nova funcionalidade de um sistema fosse preciso duplicar um pedaço grande do sistema, e customizar essa nova parte.

Como lidar com um armazém de dados construído para um único propósito – análise multidimensional – em uma empresa que pode possuir n demandas de m tipos para os dados, em que cada demanda requer praticamente um cubo próprio? E pior: como lidar com as necessidades operacionais?

Confuso? Para mim também. :-(

Eu acho que encontrei a solução (sim, tem Data Vault envolvido, claro!), mas ainda não está madura o bastante para sair aqui. Mas assim que estiver, você será o primeiro a saber.

Até a próxima! ;-)


  1. Guernica é o nome de um famoso quadro sobre um episódio da Guerra Civil Espanhola, pintada por Pablo Picasso. Sua interpretação é muito controversa. Uma das que eu ouvi é que é cheio de partes que representam aspectos do conflito, e tenta capturar a dificuldade que é, para uma mente humana, abarcar uma realidade complexa, cheia de nuances e contradições. Baseado nessa visão eu estou rascunhando um post que tenta mostrar como BI se assemelha mais à Guerra Civil Espanhola, complexa e cheia de partes, que a uma coisa como Física, que é feita de partes interconectadas e articuladas entre si. 

MDX Para Quê?

Por que alguém precisaria aprender MDX? É o que eu pretendo justificar aqui.

Preparado?

Get set, ready, go!

M-D-OQ?

MultiDimensional Expressions é uma linguagem para construção de visões de dados multidimensionais (i.e. com cabeçalhos em linhas e colunas) inventada pela Microsoft, a partir da meta simples de levar BI para as massas.

MDX é muito parecido com SQL, no sentido de que é uma consulta que “constrói” uma “tabela”, exceto por alguns fatos:

  • O resultado tem uma forma mais semelhante a uma planilha que a uma lista;
  • O motor que trata consultas MDX não é um banco de dados relacional tradicional, mas um servidor de dados multidimensional;
  • MDX não possui uma DDL, que é um conjunto de comandos para definir estruturas de dados. Em SQL, por exemplo, CREATE TABLE é um comando DDL;
  • E não tem esses comandos justamente porque o propósito do MDX é fazer consultas, não transações. Mesmo assim, criou-se uma coisa chamada writeback, que permite escrever dados de volta para o servidor multidimensional.

Se você ainda não adivinhou, MDX é uma linguagem de consulta de cubos OLAP. Daí você entende facilmente que MDX é apenas parte de uma arquitetura maior, que engloba um servidor OLAP, ou multidimensional (do qual o Mondrian é um tipo), e algum tipo de processo de atualização de dados.

Há dois bons livros para aprender sobre OLAP e MDX:

O Problema

Vamos deixar MDX de lado um pouco, e examinar o problema desta semana. Para (não) variar, é um problema que eu vim a enfrentar ao tentar resolver uma situação muito ordinária, apresentada por um colega de trabalho.

Esse colega trabalha no marketing da empresa e fez uma pesquisa com nossos empregados. De maneira geral, a pesquisa tinha dois tipos de perguntas:

  • Perguntas com respostas únicas, como sim/não ou uma lista de opções do qual somente uma podia ser escolhida. Por exemplo, setor do empregado (uma opção de uma lista), e se conhecia a estratégia da empresa (sim ou não;)
  • Perguntas que podiam ter nenhuma resposta, uma resposta ou mais de uma resposta. Exemplos: qual é seu meio preferido de comunicação (cite até três).

Para simplificar, assuma que esses dados eram coletados em uma planilha com este layout:

ID P1 P2.A P2.B P2.C
1 Sim E-mail
2 Não Cartaz Reunião
3 Sim

Obviamente a pesquisa era bem maior que isso, e tínhamos várias perguntas de cada tipo. O que é importante guardar aqui é que existe uma pergunta que gera uma resposta em uma única coluna, como a P1, e perguntas que geravam suas respostas em n colunas – duas, três, dez.

Como analisamos esses dados? Bom, por exemplo, podemos perguntar quantas pessoas conhecem a estratégia da empresa, que é a P1. A resposta é obtida somando-se todos os SIMs da lista de respostas. Um simples SELECT COUNT('SIM') AS conheco FROM pesquisa traria a resposta. Ou falando em termos de Excel, basta colocar uma função de contagem para totalizar a coluna da P1.

Outra pergunta pode ser: quantas pessoas têm no e-mail seu meio de comunicação preferido? A resposta, de novo, é obtida com relativa facilidade: contamos quantas vezes a expressão E-mail aparece na coluna P2.A.

Mas é claro que a realidade nunca é assim tão fácil, não é mesmo? Não teria graça, se fosse. ;-)

Suponha que nosso chefe peça o seguinte: “descubra os três meios de comunicação mais preferidos, por ordem do mais votado para o menos votado”.

Fácil? Algoritmicamente, talvez:

  1. Conte P2.A, P2.B, P2.c etc.
  2. Crie uma outra tabela, de duas colunas: opção e contagem;
  3. Insira, na primeira linha desta tabela, o rótulo “E-mail” na coluna 1, e sua contagem na coluna 2;
  4. Repita isso para todas as outras opções;
  5. Ordene esse tabela do maior para o menor, usando a coluna 2 e limitando o resultado em 3 linhas.

O resultado seria algo assim:

Meio Contagem
E-mail 10
Cartazes 7
Reuniões 2

“Ah”, pensas tu, “fácil como torcer para o Grêmio, guri!”


Estou em um treinamento de Lean Business Analysis pelo Luiz Parzianello, um porto-alegrense bah, tchê! Daí eu acabei pegando o sotaque, índio velho!


Então você pensa que é fácil?

Hahahahahaha…

Permita-me frisar:


HahahAHhAHHHaHAhAhAHAHHHahahaHAhahaha!!!….


É qualquer coisa, menos fácil. Por favor, tente essas análises:

  1. Qual é a porcentagem de empregados que conhece a estratégia e prefere e-mail?
  2. Qual é a porcentagem de cada opção, em cima do total de empregados que responderam essa pergunta?

A primeira análise é similar à inicial, mas com um filtro aplicado (conhece a estratégia = sim) antes de calcular a razão entre todos que responderam SIM para opção de e-mail pela quantidade de SIMs totais.

E a segunda? Simples:

  1. Calcular a razão entre a quantidade que respondeu “prefiro e-mail”, pela quantidade de participantes que tem pelo menos uma resposta;
  2. Calcular a razão entre a quantidade que respondeu “prefiro cartaz”, pela quantidade de participantes que tem pelo menos uma resposta;
  3. Etc.

E é claro que fica cada vez mais complicado: depois de dois dias trabalhando com Excel sem parar, o chefe olha seu relatório e diz: “excelente! agora quebra por setor!”

Vamos é querer quebrar a cabeça do pobre desafortunado que decidiu te ter na equipe, não é?


Vou tentar colocar de outra maneira: contagens simples são, como o nome implica, ações triviais. Só que, em geral, o maior valor de negócio está nas análises mais complexas, mais sofisticadas. Coisas que nem sempre podem ser respondidas com filtros e contagens.

Se meu exemplo não passou esse cenário, perdão. Esse é o cerne do problema: análises “complexas”


Trabalho de Ser Vivo de Crânio Ornado com Projeções Ósseas

Pode não ser um trampo excessivo quando temos uma pesquisa só, que por sua vez contém apenas uma pergunta deste tipo, que não tem mais que meia-dúzia de opções.

Mas, adivinha: meu colega vai fazer uma pesquisa assim uma vez a cada pelo menos dois meses! E cada uma das pesquisas do baita tem, por alto, uma meia-dúzia dessas perguntas, cada uma com quase dez opções, se não mais. E cada pesquisa atinge 10.000 empregados, com uma taxa de quantidade de respostas média em torno de 3.000. Ou seja, dos 10.000 pesquisados, em média, 3.000 respondem.

E conforme o número de variáveis sobe (gênero, setor, cidade, faixa etária, conhecimento etc. etc. etc.) sobe exponencialmente o trabalho para correlacionar uma coisa com outra.

Mas fica pior.

Uma Pergunta Múltipla Incomoda Muita Gente…

.. duas incomodam, icomodam muito maais.

Uma técnica prática para simplificar o trabalho de corno que é tabular esse tipo de dado é transpor parte da pergunta, ou desnormalizá-la. Por exemplo, a tabela do início vai de:

ID P1 P2.A P2.B P2.C
1 Sim E-mail
2 Não Cartaz Reunião
3 Sim

para:

ID P1 P2
1 Sim E-mail
2 Não Cartaz
2 Não Reunião
3 Sim

Notou o que eu fiz? Eu repliquei cada linha que tinha mais de uma resposta, e coloquei todo mundo lá.

Agora ficou mais fácil fazer uma contatem simples. Mas o que aconteceu se eu tiver DUAS perguntas de múltiplas escolhas?

ID P1 P2 P3
1 Sim E-mail Escolha X
1 Sim E-mail Escolha Y
2 Não Cartaz Escolha Y
2 Não Cartaz Escolha K
2 Não Cartaz Escolha Z
2 Não Reunião
3 Sim Escolha Y

Agora não basta mais contar cada coluna: é preciso deduplicá-las antes, e fazer as contas depois.

Uma vez a cada dois meses.

Em datasets pequenos, de coisa de 3.000 linhas… E algumas dezenas de colunas. Duas perguntas de cinco escolhas cada, as 3.000 linhas iniciais pulam para pelo menos cerca 6.000, podendo chegar – em casos extremos – a centenas de milhares de linhas… PARA SEREM TRATADAS NO EXCEL.

Não vira, né? ;-)

Operações de Conjuntos

Foi tentando resolver esse problema que a minha ficha caiu: eu vou precisar de um ETL específico para cada pergunta de resposta múltipla para colocar tudo como colunas simples, para permitir contagens simples, mas cada contagem vai ficar mais complicada ainda! É um círculo vicioso! A solução que achamos foi aplicar essa transposição coluna a coluna, uma de cada vez, e fazer análises estanques. Só depois, então, as análises de cada coluna são feitas.

MDX To The Rescue

Bom, MDX é difícil, na prática, mas na teoria, no conceito, é simples: uma expressão literal que manuseia conjuntos multidimensionais.

Falando de outra maneira, é uma linguagem que trata um problema complexo como o que eu expliquei aqui, com muito menos trabalho que toda operação manual.

Por exemplo, o caso inicial – top 3 canais – pode ser descrito como um conjunto formado pela união de três subconjuntos, que por sua vez recebeu uma ordenação com limite.


Eu voltarei ao assunto com um exemplo concreto. Por ora, por favor, tentem visualizar o que estou descrevendo.


Mas e se tivermos, por exemplo, várias perguntas de múltiplas respostas? Não tem importância: comandos MDX, que podem ficar verdadeiramente cabeludos, lidam com conjuntos de membros de uma dimensão (as opções de cada pergunta) e calculam as métricas para aqueles cruzamentos. Comandos que constroem sub-conjuntos podem ser aninhados para montar dois, três, n conjuntos e, em seguida, totalizá-los o apresentá-los como uma matriz – uma planilha.

Complexo? Sim. Pouco intuitivo? É, um pouco. Torna tudo viável? Sim!

Conclusão

Muito de análise multidimensional pode ser feito com um conjunto de dados simples e uma boa ferramenta OLAP. Porém, certos conjuntos de dados representam um desafio muito maior – que nem mesmo um bom trabalho de ETL pode simplificar. Podemos acabar mudando um problema complexo em outro, tão complexo quanto ou mais!

A linguagem MDX, e as tecnologias OLAP associado por trás, como servidor de dados multidimensional, pré-agregadores etc., são uma opção poderosa, geralmente certeira e muito pouco conhecida!

É esse cenário que eu pretendo mudar, daqui para o final do ano.

Até lá, guarde em mente que um analista de dados deve aprender MDX por dois motivos simples:

  • Permite analisar mais dados, mais rapidamente;
  • Simplifica o trabalho de responder uma pergunta a partir dos dados, tornando algo complexo em simples, e tornando em possível o im possível.

Até a próxima! ;-)

 

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! :-)

Vaga Pentaho Jan/2017

Isso é que é começar bem o ano!

  • Consultor Pentaho Experiência em conceitos de BI e modelagem dimensional para Data Warehouse;
  • Conhecimento avançado na linguagem SQL com foco em MySQL (versão 5.6 ou superior);
  • Experiência com a suíte completa do Pentaho sendo elas: Pentaho BA Server (versão 5 ou superior);
  • Pentaho Data Integration (versão 4 ou superior);
  • Pentaho Report Designer (versão 5 ou superior);
  • Modelagem de cubos no Mondrian (versão 3 ou superior);
  • Inglês avançado (Leitura e Escrita)

Intessados podem entrar em contato com Letícia Coelho em leticia ponto coelho arroba deal ponto com ponto br.

Feliz Ano Novo!

Engraçado como nosso cérebro roda em círculos, não? Eu pelejei, pelejei, mas não consegui imaginar nenhum nome melhor para este post. Logo, decidi transformar o último post do ano em uma tradição, no qual eu fecho o ano corrente e penso sobre o próximo, e chamá-lo sempre de feliz ano novo.


Quem me acompanha sabe, eu sou pregu… prático. :-) Não consigo inventar nada melhor? Então transformarei minha falta de criatividade em tradição. :-D Né não, Lavosier?


Sacudida

Já basta de preguiça com o título do post. Por isso eu usei “sacudida” ao invés do clássico “balanço”. (Nossa, tá piorando rápido!)

Foi um ano bem variado: teve de Data Vault a painéis, passando por ferramentas e técnicas. Queria ter feito mais, como testar bancos colunares com mais detalhe e estudar pré-agregações, mas estou satisfeito com este resultado.

Foi um ano, também, de interação maior com vocês, meus leitores. Isso é o que mais me animou, o que me supriu de motivação quando eu estava sem idéias.


Obrigado de novo. ;-)


Eu também botei um pé em dois assuntos nos quais eu, definitivamente, ainda sou um novato: BigData e Data Lake. Espero ter contribuído comentários relevantes tanto do ponto de vista concreto, ou seja, para quem precisa se envolver no assunto, como do ponto de vista filosófico, indicando os aspectos que me parecem comerciais de mais e valiosos de menos para os clientes e usuários desse tipo de projeto.

E uma das coisas que eu mais gostei: a palestra na FATEC. Só aquilo já teria feito deste um ano excepcional para mim. Obrigado à Profa. Célia , da FATEC Tiradentes, e ao Prof. Josenyr Santos, da FATEC Zona Sul. Fizeram um menino feliz. ;-)

Aprendendo a Pensar Fora da Caixa

Graças a uma maior “convivência virtual” com próceres do gabarito de Jorge “Kotick” Audy, Arthur Luz’s Data Light e o impagável Rafael Piton, acabei me abrindo para as sobreposições entre BI e toda paisagem de técnicas e filosofias ágeis, novas tecnologias de bancos de dados e formas de se fazer a coisa, e uma visão do mercado profissional de BI – respectivamente.

Vale a pena destacar alguns pontos:

  • Audy: consegui conhecê-lo pessoalmente (!!!) e ainda participei de um dos seus lendários eventos. Não tem muito o que falar: gigante em pessoa, um coração imenso, profissional refinado, profundo, experiente etc. etc. etc. Hoje ele é O cara de Ágil e inovação no Brasil – LEIA-O!! :-)
  • Arthur: uma alma de professor com estilo de um cronista. Um cara que eu leio para ver o que a Microsoft está fazendo – gostem ou não, eles investem em novidades e é imperioso saber para onde estão indo! – e para aprender como se conduz um trabalho completo e bem-feito. Ele tem séries sobre diversos temas da área. Claro que interessa mais a quem vive no mundo Microsoft, mas o estilo dele é leve e gostoso de ler e sempre acaba sobrando algo para todo mundo. Este post, por exemplo, que conta sobre as novidades de uma release do MS SQL Server 2016,  é um desbunde de minúcias, velocidade e abrangência;
  • Piton: um cara que não fala sem embutir valor. Ele usa um bordão muito parecido com o meu – ele fala BI é conceito, não é ferramenta, enquanto que eu digo BI é solução, não é ferramenta – e sempre traz ótimas dicas. Não deixe de ver o vídeo dele sobre como achar centenas de vagas. É VERDADE! Ele mostra um site que eu não conhecia, mas que não vou colocar aqui para pagar o devido tributo ao trabalho dele. Passem lá, deixem um like e naveguem para o link indicado. E assinem a newsletter dele, é bem bacana. ;-)

Preparar, Apontar, Escrever!

E agora? Para Onde?

  • Beltrano S/A, v2.0: consegui organizar as idéias e planejar meus próximos livros sobre Pentaho. O primeiro passo desses novos projetos será redesenhar a base usada no Pentaho na Prática, com processo de carga parametrizado para criar um número arbitrário de linhas, e assim conseguir bases de qualquer tamanhho – milhares, milhões, bilhões de registros – que vão servir para ir mais longe em exercícios de otimização e performance no Pentaho. O projeto continua livre e vou postar as novidades conforme aparecerem;
  • Hadoop: passou da hora de eu escrever algo mais técnico sobre ele. A tecnologia está madura e acredito que agora tenho algumas idéias sobre como posso agregar valor à comunidade. Veremos se eu dou conta;
  • Bancos Colunares: usando o Beltrano 2.0, vou tentar montar um laboratório de dezenas e centenas de milhões de linhas. É o trabalho que eu mais quero fazer!
  • memcached e Hazelcast: Na sequência de grandes volumes, caches externos são obrigatórios para melhorar a performance de consultas. Ainda preciso estudar, mas tenho um amigo que meu deu boas dicas e, no mínimo, isso eu vou tentar trazer;
  • Soluções: ainda não fiquei feliz com a série Soluções Clássicas. Está muito etéreo, muito “é assim, é assado”. Vou tentar achar casos de soluções de BI no mundo real e mostrar aqui.

Mas isso é só uma parte. Instigado por posts como este fantástico Aula de BI, eu vou mirar também em assuntos mais abertos, conceituais e misturados:

  • BI com Ágil: como funciona um projeto assim?
  • {MVP, Design Thinking Etc.} x {BI}: traduzindo, produto cartesiano de BI com MVP, DT, Scrum, Gamefication etc. etc. etc. Quero investigar como ficam as tais soluções clássicas de BI dentro de um framework de criação de produto/valor, envolvendo tudo que eu li neste ano e o que mais aparecer. Será que dá para fazer?

    Valei-me Santo Kotick! Eu vou te alugar, mestre, esteja avisado! :-D


  • Negócios em geral: BI é sobre usar dados e agregar valor. Quero explorar essa interface toda, entre TI, negócios e conhecimento. Quero tentar fazer em BI o que o Audy faz com Ágil. Sem noção? Presunçoso? Sim, claro, porque não? Ou não seria euzinho, hehe. ;-)

Nem sei o que vai sair disso tudo, mas estou rascunhando vários posts em diversos temas. Só esperando uma próxima quarta-feira para saber…

Pentaho – A Nova Série

Este ano acabou representando uma pausa na minhas publicações. Eu precisei deixar o assunto quieto para as idéias maturarem, e chegou o momento de pegar firme de novo.

Sem mais delongas, com vocês minha nova série de livros de Pentaho!


Uaaah, a galera vai ao delírio,
luzes, fogos, explosões, tambores!!!…
:-D


(quem me dera…)

Enfim. ;-)

Mesmo com a (na minha opinião) excepcionalmente boa recepção do Pentaho na Prática, ele é um tijolo com quase seiscentas páginas. Se não fosse a auto-publicação, nunca teria vindo a público em sua totalidade. Isso é ruim por vários lados:

  • Obriga o leitor a levar tudo, mesmo que ele queira só um pedaço;
  • O leitor acaba pagando pelo que não quer, o que dá uma sensação de desperdício – eu sinto isso quando compro esse tipo de livro e imagino que meu leitor sofra o mesmo;
  • É praticamente impossível lançar um livro de papel deste tamanho;
  • Atualização: mesmo que algo mude em uma apenas uma das ferramentas, sem afetar as outras, o livro precisa de uma nova edição inteira. Fazer só uma parte deixaria o trabalho com uma qualidade muito ruim – começaria a parecer uma colcha de retalhos, um caça-níquel, que é o tipo de coisa que eu mais abomino. Fazer por fazer, eu prefiro não fazer.

Por esses e outros motivos eu decidi quebrar o PnP em vários livros. Por enquanto tenho três planejados, separados em função das necessidades que me parecem ser buscadas em conjunto:

  • BA Server: deve ser o primeiro, já que é o pedaço mais desatualizado do PnP. Vai ter o de praxe – instalação, configuração e uso – e mais cache externo e otimização do Mondrian, no mínimo;
  • Apresentações de Dados: como muitos já possuem DWs prontos, acredito que a próxima coisa mais útil seja mostrar coma instalar, configurar e usar as ferramentas de exploração e apresentação de dados, como o PRD, OLAP e painéis;
  • Integração de Dados: o (provavelmente) último a sair será só sobre o PDI, com tudo que eu conseguir colocar e ainda lançá-lo dentro dos próximos trinta anos. :-) Quê?! É coisa pra chuchu!!! E desta vez eu pretendo colocar clusters e bancos colunares – e Hadoop!!!

E cada um custará uma fração do preço do PnP. Acredito que isso dará mais liberdade para o leitor, que poderá investir só no que precisar. Daí, quando – e se – quiser, pode investir nos outros. E não se iludam, isso também é financeiramente mais vantajoso para mim, sem contar que é mais fácil atualizar um volume de cada vez quando ficar obsoleto.


Atenção!

Se você comprou o PnP, atualizou para a segunda edição e se inscreveu no “Livro Secreto”, então você vai poder comprar todos esses livros a um preço simbólico, e antes de todo mundo. É o mínimo que eu posso fazer para expressar minha contínua gratidão à sua coragem. ;-)

Logo depois, quem está inscrito no GeekBI, meu fiel leitor(a), será avisado e receberá um desconto especial – claro! ;-)

Mas não se preocupe se você não tem paciência pra me aguentar te torrando toda semana: como sempre, os lançamentos serão anunciados na lista Pentaho-BR, também com uma boa oferta. ;-)


Putz! Agora que eu anunciei, vou ter que entregar! Ai… kkkk

Conclusão

Já descontados os que eu não salvei, como vagas de emprego e anúncios em geral (deve dar ai uma meia-dúzia), são quase sessenta posts, escrevendo toda quarta-feira, tendo falhado apenas uma única vez. Gostaram? Foi bom para vocês também? ;-)

Eu estava decidido a não repetir a experiência, mas do nada começou a brotar idéias, assuntos e dúvidas. Então vou assumir o mesmo compromisso em 2017: um post por semana, no mínimo, com começo, meio e fim e uma proposta clara de valor para você, meu fiel leitor. Mas esteja avisado que não haverá repetição ou lugar-comum por aqui, a não ser para desmontá-lo ou desmistificá-lo. (Aaaaiii gostoso!!! Acaba, 2016!!!! kkk)

E livros!!

Últimas palavras?


Já acabou, Jéssica?


Então aqui vai:

FELIZ ANO NOVO!!!

Vejo vocês em fevereiro de 2017, bem mais sério e mais comportado que hoje, prometo. Mesmo, mesmo!

Até lá! ;-)

Feliz Natal!

E 2016 está acabando. Semana do Natal, clima de festas… Não vou fazer um post de BI, hoje. Ou melhor, não vou fazer sobre BI, em si, mas sobre as coisas boas que BI  alavancou.


Se veio atrás de BI hoje, lamento – agora só ano que vem! Mas você é bem-vindo para terminar de ler este post aqui. Ele diz respeito à você. ;-)


Ao longo destes anos eu recebi muitos comentários simpáticos e elogiosos aqui no blog e essa é uma das coisas que BI proporciona: interação entre profissionais, invariavelmente apaixonados pelo assunto. Graças a BI eu pude estender meu círculo de relacionamentos e conhecer muitas pessoas bacanas por aí.

Piegas? Claro!!! :-D

Sempre que eu venho aqui, tentar dividir o pouco conhecimento que eu consigo acumular, eu enfrento um desafio, que para mim é enorme. Eu me forço a alinhar idéias de forma clara, concisa, com começo, meio e fim, sempre garantindo um valor mínimo para meu visitante. Quero que, quando alguém ler um dos meus posts, saiba o que o espera, e que ao terminar tenha ganhado algo. Raramente eu me permiti simplesmente “copiar-e-colar” alguma coisa aqui, mas mesmo assim sempre prezei por adicionar valor ao meu leitor.

De novo, os comentários que eu recebi me sugerem que eu tenho conseguido atingir esse objetivo. Obrigado por me contarem!

Juro para vocês, toda terça-feira eu começo a surtar, entro embaixo da mesa, abraço as pernas e fico balançando, acocorado, repetindo “não vai dar, não vai dar”… Mas quando chega na quarta-feira de manhã eu já tenho uma boa idéia do que eu quero, do que vai ser o post e como escrevê-lo.

Enfrentar esse “desafio intransponível” semanal é mais uma dessas coisas que ser apaixonado por BI tem me proporcionado. Claro que é uma tortura auto-imposta, e falhar não traz nenhuma consequência. Com esse exercício eu tenho aprendido a me auto-motivar e a buscar inspiração, situações nem sempre disponíveis no meu trabalho. Neste ano todo, falhei em publicar na quarta-feira apenas uma vez.

The Year Of The Data Vault

E para fechar o singelo post de hoje – clima de Natal! êêêêhh!!! – quero destacar um comentário que recebi recentemente, por e-mail:


Em 15/12/2016 17:41, X escreveu:

Só compartilhando uma coisa bacana. Você disse sobre a automatização na criação do Data Vault e estou vivendo isso. Muito bom! Não automatizei, mas com um simples “substituir” no xml, o processo fica semi-automático.

Estou amando Data Vault. Data Vault é vida! Data Vault é amor!


Esse comentário está sendo reproduzido aqui com a autorização de X. ;-) Muito obrigado, X!

Como eu ia dizendo, eu tratei de vários temas em 2016 e tentei falar menos de ferramentas e mais de conceitos. Tratar de ferramentas, especialmente do Pentaho, que eu adoro, é divertido, mas tende a ter uma relevância menor para os visitantes, enquanto que conceitos ou experiências são úteis para mais gente e permanecem válidos por mais tempo. Por isso eu acabei falando bastante sobre Data Vault, que tem muito ainda a ser explorado tanto em termos concretos quanto conceituais. E, de alguma forma, de repente, o assunto começou a ganhar tração aqui no Brasil, e o número de interessados aumentou, comparado a 2015.

Mesmo assim, a rasgação de seda acima me pegou de surpresa. Na verdade, fiquei completamente desarmado. Eu sou um cara que, quando se envolve, se apaixona pelo assunto. Eu passo a respirar, comer, vestir, beber etc. o assunto – minha esposa que o diga. E arroubos como esse eu acabo experimentando com frequência – mas ver um assunto motivar tanto alguém a ponto de declarar “Data Vault é vida! Data Vault é amor”, bom, eu caí da cadeira! :-D Esse cara é meu herói!

E essa é a coisa mais legal que escrever aqui tem trazido para minha vida. Paixão. Um canal para extravasar minha paixão pela ciência dos dados nas organizações, um lugar para exercer meu lado cientista, físico, e atingir realização profissional em um nível ímpar.

Nada disso teria a menor graça se não houvesse alguém do outro lado para ecoar, para irmanar essas realizações.

Se você não estivesse aí me aturando. ;-)

Muito obrigado por passar por aqui. Espero que você leve algo consigo e volte semana que vem para mais um pouco. Prometo que vou me esforçar para valer a pena!

Feliz Natal!!
Feliz Natal!!

Fábio de Salles
21 de Dezembro de 2016

As Soluções Clássicas – Atuarial

Lá em abril eu comecei uma série: As Soluções Clássicas. Até agora existem dois posts lá:

Algumas das soluções tradicionais de BI elencadas então foram:

  • CRM;
  • Crédito;
  • Seguros;
  • Supply Chain;
  • Fraude;
  • Risco.

Destas, além da introdução ao assunto, eu queria mostrar três: CRM, CS e Seguros. No meio do caminho a vida foi acontecendo e o assunto foi ficando de lado, mas hoje vou fechar a “primeira temporada” e mostrar a solução de BI para Seguradoras (e outros negócios.)

O Problema

Você conhece aquela piada de estatística sobre o consumo médio de frango assado?


Dizem que cada brasileiro come em média um frango assado por mês. Bom, então deve ter alguém comendo dois, porque com este preço eu não estou comendo nenhum!


Acho que nem estatísticos riem dessa porcaria, mas enfim, o ponto era chamar o assunto. :-)

A idéia toda baseia-se nos conceitos estatísticos embutidos na piada: se conhecemos a taxa de repetição de um evento, ou seja, se sabemos que em média, algum um certo tanto de eventos vai acontecer dentro de um certo período, podemos calcular a chance de esse evento acontecer de novo dentro de um certo tempo. E conforme conseguimos mais informação sobre esses eventos, podemos refinar o cálculo e obter indicações mais precisas sobre provável próxima ocorrência.

Por exemplo, dados coletados juntos ao Ministério da Saúde e ao Instituto do DPVAT indicam que mais ou menos 200.000 pessoas foram hospitalizadas devido a colisões de veículos em 2014. Dividindo por 12 meses temos que, em média, cerca de 16.700 pessoas se machucaram por mês em 2014.

Para simplificar o raciocínio, vamos extrapolar esse número para todos os anos seguintes e assumir que, em 2016, essa média se manteve.

Arredondando a população brasileira para 200 milhões de pessoas, podemos dizer que ao longo de um ano, ao menos uma pessoa a cada 1000 com certeza vai parar no hospital por motivo de colisão veícular.

E se soubermos mais sobre quem se acidentou, no passado, podemos melhorar a estimativa. Por exemplo, se sabemos que mais homens se acidentam que mulheres, podemos ter uma certeza razoável de que ser homem aumenta o risco, e ser mulher o diminui. E assim sucessivamente: faixa etária, localização geográfica, hora do dia em que sai de casa, estação do ano…


Sabendo que a cada mil pessoas, uma vai parar no hospital a cada ano, por colisão de veículo, qual é a chance que eu tenho de ser uma destas pessoas?


As chances mudam conforme a vida que eu levo:

  • Se eu NUNCA saio de casa, esse risco tende a zero;
  • Se eu dirijo o dia inteiro, esse risco tende ao máximo;
  • Se eu uso principalmente metrô para me deslocar na cidade, meu risco é mínimo, mas maior que se eu ficasse em casa o tempo todo;
  • Se eu sou homem, a minha imprudência natural tende a aumentar meu risco de acidentes, e se eu sou mulher, tende a diminuir.

E assim por diante. Esse é um tipo de análise Bayesiana, aliás! Cada nova informação que eu trago realoca as chances de cada evento. ;-)

Sempre que há algum risco envolvido em alguma ação, o ser humano busca minimizar esse risco ou proteger-se contra as consequências de sua realização. Assim levamos em viagem mais roupa de baixo que usaremos, compramos o dobro de cartuchos de tinta para imprimir o TCC e saímos de casa meia-hora mais cedo “para o caso de algo dar errado”.

Para que é que serve essa análise de risco? Ora, para um monte de coisas! Suponha que você vai construir uma estrada: que eventos podem comprometer esse projeto? Que risco cada um destes eventos apresenta? Se um destes dados riscos for muito grande, a prudência recomenda reter o projeto. E a mesma idéia se aplica a seguros e empreendimentos variados.

O Negócio

Em algum momento alguém sacou que essa necessidade representava uma oportunidade de negócios. É como um jogo de azar: aposto um tanto de dinheiro que nada de errado vai acontecer contigo. Se eu ganhar a aposta, eu mantenho o dinheiro. Se eu perder, eu banco o seus prezuíjo até um certo tanto.

Se eu for um bom apostador, isto é, se eu escolher bem as minhas apostas, eu ganho mais que perco, acumulando o dinheiro das apostas.

Se eu for um pusta pé-frio, perdendo mais apostas do que eu consigo bancar, vou à falência rapidinho e páro logo com isso.


Consta na Wikipedia que as primeiras compras de garantias datam do Século IV, e cobriam o transporte marítmo de bens.

O assunto é deveras fascinante e merece um bom estudo, pois ajuda a entender como chegamos até aqui. Aliás, se você tiver curiosidade, vale a pena estudar também a origem dos bancos. A idéia sempre foi a mesma: ser um ponto em que os recursos de vários pequenos investidores eram somados para alavancar negócios que, individualmente, nenhum deles conseguiriam. Os exemplos mais bacanas são as caravanas de comércio e a agricultura. Ou seja, sem bancos não temos crescimento econômico…


Divago, perdão.

Uma vez que chegamos neste ponto, tudo se torna uma questão matemática: acumular dados e fazer contas até chegar em valores que balanceiem o risco com o custo. Existe um profissional que estuda as técnicas para estimar esses riscos:


Atuário (…) é o (…) especialista em avaliar e administrar riscos.

(…) Este profissional é capaz de criar modelos matemáticos para planos de investimento e amortização, para seguro social e privado; efetuar cálculos de probabilidades de eventos, avaliar riscos, fixar valores de prêmios de seguro ou de indemnizações e, ainda, trabalhar em outras áreas coligadas ao tema de risco.1


Inteligência de Negócios Aplicado à Seguros

Quem já leu algum dos meus posts sobre Data Mining, como este aqui ou até mesmo o post que abre a série, já detectou nesta definição as palavrinhas mágicas “modelo matemático”.

E o que é que eu sempre digo sobre BI? Que, no fundo, Inteligência de Negócios é a aplicação do Método Científico para entender como a organização funciona e como extrapolar seu futuro a partir do seu passado. Isso é feito por meio de – tchan! tchan! tchan! tchaaaaan! – modelos matemáticos. Conclusão? Cálculos atuariais, que estimam riscos, são uma parte de BI. Mesmo que oficialmente ninguém afirme isso, não dá para escapar à essa conclusão: se A=B e B=C, então A=C, ponto.

Essa relação nos leva a uma outra conclusão: o analista de Data Mining que constrói modelos atuariais é um atuário. Como Analista de Data Mining hoje em dia é chamado de Cientista de Dados (pfff…) então um atuário é um tipo de Cientista de Dados!


Você pode querer argumentar que um Cientista de Dados pode ser um atuário, mas um atuário não é, necessariamente, um Cientista de Dados porque não traz todo rol de habilidades com dados habitualmente associado a Cientistas de Dados (=Analistas de Data Mining.) É, eu concordo com isso. Talvez a coisa que melhor separe as duas categorias, Analistas de Data Mining e Atuários, é que o segundo só faz cálculos atuariais, enquanto que o primeiro faz muito mais coisas – só que nada impede que ambos cresçam até englobar um o conhecimento do outro. ;-) Filosofia de mais, de volta à vaca fria!!


Ou seja, Atuária e BI são, essencialmente, uma categoria única. BI engloba muitas outras coisas, assim como Atuária, mas na hora de se aplicar uma ou outra, o rol de ferramentas é praticamente o mesmo.

Para uma visão mais geral, consulte esta página da Wikipedia. Ali você tem uma lista de várias das aplicações da Atuária. Eis uma pequena amostra:

  • Health insurance
  • Life insurance
  • Net premium valuation
  • Stochastic modelling
  • Asset liability modelling
  • Property insurance
  • Casualty insurance
  • Vehicle insurance
  • Ruin theory
  • Reinsurance
  • Investments & Asset Management
  • Dividend yield
  • PE ratio
  • Bond valuation
  • Yield to maturity
  • Cost of capital
  • Derivatives
  • Pensions
  • Stochastic modelling
  • Enterprise risk management

(Desculpem não traduzir – muito trabalho para bater o Google…)

A Solução

E que ferramentas são essas?

Ora, BI tem duas ferramentas, só:

  • Data Mining;
  • Data Warehouses.

Uma boa ferramenta de Data Mining, como SAS Enterprise Miner, e um bom projeto de DW bastam para aplicar todas as técnicas. Eventualmente, uma empresa desse ramo pode precisar comprar dados externos para poder desenvolver certos modelos matemáticos.

O próprio SAS possui pacotes prontos para esse tipo de problema – vem daí, aliás, o tema da série: soluções clássicas, soluções que de tanto serem aplicadas, acabaram empacotadas como produto.

Clicando aqui você pode conhecer a solução SAS para seguros. Já este link dá um panorama mais geral sobre as soluções baseadas em Atuária.


Note que qualquer ferramenta que faça as contas já serve. Excel, por exemplo, bem usado, pode fornecer resultados comparáveis ao próprio Enterprise Manager. O que acaba mudando, de uma ferramenta para outra, é a facilidade e praticidade da coisa.


Conclusão

Atuária é a ciência de estimar riscos. Seguros e Gerenciamento de Riscos são dois ramos de negócios assentados nessa tecnologia.

Por sua vez, BI engloba toda habilidade de acumular e analisar dados de uma organização para melhorar o negócio. Logo, Atuária e BI se interpõem, e ambos acabam formando parte do outro.

Nada mais natural, portanto, que exista um conjunto de ferramentas em BI desenhadas especialmente para lidar com problemas de Atuária. Esse conjunto de ferramentas é a tal da Solução de Inteligência de Negócios para Seguros e para Gerenciamento de Riscos. No miolo dessas soluções está sempre uma ferramenta de Data Mining, e os profissionais habilitados a usá-la. Ainda que não seja absolutamente imprescindível, o uso de um DW ajuda muito neste tipo de projeto.

Se você acredita que sua empresa pode se beneficiar desse tipo de solução, não tente fazer sozinho. Busque uma consultoria, um profissional do ramo, nem que seja só para se aconselhar. Arriscando-se sozinho você assume uma chance alta de obter conclusões erradas, e comprometer a sobrevivência de sua empresa. Melhor não economizar nisso, não é?


Estamos chegando ao final do ano, e este post conclui a primeira temporada da série Soluções Clássicas de BI. Gostaram? Acharam interessante? Ou um total despercício mútuo de tempo?


Considerando-se a piada da média de frangos, tenho medo de não ter valido nem pelas risadas… :-O


Essas são as mais fáceis de se mostrar e mais simples de se entender o uso, mas existem inúmeras outras soluções. Se eu conseguir aprender o bastante sobre alguma delas, eu voltarei ao tema. Duas que eu acho superlegais, mas que são relativamente complexas, é [SCM][scm_bitly], ou Supply Chain Management, e IT Capacity Planning. Quem sabe não são as primeiras da temporada dois?

Até a próxima! ;-)


  1. Extraído do verbete Atuário, da Wikipedia, em 12/12/16. 

Vaga para Consultor Pentaho

Recebi um anúncio de vaga para analista Pentaho:

  • Experiência com as ferramentas Pentaho Data Integration e Pentaho Report Designer;
  • Diferencial que o profissional conheça também as ferramentas CTools (ferramentas usadas para criação dos dashboards);
  • Experiência com a linguagem SQL com foco em uso no MySQL (imprescindível);
  • Local de trabalho: Próximo ao metrô Paraiso – SP
  • Contratação: CLT Full.

Os interessados podem contatar Letícia Coelho, no e-mail leticia ponto coelho arroba deal ponto com ponto br.

Livros

Mais ou menos uma vez por mês eu entro na Amazon, seção de livros, e digito “dw” ou “bi” ou “data mining” ou algum jargão da nossa área. Eu reviso a lista resultante e vou separando (clicando com o control apertado, para abrir em outras abas) todo e qualquer livro que eu ache interessante. Reviso essa seleção mais uma vez e escolho um ou dois para ler.

A última rodada me trouxe quatro livros do balacobaco.

Impossible Data Warehouse Situations

O mais divertido de todos, de longe, foi este:

Impossible Data Warehouse Situations.
Impossible Data Warehouse Situations.

É um livro antigo, do início dos anos 2000, que aborda um rosário de problemas comuns em implementações de DW. Por exemplo:

  • Quando o protótipo vira produção;
  • TI é o assassino;
  • Clientes não sabem o que querem, clássico dos clássicos!
  • A quem o time de DW deve se reportar? (CIO, gerência de departamento etc.)

Ou seja, problemas comuns. Por que, então, o título de situações impossíveis? Bom, justamente por serem comuns é que são impossíveis: impossíveis de se evitar, quase impossíveis de se resolver.

E nenhum destes problemas faz parte de nenhum curso de DW. Pode olhar, pode procurar. O máximo que você vai conseguir achar é um professor mais experiente que passou ou resolveu algumas destas situações, e vai te contar alguma coisa se você perguntar.

Dessa constatação temos o valor que esse livro possui: inestimável. Até porque não é um autor prescrevendo soluções mágicas, mas sim um painel de profissionais gabaritados que dão sua opinião a cada tópico.

Veja esta situação, como exemplo:

  • Should a line of business build its own DM?

Ou, no meu tradicional e macarrônico estilo de tradução, “um departamento deve construir seu próprio DW?” Ela é descrita, contextualizada e daí vários dos colaboradores do livro dão sua opinião. Alguns são bem rasantes, outros são mais acadêmicos, uns são pé-no-chão enquanto que outros, viajantes. Assim você acaba sempre com várias visões e idéias e propostas para o problema – uma riqueza enorme!

A resposta desse exemplo, para mim, vale ouro. Vários foram quadradinhos, “sim, porque o DW é a coleção dos Data Marts” ou “não, porque o DW é uma coisa centralizada”. Bah, isso eu já sei. Mas aí vem a Jill Diché, minha favorita: go togheter with IT. Ou seja, aproxime-se da TI e ofereça para dividir a carga: você colabora com profissionais e ganha, em troca, priorização. Como é você quem vai fazer a sua parte, você recebe antes. Isso deixa o departamento feliz, a TI feliz (porque tem mais mãos para trabalhar) e não aborrece os consumidores que competem com recursos! Gênio!

E o livro está cheio dessas!

Claro que, com essa idade, alguma coisa acaba datada, como essas duas “situações impossíveis” por exemplo:

  • O sistema de origem muda continuamente; ou uma variação
  • O sistema de origem está passando por uma mudança.

As soluções propostas são de gerenciamento, mitigação de riscos e fortalecimento dos padrões e do modelo dimensional. Hoje em dia temos outra opção (já sabe, né? Data Vaul!), mas mesmo assim não é uma mudança tão grande.

O livro fala sobre negócio (mal-entendidos, desinteres, motivação), times (disfuncional, prima-donas, encrenqueiros), clientes (chatos, ruins), chefes (burros, preguiçosos ou bagunçados), técnicas (metodologia, falta de conhecimento, de experiência), padrões (usados errados, sem padrões), ferramentas e qualidade dados, entre outros.

Como eu disse, adorei esse livro. Não consigo deixar de mencionar outros dois favoritos meus, dos padrões:

  • Os empregados usam a terminologia de maneira errada;
  • Tudo é Data Mining.

:-D

Clinical Intelligence

O nome inteiro do livro é enorme:

Clinical Intelligence: The Big Data Analytics Revolution in Healthcare: A Framework for Clinical and Business Intelligence

E ele fala exatamente isso: como usar os conceitos e idéias de BI aplicado ao campo da Saúde. Há algum exagero e um pouco de mal-entendidos, mas nada que prejudique a idéia central.

Por exemplo, ele separa BI e Analytics (item 1.2, paǵina 26), e classifica machine learning, pattern recognition e predictive modeling como motores (engines) e – não bastasse – ainda por cima diferentes. Como se um padrão não fosse um modelo preditivo, e coisas nessa linha. Dá para suspeitar um pouco se ele realmente chegou a entender tudo do que fala, mas – torno a insistir – não compromete o resultado final. Apenas leia com algum resguardo, pois ele não é da área de BI.

Já na parte que realmente interessa, meus caros, ele arrebenta.

E o que realmente interessa é o índice do capítulo 2:

Sumário do capítulo 2.
Sumário do capítulo 2.

(Peço perdão pela baixa qualidade da imagem. Puxei-a do site da Amazon, e ele não estava colaborando muito…)

Vêem? Ele mostra um tipo de análise para cada um dos vários assuntos médicos! Tem desde aspectos administrativos, como casos de uso, scorecards e indicadores diversos, a complexos modelos de atendimento clínico e previsões de custos, passando por modelos de predição de osteopatia e acompanhamento de antibióticos.

Na boa, esse é o livro de cabeceira de QUALQUER gestor de saúde. Quanto mais abrangente a responsabilidade desse gestor, mais importante se torna esse livro. Em outras palavras: leitura obrigatória para secretários e ministros da Saúde, ponto.

É uma leitura que eu passei meio por alto, afinal eu sou um alien para esse campo. Eu me detive apenas nas partes de BI (onde ele faz uma zona com alguns conceitos, acerta outros e se embanana todo com ainda outros) e matemática (em que ele, aparentemente, coleta trabalhos feitos por diversos outros times, uma coisa absolutamente normal, aceitável, afinal, só um ser sobrenatural poderia saber tanto sobre tanta coisa diversa.)

Agile Data Warehouse Design

Este livro tem uma proposta muito bacana: estabelecer uma metodologia para captura de requisitos para DW adequada a projetos ágeis, e ágil em si mesma.

Cara, ficou ruim. Deixe-me tentar de novo:


Este livro tem uma proposta muito bacana: explicar um método ágil de capturar requisitos para DW, requisitos estes adequados a projetos de gestão ágil.


Bem melhor!

Ágil como em ninja, não como em rápido.
Ágil como em ninja, não como em rápido.

E seria um livro excelente não fosse tão… poluído? Pesado? Foi difícil lê-lo do início ao fim, e eu falhei nisso – depois de um tanto saí pulando até onde aguentei. O método é interessante, parece que funciona e não é difícil. Acho que o maior galho dele é justamente ser uma receita de bolo. Ele tenta passar um conhecimento “situacional”, ou seja, de como agir em cada situação, e fica tão cheio de exemplos e detalhes e senões que a coisa toda fica pesada, trabalhosa.

A sensação é que, uma vez assimilado esse conhecimento, a coisa flui. Assimilá-lo é que parece mesmo um trabalho duro. E, já que estou no assunto, ele não resolve os problemas típicos de projetos, nem de projetos de DW, justamente como aqueles colocados no Impossible Situations – esse mesmo, sobre o qual escrevi acima.

Vale a pena ler? É, pode ser que sim. Se tiver tempo, com certeza. Mas não me parece uma daquelas técnicas que abalam o mundo, como – adivinhe? – Data Vault ou Análise Bayesiana. Mesmo assim, ele agrega.

Até porque eu cheguei numa técnica semelhante, muito mais modesta e de alcance muito menor, mas na mesma linha. ;-)

Variados

E esses eram livros que eu havia lido, mas sobre os quais ainda não falara nada. Além deles, em 2016 eu li alguns outros. Dessa leva de coisas da Amazon falei um pouco no post Férias = Livros!. Não custa relembrar (não custa mesmo, é só um copy-paste aqui, hehe):

Cada um deles é um primor de conteúdo e forma. O de expressões regulares eu deixei até separado, de tanto que eu uso. O de análise bayesiana eu leio e leio e leio e uma hora eu vou dominar!

Já o Building A Scalable DW, bom, pelamordedeus, leia! Ele e o DW Toolkit são a base para um DW Corporativo feliz e saudável! ;-)

Alguma Dica?

E isso fecha o meu ano de leitura. Agora estou procurando as coisas para 2017.

Alguma sugestão? ;-)