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. 

Full Metal BI Itch

Outro dia assisti um filme de SciFi que eu adorei, No Limite do Amanhã, ou Edge of Tomorrow no original em inglês. (Clique aqui para ver o trailer.)1

Nele o herói “ganha” o poder de resetar o dia, ativado pela morte. Assim, cada vez que ele morre ele volta para o início de um certo dia – sempre o mesmo, sempre na mesma hora. Como o dia recomeçou, as coisas se repetem, sempre as mesmas, desde que ele tome as mesmas decisões. Logo ele percebe isso: os eventos futuros mudam em função das ações dele.

Por exemplo, na primeira “vida” ele é emboscado pelo inimigo logo que chega na praia. Na segunda, ainda sob o choque de ter morrido pela primeira vez, ele morre no mesmo lugar. Na terceira vida, quando ele chega na praia ele já sabe onde o inimigo vai estar, e acerta um tiro em cheio… e sobrevive! Apenas para morrer segundos depois, de novo, e reiniciar o dia pela quarta vez.

E assim ele vai: a cada vida que ele “revive” ele já sabe onde falhou da última, e avança mais um pouco.


Agora que eu parei para pensar um pouco, exatamente como em um video-game!


Amei aquele filme. Adoraria pode esquecê-lo só para poder vê-lo de novo e sentir a mesma emoção que eu senti da primeira vez.

E o que ele tem a ver com BI?

Guenta as pontas aí, já vou amarrá-las. Antes, um pouco sobre…

Técnicas de Garimpagem de Dados

Se você ainda não leu, leia. Esse deve ser o livro de BI mais de BI que existe:

O livro de BI mais de BI que existe. Leia!
O livro de BI mais de BI que existe. Leia!

Em sua introdução ele explica uma coisa chamada “ciclo virtuoso do Data Mining”, na minha tradução livre:


A promessa do data mining é encontrar padrões interessantes dormentes em todos esses bilhões e trilhões de bits jazendo em memórias computacionais. Meramente encontrar esses padrões não é o suficiente. Você deve responder aos padrões e agir sobre eles, em última instância transformando dados em informações, informações em ações e ações em valor. Esse é o ciclo virtuoso do data mining, resumidamente.


Capítulo 1, páginas 9 e 10 da terceira edição física, ou locação 676 para quem tem o livro no Kindle.

Acho que não preciso interpretar o que ele disse, não? É muito óbvio, certo?

Se é tão óbvio, seu projeto de BI deve estar fazendo, não?

Ah, não estão fazendo porque seu projeto é de Inteligência de Negócios, não de Data Mining? Entendi. ;-) Vamos ver o início do capítulo 3, então?

O que é que pode dar errado, não é mesmo?
O que é que pode dar errado, não é mesmo?

Este capítulo do livro vai esmiuçar um problema de Data Mining em suas partes e aspectos gerais e comuns entre várias técnicas. Não vou traduzir tudo que está escrito aqui, exceto por este trecho:


Data Mining is a way of learning from the past in order to make better decisions in the future.


Traduzindo mais ou menos ao pé-da-letra:


Garimpagem de Dados é uma forma de aprender com o passado a fim de tomar melhores decisões no futuro.


The Ultimate Past is The Future!

Vamos voltar ao filme: a cada vez que o herói morre, ele volta para o início do fatídico dia. Naquele momento, o futuro ainda não aconteceu mas, na cabeça dele, já. Ou seja, para ele, o passado é uma história que já aconteceu, e está para se repetir. Ele pode, portanto, usar o que aprendeu na sua “vida anterior” para tomar melhores decisões… no futuro!


Loucura, não? Filmes de Ficção Científica com viagem no tempo são mesmo de dar nós nas nossas cabeças. Enfim, adiante.


A esta altura acho que é impossível você não notar a ligação entre Data Mining/BI e o filme. Falam da mesma coisa!!

Isso não acontece na vida real, claro, mas… E se pudesse acontecer? 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?

A-há! Agora percebeu, né? 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.

O arriscamos no cara-ou-coroa, ou apostamos em algo mais sensato.

Odd Squad

Um bom exemplo de como Data Mining age sobre nossas decisões pode ser vista no seriado infantil Esquadrão Bizarro, episódio “Undercover Olive”.

Sem entrar nos detalhes desse seriado, que é divertido pra chuchu, a história é simples: os vilões roubaram o mapa para o quartel-general dos mocinhos – o tal Esquadrão Bizarro – e vão presenteá-lo a quem vencer o torneio de jan-ken-po do mal. Para impedir que esse mapa caia nas mãos de qualquer vilão, o Esquadrão Bizarro decide mandar uma agente, disfarcada (undercover) para participar do torneio e ganhar o mapa. Eles contam com uma vantagem: Oscar, cientista do grupo, analisou torneios anteriores e fez a contagem de cada movimento (pedra, papel ou tesoura) de cada vilão. Assim, quando a agente Olívia disputa um jogo, o Oscar “sopra” por rádio qual opção ela deve fazer para ter a maior chance de vitória.

O Esquadrão Bizarro: Oscar, Srta. O, Otto e Olívia.
O Esquadrão Bizarro: Oscar, Srta. O, Otto e Olívia.

No começo é fácil: a maioria dos vilões tem algum padrão, e eles usam esses padrões para ganhar. Mas quase no fim aparece um vilão que é aleatório! Ele sempre usa quantidades praticamente iguais de cada movimento, aleatoriamente. Não existe escolha mais provável, e a equipe fica em uma sinuca de bico: chutar qualquer coisa, e arriscar, ou se agarrar ao método que usaram até ali e fazer um chute calibrado?

É como Data Mining: pode ajudar muitas vezes, mas existe sempre o risco de errar pois não é uma previsão exata.


O Esquadrão Bizarro é um programa para crianças, que usa aquele fino humor britânico. É praticamente um Dr. Who para crianças, e usa uma pancada de clichès. Oscar, o cientista do Esquadrão, é obviamente inspirado no Q, o cientista do MI:6, das histórias do James Bond. O sistema de tubos é uma interpretação infantil dos teleportes de Star Trek, e assim por diante. E tem as galinhas-laser, uma birutice que não remete a nada, só piração mesmo. ;-) Meu filho de sete anos (e eu) adora(mos), mas o de dez acha uma chatice.


Ciclo Virtuoso do Conhecimento

Apesar de o livro tratar de Data Mining e por isso usar a expressão Ciclo Virtuoso do Data Mining, na minha opinião o correto seria falar Ciclo Virtuoso do Conhecimento ou Ciclo Virtuoso da Inteligência de Negócios, já que não é a garimpagem de dados que eleva a rentabilidade da empresa, mas sim o conhecimento gerado por meio de um processo de Data Mining que provê as melhorias.

Do início do terceiro capítulo, eis o ciclo:

  1. Identificar o problema;
  2. Transformar dado em informação;
  3. Tomar uma ação;
  4. Avaliar o resultado.

Auto-explicativo, não?

Conclusão

Comprar ferramentas, montar DWs, entregar dúzias de dashboards, etc. etc. etc. são ações tidas como “de BI”. São todas vazias, inúteis e até um desperdício de dinheiro se elas não forem construídas dentro do Ciclo Virtuoso do Conhecimento, no qual todos esses projetos e ferramentas são aplicados na construção de conhecimento, que depois é usado para tomar uma ação. Sem aplicar o conhecimento obtido em uma ação concreta, todo esse esforço terá sido desperdiçado, terá sido em vão.

Volto a frisar:


Se sua empresa não tem um problema para resolver, então não precisa de BI.


E se tem um problema, não começe comprando uma ferramenta bacana, ou subindo um projeto de “Data Lake”, ou coisa que o valha. Não.

Comece pelo começo: identifique o problema.

E sempre tome uma ação. Ou você vai viver todas as suas vidas repetindo os mesmos erros e morrendo no mesmo lugar.

Está sentindo essa coceira por BI?

Aquilo não é uma espada, é uma hélice de helicóptero!
Aquilo não é uma espada, é uma hélice de helicóptero!

Até a próxima! ;-)


  1. Há uma ligação entre o título do post e o filme. Assista-o e descubra. ;-) 

Spam, Spam, Spam

Monty Phyton deve ser um caso único na história da Informática. Décadas antes de as coisas começarem a se parecer com o que temos hoje, eles faziam graça com as idéias mais bisonhas e bizarras que você pode imaginar. Essas maluquices foram tão marcantes para a geração que cresceu vendo Flying Circus que acabou em pelo menos dois casos notórios. Um deles é o nome da linguagem Python.


Assista Em Busca do Cálice Sagrado e A Vida de Brian para um curso-relâmpago em loucuro pitonesca, muito pitoresca.


O outro é a gíria spam.

Todo mundo hoje em dia sabe o que é spam: é mandar uma mensagem de e-mail, newsgroup etc. para muita gente ao mesmo tempo, indiscriminadamente. Eu estava lá, vendo essas coisas acontecerem: um belo dia um colega de facul (IFGW) contou dessa coisa que estava acontecendo, spam. E que o nome vinha de um programa de tevê da Inglaterra, que tinha uns vikings cantando “spam, spam, spam”.

Spam, Spam, Spam tem essa spam cara no spam Brasil. Bleagh!
Spam, Spam, Spam tem essa spam cara no spam Brasil. Bleagh!

Estávamos em 1991 e não existia wikis, fórum, Yahoo Answers – nada dessas coisas que hoje tomamos como garantidas. Era tudo, ainda, boataria, mas agora vinha pela Internet (e dizíamos hoax, não boato, :-) .) Não tínhamos youtube, e webcams eram uma brincadeira para saber quando o café estava pronto.


cooooof-cof-cof!!! Estou sufocando no meio de tanta naftalina! Arf! :-D (Os smileys são dessa época também! (ARGH!) )


Mas hoje nós temos. Clique aqui para assistir o famigerado sketch do Monty Python que deu origem à gíria. Depois volte aqui e continue lendo – vou relacionar isso com BI já, já.

Spam, Spam, Spam! Assista o vídeo, rache o bico.
Spam, Spam, Spam! Assista o vídeo, rache o bico.

Recobrou o fôlego? Vamos em frente.

A mensagem do sketch é simples, direta, genial: abusar de uma coisa boa a torna ruim. E não pense que isso é um exagero ou que estou forçando a barra. Água em excesso mata, oxigênio em excesso mata, comida em excesso mata! O excesso é prejudicial. Existe um outro aforismo, também muito famoso, sobre esse tema:

A diferença entre o remédio e o veneno é a dose.

Paracelsus

“Diacho, Fábio”, dirão vocês, “que é que isso tem a ver com BI??”

Hoje em dia? Tudo.

Dashmania

No post anterior eu contei um pouco do que eu vivi durante a época em que a idéia de visualizar os dados em um painel – um dashboard – ganhou força.

Faça uma busca, no Google mesmo, por BI. Só, mais nada. Depois explore os primeiros links patrocinados – não os resultados da busca, mas os patrocinados. Para mim, veio isso:

Resultados patrocinados da minha busca por BI no Google.
Resultados patrocinados da minha busca por BI no Google.

Eu segui esses links, para ter uma idéia do que anda pelo mercado ultimamente. Claro que não vou colocar tudo que vi aqui – seria maçante, e alguma destas empresas poderia interpretar mal a minha idéia.

Resumo da ópera: exceto no Manta, que parece ser uma ferramenta de otimização para ETL, aparecem todas a buzzwords, exceto (curioso…) BigData. Só que o suco de todas essas propagandas é “PAINEL”.

Só para confirmar, dei uma olhada de novo em todos os fornecedores “tradicionais” de BI, como MicroStrategy. (Caramba, dos “tradicionais” sobrou só o MicroStrategy. Hyperion, BO etc. etc. etc. foram todos absorvidos e sumiram…) E tem os novatos, como Tableau, Spotfire e o household name da área, QlikView. Painel, Painel, Painel.

O Mundo É Um Palco, Não Um Painel

Shakspeare disse:

All the world’s a stage,

And all the men and women merely players;

Na boa? Se Shakespeare vivesse hoje, aposto que ele diria:

All the world’s a dashboard,

And all the men and women merely KPI Widgets;

(Nossa, citei Shakespeare! Posso morrer agora porque nunca vou fazer nada melhor que isso! Kkkk…)

Painel, Pinel

Não tem como assistir Spam, Spam, Spam e depois de ver tanto Painel, Painel, Painel não dar uma risada… :-) Eu devia fazer um vídeo… Hmm….

Como seria o sketch do Monty Python para BI, hoje em dia?


  • Olá, meu bom homem. O que você tem de BI?
  • Bom, temos “Painel, Relatório, Integração de Dados“, “Analytics, Painel, Data Discovery Painel, Painel Discovery Analytics Painel“, “Painel, Relatórios Painel, Painel Painel Dados“, “Data Painel Discovery Painel Painel“…
  • Não quero painéis. Tem Relatórios sem Painel?
  • Painel Relatórios sem Painel? Quem iria querer isso? Bleagh!

:-D

Dashboards são boas ferramentas, como também são relatórios, OLAP e Data Mining. Mas assim como Spam, usar uma só ferramenta, o tempo todo, para tudo, é um desastre.

Conclusão

Como eu sempre digo, já tentou cozinhar feijão em uma frigideira? Ou fazer um bife em uma panela de pressão? Talvez você conseguisse feijão frito com carne de panela, mas nunca feijão e bife.

Se você precisa analisar dados em tempo real, você não precisa de BI. Olhe meu post Analítico ou Operacional para uma discussão do tema.

Se você precisa apresentar dados sumariados, atraentes, de maneira sexy, painéis são a tua ferramenta. E também o são para tarefas como acompanhamentos diversos.

Mas BI não é só painel. Putz, BI tem tanto a ver com painel como um carro tem a ver com um avião: em comum têm apenas o fato de serem meios de transporte, porque de resto são totalmente diferentes. Não dá para ir atá a padaria de avião, como não dá para chegar à Antártida de carro.

Não use só painéis, painéis para tudo, ou você vai ficar sem nada.

Spam, Spam, Painel, Spam, Painel, Painel, Painel, Spam, Painel, Painel!
Spam, Spam, Painel, Spam, Painel, Painel, Painel, Spam, Painel, Painel!

Até a próxima. ;-)

Balanced Scorecard & BI

A teoria do Balanced Scorecard por Norton e Kaplan, ou BSC para os íntimos, teve um impacto significativo no mundo do BI. Talvez, aliás, seja essa a raiz da mistura corrente entre OI e BI. Eu estava lá quando isso estava acontecendo, e vou dividir com vocês um pouco das minhas histórias sobre aqueles dias loucos.

O Mundo Até Então

Até meados do ano 2000, o top em BI de usuário era um DSS conhecido pelo acrônimo EIS, de Executive Information System. O EIS era composto por um DW e uma ferramenta OLAP, organizados de tal forma que um executivo poderia enxergar a empresa inteira a partir do topo, da maior agregação, e descer, seguindo o caminho que desejasse, até o nível mais baixo, da linha.

Assim, por definição, todo executivo ganhava o seu centro de controle ou painel de monitoração empresarial. O apelo do sistema é que ele dispensava o usuário de conhecer programação de qualquer tipo, pois um EIS era voltado para o nível gerencial, o nível tático-estrégico da organização.

Ao redor do EIS haviam uma gama de opções, entre produtos e soluções.

Por exemplo, o usuário poderia pedir um gerador de relatórios (um produto), para construir as listagens que bem entendesse, e quando desejasse. Ganhou alguma notoriedade, nesta época, o slogan “entregar o dado certo, no momento certo, para a pessoa certa”.

E haviam as soluções de BI (e ainda hão), que são pacotes fechados com um propósito definido. Soluções como CRM (gerenciamento da interação com cliente), Churn Detection (detecção e prevenção de atrito, como em call centers) ou Credit Scoring (concessão de crédito automatizado), eram desenvolvidas com uso de Data Mining sobre os dados das empresas.

E não esqueçamos dos DWs, projetos sempre complicados e difíceis, e quase sempre operando aos trancos e barrancos. A tecnologia de DWs passou por três momentos de inflexão: a criação de bancos de dados em dispositivos de acesso aleatório, por volta de 1960, foi o primeiro. DASDs habilitaram a existência de Bancos de Dados Relacionais, sem os quais não seria possível construir um serviço viável de exploração de dados – antes usavam-se fitas magnéticas, e qualquer coisa mais complexa que uma listagem agregada era um transtorno. Depois veio o Modelo Dimensional, no início dos anos 90, que resolveu a vida dos usuários ao montar os dados de uma forma inteligível, apta à exploração por analistas de negócios. Ainda faltava resolver o acúmulo de dados, que seguia também aos trancos e barrancos, atendido parcialmente por Modelagem Dimensional. O advento do Data Vault, já na década 2000, resolveu essa parte. Hoje em dia, DWs são problemas só para quem está desatualizado desde 2003.

Enquanto Isso, Na Sala de Monitoramento…

Quando alguém decide que quer gerenciar uma empresa quando crescer, esse alguém faz uma faculdade de Administração de Empresas. Dentro dessa especialidade existe um sem-número de técnicas e teorias voltadas a entender como uma empresa funciona e como tomar decisões para que ela cresca.

Dentro de Administração de Empresas existem subconjuntos de conhecimento que tratam do monitoramento de uma organização, bem como o planejamento estratégico dela. O termo “balanced scorecard” surgido durante a década de 90 refere-se, de maneira geral, a uma técnica de monitoramento de rendimento (performance) que usa indicadores financeiros e não-financeiros. Essa técnica acompanha a execução das atividades por grupos de profissionais e as consequências dessas atividades. Por algumas coincidências, e pelo movimento do mercado, criou-se a percepção que Robert Kaplan e David Norton criaram o conceito, o que não é verdade, pois a técnica já existia antes. Eles apenas desenvolveram um sistema de gerenciamento estratégico que usa a idéia de um balanced scorecard como pino central.

Balanced Scorecard

A premissa de um Balanced Scorecard é que uma empresa pode monitorar a execução de suas estratégias acompanhando certos indicadores-chaves. O Balanced Scorecard do Norton e Kaplan é uma formalização desse conceito em uma metodologia que, automatizada com auxílio da Informática, cristalizou-se em uma solução chamada Strategic Management System (SMS), ou Sistema de Gerenciamento Estratégico.

Essa metodologia está explicada no livro deles, o The Balanced Scorecard: Translating Strategy into Action. Em tese, qualquer um pode implementar o sistema em sua empresa, a partir deste livro. Eu consegui encontrar uma companhia, ESM, que vende tal sistema, aparentemente uma encarnação oficial das teorias da dupla. Eis alguns screenshots dele:

Exemplo de painel ESM.
Exemplo de painel ESM.

 

Exemplo de mapa estratégico ESM.
Exemplo de mapa estratégico ESM.

O grande truque, que deu fama e fortuna aos autores, é saber que parâmetros monitorar e entender como esses parâmetros surgem das métricas geradas pela empresa, como essas métricas se ligam aos objetivos estratégicos.

Exceto por toda essa teoria, um SMS é, nada mais, nada menos que uma coleção de painéis de instrumentos – os famigerados dashboards – com dados coletados dos sistemas da empresa.

So The Story Goes…

O livro deles saiu em 1996, mas eles já vinham fazendo sucesso com essas idéias desde 1992, quando saiu o primeiro paper sobre o tópico.

O mercado por SMS estava aquecido devido ao sucesso da dupla e suas idéias. Implementações desses conceitos começaram a surgir, e a face mais visível desses sitemas era… o dashboard! Mas não acabava aí, não! Os dados que eram apresentados nesses painéis vinham, em geral, dos sistemas informatizados da empresa.

  • BSC é voltado para administração empresarial;;
  • BI também;
  • BSC usa dados integrados;
  • DW, uma subseção de BI, integra dados da organização;
  • BSC apresenta dados em visualizações bacanas;
  • BI também.
  • Etc.

Entenderam o caminho que a coisa tomou? Até parece que BSC e BI estão ligados intimamente, mas o fato é que nem de longe BSC é uma solução de BI!

  • BSC foca em dados correntes e suas relações determinadas a priori, em monitorar os dados da empresa para aquilatar o consistência do planejamento estratégico e sua execução. Os dados são atualizados muito frequentemente (um dia ou menos) e, em boa parte das vezes, apenas a variação dos indicadores é acompanhada, não dos dados mais granulares. O histórico dos dados em si não é capturado, e portanto não é usado;
  • BI é voltado para acumular dados históricos e analisá-los para descobrir suas relações a posteriori, em busca de entender o negócio. Dizemos que os dados são usados para tentar modelar, matematicamente, o funcionamento da companhia. Fala-se em previsão, em estimativas, em correlações previamente ignordas entre as variáveis etc. etc. etc.

Não são coisas estranhas entre si, pois ambos usam dados gerados em sistemas informatizados (BSC menos, BI mais), mas não são a mesma coisa, ou sequer parentes próximos.

Mesmo assim formou-se, no mercado de BI, a percepção de que BSC faz parte de BI.

Ok, vamos relegar essa parte e focar na questão “empresas vendendo BSC, o pão quente do momento”. Imagine o que aconteceu: empresas de BSC, como a tal da ESM mencionada acima, tinham lá o seu produto, que era uma novidade então.

E as empresas que vendiam BI, tinham o quê para mostrar como sendo BSC? Coleta de dados e apresentação de dados – e a teoria do BSC em um livro! Quando vendedores de BSC mostravam seu produto, a aparência, a parte visual era importante. Quando os fornecedores de BI seguiam essa trilha, o que mais aparecia para os clientes eram… Os dashboards!!

Conclusão

Não posso afirmar, categoricamente, que a tecnologia de painéis de instrumentos foi incorporada ao BI por “culpa” do BSC. Mas eu posso contar para vocês que ao visitar clientes interessados em BSC, eu, gerente de soluções SAS, vendedor de BI, era cobrado para mostrar os painéis da solução SAS para BSC. Era contra esse aspecto que a solução oferecida pelo SAS era comparada.

Eu nunca consegui emplacar uma venda de BSC pelo SAS. O produto de BSC da concorrência (não-BI) era bom o bastante para anular as vantagens do SAS (integração de dados díspares e flexibilidade nos painéis) e conseguir o pedido, mesmo sendo mais caro. Na minha opinião, olhando para trás, eu diria que a concorrência tinha uma implementação formal de BSC, completa e pronta, enquanto que o SAS apenas tentava surfar nessa onda, reempacotando seu produto com outro público-alvo diferente do público regular de BI.

Só que, até então, painéis não eram coisas de BI. Caramba, não tinha nem no catálogo do SAS, que tem tudo!

Por isso, na minha humilde opinião, dashboards entraram para o rol de recursos de BI por contaminação do mercado de SMS, do qual o BSC Norton e Kaplan é um ilustre membro. Dashboards não são melhor ferramenta analítica que um cubo OLAP ou um projeto de Data Mining, mas são excelentes meios para levar informação e oferecer visões completas – para apresentação dos dados.

É isso. Até a próxima. ;-)

OI vs BI – O Treinamento e o Rendimento

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

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

Cenário

Eis o caso:


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


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

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


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


Comentários:

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

Fazendo Ciência

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A interpretação desses resultados é feita assim:

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

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

Analisando a Eficácia

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Erro médio:

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

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

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

Agora Sim: OI vs. BI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


Segunda Diferença: OLTP <> Histórico

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


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


Terceira Diferença: Consistência

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


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


Conclusão

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

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

Retomando o post que deu origem à série, olhemos a tabela que separava OI de BI:

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

Em qual coluna se encaixa o caso mostrado? Vejamos:

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

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

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

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

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

Espero que tenha deixado tudo mais claro.

Até a próxima! ;-)

Novo Plugin Pentaho BA Server: Self Service BI

Semana passada, precisamente dia 21 de janeiro de 2016, meu grande amigo Gerson Tessler me ligou. “Cara”, ele veio falando, “você viu o plugin de self-service BI da SPEC INDIA?”

Eu tinha visto os dois até, para ser sincero, mas ainda não havia testado nenhum:

Os dois plugins da SPEC INDIA no Marketplace.
Os dois plugins da SPEC INDIA no Marketplace.

“Instala e me liga!” Ok, Gerson, fica frio, eu vou instalar. Que agitação, só um plugin…

Uau.

A primeira coisa que nós pensamos foi “deve ter uma licença limitada, que expira e depois precisa pagar para continuar usando”, ou então que tinha alguma pegadinha. Não era razoável supor que fosse gratuito, na boa, sem “letras miúdas” na licença.

O Self Service BI Plugin, da SPEC INDIA, é um editor de dashboards para o BA Server que imita o Dashboard Designer da versão enterprise do Pentaho. Sua qualidade mais notável é dispensar (quase) completamente qualquer tipo de conhecimento baixo nível para começar a usá-lo. Por exemplo, eu levei menos de 20 minutos entre instalar o plugin, fuçar um pouco e criar esse painel:

Meu primeiro painel com o plugin: facilidade análoga à versão enterprise.
Meu primeiro painel com o plugin: facilidade análoga à versão enterprise.

Em resumo:

  • Crie consultas OLAP com o Saiku, e salve-as;
  • Crie um novo pinboard acessando o novo menu Self Service BI. Pinboard é a gíria da SPEC INDIA para dashboards;
  • Usando a engrenagem no canto esquerdo superior do novo pinboard, defina o layout dos quadros do painel;
  • Em cada painel clique no ícone de lápis e selecione as consultas Saiku. Escolha o tipo de gráfico e salve;
  • Depois… mais nada, era só isso mesmo.

O resultado é um painel estático, mas mesmo assim, para quem, como eu, ainda não é fera em CSS e HTML, é um feito e tanto! E o plugin oferece muito mais recursos que só isso: prompts, gráficos independentes, parâmetros, consultas SQL etc. etc. Você também pode criar um pin individual e salvá-lo, para reaproveitar em outros pinboards. Na boa, é um avanço e tanto para a comunidade de usuários do Pentaho! É injusto comparar o trabalho deles com outros da comunidade, até porque o deles só foi possível graças aos esforços de muitos outros grandes personagens da comunidade, mas com certeza a SPEC INDIA estabeleceu um novo marco na história do Pentaho. É uma boa notícia saber que eles são parceiros da Pentaho!

Mas nem tudo são rosas – ou eram. O Gerson me procurara não só para mostrar como esse plugin era legal, mas também porque estava dando pau: os pinboards salvos não estavam abrindo. Conseguíamos criar um novo painel, configurá-lo bonitinho, mas ao gravá-lo algo acontecia e não dava mais para abrir o painel nem para editar, nem para rodar. Bug chaaato…

Bom, eu fiz o que qualquer cara sem noção faria: acessei o site deles, achei o botão “contact us” e mandei um e-mail, perguntando educadamente como eu poderia conseguir suporte. A resposta foi tri-bacana:

Ketul Sheth é um cara de ação.
Ketul Sheth é um cara de ação.

Sendo um sujeito dolorosamente franco, eu expliquei à ele que não daria para fazermos negócio:

A voz da verdade nunca fez caridade. Grande Barão Vermelho!
A voz da verdade nunca fez caridade. Grande Barão Vermelho!

E não é que o Ketul é mesmo um homem de ação?

Ele sugeriu um WebEx dia 25, que eu recusei porque era feriado em São Paulo, e sugeri o dia seguinte, 26/jan. Não deu: era feriado na Índia (Dia da República Indiana!) Acabou ficando para quarta-feira, 28 de janeiro, 8H30min em São Paulo, 16H30min na Índia.

Montamos o WebEx e a primeira pergunta que eu fiz, depois de agradecer profusamente, foi: porquê? Por quê criaram esse plugin? Uso interno? Vão vender?


“Nós vimos que, das opções livres atualmente à disposição, nenhuma era tão fácil de usar quanto o Dashboard Designer (enterprise), e resolvemos contribuir com a comunidade oferecendo esse plugin.”


:-O

Eles vão usar o plugin para entregar os próprios projetos e tal, o Ketul falou, mas a meta é mesmo entregar um novo plugin para a comunidade Pentaho.

Passado o choque, caímos no trabalho. Compartilhei minha tela com eles que – A MEIO MUNDO DE DISTÂNCIA, DA ÍNDIA – assumiram o controle e fizeram alguns testes. Ao final, salvaram um pinboard, que eu exportei do BA Server e mandei por e-mail para eles. Isso foi quarta-feira de manhã. Ontem, quinta-feira dia 28/01/2015, antes do meio-dia aqui no Brasil (quase 20H00min na Índia), veio este e-mail:

Hey, man! All done, man! Try it again!
Hey, man! All done, man! Try it again!

Arre égua! Duplo arre égua! Subimos o servidor novamente, atualizamos o plugin diretamente no Marketplace, rebootamos o BA Server e voi-là! Funcionou!

3.1 E Agora?

Eu sugeriria, a vocês que apreciaram o esforço deles, que instalem e testem esse plugin no seu BA Server. Se não pela curiosidade, então para não deixar de conhecer um excelente produto. Lembrem-se apenas que é uma das primeiras versões, e novos bugs ou problemas podem aparecer.

Se tudo der certo, por favor, visitem a página da SPEC INDIA e deixem-lhes uma notinha de incentivo, ou comentário de agradecimento ou pura e simplesmente um breve reconhecimento do trabalho deles. Se você não sabe inglês, não se grile: escreva em português mesmo e cole este link no começo da sua resposta https://bit.ly/1Trd9hM. É um post em inglês, aqui no blog, explicando que eles receberam uma nota de gratidão de alguém da comunidade brasileira de Pentaho.

Aqui tem dois vídeos para ajudá-los a testar o plugin:

Guys, keep the excelente job! We own you one! :-D

Review: Pentaho BA Cookbook

Packt Ed. has released on August 2014 a new member of their Cookbook library, by Sérgio Ramazina: Pentaho Business Analytics Cookbook, first edition.

The today aging Pentaho Solutions was the first authoritative source of Pentaho Platform information, but it was far from practical no matter how good. Even those already into the platform had to scratch their heads a little to translate all that knowledge into action. A lot of us simply need much more than was made available. We needed pretty-a-porter how-to’s with which solve our daily paings with each Pentaho Suite component. And that’s the niche Packt has been neatly filling out: they are running into the HUNDREDS of published Cookbooks, on a lot of topics. Yeah, I know, it is starting to sound an unintended pun “we’ve got IT covered.” <chuckles>

This new book covers a lot of the newest Pentaho Suite version (v.5) recipes. Except for PDI (which already featured a dozen Packt books), the book comes into almost everything else: BA Server, Metadata Editor, Schema Workbench, PRD, and some Enterprise Edition operations, besides a bit of C*Tools.

The Good

It is a relativelly complete compendium of everything that deserves atention on the Pentaho Plaform:

  • BA Server: how to set up data sources (JNDI, Analysis, Metadata etc.), how to tie it to an LDAP server and manage users/roles;
  • Metadata: it is the first place to seriously show how to use “concepts”, an importanta metadata ahn… concept. Also, there are a lot of important tips on metadata modeling, like complex join and calculated fields;
  • OLAP: how to create cubes with Schema Workbenche, with calculate members, how to publish it and generate OLAP views with Saiku;
  • PRD: very complete, with recipes to build prompts, sub-reports, charts (including the tricky sparkline), besides having a PDI transformation for report source.

Were it not enough Mr. Ramazinas goes on to show recipes on less searched for things like interface customization and C*Tools (CDE) introduction, always with hands on, detailed examples.

Raising the bar, the book offer recipes on the Pentaho Enterprise Edition. Although Pentaho Community Edition abbility to offer everything the Enterprise Edition does, Enteprise Edition adoption is on the rise and a lot of its resources rest unusedor not fully explored by its customers. Being usefull for the sheer amount and coverage of the recipes, the book becomes even more interesting for the EE recipes it brings:

  • Analyzer: operations with OLAP client;
  • Dashboard Designer: dashboard editing made easy;
  • Interactive Report: ad hoc reporting, the heir to the gone WAQR;
  • Mobile: the inedit iPad and smart phones interface.

More than just helping those with Pentaho EE, the book opens it to those who have not bought it. IMHO, this is an excelent opportunity to get acquainted with Pentaho EE, a high quality yet cheap (very cheap for what it offers!!) versatily BI product.

Also, more than offering an extensive list of how-to’s, Packt’s cookbook format makes it for a very understandable experience for it tells not only how to do each of its recipes, but also why it works and how it does and what else there is to see. Every recipe has at least an image. Even in the grayscale Kindle all of them have a good look.

For its detailed content, its broadness (lots of things on both CE and EE) and its usability, Pentaho BA Cookbook is another must-have volume on the Pentaho Platform practioner library, and even more for a casual dabbler.

The Bad

Ok, the book shines – it is very good, have no question about it. But…

  • Kindle (Touch – my device) version (the one I reviewed) does not stop at the chapters divisions when one sweeps the finger vertically across the screen. Instead it jumps to the beggining. Annoying;
  • Some recipes are too trivial. If the user really needs somebody telling it, then he also needs help on how to setup the software, which the book does not do – and of course not! Recipe books show recipes, now how to cook or who to buy and setup a cooktop;
  • I missed some important recipes, like how to setup BA Server with other databases. There are instructions on how to do that at Pentaho’s Infocenter. However there are some other recipes which have Infocenter how-to’s too, but they’re in the book nonetheless;
  • I missed performance tunning recipes, like setting an external cache or turning on and using aggregated tables;
  • The subjects does not look like well separated. For instance, the schedulling is part of the Pentaho BA Server, but it makes a full chapter in the fartest corner of the book, chapter away from the BA Server chapter. Maybe it would make more sense to have one after another, if not totally made into a single chapter;
  • Plugins: Pentaho Marketplace’s plugins are growing by the day, but the book says little about them. It only briefs mention two of them (Saiku and Logs), besides internationalization.

None of those things diminishes the book value, however.

The… Italian

Packt is a trully global enterprise. Their writers come from all over the world and in fact most of them write in a foreign language – English. Well, Mr. Sérgio Ramazina is itallian and as every good latin (just like me, brazillian), tends to thing in a more literall English. Reading the book you almost can hear his accent in phrasings like “This is the idea that stays behind the concept of(…)” (locus 2028.) The English-born speaker would rather have a simpler “(…) the idea behind the concept(…)” Mr. Ramazina quite used up his quota, but it never impairs the reading. It is kind of easier for me, in fact, because as a Brazillian I also tend to think on that style of English. Maybe it might be stranger for a, say, Japanese reader (as it is a bit awkward for me to read Japanese writers in English.)

Anyway, I just though of making a note so you know what to expect. The book is good and the reading flows ok, just a bit… creatively. <grin>

Conclusion

Have installed Pentaho BA Server 5 and know not where to begin with? Were commited to migrate a legacy 4.8 BI Server to 5? New to Report Designer 5 or banging head against the wall with some JNDI configuration and metadata editing? Wait no further, Packt’s new Pentaho BA Cookbook is your book: a wealth of immediatelly usefull how-to’s (recipes), well layd-out and explained in details. Lots of topics on both the BA Server and its clients, as well as some topics on the Enterprise Edition. Even if it does need some improvent, this is the book to go after for Pentaho Suite 5!

O que é Data Discovery?

Ouço falar de Data Discovery há alguns anos. Estando na indústria de BI eu vejo como minha obrigação saber, no mínimo, o que é qualquer uma das buzzwords. Como eu já tentava descobrir o que era DD “de verdade” há mais de ano, eu decidi que daria cabo da tarefa de uma vez por todas. Não estava mais aguentando ouvir DD em todo canto sem saber o que era.

Neste um tanto quanto longo demais post eu vou relatar a minha jornada em busca desse conhecimento. Não é um artigo científico, não foi uma busca sistemática. Foi mais uma luta para achar alguma informação, anormalmente rara na minha opinião.

Definição? Eu Acho que Não…

Se você procurar, com o Google, Data Mining, Data Warehouse ou mesmo BI, vai achar uma renca de definições. Data Discovery, por outro lado, é um termo curiosamente “ralo”. Veja o screenshot do Google para Data Discovery:

Googling por Data Discovery: é só isso??
Googling por Data Discovery: é só isso??

Nota: que pese em defesa do DD que o Google já sabe todas as minhas preferências e enviesa todas as minhas buscas. Tente na sua máquina, em casa e no trabalho, e me mande um screenshot dos resultados. Tenho curiosidade em saber quão viciadas estão minhas buscas.

Para comparar, veja os resultados para Data Mining (figurinha carimbada) e para Anchor Modeling (coisa praticamente alienígena):

Um termo histórico, a busca por Data Mining traz muito mais resultados.
Um termo histórico, a busca por Data Mining traz muito mais resultados.

 

Sabe o que é Achor Modeling? Um termo desconhecido para a maioria, mas não para o Google. Dica: o último link é muito bom!
Sabe o que é Achor Modeling? Um termo desconhecido para a maioria, mas não para o Google. Dica: o último link é muito bom!

Sentiram o drama? Bom, vamos adiante. Acessei o verbete Data Discovery na Wikipedia para ver apenas isso:

... e isso é tudo que há sobre DD na Wikipedia.
… e isso é tudo que há sobre DD na Wikipedia.

Eis a definição inteira:

(1) Data discovery is a Business intelligence architecture aimed at interactive reports and explorable data from multiple sources. According to Gartner “Data discovery has become a mainstream architecture in 2012”.

Definition

(2) Jill Dyche calls Data discovery ‘Knowledge discovery’ and defines it as: “[…]the detection of patterns in data. […] These patterns are too specific and seemingly arbitrary to specify, and the analyst would be playing a perpetual guessing-game trying to figure out all the possible patterns in the database. Instead, special knowledge discovery software tools find the patterns and tell the analyst what–and where–they are.” [2]

As the current (2013-2014) SAS Vice-President for Best Practices her definition not surprisingly resembles the definition of Data mining:

“Data mining (…) an interdisciplinary subfield of computer science, is the computational process of discovering patterns in large data sets involving methods at the intersection of artificial intelligence, machine learning, statistics, and database systems. The overall goal of the data mining process is to extract information from a data set and transform it into an understandable structure for further use. Aside from the raw analysis step, it involves database and data management aspects, data pre-processing, model and inference considerations, interestingness metrics, complexity considerations, post-processing of discovered structures, visualization, and online updating.”

It can also be referred to as Business Discovery.

De quebra ainda achamos a definição de Business Discovery: segundo esse artigo, é a mesma coisa.

Vamos analisar as duas partes destacadas.

(1) Data discovery is…

Em tradução livre, DD é uma arquitetura de BI voltada para relatórios interativos e dados exploráveis a partir de várias fontes.

Ou seja, em primeiro lugar, DD não é um produto mas uma arquitetura. Absolutamente nenhum detalhe, por mais geral ou genérico que seja, é dado sobre essa arquitetura no restante do artigo. A busca no Google já não trouxe muita coisa, mas uma busca por architecture data discovery traz menos coisas ainda:

Outra tentativa: se DD é uma arquitetura, será que agora eu acho mais informações? Hmm ...
Outra tentativa: se DD é uma arquitetura, será que agora eu acho mais informações? Hmm …

A segunda parte da frase, “relatórios interativos e dados exploráveis de várias fontes” dificilmente é alguma coisa particular à Data Discovery. Afinal, a ferramenta mais básica de BI é um gerador de relatórios. O conceito mais básico dentro de BI é um DW, que é por natureza “dados exploráveis de várias fontes em um único lugar”.

Conclusão: nenhuma. É, nenhuma! Por este trecho da definição na Wikipedia, DD é só uma buzzword, uma repaginação de “relatórios em cima de um DW”.

Mas o artigo da Wikipedia não acaba ali. Vejamos a segunda parte.

(2) Jill Dyche calls Data discovery…

Jill Dyche chama Data Discovery de ‘Descoberta de Conhecimento’  e define isso como: “[…]a detecção de padrões nos dados.” Uma nota de rodapé aponta para um artigo na Harvard Business Review no qual consta essa definição. Ao final deste artigo descobrimos quem é Jill Dyche:

Jill Dyche

Jill Dyché é a Vice-Presidente de Thought Leadership no SAS, onde ela é responsável por estratégias para clientes-chave e análise de mercado nas áreas de governança de dados, BI, MDM e BigData. Ela escreveu três livros sobre o valor de negócios trazido pela informação.

O culpado da tradução atroz sou eu mesmo, e por isso aqui vão algumas explicações:

  • Thought Leadership é algo como lider intelectual, no sentido de quem pensa muito e lidera (não como o Cérebro gostaria;)
  • Valor de Negócios trazido pela informação: o quão importante um conhecimento (uma informação) é para o negócio, e não o quanto a mais se fatura graças a uma informação. Mais do que saber para qual cliente vender, mais informação sobre o negócio traz mudanças e mais negócios.

A mulher não é fraca, não. Poucas personalidades em TI tem a prerrogativa ou a sorte de definir, sozinha, uma buzzword. Ela está no mesmo nível do Bill Inmon, Pai do DW: Jyll Diché, Mãe do Data Discovery.

Bom, mas e então: o que tiramos desta definição?

De novo: nada. Sim, nada. Porquê? Oras, caramba, por que “a detecção de padrões nos dados” é a mera definição de Data Mining!

Data mining (…), an interdisciplinary subfield of computer science(…) is the computational process of discovering patterns in large data sets(…)

Conclusão: uma vice-presidente do SAS (a multinacional de BI,  uma empresa Thought Leader em Data Mining) define Data Discovery como Data Mining. Ou seja, uma nova buzzword para (re)definir uma antiga buzzword.

Na verdade, esse é um movimento clássico do SAS. Periodicamente eles colam um novo jargão para tentar se descolar da concorrência. O SAS tem um grande problema de propaganda (eles não fazem, e se orgulham disso) e por isso volta e meia se saem com uma dessas. Eu me lembro de um GUSAS (2009, acho) em que eles vieram com essa de BA – BI estava morto, o lance agora seria BA, Business Analytics.

Mais Alguém?

Ok, então em termos de definições formais isso é (praticamente) tudo que temos: um artigo circular da Wikipedia montado sobre um post de uma VP do SAS.

Eu venho repetindo essa pesquisa por definições formais há mais de um ano, e sempre chego mais ou menos aos mesmo artigos e aos mesmos lugares, mesmas pessoas e mesmos conceitos. Pode ser um erro de vício meu, pode ser incompetência minha em usar o Google,  mas se um profissional do ramo repetidamente procura por um assunto, fuça e nunca encontra muito mais que só isso, então provavelmente isso é que o tem para ser encontrado. Mas nem de longe é tudo que existe.

Há outra fonte de informação e conhecimento sobre assuntos de BI: os próprios fornecedores. Essa é uma fonte que não pode ser menosprezada, já que frequentemente novos conceitos surgem de necessidades do mercado que um fornecedor foi inteligente o bastante para identificar e atender. Isso quando uma encomenda direta não é o motivador. Um caso recente das duas situações é Ruby (encomenda direta) e Rails (um resultado colateral.)

Quem é famoso por Data Discovery? Tableau e QlikView me vêem imediatamente à cabeça. Eu também bati um papo com o CEO da Panorama sobre o Necto, que na minha opinião entra na categoria.

Depois eu forcei umas buscas com o Google e achei também SAS, MicroStrategy, Teradata, IBM e SAP (Lumira.) Também achei a Hitachi, mas era um “nada a ver” – coisa de encontrar arquivos em NAS.

Não posso examinar tudo, pois mataria vocês de tédio. Vou destacar os mais importantes (de novo, na minha opinião.) O critério para escolher o mais importante foi bem prático: que empresa se marketeia como “de Data Discovery”. Depois eu vou comentar um pouco sobre os outros fornecedores.

Aviso: tudo que virá a seguir é uma FORTE manifestação da minha opinião pessoal.

Não é uma análise técnica, e não necessariamente eu endosso qualquer um dos produtos a seguir, muito menos detrato-os. Tenho minha cabeça formada e respondo por minha opinião. De novo, este post relata minha saga para tentar entender um conceito, e por isso é uma história totalmente enviesada por meus pontos-de-vista. Se não gostar de algo, esteja à vontade para reclamar.

QlikView

Eis o Thought Leader em DD, na minha opinião. Pelo que eu testemunhei nestes últimos anos, foi a QlikTech que lançou a moda e surfou (e ainda surfa) essa onda. Eles têm um excelente produto, tanto que são adorados pelos clientes. Tive oportunidade de ler o livro QlikView 11 for Developers e ganhei algum entendimento de como ele funciona.

O que eles têm a dizer sobre DD?

Business Discovery is a whole new way of doing things that puts the business user in control. Unlike traditional BI, where just a few people are involved in insight creation, Business Discovery enables everyone to create insight. It’s about workgroups, departments, and entire business units having access to the data they need to make better decisions. With QlikView, businesses can take insight to the edges of their organization, enabling every business user to do their jobs smarter and faster than ever. QlikView enables all users to create tailored insights that meet their unique business needs and timelines.

Putz, acho que chegamos tarde demais: não existe mais DD, agora é Business Discovery. Bom, vai ter que servir. Aqui tem uma mensagem interessante: nada sobre gráficos bonitos e rápidos, mas sim sobre todos na empresa poderem acessar os dados. No final da página tem uma lista de white papers, e um deles é o pote de ouro: um manifesto sobre Business Discovery!! Eles realmente encamparam o assunto!

Só que eu não consegui baixá-lo do site. Uma busca ligeira no Google e voi-lá, manifesto BD! A mensagem é muito boa:

  • Informação pode mudar o mundo;
  • Eles querem tornar o nosso trabalho mais fácil;
  • Negócios estão sendo impactados por pessoas;
  • Merecemos mais que uma bela interface;

Graças ao que eu li no livro QV 11 for Developers eu acho que consegui entender parte da mensagem. Se eu entendi corretamente, BD (que deve ser o mesmo que DD) é uma ferramenta de BI com gráficos beirando o divino de tão bonitos e animados, que busca os dados diretamente dos sistemas de origem.

Parece que o acesso direto a dados é algo importante, mas definitivamente o lance são os gráficos bonitos. Eis um excerto do manifesto, no qual eu destaco em negrito as menções a “coisas bonitas e legais”:

QlikView (…) seductively slick and intuitive dashboards are easy to navigate and fun to use. We support rich colors and robust graphics. We encourage data to speak for itself in vivid shapes and colors. We’ve got style in spades. (…) QlikView is gorgeous — but it’s also genius. We bundle the best of Business Discovery into one application. It allows you to access all your data sources, create your own dashboards, ask your own questions, and get answers instantly from a blazing fast associative technology. Untethered from traditional business intelligence, you can slice and dice data and drill in, out, up, down, and sideways. You can tweak, improve, improvise, and innovate to your heart’s content.

Curioso, não? Segundo o manifesto, sem os fios que te prendem ao BI tradicional (o que é isso???), você pode fatiar e picar furar e deslizar e dançar nos dados como quiser. Curioso porque essa é a promessa do OLAP, é velha, já foi feita por muitas outras empresas e não tem nada, realmente, de novo. Agora, o que é BI tradicional? Seria muito legal se eles fossem mais específicos ou mais claros. Enfim, o manifesto é deles, eles se manifestam como quiserem.

Bom, o suco até agora é: DD já era, o lance é BD, que é melhor que BI tradicional porque é mais livre.

Talvez Business Discovery não seja algo tão diferente: se agora o QV é uma ferramenta de BD, um dia foi de BI antes de ser de DD. O site QuickIntelligence registrou o momento em que a QlikTech tentou se desligar de BI abraçando DD em um post de abril de 2011:

QlikTech has recently shifted their marketing message very slightly to position QlikView as a Data Discovery tool, moving away from the Business Intelligence tag.

Eu não estava lá quando isso aconteceu, mas se o post acima for minimamente verossímel (e tudo indica que seja), a ferramenta não parece ter sofrido mudança, mas apenas um “reposicionamento” através de “uma mudança de mensagem de marketing”. Em miúdos: o QlikView “virou” uma ferramenta de DD só porque eles passaram a se definir desta forma. Talvez a mudança para Business Discovery seja, na verdade, só uma nova mensagem de marketing.

Resumindo: se QlikView é Data Discovery, então Data Discovery e Business Discovery 1) são a mesma coisa e 2) DD diz respeito a montar belos e atraentes e divertidos gráficos com os dados. De acordo com o livro mencionado anteriormente, porém, acessar os dados diretamente não é um objetivo, mas antes uma possibilidade: se precisar, o QV acessa diretamente, mas o ideal, mesmo, é ter um modelo dimensional com os dados prontos para consulta.

Tableau

Não conheço produto. O descobri porque toda vez que procurava DD no Google, anúncios do Tableau apareciam – daí concluí que eles se posicionam como ferramenta de DD.

O site é muito bonito, e todo alinhado com as buzzwords do momento:

Tableau é o bicho! Buzzwords, Buzzwords, Buzzwords! (Cadê o "belos gráficos"??)
Tableau é o bicho! Buzzwords, Buzzwords, Buzzwords! (Cadê o “belos gráficos”??)

Clicando em Products, a mensagem abaixo da bela figura diz:

Our breakthrough products let you create rich analyses and share your insights with colleagues in seconds.

Um termo diferente: “ricas análises”. É bem diferente de “ricos gráficos” ou “belas análises” – intuitivamente eu diria que sugere análises caprichadas e bem feitas. Junto a isso, a vantagem de “compartilhar com seus colegas em segundos”.

Outros termos que se destacam lendo mais a página de produto aparecem Fast, Easy, Any Data, Share. Notadamente nenhuma menção a belos gráficos. Remarkable!

Eu li as páginas dos produtos, diagonalmente, e eles sempre batem na mesma tecla: análises sofisticadas (ricas). O produto existem em versões desktop (incomum – e com uma opção gratuita, chamada Public) e web (com uma opção SaaS, chamada Online) e em nenhum lugar existe uma única menção a coisas bonitas e atraentes.

Eu queria dizer o Tableau é o “me too” do QlikView, ou seja, a empresa que viu o sucesso do vizinho e decidiu pegar o vácuo, mas não consigo. Eles não usam a mesma chamada de vendas, e nem sequer as mesmas buzzwords. Se bem que o QlikView não fala muito em nuvem nem análises ricas…

Enfim, do Tableau eu não consegui aprender nada sobre o que porventura seja Data Discovery.

Necto

Yeah! Acertei em cheio! Olhem só a frase de abertura:

Best of Enterprise BI and Visual Data Discovery – Combined

Se QlikTech é Business Discovery (== Data Discovery.newBuzzword(); ), com um certo desprezo pelo BI tradicional (??), o Necto é o melhor da soma dos dois! Talvez eles tenham alguma opinião ou definição sobre DD. (Opa! Eles disseram DD? Putz, também ficaram para trás… <grin>)

A Panorama é a alegria do repórter de BI. Da mesma página linkada acima:

Panorama Necto is advancing Business Intelligence 3.0 to the next level, bringing together the very best of Enterprise BI with Visual Data Discovery, providing enterprises with new ways to collaborate and create unique contextual connections.

Necto 14 is the first BI solution to provide business users with personalized, intuitive, and interactive analytics, delivered through a highly visual and understandable infographic format. Business users can use Panorama Necto 14’s self-service data discovery and visualization capability to uncover hidden insight, present vital data, and track performance using interactive infographics that dynamically reflect business changes.Necto 14 improves every step of your business decision making process.

BI 3.0? Enterprise BI, formato infográfico altamente visual, self-service Data Discovery!!! MEUSANTODEUSÉMUITABUZZWORDJUNTA!!!! (ROFL!) Se eu tivesse pintado as buzzwords de vermelho ao invés de fazê-las negrito, o texto acima pareceria a bandeira do Flamengo!

Uma coisa que eu gostei é que eles escrevem muito. Há vários textos e white papers sobre o que eles fazem, o que é BI 3.0 e porque são diferentes. Entretanto, eles tomam DD como uma coisa já assimilada e nunca discutem o conceito em si.

Por outro lado, tem tanta buzzword em toda essa informação que fica difícil dizer do que eles estão falando. Eu tive chance de trocar umas palavras (via LinkedIn) com o CEO deles, mas o que realmente me ajudou foi assistir alguns vídeos, especialmente aqueles nos quais eles demonstram a visão do produto, mas não consegui achar o mesmo vídeo de novo.

A idéia é boa: somar Facebook com QlikView e conseguir gente para analisar um problema via uma ferramenta colaborativa.

Enfim, segundo eles, Data Discovery é o bicho se for com o produto deles, claro, já que nenhum outro oferece tantas coisas legais em tão pouco espaço de tela. (Still ROFLing from BW OD!) Mas nada sobre o que é DD. Ou seja, “better me too”: quis fazer um QlikView melhor que o QlikView e inventou outras coisas. Gostei da idéia de times adhoc para análises de dados. Me parece pouco útil para empresas de médio porte ou menores, mas pode muito bem ser o futuro para empresas de grande porte. Vou ficar de olho!

Os Outros

Pausa para uma piada:

Um dia um grande especialista em vermes foi convidado, por um zoológico, para fazer uma palestra sobre elefantes. A oportunidade era boa, mas ele não sabia nada sobre elefantes. Ele aceitou, e sua palestra começava assim: “Os elefantes são grande animais, que possuem quatro membros, uma tromba e uma uma cauda, semelhante a um verme. Os vermes subdividem-se em…”

Moral: todo mundo só fala do que sabe. ;-)

Os fornecedores a seguir lembram um pouco essa piada: eles já estavam no mercado quando a moda pegou, então eles deram um jeito de entrar nela. Os destaques vão para a Teradata, que patrocina um livro, DD for Dummies, masapesar disso o produto não tem uma única menção a “Quickly build beautiful visualizations with just a few clicks”, e para a SAP, gigante alemã do ramo de ERPs, cujo produto inteiro é só “Quickly build beautiful visualizations with just a few clicks”.

SAS

A empresa de BI por excelência, e a cunhadora do termo. Tem um produto específico chamado (adivinhe!) SAS Visual Data Discovery. O sales pitch (a chamada de vendas) é “acesso visual às avançadas capacidades analíticas do SAS, que permite interagir visualmente com dados para clarear o entedimento e alavancar a ação”. Um clássico, sem dúvida. Deve ser caro para dedéu, como tudo do SAS, mas eu não apostaria no SAS contra o QlikView. Não que o SAS não deva ter um bom produto, mas o foco do SAS – a especialidade dele – é solução de BI (que é o que realmente interessa), e por isso todos os outros produtos existem para oferecer competição nos nichos.

MicroStrategy

Não existe um produto chamado explicitamente de Data Discovery. Procurando por microstrategy data discovery no Google voltam alguns links que levam para esta página. Nela a MicroStrategy mostra um produto chamado Visual Insight e tem a seguinte apresentação inicial:

A Faster Way to Visualize Your Data

MicroStrategy Visual Insight empowers you to discover insights from your data using compelling visualizations. Quickly and easily explore any data contained in personal spreadsheets, databases, or Hadoop. Investigate and analyze the data further by defining new metric calculations, zooming into details with filters, and color-coding the results with thresholds. Create multiple visualizations to get additional insights and perspectives that enhance data comprehension. Combine your findings into a dashboard you can save and share with your colleagues.

Eis os elementos clássicos (ou típicos) da mensagem de DD: obter insights, visual atraente, rápido e dados vindos de qualquer tipo de fonte. Ou seja, mais um “me too”. O curioso, aqui, é que a MicroStrategy tradicionalmente faz exatamente isso – belas visualizações de dados, com alta performance. A parte “de qualquer tipo de fonte” é universal, já que qualquer ferramenta faz isso se jogada sobre um DW. Não sei se ele oferecem Data Blending (outra buzzword – mas isso fica para outro post.)

Repare que, ao contrário do SAS, não existe menção a funções analíticas sofisticadas ou avançadas – só visualizações e gráficos bonitos, rápidos e avançados.

Finalmente, eles oferecem uma lista de outras fontes de informação, muito curiosa:

  • Whitepaper: Checklist for Achieving BI Agility
  • Whitepaper: Enabling Data Discovery
  • Whitepaper: Three Reasons Why Data Discovery Falls Short (segundo eles, DD é útil, mas não é tudo)
  • Webcast: 7 Steps for Achieving BI Agility (que inclui um caso de DD com MicroStrategy)
  • Webcast: A Guide to Governed Data Discovery

Hmm… Eles entraram na onda ou não??

Teradata

O produto da Teradata, a empresa de big data antes do BigData, dos bancos de dados gigantescos e de altíssima performance (não tem tera no nome à toa) chama-se Aster, que oferece “poderosos insights através de uma solução integrada, otimizada para todos os dados, múltiplas análises e velocidade, com um esforço mínimo”. Não achei que o Aster responde por DD, mas como tanto via Google quanto via search field, os resultados são iguais, entendi que essa é a mensagem que a Teradata quer passar. Na minha opinião, faltaria a parte de visualização, mas ei, talvez DD não tenha mesmo nada a ver com visualização.

IBM

Tudo com a IBM é tão vasto, completo e complexo que até buscar produtos de DD deles, no Google, é uma tarefa difícil. O primeiro site que eu encontrei, depois de algumas tentativas, foi o VizWorld. O autor do post discute a nova oferta de produtos da IBM para DD na nuvem, e menciona um tal de projeto Neo, em beta ainda em novembro de 2013. Hm, sei, projeto Neo. Nem fui atrás.

Tentei o Google de novo e fui para um resultado que eu dispensei inicialmente: InfoSphere Discovery – eu confundira com WebSphere. InfoSphere é a linha de BI da IBM. Cavando um pouco cheguei a muitas outras coisas, mas em resumo, se existe DD para a IBM, ela se resume em três coisas: visualization, visualizationvisualization (Balmer ficaria orgulhoso.) Eles tem um motor de visualização adaptativa (RAVE), uma comunidade de especialistas de visualização (Many Eyes) etc. etc. etc.

E tem o Cognos, que a IBM comprou há algum tempo. Diferentes nomes, mesmas funções.

Agora eu me lembro porque eu nunca vi nada de BI da IBM – é tudo tãããooo difícil e abstrato…

SAP

SAP é outro mundo do tamanho da IBM. Eles têm produtos próprios de BI, relatórios, DW etc. Entre outras coisas, eles compraram um dos antigos nomes de BI, o Business Objects (BO.) Mas eu fiz uma pesquisa no Google por SAP data discovery e não veio nada disso. Veio um tal de SAP Lumira. Eis o que aparece no site deles:

Quickly build beautiful visualizations with just a few clicks. Combine data sources and get the big picture and granular details together. Visualize large volumes of data without having to sacrifice performance. Maximize data knowledge and drive immediate outcomes.

Preciso dizer mais? “Big Bad German Business Me Too”.

Excel

A Microsoft não reposicionou o Excel como ferramenta de BI, mas no fundo o Excel é o proverbial “lápis e papel” de BI. Excepcionalmente versátil, imensamente útil, o Excel é a ferramentra de BI por excelência. É nele que baixamos os dados para “fazer uma contas e ver se os números estão batendo”. Ele está muito longe de ser capaz de oferecer uma solução de BI, mas em princípio, está tudo lá.

Eu decidi incluir o Excel na lista porque a QlikTech o faz parecer uma ferramenta de DD: ele pode acessar uma enorme gama de dados e produzir fácil e rapidamente uma gama de boas (e até belas) visualizações de dados.

Claro que eu estou usando a palavra Excel como usamos Bombril: tanto poderia ser o Calc, do LibreOffice, quanto o próprio Excel. A categoria é Planilha Eletrônica. Mas ninguém compra palha de aço Brilhante – compramos Bombril mais barato!

Pentaho

Rapaz, a Pentaho é outro SAS. Tem muita coisa, e faz tudo mas (curiosamente) resolveu não investir no jargão DD. Eles criaram o deles (ah, tão SAS…), Data Blending (que eu também estou apanhando para captar, mas enfim, o problema aqui sou mesmo eu – ainda não parei para ir atrás.)

Seguindo a definição da QlikTech, por outro lado, o Pentaho BI Server EE é uma ferramenta de DD pois facilmente produz belos gráficos a partir de qualquer fonte de dados, sem intervenção do departamento de TI. O Pentaho CE também pode fazer isso, mas dá um pouco mais de trabalho. Além disso, também acessa qualquer fonte de dados. (Banco de dados 100% em memória não foi mencionado, mas o Pentaho também pode usar um se precisar.)

Finalmente, podemos juntar uma ferramenta de webmeeting, como o BigBlueButton ou OpenMeetings, para ter os times adhoc. Se o Pedro conseguir trazer para o CDE a facilidade do Pentaho EE Dashboard Designer, então o BI Server poderá oferecer infográficos adhoc. Isso completaria a visão de BI 3.0 da Panorama. O que também é uma opção para qualquer outra ferramenta. Nada mal.

Conclusão

O que é Data Discovery? Na minha opinião:

  1. Segundo a Wikipedia, é só uma nova buzzword do SAS, criada para substituir Data Mining;
  2. Segundo o mais importante player da área, a QlikTech, é uma ferramenta de análise de dados capaz de gerar belos gráficos;
  3. Segundo os outros fornecedores, incluindo a Pentaho, é folder fodder – só encheção de linguiça.

Por enquanto, a minha despretenciosa e ordinária pesquisa – a que qualquer um poderia fazer – chegou à conclusão que Data Discovery se trata de um termo específico da área, criado para diferenciar um fornecedor de outro no lotado mercado de ferramentas de BI. Em jargão castiço, Data Discovery é só uma buzzword.

Por inferência, a mesma conclusão espalha-se para Business Discovery.


A Seguir: O Que É Data Discovery, Parte 2 – Discussões no LinkedIn

Ok, então eu esgotei o que a minha parca competência de googlador profissional consegue me trazer. É hora de jogar a toalha e buscar o conselho dos meus pares da indústria de BI. É hora de postar a mesma pergunta no LinkedIn.

Semana que vem eu publicarei a resenha do livro Pentaho BA Cookbook, e depois (talvez) um post sobre o que destaca uma solução de BI de uma mera ferramenta. Daí, na semana seguinte, se eu conseguir, eu publicarei a segunda parte.

Tentem não me linchar – eu estou só compartilhando os meus pensamentos sobre a aventura que tem sido essa busca. Nada aqui tinha a menor intenção de ser minimamente formal ou definitivo, nem elogiar ou detratar ninguém. Se você discorda de algo que eu escrevi, é bem-vindo para comentar educadamente.

Até lá!

O Que Leva à Alta Performance?

Michael Porter, da Harvards Business School, diz que o rendimento de uma empresa é empurrado por dois fatores: estratégia e execução.

Phil Rosenzweig escreveu em seu livro The Halo Effect (com a tradução Derrubando Mitos) que, se isso é verdade, então tocar uma empresa com sucesso é uma coisa arriscada pelo simples fato de que nada dá a menor garantia que escolheremos sempre a estratégia vencedora, ao invés de alguma outra estratégia furada.

Não bastasse a dificuldade na escolha da estratégia, a execução dela também é um desafio de porte semelhante. Coisas que funcioaram para uma empresa não necessariamente vão funcionar para outra. Coisas que deram certo no passado ou em outro mercado, podem não dar certo agora, para sua empresa. Ou seja, a execução é algo que também depende de sorte e de alguma experimentação. Claro que existem coisas que são atemporais e independente de mercados ou indústrias – gestão de pessoas, finanças, estoque, algumas automações etc. Uma empresa depende de tantos processos e de tanta gente para funcionar que uma parte dela, com certeza, será particular ou diferente do restante.

Não sei se consegui me fazer entender, e por isso aqui vai o resumo:

  • Duas das maiores e mais afinadas mentes científicas de nosso tempo argumentam que o sucesso de uma empresa depende de sua estratégia e da execução dessa;
  • Adotar uma estratégia é igual a descartar TODAS as outras estratégias possíveis;
  • Não é possível saber de antemão qual estratégia vai dar certo, e qual vai dar errado;
  • Implantar (executar) essa estratégia é algo que depende de conhecimento, experimentação e sorte.

Melhorou? Leiam o livro do Rosenzweig para uma iluminação maior, mas se você acha que entendeu a lista acima, beleza, consegui o que eu queria. Próxima pergunta:

Como Escolher uma Estratégia?

O Rosenzweig discute isso brevemente. Resumindo, não dá para competir com todo mundo, em todos os mercados, oferecendo todos os produtos para todos os clientes. É preciso fazer escolhas, é preciso tomar decisões, como por exemplo:

  1. Em que mercado vamos atuar?
  2. Que produto vamos oferecer?
  3. Contra quem vamos concorrer?
  4. Vamos vender por menos que a concorrência, ou cobrar um prêmio por mais qualidade/conteúdo/rendimento/etc?
  5. Quanto os clientes estão dispostos a pagar?

Como Executar a Estratégia?

Larry Bossid disse que “Nenhuma estratégia entrega resultados a menos que convertida em ações específicas.” Uma vez que a estratégia foi escolhida, a execução precisa ser suficiente e isso implica em fazer mais escolhas. É irreal pretender executar 100% das atividades possíveis e ter 100% de qualidade em 100% das vezes. É preciso escolher no que investir tempo e recursos, e decidir que atividades serão deixadas de lado ou terão menos atenção.

A diferença entre a execução e a estratégia é que a estratégia depende muito do que está fora da empresa, e a execução depende quase que totalmente do que está dentro da empresa.

Ou seja, se a sua empresa ainda não existe, se ela é só um Plano de Negócios, você precisa de dados gerados por outrem. Você não tem nada, e precisa pesquisar tudo. Você ainda não sabe nada sobre seu (futuro) negócio, tudo são estimativas, chutes e palpites.

Você faz o melhor que pode para tirar a empresa do papel, e durante um tempo voa por instrumentos, meio às cegas, contando com a melhor informação que você conseguiu acumular e seu taco para o negócio.

Uma vez que sua empresa passou a existir, dados começaram a ser gerados – pedidos, itens produzidos, serviços prestados, clientes adquiridos e perdidos, lucratividade, competição, market share etc. etc. etc. A partir daí você pode avaliar se está indo bem ou não. Você consegue dizer se está executando bem, ou não, se sua estratégia está dando certo, ou não.

Inteligência de Negócios, Estragégia & Execução

Rosenzweig conclui, no capítulo nove do Halo Effect, que executar brilhantemente uma estratégia de sucesso pode levar uma empresa à falência. Se o mercado mudar, se a tecnologia mudar, se a concorrência mudar – se alguma coisa mudar o mundo no qual sua empresa existe –  sua empresa vai ficar vulnerável, e a única forma de lidar com isso é estar sempre atento e, eventualmente, decidir mudar de estratégia, antes que seja tarde demais. No final deste capítulo, Rosenzweig cita Tom Peter de novo:

Para ser excelente, você precisa ser consistente. Quando você é consistente, você é vulnerável a ataques. Sim, é um paradoxo. Vire-se com isso.

E como você decide que é hora de mudar de estratégia? Como você descobre se o problema não é estratégia, mas sim execução? Ou o inverso?

Uma empresa é uma coisa viva, que existe em um mundo em constante mutação. Organizações podem ser entendidas em si, e em seu meio-ambiente, por um único indivíduo até certo tamanho: uma padaria, uma farmácia, uma escola – um supermercado, talvez. Acima de um certo tamanho, as interações dentro da empresa, e da empresa com o meio externo são tão numerosas e complexas que uma só pessoa não consegue abarcar em sua mente toda aquela informação e tirar sentido dela. A partir de um certo tamanho, repensar a estratégia e avaliar a execução passa a ser uma tarefa sobre-humana.

E é nesse ponto que se encontra o valor da Inteligência de Negócios. A captura e análise sistemática de todos os dados que sua empresa gera, e se possível, dados do mercado e dos clientes, só pode ser feita com ferramentas específicas. Essas ferramentas se separam em duas categorias: acúmulo de dados e análise de dados. Armazéns de Dados (Data Warehouses) cuidam do acúmulo. Ferramentas como OLAP e Data Mining cuidam da segunda. Recursos de apresentação, como painéis e relatórios, comunicam os resultados para a empresa, e servem como guias para avaliar o risco da estratégia atual, para avaliar a qualidade da execução em curso.

Inteligência de Negócios é a disciplina que habilita uma empresa a buscar alto rendimento.

Juntando à conclusão do post anterior:

Inteligência de Negócios é a disciplina que habilita uma empresa a buscar alto rendimento através da compreensão de seu negócios mediante a aplicação do Método Científico.

Fechou, é isso. Até a próxima.