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.
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!
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?
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
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?!…
(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! ;-)
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 é 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:
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:
Conte P2.A, P2.B, P2.c etc.
Crie uma outra tabela, de duas colunas: opção e contagem;
Insira, na primeira linha desta tabela, o rótulo “E-mail” na coluna 1, e sua contagem na coluna 2;
Repita isso para todas as outras opções;
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:
Qual é a porcentagem de empregados que conhece a estratégia e prefere e-mail?
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:
Calcular a razão entre a quantidade que respondeu “prefiro e-mail”, pela quantidade de participantes que tem pelo menos uma resposta;
Calcular a razão entre a quantidade que respondeu “prefiro cartaz”, pela quantidade de participantes que tem pelo menos uma resposta;
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.
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…
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! :-)
Geek BI 