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

Thank You!

This is a special post for Mrs. Ketul Sheth and Brijesh Shah, Pentaho Comunity Heroes:


Dears Mr. Sheth and Mr. Shah, thank you very much for helping us, the Pentaho Comunity in general, and the Brazillian Pentaho Comunity in particular, with the fantastic Self-Service BI Plugin, published by SPEC INDIA.


You’ve been linked here because the person who posted this link to you does not speak English but wanted to let you know he/she is thankfull.

As for myself, Fábio, it was a pleasure talking to you too. Keep up the good job!

Best Regards,

Brazillian Pentaho Comunity
https://br.groups.yahoo.com/group/pentahobr

O Futuro do BI

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? ;-)


Analítico ou Operacional?

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;
  • Prometem dispensar um DW, descartando com isso o exame de dados ao longo do tempo;
  • 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!

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.

Até a próxima! ;-)

E Que Venha 2016!

Este é um daqueles tediosos posts sociais, manjam? Eu vou agradecer a você, meu leitor, e ponderar sobre o futuro blá, blá, blá…

Você foi avisado. Adiante! ;-)

Para um ano que teimava em não acabar, me impressiona que tenha chegado ao fim. Fazendo um balanço, eu notei uma coisa: aos poucos eu migrei de artigos técnicos, voltados ao Pentaho e ao dia-a-dia de projetos de BI e DW, para posts mais conceituais, mais filosóficos. Acho que duas situações atuaram para isso. Primeiro, principalmente em 2015, eu firmei certas idéias, o que me levou a refletir muito e, consequentemente, a colocar tudo para fora aqui.

Em segundo lugar, eu tive um feedback muito positivo sobre alguns dos temas e conteúdos apresentados. Eu sempre tento escrever algo que valha a pena ler, que justifique os minutos que um leitor gasta aqui, e me cobro muito isso – eu não publico nada que eu não teria gostado de ler. Aparentemente, dada a ausência de críticas negativas explícitas ou veladas, e a variedade dos comentários bacanas, simpáticos, de leitores que dizem ter apreciado estas mal-traçadas, eu consegui atingir esse objetivo no mínimo algumas vezes.

Então, a você que veio, leu e gostou, obrigado pela visita! Continuarei me esforçando para produzir algo do seu gosto! E se um dia você achar que eu errei ou perdi a mão, eu agradeceria se me desse um toque. É como aqueles velhos clichês, mas tão verdadeiros e fresquinhos como os pães que embalam:

"Obrigado pela preferência!", "Servimos bem para servir sempre!"

“Obrigado pela preferência!”, “Servimos bem para servir sempre!”

:-D

E Agora?

Em 2016 eu pretendo perseguir estes objetivos:

  1. Publicar a segunda edição do Pentaho na Prática – finalmente!
  2. Publicar um livro sobre como publicar e-books na Amazom.com, quase pronto! Quero ajudar quem quiser escrever um livro sozinho, e farei isso dividindo o que eu aprendi sobre o assunto;
  3. Retomar o projeto da Beltrano S/A e evoluí-lo para um estágio no qual cada um possa criar quantas linhas quiser, em que sequência de datas e arranjos de produtos desejar;
  4. Voltar com os posts mais práticos. Eu parei com eles um pouco porque não via mais necessidade, afinal, tantos publicam tanta coisa boa, para quê eu vou querer repetir? Mas um ex-aluno me disse que Inglês ainda é uma barreira, e que ter algum material traduzido pode ser muito útil. Por conta disso, vou escolher alguns assuntos que julgar interessantes, e fazer ou uma tradução, ou um post na mesma linha;
  5. Atender pedidos, como sempre. Mande o seu!

É isso. Este ano foi uma aventura divertida, e foi uma honra e um prazer contar com vocês por aqui. Vejamos o que o ano que vem no nos reserva!

E Que Venha 2016!

Categorias:Generalidades Tags: , ,

Testes de Data Warehouses

Todos que desenvolvem ou desenvolveram um processo de ETL para um DW sabem que existe um calcanhar-de-aquiles no processo: testes.

Quando escrevemos um pedaço de código em alguma linguagem, como C ou Java, podemos rodar um teste, debugar linha a linha, decidir se o código funciona ou não e ponto final. Existem até mesmo técnicas de desenvolvimento que pregam que os testes devem ser desenhados antes, e só depois deve ser escrito o programa (TDD.) Mas como ficam os testes em processo de ETL?

Começa que, em 2015 (praticamente 2016), pouca gente escreve ETL como um programa ou scripts. É difícil abandonar as facilidades, o poder e a versatilidade de uma ferramenta gráfica, como o PDI ou o PowerCenter, e escrever o ETL como um programa. Dá muito trabalho, muitas desvantagens e nenhuma vantagem. Logo, está fora de questão escrever programas para ETL só para poder usar testes automatizados. Mas mesmo que, masoquistamente, optássemos por um programa para ETL, o teste do programa não resolve o verdadeiro teste: os dados.

Veja, o problema de testar um processo de ETL para um DW é composto por duas partes:

  • Testar o processo em si;
  • Testar se o processo tratou os dados de maneira correta.

O Processo em Si

A primeira parte é a mais fácil. Basta verificar se o processo roda de ponta-a-ponta. Rodando, se ele resiste a erros comuns, como strings no lugar de números e campos com nulos. Para esses testes basta rodar o processo contra a massa de dados original e verificar se ele chega até o fim; injetar alguns erros na massa e repetir o teste, e assim por diante.

Não é difícil imaginar uma lista de erros, que possa ser forçada sobre uma massa de dados autêntica. Dados que contenham todo tipo de erro que pudermos pensar bastam para testar o processo de ETL contra erros de desenvolvimento mais ordinários, por assim dizer.

Tratando Dados Corretamente

É aqui que a porca torce o rabo. Conhece Calvin & Haroldo? Nesta tirinha (não posso colar a imagem, tem copyright), a professora pede ao Calvin para explicar a Primeira Lei de Newton com as próprias palavras. Eis a explicação dele:


Yakka foob mog. Grug pubbawup zink wattoom gazork. Chumble spuzz.

Calvin & Hobbes


Como dizer que ele está errado, se não conhecemos o significado das próprias palavras dele? É o mesmo problema nessa segunda categoria de testes: os dados estão como deveriam estar? Ora diabos, e como é que eles deveriam estar?

Não sei se consigo me fazer entender. Uma tabela dimensão “Clientes”, por exemplo, precisa ter a lista dos clientes da empresa. Agora, suponha que o processo de ETL força uma situação acidentalmente, mas não percebemos isso de cara. Sei lá, vamos dizer que um filtro no meio do processo sem querer removeu todo cliente do gênero feminino (um ETL machista, kkkk.) A transformação vai rodar, os dados serão carregados mas estarão errados! Que tipo de teste alguém desenha para detectar um erro desses, chamado de erro de domínio?

Poderíamos contar o domínio na origem, comparar com o destino e… e o quê? Dizer que se der diferente, o processo está errado? E como decidir quando um cliente não entrou na dimensão por uma questão legítima? Poderíamos estabelecer uma margem de erro, talvez?

Qual é sua opinião? Seus ETLs tratam erros de domínio? Como?

A solução que eu encontrei até agora é semi-automática:

  1. Um time formado por usuários e desenvolvedores revisam e validam cada resultado;
  2. Estatísticas são coletadas após essa validação e tomadas como parâmetros centrais;
  3. A cada nova carga, as estatísticas do DW atualizado são coletadas e comparadas com as estatísticas originais;
  4. Em caso de uma variação significativa, os desenvolvedores são automaticamente alertados, e um aviso é disparado para os usuários, informando que o processo de ETL “está passando por revalidação periódica e em breve os senhores serão notificados da normalidade do processo”.

Caímos de novo na mesma situação do quadrinho do Calvin: o que é uma variação significativa? E, novamente, a solução que eu vislumbro é empírica: começamos com uma tolerância zero, e a cada nova carga revisamos os dados e ajustamos a tolerância um degrau para cima. O processo acaba convergindo para uma “normalidade” e apenas acidentes passam a ser detectados. Porém, note que isso não isenta a equipe de um controle de qualidade periódico.

É claro que, uma vez que o processo atinja alguma estabilidade, as avaliações podem ficar mais espaçadas.

Arquitetura de Testes

Ok, se já entendemos que tipos de testes podemos/devemos fazer, resta a questão prática: que infraestrutura montar, em desenvolvimento, que colabore para manter o processo de ETL válido? Idealmente, que permita até avaliar sua performance (outro tipo de teste, aliás)?

Novamente recorrendo à analogia com o desenvolvimento em linguagens de programação, um ambiente de testes moderno é feito por um ambiente de integração contínua (ou CI, de Continuous Integration), um repositório de código e servidores de apoio (como os que o sistema teria se estivesse em produção.) Funciona assim:

  • Desenvolvedores puxam atualizações do repositório para suas estações;
  • Eles evoluem o código até o ponto desejado e comissionam as mudanças de volta ao repositório;
  • O servidor de CI, que monitora o repositório de desenvolvimento, entra em ação:
    • Puxa as atualizações assim que elas são dão entrada no repositório;
    • Compila e monta uma “build”;
    • Roda os testes unitários (regressão e novas funcionalidades;)
    • Roda os testes de integração;
    • Monta um pacote de artefatos “deployables”, para teste;
    • Atribui uma tag para a versão que acabou de tratar…
    • … e finalmente informa os resultados à equipe;
  • Se a compilação ou algum teste falha, o servidor de CI informa à equipe de desenvolvimento.

No caso de um erro, a equipe aplica-se em resolvê-lo o mais brevemente possível, submetendo essa revisão para o servidor de CI, via versionamento, para reiniciar o ciclo.


A lista acima foi traduzida livremente a partir do original aqui.


Não vejo porque não possamos montar uma solução igual para ETL. A única diferença, até onde eu posso notar, é que um processo de ETL construído com uma ferramenta visual não é compilado. Cada um dos passos da lista anterior possui um equivalente direto para um projeto de ETL e apenas os testes precisariam ser revistos.

Desenvolvimento

Todo projeto deve usar um repositório versionável (com o Git, meu favorito) para desenvolvimento. Mesmo que seja projeto de um membro só, composta pela famosa e ubíquia euquipe, um repositório é imprescindível. Logo, os dois primeiros itens da lista são pontos obrigatórios e (deveriam ser) correntes em todos os projetos de ETL.

Servidor de Integração Contínua

Um servidor de integração contínua periodicamente puxa o “código” atualizado e conduz o processo de integração e testes. Existem servidores de CI (CIS) já prontos, com muitas e muitas funcionalidades que talvez se adaptem a um projeto de ETL, como o Hudson. Em último caso, se nenhum deles servir, podemos construir um processo no PDI (a ferramenta de ETL da Pentaho, para os novatos) para emular um CIS.

Layout Genérico

A figura abaixo esquematiza um ambiente CIS para ETL, que por definição deve refletir a estrutura real:

Arquitetura genérica de um ambiente de testes para desenvolvimento de ETL.

Arquitetura genérica de um ambiente de testes para desenvolvimento de ETL.

Note os vários servidores de bancos de dados: um ambiente de testes digno deste nome precisa dispor de um cenário real para certos casos e para isso cópias completas dos bancos de origem são necessárias. Não falo de replicação contínua, em tempo real ou mesmo esporádico, mas apenas de uma infra-estrutura que replique a carga à qual o processo de ETL será submetido no ambiente real.


Se testes de performance são parte do conjunto de testes de um CIS, ou não, é um tópico aberto a debate. A eliminação de gargalos e melhora de rendimento é um processo de tentativa e erro, e sem dispor, em desenvolvimento, de uma fonte semelhante à real, acabamos usando o processo de ETL de produção para testar as melhorias de velocidade. No meu humilde entendimento, essa atitude é antiprofissional porque sujeita a operação da empresa a fatores variáveis e contraproducente, pois reduz a velocidade do desenvolvimento à velocidade das cargas do DW (ou seja, se ocorrer um refresh por dia, então os testes acontecem uma única vez por dia.) Eu, porém, tenho certeza que esse tipo de teste é dos mais importantes.


Para os testes que descreverei abaixo, cada banco de origem precisa ser backapeado em pelo menos dois dias diferentes e o banco de destino deve ser criado vazio.

Testes

Eis aqui uma lista dos testes que podemos fazer em um processo de ETL.

Elementares há dois testes:

  • De Processamento
    Neste teste ambos os bancos (origem e destino) estão vazios. O processo de ETL roda “em falso”, e o resultado é um vai/não vai para o processo como um todo. Seria o equivalente ao teste de compilação de uma linguagem tradicional: se o teste falhou, o dono do artefato que causou a falha deve ser avisado para consertá-lo. Não tenho certeza se ele é sempre possível, ou se um teste de sucesso poderia esconder uma falha ordinária – como um nome errado de tabela, coisa que deveria parar o processo.
  • De Carga Cheia
    Agora o banco de origem está cheio, e o de destino, vazio. O processo roda e realiza uma carga completa no destino. Em adição ao vai/não vai anterior, este teste dá a validação completa do ETL, ou seja, se o ETL faz alguma validação de domínio, ela é submetida a uma execução real, em condições normais. Incidentalmente, ele dá o perfil de rendimento/vazão do processo.

Esses testes são o mínimo que podemos fazer com o processo de ETL, pois ele nos mostra como o processo se comportaria no ambiente real.

Complementares

Extendendo os cenários anteriores, dois outros tipos complementam a lista dos testes mais básicos. São eles os testes:

  • De Carga Zero
    O teste de carga zero equivale à re-execução do Teste de Carga Cheia logo após seu fim. Nesta situação, em que o banco de origem não sofreu nenhuma alteração antes de ser reprocessado, e o de destino está com a carga inteira, o resultado deve ser uma carga zero, já que nada mudou. A exceção é a carga de estruturas que arquivam fotos, como fatos históricas. É um teste essencialmente de performance, já que se o processo passou pelo Teste de Carga Cheia, deve passar pelo Teste de Carga Zero.
  • De Carga Padrão
    O último dos testes é rodado com o banco de destino na situação após o Teste de Carga Cheia, mas com uma nova versão do banco de origem, capturado em momento diferente da versão usada nos testes de carga cheia e zero (que são a mesma.) Este teste fornece indicadores do rendimento do processo “em cruzeiro”, que dizer, nas condições que o processo enfrentaria refresh após refresh.

Esses dois testes, e especial o segundo da dupla, são os que permitem a criação de melhorias no processo de ETL. Podemos avaliar as mudanças feitas no processo de ETL em busca de mais performance rodando o cenário de Carga Padrão repetidas vezes. Claro que um preparo especial do ambiente é necessário, pois devemos resetar o DW à condição de carga inicial, descartando as inserções causadas pela carga das diferentes versões de bases de origem. Todas essas condições e configurações particulares podem render o processo de testes lento ao ponto de não permitir mais que um teste por dia, mas pelo menos não impactam o processamento operacional da organização.

Até agora estamos jogando o processo de ETL contra um mundo ideal, na qual as bases de origem não escondem surpresas.

Falhas

Só que testes de verdade, quando escritos para esgotar as possibilidades de um pedaço de código, alimentam condições que deveriam disparar um erro no processamento. Um teste de um código em Java, por exemplo, pode forçar situações de erro para descobrir se os tratamentos de exceções estão funcionando conforme esperado.

O último cenário é o mais complexo. Por falta de um nome melhor, temos o teste:

  • De Carga Podre
    Uma massa de dados igual ao Teste de Carga Padrão, mas eivada com todo tipo de erro possível.

Essa massa de dados dá um bocado de trabalho para ser produzida, já que precisa ter dados errados, mas não totalmente inúteis. Um campo com tipo errado aqui, uma linha nula ali… Pior: já vi casos em que o banco de dados corrompe algum conteúdo, e um teste contra essa situação precisaria forçar esse comportamento do servidor de bancos. E como fazer backup de uma banco com um erro destes?

Esses testes são, também IMHO, obrigatórios, já que são eles que atestarão a robustez do processo de ETL.

Conclusão

Os processos de ETL que eu construo passam por relativamente poucos testes, e isso me incomoda. Observo projetos que são acometidos por novos erros de carga às vezes até diariamente – é como se o DW nunca ficasse “saudável”. Ainda não tenho resposta para isso, mas acredito que o primeiro passo seja construir uma arquitetura de desenvolvimento equipada com testes automáticos. Melhor ainda, equipada com um framework que permita encaixar novos e variados testes. Com um pouco de tempo, essa infraestrutura e novas técnicas de teste podem melhorar a atualização do DW, dando mais um passo em direção à qualidade total também nos dados para BI.

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 136 outros seguidores