Me bateu um grande arrependimento. Eu deveria ter salvado screenshots de todas as propagandas de self-service BI e Data Discovery e Business Discovery que eu vi nestes últimos 20 anos. Por que aconteceu o que eu sabia que ia acontecer, mas estou sem provas!
Desde o início dessa mania de Self-Service BI e tals eu venho dizendo: é furada! Não é possível ter dezenas, centenas de pessoas consumindo dados diretamente de sistemas transacionais, sem precisar de ninguém mais!
E olhem só o que eu acabei de ver:
Ora, ora, ora. Como é? NÃO dispensa? E quando foi que descobriram isso? :-)
Bom, parece que o vento levou… Voltamos ao início, então? Agora é TI, projeto e DW?
Tudo o que eu posso dizer é que eu aprendi a lição: santo print salva!
Em 12 de janeiro de 2017 eu estive no evento DBTalk Liderança Ágil, tocado pelo meu ídolo agilista Jorge “Kotick” Audy. Foi uma hora e meia sendo soterrado por avalanche atrás de avalanche de assunto sobre liderança, Ágil, organizações, modelos, psicologia…
Como todo bom evento, semelhante a um boi, nada se perdeu, tudo se aproveitou. Depois de tudo que veio na palestra, ainda tive chance de bater papo com ele e muitas outras figuraças que estavam por ali.
É sério, não percam esse evento, que ocorre frequentemente em Porto Alegre, sede da empresa, e com alguma frequência aqui em São Paulo. É do balacobaco.
Uma dessas conversas foi o espanto geral de que há pouco, em termos de Ágil, sendo feito em Inteligência de Negócios. Na verdade é pior que isso: o pouco que eles viram fui eu que levou – um zé ruela qualquer. Fora o que este vosso humilde servo-zé-ruela fez, eles mesmos confirmaram que nunca viram nada.
E porquê? Por que tão pouco existe sobre BI, com Ágil?
Eu descobri essa resposta há muito tempo, mas só ali a minha “Guernica” 1 BI-Ágil ficou completa, só ali é que a última peça fez clique no lugar.
Por causa do cubo.
Adoro Kimball, tanto que fiquei muito triste ao saber que se aposentou – acabou-se minha chance ter aulas com ele. Mas o enorme sucesso de suas idéias acabou levando a uma absurda prevalência da Modelagem Dimensional em projetos de dados para BI. Como em geral são projetos de DWs ou data marts, acabamos sendo levados a pensar tudo em termos de cubos.
Estão acompanhando? Atrelada a projetos de BI existe uma forte cultura de modelagem de dados à moda do Kimball. Assim, nos acostumamos a “pensar” os dados de projetos de BI como organizados em cubos multidimensionais.
E – na minha humilde opinião – esse é O problema. É esse o motivo para existir tão pouca coisa de Ágil para Inteligência de Negócios.
Não sei se vou conseguir passar, aqui, por escrito, a minha percepção do problema e como intuí a resposta, mas vamos tentar.
O Mundo Não é um Quadrado em 3D
Para começar, há muitas necessidades em BI para as quais um cubo é uma abordagem inadequada, quando não atravancadora.
Um exemplo fácil é Data Mining
Resumidamente, Data Mining ou Garimpagem de Dados na minha tradução favorita, é um processo que parte de uma questão de negócios, como o que fazer para aumentar as vendas em 5%? ou como decidir quanto crédito fornecer a cada cliente, e usa Matemática sobre os dados disponíveis para construir um modelo da realidade. Realidade esta que não se apresenta clara, límpida e cristalina nos bancos de dados da empresa, mas sim como uma massa bagunçada e suja de dados oriundos de inúmeras fontes – sistemas transacionais, pesquisas, bases externas, canais diversos etc.
O resultado do processo de garimpagem é um modelo matemático que descreve a realidade, e a realidade é suja.
Para fornecer um resultado com algum grau de confiabilidade, Data Mining precisa de dados crús.
Por outro lado, dados limpos, como os necessários para análises multidimensionais típica, não refletem a realidade completamente. Erros, vazios, nulos, tudo isso é descartado para levar ao cliente uma estrutura com dados claros, que permitam interpretação sobre o que sabemos, já que não adianta especular sobre o que não foi capturado.
Na melhor das hipóteses, dados sujos são disponibilizados para análise com alguma marcação, como “Não preenchido”, “Inválido” etc. Empresas que sofrem com qualidade de dados fazem isso porque assim conseguem um mínimo de certeza em suas respostas. E alguma informação é melhor que nenhuma, sempre.
Outro exemplo? Claro: painéis.
“Como assim!”, exclamarão vocês, “painéis se dão muito bem com cubos!”
É, não posso negar que se dão bem, vocês quase têm razão.
Quase.
Como é mesmo aquilo que dizemos sobre martelos? “Para um martelo, todo mundo é prego.” Se você quer montar um modelo de dados dimensional, para tudo, vai estar condicionando tudo a uma visão dimensão vs. fatos.
Painéis tendem a aglomerar diferentes visões sobre um dado aspecto da sua organização. Logo, não raro temos em um único painel widgets apontando para diferentes fontes de dados. Diferentes origens.
Diferentes cubos.
Vou escrever ao contrário para ver se fica mais claro:
Preparar dados para um painel usando um único cubo requer a consolidação de diferentes grãos em um único, que sirva para tudo.
Caso isso não seja possível, precisaremos de mais de um cubo.
Logo, uma visão de cubos te obriga a transformar toda sua realidade, em que as relações são mais complexas que as relações de um modelo dimensional, em vários pedaços. Isso acaba destruindo a produtividade porque para cada pedaço você precisa passar por todo processo de desenvolvimento de modelo dimensional!
É isso que redime o setor de Data Discovery, meu eternamente incômodo e aborrecido setor de ferramentas para Data Discovery.
Não tenho nada contra ferramenta nenhuma! Mas tenho contra argumentos frágeis e superficiais! Leia aqui!
O que está no centro de uma ferramenta de Data Discovery não é a capacidade de produzir resultado sem precisar de um DW. Caramba, uma ferramenta de DD não tem nada que uma de BI não tenha! São absolutamente iguais!
O que destaca DD da prática tradicional de BI é que Data Discovery prescinde do processo de modelar um cubo como intermediário para análise! Você nunca pode se livrar de um DW porque o Tempo é a variável mais importante de todas, mas em nenhum lugar está dito que é obrigatório ter um cubo para historiar dados! O que no fundo DD faz é abrir mão de um horizonte de tempo maior em prol de maior velocidade na geração de valor!
Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
> Indivíduos e interações mais que processos e ferramentas
> Software em funcionamento mais que documentação abrangente
> Colaboração com o cliente mais que negociação de contratos
> Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
Esse é precisamente o ponto:
Indivíduos e interações mais que processos e ferramentas
O que é que acontece quando colocamos um cubo à frente de qualquer resultado? Resposta: estamos valorizando o processo e a ferramenta!!
Por que é que temos tão pouco de Ágil em BI?
Que tal analisar o que existe de Ágil para BI listando os livros que tocam no assunto?
Entrei na Amazon.com e coloquei BI e Agile. Deu nisso:
Ágil e BI na Amazon: livros sobre… DW?
Depois do terceiro resultado tudo ficava mais ou menos confuso – ou tinha pouco/nada a ver com BI ou com Ágil ou com ambos. Fechei a busca, e coloquei Data Warehouse e Agile:
Agile Data Warehouse Design: Collaborative Dimensional Modeling, from Whiteboard to Star SchemaNov 24, 2011
Agile Data Warehousing for the Enterprise: A Guide for Solution Architects and Project LeadersOct 8, 2015
Better Data Modeling: An Introduction to Agile Data Engineering Using Data Vault 2.0Nov 21, 2015
Super Charge Your Data Warehouse: Invaluable Data Modeling Rules to Implement Your Data Vault (Data Warehouse…May 20, 2012
The Official Data Vault Standards Document (Version 1.0) (Data Warehouse Architecture)Sep 27, 2012
Data Architecture: A Primer for the Data Scientist: Big Data, Data Warehouse and Data VaultNov 26, 2014
Agile Data Warehousing Project Management: Business Intelligence Systems Using ScrumSep 28, 2012
Growing Business Intelligence: An Agile Approach to Leveraging Data and Analytics for Maximum Business ValueSep 21, 2016
Growing Business Intelligence: An Agile Approach to Leveraging Data and Analytics for Maximum Business ValueSep 19, 2016
Extreme Scoping: An Agile Approach to Enterprise Data Warehousing and Business IntelligenceAug 15, 2013
Agile Data Warehousing: Delivering World-Class Business Intelligence Systems Using Scrum and XPAug 5, 2008
Lean Analytics: Use Data to Build a Better Startup Faster (Lean Series)Mar 21, 2013
Ou seja: muita coisa sobre DW e Ágil, mas pouca sobre BI e Ágil.
Ora, bolas, é a Amazon! Eles vendem, e isso enviesa tudo. Vamos procurar uma coisa mais abrangente, mais neutra: o Google!
Ágil e BI, segundo o Google: ferramentas?!…
(Claro que eu sei que o Google também enviesa os resultados. Na verdade, enviesa tanto que eu precisei remover a renca de anúncios que vinha antes do quadro acima. Mas é mais aberto que a Amazon.com, não resta duvida.)
De novo, foco em ferramentas! Ou quase. Se seguimos o link para a Wikipédia, achamos algo mais próximo de Ágil:
Agile Business Intelligence (BI) refers to the use of the agile software development methodology for BI projects to reduce the time-to-value of traditional BI and helps in quickly adapting to changing business needs.(…)
Opa, agora sim! “Ágil BI refere-se ao uso da metodologia de desenvolvimento de software ágil para projetos de BI, para reduzir o tempo-até-valor”! Eles até citam a “metodologia” que nasceu para resolver problemas de desenvolvimento de software, mas focam no que é importante: rápida geração de valor para a organização.
Curiosamente, essa mesma definição tem como referência produtos de software para “fazer BI Ágil”, um tal de Consensus e outro, Logix – nunca havia ouvido falar de nenhum dos dois, o que para mim é suficiente para colocar esse artigo em quarentena. Vou lê-lo e estudar essas ferramentas com mais calma e decidir se é mais algum fornecedor querendo surfar hype, ou se me parece válido, sólido.
Vamos refazer nossa pergunta: por que é que temos tão pouco de Ágil em BI?
Resposta: não sei. Mas se eu precisasse chutar algo, diria que é porque todo mundo entende que o tratamento de dados vem no centro de todo projeto de BI, que por sua vez está perpetuamente voltado para o modelo dimensional.
Colocando de outra forma:
IMHO, temos pouco de Ágil para BI porque quem se dedica a este assunto acaba preso na questão de produzir dados e não de solucionar problemas.
E eu acredito que, também IMHO, isso acontece porque o enorme sucesso da Metodologia de Modelagem Dimensional, de Ralph Kimball, criou em nós uma associação automática entre BI e Cubo.
Conclusão?
Dificilmente isto aqui é uma conclusão, pois eu ainda não cheguei nela. O que eu tenho, por enquanto, é a forte sensação de que o problema de produzir dados para projetos de BI está polarizando a aplicação de técnicas ágeis para BI, causando foco excessivo no desenvolvimento de cubos, ou seja, de modelos multidimensionais.
Eu ainda não achei uma evidência forte de que isso bloqueia o desenvolvimento ágil, ou de como esse bloqueio atuaria, se existir. Intuitivamente eu percebo que um modelo dimensional não é algo muito difícil de ser atacado com métodos ágeis, e até por isso mesmo há tanto material sobre esse assunto. Me parece que o fato de termos um modelo dimensional no meio do caminho entre a necessidade de negócio e a solução de BI é que atravanca as coisas, que por sua vez é justamente a causa aparente do sucesso do Data Discovery. E não podemos ignorar a frequência de fracassos de projetos de DW.
Por exemplo, se um DW cresce pela colagem de um cubo em outro através de dimensões comuns ou conformadas – a tal Bus Matrix – então cada nova necessidade acaba criando algum retrabalho ou uma nova expansão do DW. Eu estou começando a achar que o Modelo Dimensional permite muito pouco reaproveitamento. Quase como se, a cada nova funcionalidade de um sistema fosse preciso duplicar um pedaço grande do sistema, e customizar essa nova parte.
Como lidar com um armazém de dados construído para um único propósito – análise multidimensional – em uma empresa que pode possuir n demandas de m tipos para os dados, em que cada demanda requer praticamente um cubo próprio? E pior: como lidar com as necessidades operacionais?
Confuso? Para mim também. :-(
Eu acho que encontrei a solução (sim, tem Data Vault envolvido, claro!), mas ainda não está madura o bastante para sair aqui. Mas assim que estiver, você será o primeiro a saber.
Até a próxima! ;-)
Guernica é o nome de um famoso quadro sobre um episódio da Guerra Civil Espanhola, pintada por Pablo Picasso. Sua interpretação é muito controversa. Uma das que eu ouvi é que é cheio de partes que representam aspectos do conflito, e tenta capturar a dificuldade que é, para uma mente humana, abarcar uma realidade complexa, cheia de nuances e contradições. Baseado nessa visão eu estou rascunhando um post que tenta mostrar como BI se assemelha mais à Guerra Civil Espanhola, complexa e cheia de partes, que a uma coisa como Física, que é feita de partes interconectadas e articuladas entre si. ↩
Pronto, lá vamos nós de novo! A bola da vez é Shadow IT, que é a organização de TI fora da TI.
Gartner: Shadow IT refere-se a equipamentos, softwares e serviços informatizados fora da propriedade e controle do departamento de TI de uma organização.
Wikipedia: Shadow IT é um termo usado com frequência para descrever sistemas de tecnologia da informação construídos e usados dentro de uma organização sem aprovação explícita. Assim como o termo Stealth IT, Shadow IT é usado para descrever soluções especificadas e entregues por outros departamentos que não o de TI.
Soa familiar? Deveria! Olhe esta notícia, de 2 de Fevereiro de 2016:
Este artigo discorre sobre a tendência de a operação das ferramentas para BI sair da TI e migrar para dentro dos departamentos que usam essas ferramentas. Como estamos em 2016 e a onda de Data Discovery já está passando, o repórter coloca as coisas em uma perspectiva suave comparado ao que foi 2015: “TI ainda tem um papel na captura e preparo dos dados para consumo pelos usuários de negócio”.
Cuma??? Li isso mesmo? “TI ainda tem um papel…”.
Nossa. :-O
Um ano atrás todas as propagandas de Data Discovery e outros quejandos berravam “livre-se da TI, acesse seus dados diretamente, sem precisar de ninguém!” Era praticamente a reedição da Reforma Protestante, agora para Inteligência de Negócios…
Nada como um dia após o outro.
Eu até procurei um pouco de todo esse marketing anti-TI, mas não consegui encontrar. Começo a pensar se não vi coisas, ou se não entendi tudo errado.
À Sombra da TI
De volta à vaca fria, o ponto que eu queria enfatizar é que sempre existiu alguma independência entre os departamentos de TI e o restante da empresa. Nas pequenas empresas familiares, um departamento (ou até mesmo dois!) ficam concentrados em uma só pessoa, e o funcionamento da empresa depende das aptidões e talentos multidisciplinares de todos os empregados. Meu primeiro emprego, por exemplo, foi como assistente de vendas na ACATEC (nossa, ela sumiu…) e o trabalho usava uma mistura bagunçada de Word, Access, fax e e-mails. Aos poucos eu aprendi a usar o Access e evoluí o processo de trabalho, até ficar totalmente centrada no Access e eliminar 100% de papel (isso está no meu CV, hehe – e era 1998!!!) Nesse Access registrávamos o contato do cliente, abriámos propostas, mandávamos mala-direta etc. Eu era a TI, o BI, o Marketing E assistente de vendas. :-)
Depois eu fui trabalhar no SAS (graçasadeusaindaestálá!), uma empresa muito, muito, muito maior. Havia um departamento de TI, um cara para cuidar da infra e tudo mais…
… MAS TODO MUNDO ANOTAVA TUDO EM PAPEL!!
O escritório do SAS na maior cidade do maior país da América do Sul tinha uma rotina de trabalho mais manual que da pobre ACATEC. E o que eu fiz? Reconstruí o banco de dados em Access e automatizei o meu trabalho, claro. Mostrei para meus colegas e eles disseram que alguém já tinha tentado fazer a mesma coisa, e até resgataram o que foi feito, mas que não deu em nada.
Foi a primeira vez que eu me dei conta de que não podemos forçar uma boa ferramenta em qualquer uso. O que eu consegui fazer em um dia com Access eles passaram meses tentando, usando o próprio SAS, e não conseguiram. O fato é que o SAS não era voltado para aquela função. Daria para fazer – tanto que eles conseguiram alguma coisa – mas não teria dado tão certo como meu Access nem com todo conhecimento do mundo. E isso faz quinze anos!!
No final veio um mega-sistema da sede, nos EUA, via web, mas ainda não fazia tudo que o meu fazia – estava planejado, mas na primeira etapa era só um apoio para elaboração de propostas. Enfim, saí de lá para uma empresa que vendia software de automação industrial (SCADAs), que era parte de um grupo maior, que incluía uma software house para automação comercial. Era uma empresa nacional, chamada Aquarius, com alcance internacional. Um meio-termo, portanto, entre o SAS e a ACATEC.
Eu, de peixes, trabalhando na Aquarius. Piada pronta… :-P
De novo, operavam na base do papel, e-mail, Word, agendas particulares (de papel! Eu era um dos dois únicos caras com um Palm.) O que eu fiz? Adivinhou: saquei o Access do pacote MS Office, que todo mundo tinha, e reconstruí meu gerenciador de contatos/vendas. Desta vez meu trabalho era todo de campo, e por isso eu precisava visitar muitos clientes. Não tive dúvidas! Criei uma função de planejamento de roteiro. Assim eu poderia passar uma semana no escritório contatando os clientes e fechando agenda para, vai, o sul de Minas Gerais, e registrar tudo. No final eu imprimia um relatório e passava a semana na estrada, ticando empresa após empresa.
De novo, mostrei o que tinha feito em uma reunião da diretoria da empresa. De novo… está ficando cansativo, mas vamos lá…
De novo eles falaram “nossa, igual ao que estamos fazendo!” e me mostraram o que estavam desenvolvendo a coisa de ano ou pouco mais. Claro que eles estavam fazendo um produto para vender e não se comparava com o meu nem em funcionalidades nem em qualidade e aparência. O meu era um Access, manuseado metade por formuláros, metade por tabelas, enquanto que o deles era um aplicativo especial, com instalador, cliente-servidor, todo cheio de ícones bonitos e telas funcionais.
Mas mesmo assim eu os bati – cheguei antes no fim. Na verdade, acho que eu tinha acabado de recriar a idéia do ágil e não sabia. (Eu fazia pedaço por pedaço, para atender uma necessidade imediata.)
Excel-ente!
E esta semana, lendo por aí eu me deparei com o tal do Shadow IT. Ora bolas, eu sempre fui uma sombra de TI! Não quero nem nunca quis sabotar nada, sem contar que algumas vezes eu era a própria TI. Eu sempre tentava obter e adotar a solução oficial. Quando essa não vinha, ou não resolvia um mínimo dos meus problemas, eu partia para resolver eu mesmo.
A maior ferramenta de BI de todos os tempos.
Quando os projetos de DW e BI começaram a demorar muito, a frustrar os usuários finais, o que foi que aconteceu?
Eles começaram a contornar à TI! Não é à toa que a funcionalidade mais requisitada em TODOS os projetos de exploração e visualização de dados (aff… “projetos de BI”) é EXPORTAR PARA EXCEL!!! Porque assim cai em uma coisa que o usuário pode fuçar sozinho, sem ser barrado ou frustrado pela TI e pelos “donos” do projeto de BI.
Na minha opinião, foi essa atividade parelala, tocada à sombra da TI formal, que os fornecedores de ferramenta de BI decidiram alimentar. Eu sempre impliquei com todo aquele papo de vendedor, como “se conecta a qualquer fonte de dados”, “self-service!”, porque quase todas as ferramentas de BI, se não todas mesmo, conectam-se a quase todas as fontes de dados, ou ao menos ao conjunto dos bancos mais famosos. Isso nunca foi uma revolução.
A revolução, mesmo, foi o vendedor desviar da porta do departamento de TI e ir bater no departamento de vendas. Na minha opinião, as modernas ferramentas de BI, mais leves e de menor porte, vieram na esteira dessa mudança no paradigma de vendas, e não o contrário.
Eu não levei mais que alguns meses no SAS para chegar a conclusão que BI se vende na diretoria, não na TI. Mais tarde eu percebi que, de maneira geral, essa abordagem é um traço da cultura de vendas do SAS e por isso veio a mim tão rápido (e eu me achando esperto…) Apenas frequentávamos a TI para ter certeza que não seríamos sabotados por um gerente magoado ou por uma prima-dona dodói. Mas nossa mira era sempre o C-Suite, nunca TI.
Conclusão
Meu ramo é BI, e tendo a olhar só BI. Porém, esse movimento “Self-Service” para informatização existe em muitos outros campos. Quantos gerentes não usam planilhas e smartphones para cuidar de suas agendas, deixando o sistema de agenda corporativa para um papel de comunicação/interface? Ou quantos departamentos inteiros não rodam em sistemas locais, completamente separados dos sistemas oficiais da empresa? E quando essa situação surge, adivinha o que acontece? Punem-se os responsáveis pelo sistema paralelo e força-se a adoção do oficial? Não, muito pelo contrário! Não raro a TI oficial assume que o sistema paralelo existe e funciona e deixa de competir por aquele “nicho” local, dedicando suas forças a coisas que ainda precisam da ação oficial.
O termo Shadow IT para faladores de português pode induzir à percepção de algo sombrio, fúnebre ou fora-da-lei. Mas em português, quando ficamos por perto, mas não à frente, ficamos à sombra de algo ou alguém. É esse o sentido, na minha interpretação, do termo Shadow IT. A tradução mais adequada talvez seja TI Paralela ou TI Alternativa.
Ao observar esses fatos – a TI paralela por necessidade, conveniência ou comodidade – e a explosão do mercado de ferramentas, eu passei a acreditar que não estamos vivendo a era do BI Self-Service, mas a do BI Paralelo, do Shadow BI.
O que me leva à uma forçosa conclusão:
Não existe Data Discovery. Não existe Data Lake. Não existe qualquer-coisa-BI-self-service, como eu venho argumentando há algum tempo, aliás.
O que existe é um mercado de softwares para a TI Paralela, e Self-Service Business Intelligence é um desses sub-mercados.
Quando eu me sentei para escrever esse artigo minha visão era colocar Shadow IT e o movimento de BI Self-Service lado-a-lado e, por meio de alguns paralelos, questionar se o que estava acontecendo não era a ascenção da Shadow IT, muito mais que o crescimento do auto-serviço. Só que eu não estava preparado para o que eu descobri: como sempre, eu recolho algumas referências para alimentar meus argumentos1, mas eu encontrei uma extrema dificuldade (leia-se: uma infrutífera hora googlando sem resultados) para encontrar propagandas, anúncios, posts esgoelando sobre “como a ferramenta X vai te dar independência da TI”.
Ao invés disso eu encontrei declarações contemporizadoras, suavizando o embate entre TI e usuário pelo acesso aos dados. Uma situação praticamente impensável a até um ano atrás, ou menos.
Eu não acredito em ferramentas de exploração de dados totalmente dominadas por usuários de negócio – self-service, data discovery – porque isso demanda um conhecimento e habilidade fora do alcance de 99% dessa comunidade. Acho mais fácil acreditar em um departamento de TI paralelo, translúcido, oculto nas dobras do continuum espaço-tempo, digo, corporação-tempo.
No fundo, você sempre precisa tratar os dados, sempre precisa de profissionais que só vão ser encontrados no departamento de TI. Me parece que a que mudou não foi o poder, da TI para o usuário, mas sim o que é a TI, que saiu do departamento e foi para mais perto do usuário final.2
Ufa!
Até a próxima! ;-)
O que me deixa aberto ao viés de confirmação, acusação da qual eu me declaro totalmente culpado. ;-) ↩
O título é um infame trocadilho. Não deu para aguentar, perdão. ↩
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.
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!
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.
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:
“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.
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.
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.
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:
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;
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;
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;
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.
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.
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.
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.
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.
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!
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 vá 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.
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.
“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.
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.
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!
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!
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:
O post da semana passada, Analítico ou Operacional?, nasceu de uma pergunta feita por um aluno meu, em uma de minhas turmas de BI com Pentaho pela 4Linux. Ele me perguntou “qual é sua opinião sobre o futuro do BI?”
A propósito: eu não me lembro quem perguntou isso. Se você, meu precioso pupilo, estiver lendo estas mal-traçadas, por favor identifique-se por meio de um comentário. Te devo no mínimo um grande obrigado e, no máximo, um café – lamento, é a crise. :-)
“Boa pergunta”, respondi eu, já que é a resposta-padrão de qualquer professor quando não sabe o que responder. ;-)
Eu nunca havia parado para ponderar sobre o caminho da indústria de BI, e para onde ele estava nos levando. Até aquele momento eu via o mercado de BI daqui há cinco anos exatamente como o vejo hoje, uma bruta confusão de produto, ferramenta, conceito, necessidade… Uma babel, praticamente, e sem mudanças à vista.
Aquela pergunta catalisou o entendimento dessa confusão. Aquele momento de revelação culminou, justamente, no post Analítico ou Operacional?.
E qual foi a resposta que eu dei ao meu aluno?
Quando uma empresa aborda “BI”, automaticamente ela se envolve com um espaço de produtos e serviços. Atualmente, esse espaço está dividido, grosseiramente, em ferramentas de DW (ETL, ferramentas de análises de dados (OLAP, relatórios e Data Mining) e ferramentas de apresentação de dados (Data Dicovery.)
Costumeiramente, projetos de BI são direcionados ou pela necessidade de visualização/análise de dados, que é o BI do dia-a-dia, ou para Data Mining, restrito a um time de especialistas.
Ocorre que, como colocado no post anterior, esse BI do dia-a-dia está cada vez mais voltado para análises ou visualizações de dados operacionais, e cada vez menos preocupado com o histórico dos dados. Isso não quer dizer que existe cada vez menos profissionais preocupados em analisar a empresa para direcionar suas estratégias, mas sim que há cada vez mais gente nas empresas querendo acesso aos dados, em geral correntes. Uma tendência perfeitamente compreensiva e saudável – boa, até. Ela mostra que a importância de entender e analisar dados em uma organização está crescendo, que está aumentando o reconhecimento do valor das iniciativas de BI.
Eu já vi esse momento de confusão em vários mercados e situações. Quer um exemplo recente? iPod. Tudo começou com o os tocadores portáteis de áudio, lançados por volta de 1998. Durante um tempo a indústria fonográfica e a tecnológica se estranharam, até que Steve Jobs resolveu o imbróglio do faturamento com música digital lançando o iPod/iTunes.
Meu aluno queria saber se BI era um bom mercado de trabalho, se estava crescendo ou o quê.
Minha conclusão, minha resposta ao meu aluno, foi a seguinte:
Inteligência de Negócios é um aliado indispensável de qualquer empresa ou organização que lide com um volume de dados acima de um certo tanto. Não é uma escolha, é uma necessidade imperiosa dispor de capacidade de BI na empresa. E é assim pela simples natureza do mundo corrente, nada mais. A década de 2000 abrigou a popularização de BI. A década atual, 2010, é a primeira em que BI é visto como uma coisa natural, não mais como uma novidade. Logo, minha primeira conclusão é que o mercado de Business Intelligence vai continuar firme, forte e em expansão por algum tempo ainda.
Não sei como a concorrência profissional está evoluindo, mas profissionais de BI sempre foram “moscas brancas”, e acredito que ainda será assim por um tempo. Se você deseja ingressar nesse mercado, ele ainda me parece promissor.
Foi neste ponto que eu entendi a separação estratégico-operacional evoluindo em BI. Eu segui adiante e complementei a resposta:
Em segundo lugar, o mercado atual de Inteligência de Negócios está passando por uma transformação. Há algum tempo vem crescendo um nicho de exploração de dados vivos, buscados diretamente das fontes, sem passar por um DW.
Essa necessidade é atendida, hoje, pelos mesmos profissionais que vieram de Business Intelligence. Provavelmente, a especialização cada vez maior desse conjunto “profissional + ferramenta” vai acabar forçando o reconhecimento de um novo paradigma, o paradigma da exploração e visualização de dados operacionais.
Na minha opinião, BI vai se abrir em dois outros ramos: um setor voltado para consumo de dados operacionais, vivos, por meio de ferramentas conhecidas hoje por Data Discovery, e outro, formado pelo que hoje percebe-se como “BI clássico”. Como o conjunto de habilidades para BI é diferente das de OI, imagino que um novo mercado profissional vá florescer.
Provavelmente teremos, em breve, dois tipos de especialistas de dados: o cara voltado para OI, dominando um pouco de muitas tecnologias, e o sujeito de BI que, como é hoje, terá um conhecimento mais profundo sobre uma gama mais estreita de tecnologias. Por exemplo, o DD-man precisa manjar de bancos de dados, ferramentas de exploração, tratamento de qualidade de dados, dashboards, atendimento a cliente etc. etc. etc. – e tudo junto. O BI-people, por outro lado, seguirá sendo como é hoje: um domina DW, outro é Analista de Data Mining, vai ter o sujeito do balcão, para entender a demanda do cliente e levá-la para o desenvolvimento, a equipe de ETL, um especialista em performance/altos volumes de dados, e assim por diante.
Acredito que existem dois mercados sobrepostos no mesmo nome. Um de ferramentas voltadas para aquela insaciável sede de “ver” os dados, e outro voltado à sede de conhecimento do negócio, não dos dados explicitamente. Eu sempre afirmo que BI é muito mais que ferramentas e dados. Inteligência de Negócios cria valor ao alimentar de conhecimento as mentes dos estrategistas da organização, na minha visão.
A turma em questão ocorreu em Agosto de 2015, mais de seis meses atrás. Quanto mais eu pensava sobre isso, mais sentido fazia e hoje eu vejo a evolução do DD como uma tendência irreversível. Nem imagino como essa “pressão” vai reformatar o mercado de análises de dados, mas estou convencido que existe um sub-mercado crescendo por aí, e que isso vai ter impacto não apenas na forma como acessamos os dados dentro de uma organização, mas também no perfil do profissional que atuará nesse segmento. E, a reboque, no mercado de treinamentos.
E aí, hein? Como será esse profissional? Quem vai treiná-lo? Em que tecnologias?
Quem viver verá. ;-)
Tudo que eu coloquei aqui nasceu em uma conversa informal e até hoje eu não parei para procurar pesquisa que confirme a minha opinião. É só a minha percepção, mais nada. Logo, por favor, não vá mostrar isso à alguém dizendo que é um fato escrito em pedra, beleza? ;-)
Quem acompanha o blog sabe que eu tenho uma divergência conceitual com partes do mercado de ferramentas de BI. Em geral eu questiono a idéia de analisar dados operacionais. Mais especificamente, eu venho cutucando o conceito de Data Discovery.
Acredito que finalmente entendi a confusão e vou dividir com vocês a minha opinião. Como sempre, vale o disclaimer: é a minha opinião, logo você não é obrigado a gostar dela ou concordar. Terei prazer em ouvir críticas ou outras opiniões, mas no final – como diz o Homer Simpson – a opinião é minha e faço com ela o que quiser, certo?
Fundamentação
Primeiro vamos estabelecer o terreno no qual eu colocarei meu argumento. Esse “terreno” é o uso que BI tem para uma empresa, uma organização. Como eu sempre digo, a definição de BI varia selvagemente e que o único consenso é que não há consenso sobre o que é BI. Porém, todas as técnicas e ferramentas da indústria de BI compartilham mais ou menos o mesmo discurso, a mesma promessa de valor: analisar os dados da organização para melhorar seu desempenho. Esse, então, é o chão do meu argumento:
BI trata de gerar valor a partir dos dados de uma organização.
Se concordarmos com isso – e você não é obrigado a concordar, lembre-se – então a próxima questão é “como isso acontece?” Olhemos para o mundo real: em que situações ter conhecimento dos dados gera valor para a empresa?
Empresas como uma Net ou uma Americanas.com vendem algo. A Net vende serviços e a Americanas.com é uma loja de comércio eletrônico. Algo em comum a ambas é o processo de reclamações: sempre que um dos clientes dessas empresas tem um problema, esse cliente aciona a empresa e registra uma demanda. Essa demanda é tratada, indo e voltando dentro da empresa, até que ser resolvida.
Uma forma de os dados nestas organizações serem usados para gerar valor é responder perguntas da gerência desse departamento. Por exemplo:
Quantas demandas temos em aberto, agora?
Que porcentagem dessas são urgentes?
Qual é o tempo médio de resolução de demandas?
Quais são as dez (ou vinte ou quantas você quiser) demandas mais antigas?
E assim por diante.
Outra maneira gerar valor para a empresa com esses dados é responder a estas perguntas:
O número de demandas em aberto está aumentando ao longo do tempo?
Como está variando a porcentagem de demandas urgentes em relação ao total, ao longo do tempo?
A “idade” das nossas demandas tem aumentado ou diminuído?
Uma Coisa é Uma Coisa, Outra Coisa é Outra Coisa!
O primeiro grupo de perguntas gera valor para a empresa porque está dando pistas sobre que ações tomar a seguir:
Quantas demandas temos em aberto, agora? Se sabemos qual é nossa capacidade de atendimento, sabemos imediatamente se estamos enrascados;
Que porcentagem dessas são urgentes? Caso haja um número excessivo de demandas urgentes, as urgentes delongam o atendimento das normais, que viram atrasadas e depois urgentes, gerando um círculo vicioso até o caos total;
Qual é o tempo médio de resolução de demandas? Se estiver fora da meta, precisamos nos mexer para voltar a ela;
Quais são as dez (ou vinte ou quantas você quiser) demandas mais antigas? Traduzindo: quem precisamos resolver antes?
As perguntas deste tipo estão voltadas para o aqui e agora. Elas são instrumentos para ações operacionais, ações que cuidam do dia-a-dia da empresa. Mesmo assim, essas perguntas dependem de um conjunto maior de conhecimentos para poder ajudar de verdade. Quer um exemplo?
Quantas demandas temos em aberto, agora? Inútil saber isso se não sabemos qual é nossa capacidade;
Que porcentagem dessas são urgentes? Em que ponto temos demandas urgentes em excesso?
Qual é o tempo médio de resolução de demandas? Qual é a meta?
Quais são as dez (ou vinte ou quantas você quiser) demandas mais antigas? Precisamos resolver antes quem está aberto há mais tempo ou quem tem um valor maior envolvido? Ou combinação desses dois parâmetros e mais alguns outros?
Enfim, tomar decisões operacionais a partir dos dados do momento dependem de conhecimento sobre o negócio. Os dados, por si só, não trazem esse conhecimento.
Já o segundo grupo está olhando o negócio ao longo do tempo, para ajudar a decidir que rumo tomar. São perguntas que refletem um anseio de melhorar a gestão, de evitar riscos e ter mais segurança nas ações. Cada pergunta daquelas nasceu de uma vontade de evitar problemas e melhorar o rendimento (fazer mais gastando menos) da empresa. Veja:
O número de demandas em aberto está aumentando ao longo do tempo? Traduzindo: se tudo está bem e estamos atendendo bem ao nosso cliente, então o número de demandas abertas deve estar caindo de um período (semana, mês etc.) para outro. Está? Se a quantidade de demandas está aumentando ao longo do tempo, o que está causando esse aumento?
Como está variando a porcentagem de demandas urgentes em relação ao total, ao longo do tempo? Tradução: nossa equipe, processos e ferramentas estão adequados para nossa realidade? Em que ponto perderemos o controle?
O gerente perguntou “A ‘idade’ das nossas demandas tem aumentado ou diminuído?” mas ele queria ter perguntado “Nossos clientes nos vêem como eficazes?”, ou talvez “Vamos perder algum cliente por atrito com o atendimento”?
Acredito que, a esta altura, meu argumento se auto-evidenciou:
Existem duas demandas distintas por análises de dados dentro uma organização: operacional e estratégico.
E Daí?
O berro que eu acredito ter ouvido de vocês é “descobriu a América, tontão! Todo mundo sabe disso!”
É mesmo?
Se todo mundo sabe que existem duas demandas distintas por dados, então porque é que ambas são chamadas pelo mesmo nome?
Toda e qualquer análise de dados, de qualquer tipo, em qualquer situação, tem respondindo por apenas um nome nestes últimos 20, 30 anos: Inteligência de Negócios.
Bom, se João é Pedro, então tanto faz chamá-lo de Pedro ou João. Agora, se João é diferente de Pedro, então João não é Pedro e por isso não podemos chamar João e Pedro pelo mesmo nome.
Deixe-me traduzir: eu não posso usar o mesmo nome para duas coisas distintas, ou não seriam distintas!
Admito que isso acontece em muitas situações na nossa vida, mas vocês hão de convir que, quando isso acontece, em geral sabemos que temos mais de um significado em jogo, e também sabemos a qual destes significados estamos nos referindo. Tem um exemplo no seu bolso, ou em cima da sua mesa: olhe ali, seu celular.
Não sacou?
Oras, celular é o que o seu avô usava. O nome correto destes novos aparelhos de telefonia móvel é smartphone! Chamamos tudo de celular porque é mais fácil, todo mundo entende e, bom, quem ainda usa um celular das antigas? E que diferença faria usar o nome certo? Os antigos aparelhos estão sumindo…
Eu estudei piano por um tempo e, apesar de ter um em casa, meu acabou me presenteando com um teclado da Casio. Chamei meus amigos (músicos, boa parte deles) para mostrar a novidade e tasquei: “olha só, o orgão que meu pai me trouxe!” Meu amigos caíram na gargalhada e eu, goiaba que só, não entendi nada. “Cara”, um deles falou, “orgão é seu *****, isso aí é um teclado eletrônico!!!”
Voltando à vaca fria, ao considerar que duas coisas distintas são a mesma, quando não são, estamos abrindo a porta para uma confusão danada. Essa confusão tem causado consequências problemáticas, que nem sempre são claras.
E, olha só!, produtos que se auto-categorizam como “de Data Discovery” são voltados precisamente para o exame de dados operacionais. Se não, vejamos:
Prometem acessar o dado diretamente nos sistemas de origem;
Oferecem uma vasta gama de opções de visualização de dados;
Focam em “velocidade de análise”.
Conclusão
Toda empresa depende de uma série de projetos de TI (e Negócios) para se manter viva. Projetos como ERP, BPMS e BI são o feijão-com-arroz para qualquer organização no século XXI, e o sucesso da execução destes e de vários outros projetos tem um impacto direto na saúde da organização.
Basta olharmos para a propaganda de empresas do espaço de Data Discovery para notar que seus produtos são voltados a atender necessidades de acesso e manuseio de dados operacionais. Percebemos que são projetos de TI distintos ao compararmos alguns aspectos entre produtos de Data Discovery e de BI:
Aspecto
Estratégico
Operacional
Ciclo de vida dos dados
Histórico
Vivos, quase tempo-real
Origem dos dados
Armazém de Dados
Sistema de origem
Velocidade de manuseio dos dados
Não é crítica
Crítica
Funcionalidade mais importante
Data Mining
Formas de visualizar os dados
É perigoso, se não cabalmente daninho para uma empresa, adotar como solução de um problema o produto adequado a outro. Você teria coragem de assinar a compra de um ERP para montar uma solução de workflow? Não, né? E olhe que há uma semelhança razoável entre ERP e BPMS para nos tentar a usar só o ERP para as duas coisas!
Solucionar as necessidades de dados operacionais com um projeto de BI é contraproducente:
Sai mais caro, já que embute pelo menos um projeto extra, o de DW
Frustra os usuários:
Se vêem forçados a usar ferramentas inadequadas à sua necessidade;
São obrigado a viver em um ciclo de projeto mais longo do que o necessário, pois embute a revisão do DW quando uma simples mudança na camada de apresentação já teria sido suficiente.
Da mesma fora é danoso à empresa adotar ferramentas de DD para necessidades de BI: descartar o histórico dos dados compromete as análises de causa e efeito, anulando a capacidade de compreensão e planejamento.
É uma sutileza, mas o usuário de BI também se frustra com ferramentas para manuseio de dados operacionais, pois as ferramentas voltadas para análises operacionais não são o mesmo que ferramentas OLAP.
Se temos duas necessidades claramente distintas, com público-alvo, premissas e técnicas diferentes uma da outra, e uma delas chama-se BI, a outra não pode ser BI. Por falta de um nome melhor, chamerei o não-BI de Inteligência Operacional, OI.
Não gostei muito de OI, mas a alternativa me soa ainda pior: Não é BI!
Ter claro em mente que existem demandas distintas é fundamental para atender ambas corretamente. Mesmo que compartilhem algo, como máquinas e alguns tipos de software, a simples diferença de público-alvo já justifica um atendimento em separado – no mínimo com relação aos dados que cada projeto usa. O preço de atender cada projeto com a solução errada vai de um mero desconforto entre os usuários a consequências severas para a organização.
Como capturar e documentar requisitos para projetos de BI gerenciados por métodos ágeis?
Ágil, Não Rápido
Quando Kent Beck, Martin Fowler, Ken Schwaber, Jeff Sutherland e toda patota declararam o Manifesto Ágil, eles não estavam preocupados com a velocidade do desenvolvendo de software, mas sim com a dificuldade cada vez maior em escrever bons produtos. Até início dos anos 2000, o paradigma de desenvolvimento de software era espelhado no paradigma de construção civil: ninguém assentava um tijolo até tudo estar absolutamente calculado e verificado.
É o mesmo que dizer que Romeu e Julieta foi escrito de uma vez, em algumas semanas, depois de Shakespeare passar alguns anos detalhando os personagens e a história. Não que eu seja especialista no processo criativo shakespeareano, longe disso! O que eu quero dizer é que construir paredes e escrever algo são atividades muito diferentes. Meu melhor exemplo são meus posts como exemplo: eu reescrevo cada post – inteirinho – pelo menos uma vez.
Imagine construir e derrubar uma parede até ela ficar perfeita. Imaginou? Bom, vá além: imagine construir e demolir uma casa inteira, até ficar como você quer. Ou pior: construir e vê-la desabar sobre o próprio peso vezes sem conta, até acertar a posição das vigas e conseguir que a centésima vigésima terceira encarnação da casa não caia só porque alguém bateu a porta da frente com força.
É ruim, hein! :-P
O cerne do conceito de desenvolvimento ágil não é a velocidade, mas a melhoria contínua.
Por isso no manifesto eles dizem que vêem valor em “processos, ferramentas, documentos etc.”, mas que vêem ainda mais valor em “indivíduos, colaboração, resultados etc.” Está lá, com todas as letras: trabalhar para obter um bom resultado é o que interessa. E não adianta trabalhar a toque de caixa, fazendo tudo nas coxas, só para chegar rapidamente ao final. O que interessa é avançar, melhorando continuamente e sem comprometer o futuro com decisões apressadas ou serviço mal-feito.
Inteligência de Negócios Ágil?
E como você trabalha melhoria contínua em Inteligência de Negócios? Como casamos BI com Ágil?
Eu venho estudando essa questão, meio que sem querer, já há alguns anos. Como sempre, tudo começou porque eu queria aplicar Scrum de qualquer maneira, custasse o que custasse! Eu havia acabado de ler Agile Project Management with Scrum, do Ken Schwaber, e estava louco para pôr em prática aquelas idéias. Era tudo tão simples, tão elegante, tão poderoso que eu precisava tocar um projeto com Scrum.
Tive uma sorte danada: havia acabado de receber um projeto e ele servia como uma luva em todas aquelas idéias. Aprendi tudo de Scrum, botei em prática, e o projeto funcionou muito bem.
Quer dizer, praticamente. Algums detalhes não deram muito certo:
Automação de Testes: como você testa um ETL ou um relatório, continuamente? Como montar testes de regressão em um modelo dimensional?
Histórias: como eu transformo a necessidade do cliente em uma história, e depois mapeio isso nas atividades típicas de um projeto de BI, como desenhar o modelo dimensional, desenvolver o ETL e construir um relatório ou painel?
Refactoring: sério, refatorar um banco de dados?? Freaking how??
Ainda não encontrei uma resposta satisfatória para os testes. Já refatorar bases de dados, por incrível que pareça, é um problema que já foi resolvido: o livro Refactoring Databases disseca o assunto completamente. Estou lendo esse livro agora mas, pelo pouco que eu já li, posso dizer que ele é essencial para qualquer DBA que seja membro de uma equipe de desenvolvimento de software – ou BI – contemporânea. Leia!
Senta que Lá Vem História…
O que nos deixa no assunto deste post: levantamento de requisitos ágeis para Inteligência de Negócios.
Existem várias técnicas de levantamento de requisitos para projetos ágeis. A mais famosa, provavelmente, é o conceito de História: o cliente e a equipe de desenvolvimento constroem uma narrativa que incorpora a necessidade do cliente na forma de uma ação, de uma história. Por exemplo: “como gerente de vendas, eu quero poder ver as vendas deste mês dia-a-dia, quebradas por vendedor, produto e cliente”.
Essa foi a minha abordagem para aquele projeto. Funcionou, no sentido em que permitiu organizar o trabalho, quebrá-lo em partes e controlar a entrega. Por outro lado criou outros problemas. Exemplo? O tamanho, para começar. Quem já está acostumado com projetos de BI vê imediatamente que o cliente precisa de 1) um cubo OLAP com três dimensões, de vários níveis cada, ligadas a uma fato, tudo isso carregado por 2) um processo de ETL que leva os dados da origem a um 3) modelo dimensiona. Ou seja, uma única história dá origem a um Data Mart inteiro! É muito grande!
Outro problema é o que a própria história conta: há tantas formas de construir a apresentar esses dados que umas poucas linhas de texto é um canal muito “estreito” para enfeixar tantas possibilidades. Como adicionar detalhes? Escrevendo mais? E como fazer o cliente entender o que foi prometido e o que está sendo desenvolvido?
Eu cheguei a escrever sobre um problema relacionado à essa imprecisão: Cruel Sucesso. Para te poupar do esforço de lê-lo, resumidamente, quando você acerta na mosca, o cliente muda a demanda. Depois de algumas iterações acontecendo isso, o cliente desenvolve a sensação contrária, e passa a acreditar que o projeto nunca acerta! E, na minha opinião, isso acontece porque ele só entende claramente o que pediu quando recebe. E é neste momento que ele reavalia sua necessidade a refina. Entendeu? Não? Bom, então leia aquele post antes de continuar, hehe. :-)
Requisitos Para Gestão Ágil
Enquanto eu batia cabeça com isso eu tomei contato com outra técnica fantástica: Data Vault. Se você acompanha meu blog sabe o quanto eu sou apaixonado por DV.
De novo, louco para construir um DV e testar todas aquelas idéias, eu consegui um projeto perfeito. Não apenas pude aplicar Data Vault, mas o fiz com Scrum, o que foi duplamente satisfatório aliás. O resultado desta experiência virou o Primeiro Curso de Data Vault do Brasil. Estou evoluindo aquele material e em 2016 eu espero lançar uma versão definitiva, completa.
E foi deste material que eu puxei uma coisa muito interessante: uma técnica para levantamento de requisitos para projetos de BI. Não apenas qualquer projeto de BI, mas principalmente projetos gerenciados com alguma técnica Ágil, como Scrum ou Kanban.
Funciona assim: ao invés de escrevermos uma história, e depois quebrá-la em modelo de dados, ETL, apresentação etc., começamos anotando cruamente o que o cliente diz que precisa. Essas anotações são transformadas em protótipos que são revisados pelo cliente e ajustadas e revisadas e ajustadas etc. etc. … Em algum momento o cliente vai se dar por satisfeito e o último protótipo vira o requisito! Daí o resto é história: montar um documento que combine protótipo e a demanda do cliente em uma forma que ajuda a equipe de desenvolvimento e comunica claramente a expectativa do cliente.
4Shot Agile BI com Pentaho
Eu contei para vocês que eu comprei um apartamento? ;-) Agora eu tenho uma dívida de quarenta anos, e preciso fazer caixa. Por isso, quando uns meses atrás a 4Linux me apresentou o conceito de Shot e me perguntou se eu tinha alguma proposta, na hora eu apresentei a idéia acima.
Um Shot é um curso de curta duração (tipicamente um dia), focado sobre um único assunto e, em geral, voltado para um público específico. A 4Linux é, com certeza, o maior fornecedor de treinamentos em Software Livre e eu tenho a honra de ter produzido o treinamento Pentaho que eles oferecem (e de vez em quando ministro uma turma.)
Semana que vem, dias 1, 2 e 3 de Setembro de 2015, ocorrerá a primeira turma deste Shot. As vagas são muito limitadas porque as turmas são propositalmente pequenas, de no máximo oito alunos. A idéia é oferecer um curso reforçado, intenso, e uma turma maior não permitiria isso. Também não é um assunto para principiantes. Não é nada esotérico, mas se esse vai ser seu primeiro curso em BI, bom, se prepare. ;-)
Máquina virtual pré-fabricada, pronta para os exercícios.
O curso inclui apostila e dois DVDs, com uma máquina virtual preparada para os exercícios, os exercícios resolvidos, templates, SQLs, backup de bancos e cópias de todos os softwares usados e mais alguns. E apesar de a propaganda dizer que ele é 80% prático, eu acabei fazendo um pouco mais – você não vai ter folga! Mas nem tudo será suor e teclados massacrados: como serão turmas presenciais, teremos o famoso coffee-break da 4Linux. :-)
Os leitores do blog que desejarem se inscrever terão um preço especial: R$199,00 contra R$299,00 do site. Para isso você precisa entrar em contato diretamente com Daniela Araújo (e-mail daniela.araujo@4linux.com.br) e contar que descobriu sobre o Shot no blog Geek BI.
Ora, ora, ora. Como é? NÃO dispensa? E quando foi que descobriram isso? :-)
Geek BI 