Quem Não Se Comunica, se TrumBIca!

Há algum tempo eu comentei que nunca vi um projeto de BI aplicar técnicas ágeis com sucesso. E completei:


Se você, que me lê, experimentou sucesso aplicando as técnicas ágeis a projetos de BI, mesmo que um sucesso relativo, me conte.

Bom, um dos meus amigos viu o post e me ligou: ele conseguiu! Maycon Queirós, o convidado do episódio #11 do OSBICast, adotou a prática ágil na empresa em que trabalha. E na conversa que se seguiu ele me contou o segredo, o que deu certo e o que deu errado. Este post destaca esses pontos. Boa diversão! :-)

Padrão Scrum

Jorge Kotick Audy, meu mestre em Ágil & mudanças, diz que:


“Considere que cada técnica ou boa prática é uma opção em um grande buffet, considere também que para se servir desta infinidade de opções é preciso ter um prato. O prato que você pega ao se dirigir ao buffet é o seu método-base, aquele que você acredita que mais tem afinidade e valor para seu processo de trabalho.”

Se fosse um buffet, o método escolhido seria o prato!


O Maycon, em conjunto com colegas de equipe, construiu um processo ágil que segue essa filosofia. Em princípio, eles aplicam um Scrum com sprint de duas semanas, com todos os ritos (priorização, planejamento, demo e revisão) e, no lugar de histórias, eles falam demandas ou requisitos.

Uma coisa que ele notou é que o processo começou encaroçado, em que vários erros e idas e vindas aconteceram. Porém, por conta da natureza iterativa do Scrum, e das práticas de inspeção, auto-crítica e modificação, eles melhoraram a cada sprint. Hoje eles possuem um processo que funciona, dá resultado e gera pouco desperdício.

Por exemplo, as primeiras sprints precisaram tratar de infra-estrutura, qualidade de dados e aprendizado da equipe. Volta e meia algo retornava para ajustes, falhas eram corrigidas e processos eram melhorados. Conforme a comunicação como cliente melhorava, conforme a equipe ficava mais entrosada, e os problemas iam sendo tratados, a velocidade começou a aumentar.

Durante essa maturação ele realizaram algumas adaptações:

  • Standup/daily: o time faz duas reuniões rápidas todo dia. Uma de manhã, em que planejam o dia, e outra no encerramento, em que avaliam o que aconteceu.
  • Priorização: normalmente faz-se a priorização no planejamento da sprint. Eles fazem isso, mas fazem uma repriorização no meio da sprint.
  • Padrões: toda demanda que recebem entra via um modelo de solicitação, poupando tempo e ganhando velocidade;
  • Demo/Review: apresentam o resultado para o cliente e depois fazem a auto-análise e auto-crítica – padrão. O que ele apontou como diferente é que não evitam puxar a orelha do cliente se ele tiver algo errado.

Porém, na percepção dele, o que realmente faz diferença é a comunicação. Mas, uma coisa de cada vez: primeiro, vamos ver cada um destes aspectos em mais detalhes e depois veremos o detalhe da comunicação.

Ritos Não Tão Retos

Uma vez feita a priorização com o cliente (metade de um dia) e planejada a sprint (a segunda metade), eles entram no ritmo diário de daily stand-up, até concluir a sprint, quando realizam a demo para o cliente (primeira metade do dia) e a review (segunda metade).


“A gente costuma resolver os dois pontos (tanto do início quanto do fim da sprint) em menos da metade de um dia (em parte por fazer a revisão das prioridades no meio da sprint). Procuramos ser objetivos nas reuniões (principalmente quando envolvem outros times) para otimizar ao máximo o tempo.”


E o que acontece se sobrar tempo?


“A gente já acerta o que vai entrar para a próxima sprint com o cliente fazendo eventuais ajustes na prévia do que foi acordado na reunião da semana anterior. Isso costuma ser rápido por conta desse trabalho antecipado, mas nesse ponto a gente já conseguiu deixar todas as tarefas pontuadas e negociamos o que pode ser deixado para uma sprint seguinte caso a carga ultrapasse o limite de pontos que estabelecemos por sprint. Antes de começar a sprint nova, fazemos a review interna junto com a retrospectiva, o que sobrar de tempo nesse dia a gente já dedica para as tarefas da nova sprint.”


A daily tradicional é um ritual em que cada membro da equipe conta o resultado do dia anterior (o que foi feito), o plano do dia (o que será feito hoje) e as dificuldades. Quando todos fizeram isso a daily acaba e quem não tem mais nada a resolver parte para o trabalho. Quem precisa de ajuda se reúne com quem pode ajudar e debatem como resolver os problemas. Depois, esses também partem para o trabalho.

Entretanto, a equipe do Maycon realiza duas dailys por dia. A primeira do dia, de manhã, é usada para se falar sobre o que será feito. Daí, nesta mesma reunião eles já conversam sobre como realizar o trabalho, que problemas podem aparecer e que soluções devem aplicar. É como um conselho de classe, pelo que eu entendi: um fala, os outros ouvem e dão dicas, palpites, sugestões e avisos de riscos e perigos. Quando todos houverem falado, a gangue se separa para cuidar do próprio trabalho.

Daí, no final do dia, eles voltam a se encontrar para avaliar o que aconteceu. Revisam o trabalho do dia, se algum problema novo apareceu e simplesmente acabam o dia. Na minha opinião é um modelo interessante, por que poupa o esforço de se lembrar do que aconteceu e sumariar em poucas palavras. Não sei como é com programação mas, em BI, isso é um trabalho considerável. Poder fechar a porta todo dia e não precisar carregar isso para o dia seguinte me soa como algo muito bom.

No scrum padrão a sprint segue ininterruptamente, até o final. No caso deles, não: no meio da sprint eles fazem uma repriorização. Eles examinam o ritmo de produção, o backlog e decidem se vão pegar mais alguma coisa, ou se vão apenas terminar o que estão fazendo. Como eles envolvem o cliente neste momento, o resultado líquido é uma indicação de como o projeto está indo e o que provavelmente vai ser abordado na próxima iteração. Nas palavras dele:


“Nessa repriorização às vezes fazemos mudanças na sprint atual se houver algo mais urgente, mas o principal propósito é já ter uma prévia da próxima sprint, assim a gente já chega mais preparado pra quando ela começar, assim fazemos o refinamento prévio dessas demandas para entrar com elas já redondas.”


Olhando de fora parece que eles param muitas vezes para rever o andamento do trabalho e replanejar. Pelo que o Maycon descreveu, esses processos são leves, e não ocupam tanto tempo assim. Além disso, o backlog selecionado para sprint nunca ultrapassa 80% do tempo da sprint.

Foi aí que eu notei o padrão: tempo para inspeção espalhado ao longo de todo trabalho.

Eureka! :-)

Priorização

Uma coisa que vocês precisam entender sobre o Maycon é que ele é um gênio disfarçado. Conversar com ele é uma tranquilidade – um cara ponderado, rápido de pensamento, mas muito paciente para falar, ótimo ouvinte. Um cara gente-fina. Daí, no meio da conversa você percebe que ele está olhando longe, muito longe. Metaforicamente falando. Quando você começa a perceber os detalhes do que ele construiu, das escolhas que ele fez, tudo começa a brilhar. Daí que, de repente, você nota que ele é qualquer coisa, menos uma pessoa ordinária. Um gênio, escondido no meio do dia-a-dia. O padrão de deixar tempo sobrando é uma dessas genialidades.

Ele aplicou a Teoria das Restrições ao processo ágil.


A Theory of Constraints (ToC) é um paradigma administrativo e intelectual no qual o principal parâmetro de operação de uma orgamização é o fluxo de trabalho. De acordo com ela, quando esse fluxo sofre interrupção por uma restrição (constraint), a produtividade sofre e a lucratividade cai. A solução é identificar essa restrição e removê-la, para que a produtividade cresça. Se tiver interesse no assunto, leia A Meta e Não é Sorte, ambos do criador da teoria, Elyahu Goldratt.

A ToC foi desenhada para tratar indústrias, mas ela é tão poderosa que se aplica em praticamente todas as indústrias e até mesmo em TI, mesmo quando a maior parte do trabalho é intelectual. Para um bom exemplo dessa situação leia Corrente Crítica, do Elyahu Goldratt, e Projeto Fênix, de Gene Kim e outros.


Como toda sprint, a deles começa com a priorização das demandas pelo cliente. Depois eles aplicam o básico do planning poker com Fibonacci para determinar o esforço envolvido. Não existe uma correspondência direta, mas eles se acostumaram a pensar nos pontos como uma escala de dificuldade. Uma coisa com 1 ponto é considerada trabalho de algumas horas. Com dois pontos, um dia, com três, dois dias, cinco dá uma semana (meia sprint), com oito e treze pontos correspondendo à sprint inteira ou maior. Nas palabras dele:


“A ideia também é tentar evitar itens com pontuações muito altas na sprint, pois isso aumenta a incerteza do tempo de entrega. Procuramos quebrar em partes menores essas demandas mais complexas. Normalmente, não temos demandas com pontuação acima de 5 na sprint.”


Daí, eles selecionam trabalho para encher até, no máximo 80% da sprint. Aprovam com o cliente e começam.

Por quê eles fazem isso? Nas palavras do próprio Maycon, por que eles sabem que a chance de aparecer um imprevisto durante a sprint é grande. Se eles alocarem 100% do tempo ao trabalho, as emergências vão ser um duplo transtorno: vão atrasar a sprint e ficar sem atendimento. Por outro lado, se não acontecer nada, eles podem terminar com calma, o que reduz a chance de erros, podem também começar a se preparar para a próxima iteração.

A importância dessa folga que eles deixam foi descoberta pelo Elyahu Goldratt e tornada bem clara no Projeto Fênix:


O tempo de espera é dado pela razão entre a porcentagem de tempo ocupado pela porcentagem de tempo livre. Em outras palavras, se um recurso está ocupado 50% do tempo, então ele está livre 50% do tempo. O tempo de espera é 50% dividido por 50%, portanto, uma unidade de tempo. Vamos dizer que seja uma hora. Então, em média, nossa tarefa esperaria na fila por uma hora antes de ser atendida.

Por outro lado, se o recurso está ocupado 90% do tempo, então o tempo de espera é 90% dividido por 10%, ou nove horas. Em outras palavras, a tarefa esperaria nove vezes mais tempo na fila do que se o recurso estivesse livre por 50% do tempo.

The Phoenix Project, Kindle Edition, Posição 3638.

O gráfico abaixo, tirado do mesmo ponto no livro, mostra o que acontece com o tempo de espera por um recurso em função do tempo livre desse recurso:

Tempo de espera em função de tempo livre.

Quanto mais você ocupa um recurso, mais você atrasa a fila.

Vai daí que ao manter 20% de reserva de tempo na sprint, Maycon e equipe garantem que seu tempo de espera é de 80% / 20% = 4 unidades. Se a sprint toda leva 10 dias, 4 unidades são 4 dias. Mas a conta é melhor do que isso. Veja, pela definição, 4 dias seria o tempo de espera até o recurso (a equipe) acabar a tarefa corrente para poder se dedicar à emergência. Mas, como eles reavaliam o planejamento todo dia, então eles têm um horizonte de oito horas, o que dá 4 horas de tempo de espera.

Lido de outra forma:

  • O trabalho planejado ocupa 8h por dia;
  • Por definição, eles assumem 80% de carga do dia;
  • A definição de tempo de espera é % ocupado dividido por % livre;
  • O tempo de espera no dia é de 6,4 horas (80% de 8h) dividido por 1,6 horas (20% de 8h), ou 4h;
  • Portanto, qualquer tarefa que apareça de surpresa terá que esperar no máximo 4 horas para receber atenção.

Se você achou confuso, pense nessa situação no extremo de ocupação total (100%): a tarefa ficaria na fila indefinidamente, até a sprint acabar. Com 80% de ocupação, ela fica no máximo 4h. E dizemos “no máximo” por que cada pessoa tem seu próprio tempo de espera. Se todo mundo estiver sincronizado, e qualquer um puder pegar a emergência, então em no máximo quatro horas vai haver alguém disponível. Como ninguém anda no mesmo ritmo, sempre tem gente com uma fila menor e que pode tratar a emergência o quanto antes.

E isso é simplesmente genial.

Ele eliminou o problema de incêndios afetando o desenvolvimento. Quantas vezes você viu alguém fazendo isso? Eu vi o pessoal dobrando o tempo prometido para ter gordura para queimar, mas nunca limitando o trabalho para ter fluxo!

Modelos

Uma vez que ele domou as constantes interferências não-planejadas, a maior fonte de atrasos de um projeto simplesmente sumiu. Veja, ele não ficou mais rápido, mas sim achou uma forma de não ficar mais lento. Com essa mesma mentalidade eles trabalharam cada aspecto do projeto, melhorando e buscando formas de ganhar produtividade.

Uma das formas encontradas por eles foi normalizar as demandas: cada história, chamada de requisito ou demanda, é sempre de algum tipo que eles já fizeram:

  • Relatório;
  • Extração de dados;
  • Análise (OLAP);
  • Painel.

Raramente algo cai fora dessa lista. Na pior das hipóteses os dados não estão disponíveis, e eles precisam escrever ou atualizar um processo de ETL. Na melhor das hipóteses eles precisam apenas construir o artefato de entrega. Então, por exemplo, para um relatório o modelo fonte de dados, título, colunas, agregação, filtros, rodapé, gráfico etc. etc. etc.

Para cada uma dessas demandas há um modelo de requisição. O cliente preenche esse modelo e submete à equipe. Nem sempre o modelo vem totalmente preenchido, claro, ou com todos detalhes necessários (às vezes aparecem coisas que ainda não foram pedidas.) Quando a equipe examina o modelo, ela avalia a necessidade de dados e conversa com o cliente para definir os pontos em aberto, refinar o entendimento e acertar o entregável. Uma demanda nunca começa a ser atendida sem haver uma grande compreensão do que é para ser feito – tanto por parte da equipe, quanto por parte do cliente.


“É comum fazermos sugestões com base em demandas que entregamos anteriormente com o intuito de enriquecer a solicitação ou simplificar o escopo para entregar o resultado esperado com menos esforço.”


No começo, o Maycon contou, a comunidade de clientes da equipe de BI torcia o nariz (e alguns ainda torcem), mas com o tempo a cultura de usar modelos e conversar com a equipe se formou e hoje é aceito normalmente.

Review

Além de tudo isso, o Maycon acredita que um aspecto que colabora para o sucesso do processo ágil deles é o rito de encerramento da sprint. Eles não fazem nada de realmente diferente: no último dia da sprint, a primeira metade é fazendo a demo com o cliente e a segunda fazendo a retrospectiva com a equipe. Na verdade, eles têm levado menos de uma metade de dia para isso, graças aos ganhos de produtividade adquiridos até aqui.

O que eles fazem a mais é que rola uma DR com o cliente. Com muito tato e muito respeito mútuo, ao cliente são colocados os pontos negativos sob a responsabilidade dele, o cliente. E isso é feito publicamente, na frente da equipe e até pares do cliente. A intenção não é causar constrangimento, óbvio, mas sim deixar que o peso das consequências de escolhas inadequadas seja experimentado por completo, intensamente, pelo cliente danadinho. O Maycon sempre pega leve, é um cara tolerante e tals, mas eu sei que ele pode ser muito intenso quando algo sai errado ou quando alguém não faz a própria parte. A capacidade de abordar um ponto negativo, uma falha ou irresponsabilidade com seriedade sem criar mágoa e ainda causar impacto é algo da personalidade dele.

Porém, quando o cliente cria valor para a equipe, sendo parceiro e ajudando, trazendo soluções junto com os problemas, participando e não se furtando a tratar o que é difícil, ele ganha um reconhecimento público, perante à equipe e a seus pares e até para a empresa. Assim o processo e as pessoas envolvidas premiam quando as coisas saem bem ou melhor que o esperado.

Se eles tratam com muita seriedade e austeridade a colaboração do cliente, imagine como eles se cobram. A review, que é feita só entre a equipe, tem muito mais seriedade e muito mais auto-crítica. Entre eles há o compromisso de não deixar nada sem falar, o que leva a certos momentos mais tensos, mais pesados. Mas, de novo, esse é o teste de uma equipe vs. um bando de gente. O time conversa, argumenta, disputa, mas no final o objetivo é único e todos se entendem.

Uma coisa importante de notar, que está em linha com as práticas inauguradas pela Toyota, é nunca sair de uma sprint sem ter nada para melhorar. Com o tempo, claro, o volume de melhorias necessárias acabou diminuindo, o que os levou a se comprometeram em sempre gerar alguma mudança. No mínimo, quando nada mais precisa ser retocado, eles procuram algum incremento para o processo de requisitos – algo sempre tem que melhorar.

Quando eu pedi para o Maycon revisar o post antes de publicá-lo, ele adicionou isso:


“Acho isso muito importante, o próprio processo e ritos passaram por iterações ao longo do tempo. Vamos calibrando o tempo alocado para cada rito, frequência ou se devemos introduzir um novo processo. Por meio das métricas de desempenho das sprints (pontos entregues, bugs encontrados, problemas nos requisitos, etc.) conseguimos dizer se as mudanças estão sendo benéficas ou não. É possível que daqui uns anos o processo que a gente siga já tenha mudado para que ele se adapte à realidade enfrentada no momento.”


Simples & Interligado

Estou concluindo o post e para mim está muito firme a sensação de que mesmo que eu empregue as mesmas práticas, eu não vou obter o mesmo resultado. Batemos papo por quase duas horas, e algo constante na fala do Maycon era “comunicação”. “A gente sempre se fala bastante”, “a gente sempre conversa com o cliente o tempo todo”, “a gente nunca deixa de contar algo importante” etc. etc. etc.

as práticas dele podem até causar um impacto (a idéia do modelo é ótima!), mas eu percebi que, sem essa capacidade de manter a equipe em um estado de troca de informações constante, o resultado talvez não fosse tão bom.

Comunicação é a chave. E isso quer dizer que saber comunicar é uma habilidade crucial. Talvez seja A habilidade.

Know-How

Falamos de várias outras coisas. Por exemplo, débito técnico. Como todo mundo, eles tiveram momentos de explosão de débito técnico, que ainda está sendo tratado. Ora eram compromissos assumidos em função de tempo e restrições do projeto, ora era falta de conhecimento (na ferramenta, no assunto, em qualquer coisa.) Não há segredo para ele, aqui. É preciso estar atento para evitar criar mais débito sem querer, e estar ciente das consequências quando um débito será incorrido propositalmente. “É a vida”, disse ele. ;-)

E Continuous Delivery/Continuous Integration? Não usam, e o deploy é todo manual. Porquê? Bom, ele explicou, por que o que precisa ir à produção geralmente é bem pouca coisa. O arquivo de um novo relatório, um ajuste no ETL, um painel publicado e só. Não há tanta coisa sendo levada com tanta frequência à produção, nem é um processo tão complexo, que precise de automação. E ele completou: “mas se um dia o processo de deploy se tornar mais complexo ou comece a tomar um tempo considerável, isso vai ser considerado como uma opção de melhoria no momento da review.”

E como fica o processo de modelagem dos dados? É a complexidade de sempre: usam modelos estrela regularmente, ou outras soluções quando é necessário. Uma coisa interessante é que eles investem cerca de 10% do tempo da sprint em documentação. Eles ponderam com cuidado a relação custo-benefício para que seja documentado apenas o que será útil. A maior parte das vezes eles registram:

  • Dúvidas frequentes;
  • Padrões de design;
  • Desenho de soluções
  • Descrições de cubos e relatórios; e
  • Resultados de análises de dados mais complexas.

Isso, segundo o Maycon, salva muito esforço e tempo na hora de atender o cliente.

Ainda sobre o modelo, eles procuram evitar criar uma nova estrela/tabela para qualquer nova demanda. Eles tentam encaixar no que já existe, e apenas se não houver como é que se criam novos recursos de dados. Uma coisa interessante: cada modelo tem prazo de validade. Após um ou dois anos, cada modelo de dados (tabelão ou estrela ou qualquer outra coisa) é obrigatoriamente revisto. A meta é encerrar coisas antigas (desligando a carga, mas não apagando-a) e evitar que dados incorretos comecem a chegar para os usuários sem que ninguém perceba. Essa é uma excelente prática, que eu vou copiar. Aliás, eles não fazem apenas esse acompanhamento. Há uma dedicação de esforço contínuo para que o modelo se mantenha coerente e funcional, esforço no qual aplicam parcela considerável de tempo.

Conclusão

Resumindo, Maycon Queiros, da Bemobi, ajudou a construir um processo ágil de desenvolvimento de soluções de BI, composto por:

  • Scrum;
  • Dupla daily (ou duas halfies?);
  • Priorização/repriorização a meia-sprint;
  • Demo com appraisal do cliente;
  • Review com melhoria obrigatória.

Fora isso, alguns aspectos são relevantes mesmo fora do contexto de agilidade de projeto:

  • Bastante documentação;
  • Relação de respeito com o débito técnico;
  • Governança do Data Warehouse.

Essa é a parte visível. Na parte invisível, ele cuida para que haja muita comunicação, que as partes se conversem bastante e que nenhuma delas crie a sensação de ser dona da verdade, mantendo-se sempre abertos ao diálogo, a escutar o colega. O Maycon resumiu isso muito bem:


“Vale mencionar a importância de reforçar boas práticas e padrões de design e desenvolvimento, além de construir soluções de forma que sejam de fácil manutenção e extensão. Isso, claro, vem muito com a experiência. O conhecimento adquirido deve ser propagado para os membros júnior e pleno da equipe de forma que haja um estilo de desenvolvimento seguido por todos.”


Essa parte é cultural e, na minha percepção, é fruto da personalidade e do profissionalismo acima da média que o Maycon tem. O que torna fácil entender por que ele pediu para eu deixar no post a seguinte observação:


“Uma coisa, aproveitando, caso você faça referência a mim em um artigo sobre esse assunto, gostaria que mencionasse também Ciro Xavier e Eric Mozetic, eles trabalham comigo na Bemobi. Muito do que te falei foi fruto de discussões entre nós.”


Esse é o primeiro método de gestão ágil de BI que eu vejo funcionando (o meu não conta.) Adoraria saber o que você acha dele. Viu algo parecido, em algum lugar? Faria algo igual? Faria diferente? Comente!

:-)

BI & ToC – Parte 3

No post Por que Inteligência de Negócios estagnou em painéis? eu coloquei o seguinte questionamento:

Tudo que responde pelo nome de BI, hoje em dia, data de vinte, trinta anos atrás. Porquê?

Para descobrir esse por quê apliquei a técnica de Árvore de Realidade Corrente, da Teoria das Restrições.

Leia o primeiro post para entender a motivação. O segundo, Inteligência de Negócios & ToC, foi apenas um ponto intermediário. Não fará falta para entender o de hoje, mas fique à vontade para lê-lo.

Efeitos Indesejáveis

A lista de EIs até agora é a seguinte:

  1. Time de BI não tem voz ativa na condução do projeto
  2. Time gradualmente perde autonomia para tomar decisões de projeto/técnicas/ tecnológicas
  3. Uma demanda típica requer muito trabalho
  4. Uma demanda vai e volta várias vezes, até o usuário se dar por satisfeito
  5. Usuário prefere adotar soluções manuais
  6. Usuários abandonam soluções rapidamente
  7. Valor percebido é pequeno
  8. A análise do problema é encerrada prematuramente
  9. A carreira do empregado corre risco
  10. A demanda não resolve o problema de negócio
  11. A empresa acredita que a solução do problema requer BI
  12. A empresa decide investir em um projeto de BI
  13. A empresa decide resolver o problema
  14. A empresa descobre um problema
  15. A fama de projetos de BI é ruim
  16. As consequências (EIs) são tomadas pelos problemas (as causas)
  17. A solução não resolve o problema de negócio
  18. Cada demanda tem aplicação limitada ao problema que a originou
  19. Cada problema resolvido expõe outro problema
  20. Capacidade do time e do gestor são questionadas
  21. Demandante questiona decisões técnicas
  22. Demandas demoram a ser atendidas
  23. Demandas têm pequena vida útil, tornando-se obsoletas rapidamente
  24. Desenvolvimento emprega muitas ferramentas
  25. Desenvolvimento requer muitos passos.
  26. Empregado é a causa do problema
  27. Empregado esconde a verdade
  28. Empregado sabota projeto
  29. Equipe de BI não é consultada para desenhar solução
  30. Existe pressão por resultados
  31. Gestor de BI sofre desgate de imagem
  32. Há a impressão de que projetos de BI não saem do lugar
  33. Objetivos são confusos
  34. O demandante desenha uma solução para o sintoma, e não para a causa
  35. O demandante não entende com clareza qual é seu problema de negócio
  36. O entregado não atende ao usuário
  37. O patrocinador do projeto se desgasta com atrasos e aumentos de custos
  38. O problema de negócio se manifesta através de EIs
  39. Projeto de BI sofre sabotagem branca
  40. Projetos de BI tendem a se alongar
  41. Retrabalho surge constantemente
  42. Sintomas podem mudar
  43. Soluções envolvem dados, negócio, análise, visualização e aplicação

Recapitulando: EI é o nome dado aos problemas que experimentamos. Significa Efeito Indesejável, indicando que não é o problema, mas um efeito causado pelo problema. A causa-raiz dos EIs é o (ou são os) problema(s).

Árvore de Realidade Atual

Todos os EIs anteriores estão ligados. Como explicado anteriormente, a árvore deve ser lida de baixo para cima, seguindo o formato

SE EIn ENTÃO EIm

Onde n e m são índices: EI1, EI2, EI3, …, EIn, …, EIm, …

CRT para BI versão 1.0. Clique para ver a imagem em alta resolução.

O começo da árvore se lê assim:

  1. Se “A empresa descobre um problema” então “O problema de negócio se manifesta através de EIs”;
  2. Se “O problema de negócio se manifesta através de EIs”, então “As consequências (EIs) são tomadas pelos problemas (as causas)”;
  3. Se “As consequências (EIs) são tomadas pelos problemas (as causas)” e “Empregado esconde a verdade”, então “O demandante não entende com clareza qual é seu problema de negócio”
  4. Se “…”, então “…”;

E assim por diante.

Sabemos se árvore está certa se faz sentido: se, ao ler o ramo, você pondera que é lógico, é puro bom senso, que faz sentido e até mesmo é óbvio, então é uma relação é válida. Se não, então eu provavelmente cometi um erro. Neste caso eu preciso re-examinar a relação e tentar entender o que não faz sentido e criar novas relações até chegar no caminho certo.

Conclusão

Eu considero que essa é uma versão 1.0 por que ela inclui os principais EIs que eu experimentei em projetos de BI:

  • O cliente não sabe o que quer;
  • O problema não é claro;
  • O time de BI é desafiado constantemente por causa das consequências de projetos anteriores;
  • Existem interesses escusos envolvidos (eu relutei em aceitar, mas no final fez sentido;)
  • A motivação para empregar BI não é clara, quando não é simplesmente “seguir a moda”.

A julgar pela recepção dos posts, vários de meus amigos e conhecidos experimentaram a mesma coisa ou situações semelhantes.

Como das vezes anteriores, eu deixei a árvore de lado por um tempo e voltei para lê-la. E como das vezes anteriores, já achei coisa que não faz sentido. Por exemplo, “se a empresa decide resolver o problema, então ela acredita que a solução do problema requer BI” não tem pé nem cabeça. Deveria ser algo como “se a empresa decide resolver o problema e alguém disse que BI resolve, então a empresa decide investir em um projeto de BI”.

E você? O que acha da lista de EIs até agora? E da árvore?

Comente! :-)

Direto na Raiz… do Dente?!

Inteligência não escolhe casa. Passeando pela web eu dei de cara com um site de sistema para clínicas odontológicas que, pasmem, aplica BI direitinho:

Início do post.

O post, publicado por um certo Mizael Oliveira em 6/7/20, fala sobre “análise preditiva”, que é um jargão para modelagem matemática. Ele explica o que é a tal análise, por que se deve fazê-la, dá alguns objetivos de negócio e uma visão geral de como se fazer esse tipo de estudo.

Na boa? Eu queria ter escrito este post. Descontados os erros de português (que não são poucos, nem especiais), o artigo é irretocável:

  • Ele respeita o público-alvo (gestores de clínicas), não se pavoneando em explicar regressões ou cluretizações bá blá blá;
  • É voltado para negócio, explicando como o processo impacta a vida financeira da clínica;
  • É concreto, pois dá exemplos de indicadores a se analisar, exemplificando as consequências;
  • Apesar de não entrar em detalhes de baixo nível, ele dá uma ponta para o gestor desfiar o novelo: tabule os dados em Excel e examine os gráficos das métricas. Serem humanos não conseguem extrair correlações complexas, mas conseguem descobrir visualmente o comportamento de uma variável ao longo do tempo;
  • Possui ritmo e encadeamento: o autor introduz o assunto por uma justificativa de negócio, explica a ideia, coloca as condições para realizar as análises e dá uma noção de como fazer. Ao longo do texto ele insere links para assuntos relacionados e termina com uma conclusão modesta e poderosa, sem bancar o sabe-tudo.

Estou lendo e relendo (e fechando os olhos para os errinhos chatos de português) e fico cada vez mais fascinado. A sugestão de legendar (ganhou pontos por evitar taggear e etiquetar) os dados é genial, tanto do ponto de vista de análise quanto pedagógico.

O cara é bom. Putsgrila, muito bom.

E por quê eu vim aqui pagar pau para um post tão fora do meu assunto? Por que não é nem um pouco fora do meu assunto! Aquilo é Business Intelligence raiz! Tomem o que o Moziel escreveu como uma lição de Inteligência de Negócios: pensem suas empresas e estratégias como o artigo, com foco em Negócio, clareza de objetivos e processos e relevância de ações.

Um dia eu vou postar coisas tão boas quanto ele. :-)

Dica: Erro de Certificado de Segurança no PDI

Eu tenho a honra de participar de um grupo de WhatsApp sobre Pentaho, no qual estão os maiores e melhores profissionais brasileiros (e alguns internacionais ;-) ) em BI e Pentaho. Como ninguém sabe tudo sobre tudo, volta e meia alguém pede uma ajuda aos “colegas”. Semana passada colocaram a questão:

Estou tentando usar um HTTP Client em uma página com HTTPS, mas está dando erro de certificado…

O erro todo é esse:

    2020/10/25 11:12:30 - Spoon - Running transformation using the Kettle execution engine
    2020/10/25 11:12:30 - Spoon - Transformation opened.
    2020/10/25 11:12:30 - Spoon - Launching transformation [transf_download_files]...
    2020/10/25 11:12:30 - Spoon - Started the transformation execution.
    2020/10/25 11:12:31 - transf_download_files - Expedindo in�cio para transformação [transf_download_files]
    2020/10/25 11:12:31 - Generate rows.0 - Finished processing (I=0, O=0, R=0, W=1, U=0, E=0)
    2020/10/25 11:12:31 - Add constants.0 - Finished processing (I=0, O=0, R=1, W=1, U=0, E=0)
    2020/10/25 11:12:31 - HTTP client.0 - ERROR (version 9.0.0.0-423, build 9.0.0.0-423 from 2020-01-31 04.53.04 by buildguy) : Because of an error, this step can't continue: 
    2020/10/25 11:12:3…

Observando o erro, o Marcello Pontes (um cara para lá de super-mega-poderoso e, não à toa, CTO da OnCase) comentou que o certificado parece ser self-signed. Para lidar com essa condição, o Marcello explicou, é preciso adicionar esse certificado ao sistema operacional que está rodando o PDI, e sugeriu olhar estes casos:

Com isso, o Marco Smanioto achou a solução do problema do nosso amigo:

  1. Acesse o site;
  2. Copie o certificado para o disco local;
  3. Importe-o com o comando abaixo (Windows):
    "c:\Program Files\Java\jdk1.8.0_241\bin\keytool" -alias CERT_IBAMA -import -keystore c:\Program Files\Java\jdk1.8.0_241\jre\lib\security\cacerts" -file "c:\[USURÁRIO]\cert_ibama.cer"

Se você estiver no Linux ou Mac, o programa usado é o mesmo: keytool. Apenas preste atenção em como passar os parâmetros, e tudo deve funcionar.

No caso do certificado do IBAMA (que é o site que gerou esse problema), a senha dos certificados é changeit.

Se essa dica te ajudou, não deixe de passar nos perfis do Marcello Pontes e do Marco Smanioto e deixar um muito obrigado. ;-)

Inteligência de Negócios & ToC – Parte 2

No post Por que Inteligência de Negócios estagnou em painéis? eu coloquei o seguinte questionamento:

Tudo que responde pelo nome de BI, hoje em dia, data de vinte, trinta anos atrás. Porquê?

Para descobrir por quê, eu decidi aplicar a Teoria das Restrições, ou no original, a Theory of Constraints – ToC.

A Teoria das Restrições é um arcabouço conceitual que permite analisar situações de bloqueio, em que o progresso cessa sem causa aparente, ou com aparentes inúmeras causas.

Quando temos a sensação de que estamos o tempo todo apagando incêndios, a ToC diz que muito provavelmente estamos enfrentando as inúmeras consequências de um ou dois problemas-raiz. Quem já participou de alguns projetos de BI com certeza passou por essa sensação: tudo começa bem, até, mas aos poucos, como um acidente de trem em câmara lenta, o projeto sai dos trilhos e entramos no modo de controle de dados, de salvar o que dá, de gerenciar expectativas etc.

Para esse contexto a ToC oferece a técnica Currente Reality Tree – CRT, que permite organizar o conhecimento, a intuição e os fatos, e analisá-los sistematicamente, até chegar à raiz dos problemas. Para construir a CRT criamos uma lista de problemas, chamados de Efeitos Indesejáveis (EIs) e os ligamos uns ao outros, até achar a causa de tudo.

Efeitos Indesejáveis

Conforme criamos a árvore, descobrimos novos EIs. A partir do trabalho com a lista de EIs do post anterior, eu acabei descobrindo vários novos (obrigado Elias, pela sugestão! ;-) ) e, dos 23 EIs iniciais, hoje eu tenho 32:

  • Os possíveis interessados não se motivam a usar
  • Baixa resiliência: mudanças no ambiente levam a comprometimento dos resultados e retrabalho
  • Complexidade explosiva: cada nova demanda requer mais trabalho que a anterior
  • Técnicas clássicas de gestão ágil não funcionam com projetos de BI
  • Cada solução tem baixa flexibilidade
  • Uma solução dificilmente resolve dois problemas
  • Demandas similares originam soluções distintas
  • Cada demanda atendida gera uma nova demanda
  • Ciclo de vida longo: uma demanda típica demora tempo demais para ficar pronta
  • Usuários prefere adotar soluções manuais
  • O entregado não atende ao usuário
  • Usuários abandonam soluções rapidamente
  • Demandas demoram a ser atendidas
  • Demandas não são claras
  • Muito retrabalho: uma demanda vai e volta várias vezes, até o usuário se dar por satisfeito
  • Retrabalho surge constantemente
  • A demanda descreve a solução, não o problema
  • A solução não resolve o problema de negócio
  • Cada problema resolvido expõe outro problema
  • Cada demanda tem aplicação limitada ao problema que a originou
  • Demandas têm pequena vida útil, tornando-se obsoletas rapidamente
  • Valor percebido é pequeno
  • O demandante não entende com clareza qual é seu problema de negócio
  • O demandante não sabe como resolver o problema de negócio
  • Projetos de BI patinam e não saem do lugar
  • Uma demanda típica requer muito trabalho
  • Desenvolvimento emprega muitas ferramentas
  • Investimento em tempo é alto
  • Soluções envolvem dados, negócio, análise, visualização e aplicação
  • Visão da solução vem do cliente
  • Projetos de BI tendem a se alongar
  • O patrocinador do projeto se desgasta com atrasos e aumentos de custos
  • Gestor de BI sofre desgate de imagem

Árvore de Realidade Atual

Eu consegui ligar os dois pedaços independentes que eu mostrei no post anterior, e ainda adicionei muitos outros. Hoje estou com 24 EIs na árvore, com ainda 9 que eu não sei bem como relacioná-los.

A imagem pode ser visualizada em alta resolução clicando-se nela.

Esse diagrama é lido de baixo para cima, usando-se uma frase de causa-e-efeito:

SE EIn ENTÃO EIm

A árvore acima seria lida assim:

  1. Se “o demandante não entende com clareza qual é seu problema de negócio” então “o demandante não sabe como resolver o problema de negócio”;
  2. Se “o demandante não sabe como resolver o problema de negócio”, então “a demanda descreve a solução, não o problema”;
  3. Se “a demanda descreve a solução, não o problema”, então “demandas não são claras” e “a solução não resolve o problema de negócio”;

E assim por diante.

Como sabemos se árvore está certa? Simples: se faz sentido. Se, ao ler o ramo, você pondera que é lógico, é puro bom senso, que faz sentido e até mesmo é óbvio, então é uma relação é válida. Se não, revise-o: procure expressar o relacionamento de maneira mais clara, até mesmo criando novos EIs intermediários.

Por exemplo, só de ler “Se o demandante não sabe como resolver o problema de negócio, então a demanda descreve a solução, não o problema” vemos que essa relação está errada. Porquê? Ora, porque não tem nada a ver “não entender o problema” com “ao descrever o problema, o demandante descreve a maneira pela qual ele acredita que vai resolver o problema”.

Já a relação “Se as demandas não são claras então uma demanda vai e volta várias vezes, até o usuário se dar por satisfeito” faz sentido. É óbvio, até: se o cliente não sabe o que quer, vamos tatear até ele descobrir.

Conclusão

Só de começar a ler a árvore já vi coisas que não batem. Vou dar alguns dias para meu cérebro processar e daí vou tentar de novo.

E você? O que acha da lista de EIs até agora? Sabe de algum que deveria estar ali? Acha que tem algum sobrando?

E a árvore? O que achou dela? Encontrou muitas coisas sem sentido? Se não achou, descobriu alguma coisa nova, ou é tudo óbvio?

Comente! :-)

Dica: Erro de Drill Down no Saiku

Ainda em setembro (em 9/24/2020, para ser exato), o grande Emannuel Roque mandou uma dica:

“Quando vc faz o drilldown no Saiku, em alguma situações, o Saiku passa o parâmetro com [ ] na url”.

Não vou entrar em detalhes técnicos sobre como funciona esse mecanismo mas, para não deixar completamente em aberto, eis um resumo do que acontece. O Saiku é um servidor dentro do servidor Pentaho, que se comunica com o cliente HTML via chamadas HTTP. Essas chamadas atravessam o Tomcat, que reclama de algumas strings. Quando essa situação acontece, o servidor retorna um erro.

Por exemplo, ao tentar fazer o drill down de um determinado cubo, a URL abaixo é gerada:

http://localhost:8080/pentaho/plugin/saiku/api/api/query/C87354D7-7444-C940-BEF1-D0E3AAF6A457/drillthrough/export/csv?maxrows=10000&position=1:0&returns=%5BMeasures%5D.%5BDevedores%5D

Isso causa esse erro:

8-Sep-2020 17:04:37.723 INFO [http-nio-8080-exec-5] org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request header Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level. java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986 at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:479) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:684) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748)

A solução é adicionar o parametro relaxedQueryChars="[,]" ao arquivo server.xml, em ./tomcat/conf/. Para isso, abra o arquivo, procure o conector do pentaho e coloque a string relaxedQueryChars="[,]" lá.

O original é:

Depois de incluir a string, fica assim:

Salve, reinicie o servidor e voi-là! A partir de agora o erro não deve acontecer mais.

Se este post te ajudou, não deixe de passar no LinkedIn do Emannuel e deixar um obrigado. ;-)

Coisa do Emannuel, não me pergunte…

BI & ToC

Por que Inteligência de Negócios estagnou em painéis?

“Você está exagerando”, posso ouvi-los dizer. “BI não estagnou e não é apenas painéis – existem DWs, relatórios, OLAP, Data Mining…” E mais: toda empresa que se preze hoje possui um time de dados, para suportar as análises que toda empresa necessita para simplesmente continuar existindo.

Certo, existe mesmo. E certo, as empresas possuem seus times de dados. Mas são todas coisas de vinte, trinta anos atrás. O que foi feito de novo, desde então? Ágil? Lean? Mah! Nem perto disso!

Se você está trabalhando com Ágil ou Lean em um projeto de BI, por favor, me contate. Eu ainda não vi projeto desses (de sucesso) até hoje.

E olha que eu nem estou entrando na questão de Big Data e de (argh!) “Data Science”! Vai daí o meu questionamento: por que BI parou no tempo?

Eu decidi descobrir o que é que está acontecendo, o que eu pretendo fazer aplicando a ToC.

A Teoria das Restrilções (do inglês Theory of Constraints – ToC) é um arcabouço conceitual que permite analisar situações de bloqueio, em que o progresso cessa sem causa aparente, ou com aparentes inúmeras causas. Por exemplo, a ToC permite estudar conflitos e resovê-los (evaporação de nuvem) ou descobrir as causas-raiz de uma dada situação (árvore de realidade atual.) O assunto todo é fascinante, e eu recomendo a leitura dos livros abaixo se você quiser conhecer o tema:

Árvore de Realidade Atual

A ToC diz que a maioria dos problemas que aparecem quando temos uma situação de “combate de incêndio”, em que o tempo todo apenas apagamos incêndios, é na verdade consequência de um ou dois problemas-raiz.

Para esse contexto a ToC oferece uma técnica chamada de Currente Reality Tree – CRT. Com ela podemos organizar o conhecimento, a intuição e os fatos, e analisá-los sistematicamente, até chegar à raiz dos problemas. O processo de construção da CRT é enganadoramente simples:

  • Crie uma lista de efeitos indesejáveis (EIs;)
  • Selecione dois e ligue-os com causa-e-efeito: SE EIn, ENTÃO EIm (n e m são índices;)
  • Repita até acabar a lista;
  • Crie novos EIs conforme sentir a necessidade.

Feito isso, o EI que estiver na raiz de todos outros é o problema-raiz.

Efeitos Indesejáveis

Listar os problemas, ou Efeitos Indesejáveis, é o primeiro passo. Eu me sentei com uma folha de papel em branco e, por coisa de uma hora, eu fui anotando tudo que me veio à mente. Eis a primeira tentativa:

  1. Baixa adoção;
  2. Trabalhoso desenvolvimento;
  3. Demandas demoram a ser atendidas;
  4. Complexidade explosiva;
  5. Baixa resiliência;
  6. Valor percebido é pequeno;
  7. Demandas não são claras;

Depois de alguns dias, eu voltei ao assunto e refiz a lista:

  1. A maioria dos usuários potenciais prefere adotar soluções manuais
  2. Uma demanda típica demora tempo demais para ficar pronta (longo ciclo de vida)
  3. Demandas têm pequena vida útil, tornando-se obsoletas rapidamente
  4. Cada demanda tem aplicação limitada (baixa flexibilidade)
  5. Demandas similares originam soluções independentes
  6. Em geral, uma demanda vai e volta até o usuário se dar por satisfeito (muito retrabalho)
  7. Usuário questiona decisões técnicas com frequência
  8. Usuário coloca demanda descrevendo solução (i.e. a demanda descreve a solução, não o problema)
  9. Com frequência o entregado não atende ao usuário
  10. Uma demanda típica requer muito trabalho
  11. Usuários abandonam soluções rapidamente

Comparei as duas listas, adicionei alguns outros EIs e criei a lista “final”:

  1. A demanda descreve a solução, não o problema
  2. Baixa adoção: os possíveis interessados não se motivam a usar
  3. Baixa resiliência: mudanças no ambiente levam a comprometimento dos resultados e retrabalho
  4. Cada demanda atendida gera uma nova demanda
  5. Cada demanda tem aplicação limitada ao problema que a originou
  6. Cada problema resolvido expõe outro problema
  7. Cada solução tem baixa flexibilidade
  8. Ciclo de vida longo: uma demanda típica demora tempo demais para ficar pronta
  9. Complexidade explosiva: cada nova demanda requer mais trabalho que a anterior
  10. Demandas demoram a ser atendidas
  11. Demandas não são claras
  12. Demandas similares originam soluções distintas
  13. Demandas têm pequena vida útil, tornando-se obsoletas rapidamente
  14. Desenvolvimento trabalhoso: requer muitas ferramentas, envolve muitos passos
  15. Investimento em tempo é alto
  16. Muito retrabalho: uma demanda vai e volta até o usuário se dar por satisfeito
  17. O entregado não atende ao usuário
  18. Projetos de BI não são propensos a serem tratados com técnicas de gestão ágil
  19. Uma demanda típica requer muito trabalho
  20. Uma solução dificilmente resolve dois problemas
  21. Usuário questiona decisões técnicas com frequência
  22. Usuários abandonam soluções rapidamente
  23. Usuários prefere adotar soluções manuais
  24. Valor percebido é pequeno

Normalmente não se escrevem tantos EIs só para começar, mas eu estou há 20 anos na área e meio que fui desabafando, anotando tudo que eu já vi ser problema ou inconveniente. Eu cheguei a repetir algumas coisas, escrevendo-as de forma diferente, atingindo mais de trinta itens. Depois eu revisei e limpei, chegando nestes 24 itens. Mas isso não é final, é o começo.

Árvore de realidade atual

O processo de construção é simples: eu preciso ligar todos os EIs (e criar novos à medida que eles sejam necessários) em relações de causa-e-efeito. Originalmente, esse processo era mecânico, físico, colando post-its em uma folha de papel (ou quadro-branco) e desenhando as relações. No final aparece a “árvore”:

ARA do livro Não É Sorte

O processo de relacionar EIs é trabalhoso. É preciso varrer a lista pensando em como aqueles itens se relaciona, pegar dois e testar – SE ei1 ENTÃO ei6 – e assim por diante. Quando um par bate, escrevemos em post-its, colamos no papel e desenhamos as setas de causa e efeito.

O meu trabalho ainda está no início. Eu já consegui essas relações:

Pedaço da árvore de BI

E estas:

Conclusão

Se você não conhece a Teoria das Restrições, eu recomendo que leia os livros. A sua vida vai mudar com o que você vai aprender.

Isto posto, o que me diz da minha lista de EIs? Você concorda com todos aqueles? Que EI você adicionaria? Qual você acha que está errado e não deveria estar ali? Vê alguma relação entre eles?

Eu não sei quando eu vou continuar esse trabalho, mas eu pretendo finalizá-lo. Nem que seja para saber por que é que, mesmo sendo tão importante, BI não vai para frente.

(Aliás, se você discorda de mim, eu vou adorar ouvir seu argumento!)

É isso. ;-)

PDI 8.x/9.x no Ubuntu 20.04

Pessoal, alguém está com problemas para rodar o PDI 8.x ou 9.x no ubuntu 20.04?

Esse erro acontece de repente, sem motivo aparente. Ele está ligado a uma biblioteca do sistema operacional que foi removida na versão 20.04 (abril de 2020) do Ubuntu e, apesar de chato, não é um erro grave – podemos continuar usando o Spoon normalmente.

Mas não precisa ser assim. O grupo de WhatsApp de Palestrantes Pentaho bateu uma bola ontem e o Emannuel Roque veio com uma solução, que ele encontrou no forum do Pulse, que teve o mesmo problema. Eu testei e funcionou.

Primeiro, garanta que esteja com o Java da Sun, ops, Oracle. Apesar de a página de referência dizer que o OpenJDK serve, eu prefiro o da Oracle. Para qualquer um dos dois use a versão 8, ou você terá problemas:

Depois, usando a linha de comando, adicione o repositório do Ubuntu 18.04:

sudo add-apt-repository 'deb http://archive.ubuntu.com/ubuntu bionic main universe'

Esse comando deve atualizar o cache local automaticamente. Se não atualizar, comande:

sudo apt update

Quando acabar de atualizar, instale a biblioteca faltante:

sudo apt install -t bionic libwebkitgtk-1.0-0

Pronto! É só rodar o Spoon 8.x ou 9.x e correr pra galera! :-)

(Não me perguntem, isso veio com a dica do Emannuel! Kkkkkk….)

E o Vento Levou…

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!

É isso. ;-)