Dashboards e a performance ideal

Read this post in English HERE

Hoje um colega de projeto me fez uma pergunta que

gostaria de compartilhar com os amigos leitores do blog:

Como avaliar se o tempo de resposta de um dashboard é aceitável?

Uma das entregas do projeto, um dashboard com indicadores de custos de produção para uma empresa de mineração, demorava mais de um minuto na sua primeira execução.

A resposta às vezes me parece tão simples quanto óbvia: quando você acessa um portal de notícias, em quanto tempo espera ter todas as informações na tela? Mesmo que o portal seja o mais completo disponível, com todas as notícias do momento, se a cada vez que você acessar a informação precisar aguardar mais de um minuto para ter a notícia, provavelmente vai procurar outro portal.

É claro que esta analogia não abrange todos os aspectos de um cenário com um dashboard corporativo, porque podem estar envolvidos assuntos como infraestrutura, relevância da informação na companhia, volumetria, viabilidade de se ter acesso por outro canal e assim por diante. Isso todos nós, técnicos, sabemos e muito bem. Mas nem sempre o usuário, aquele executivo que passa por umas 5 reuniões no mesmo dia e geralmente consegue parar por 15 minutos pra dar atenção à tecnologia, sabe ou concorda com isso. Já presenciei algumas discussões (leia-se “brigas”) entre sponsors e gerentes de projeto sobre este assunto, cada um com a sua razão. O lado técnico mostra que aquela informação anteriormente tomava 2 dias de esforço de uma equipe pra ser obtida e o sponsor argumenta que durante a pré-venda, com apenas um click, a informação era apresentada instantaneamente.

Na minha humilde opinião, um minuto pra se obter uma informação pode ser excelente, mas desde que seja em um relatório, que pode ser executado em background enquanto o usuário executa suas outras tarefas. Neste caso, é comum encontrarmos relatórios não de um minuto, mas de até mesmo horas de execução.

Mas quando falamos em dashboards, seja ele acessado por um PC ou via mobile, geralmente o usuário aguarda a resposta a cada click, e um minuto parado, apresentando a informação em uma reunião ou somente buscando respostas de negócio, muitas vezes é o argumento necessário para se inutilizar aquele dashboard que nos tomou dias de desenvolvimento.

Existem técnicas para se melhorar a performance de um dashboard; agendar uma execução prévia dos dados costuma ser uma delas, embora muitas vezes isso limite o escopo da informação disponibilizada. Desenvolver uma estrutura de dados específica para cada dashboard durante a fase de ETL também é uma opção bastante escolhida, embora muitas vezes inviabilizada por questões como custo e governança. A aplicação de tecnologia in-memory é geralmente a melhor das opções, quando realmente é uma opção.

Em resumo, se percebemos que a informação solicitada para um dashboard não vai atender os requisitos mínimos de navegabilidade para este tipo de front-end, o ideal é sugerirmos ao cliente um relatório ou outra solução de front-end. Definitivamente, um dashboard completo, na minha opinião, não é um dashboard cheio de informações e gráficos incríveis, mas um dashboard que dê a resposta para o usuário antes que ele comece a pensar em outro tipo de pergunta, como por exemplo, será que eu não encontro essa informação em outro lugar?

Sobre o exemplo citado acima, já que não estava prevista ainda para esta fase do projeto a utilização da tecnologia in-memory, precisamos buscar outras soluções. Com uma série de otimizações de queries e melhor sincronização nas execuções das mesmas, aplicações de novas lógicas e ajustes pontuais na navegação, conseguimos reduzir o tempo de execução do dashboard para cerca de 12 segundos na primeira execução e de 4 segundos, em média, para resposta a cada click durante a navegação. O tempo foi considerado justo tanto pelo lado técnico como pelo lado funcional, em vista da qualidade da informação apresentada, mas é possível que para alguns amigos leitores do blog, este ainda não seja um tempo de resposta ideal. Considero aceitável, embora acredite que este ainda seja o limite a ser sugerido em casos mais extremos quando se desenvolve um dashboard sem a utilização da tecnologia in-memory.

Um abraço,

-----------

Igor Alexandre Jakuboski é profissional de Business Intelligence há mais de 7 anos, tendo já atuado em dois dos principais fornecedores de soluções de BI do mercado e liderado projetos no Brasil e no exterior. Atualmente atua como Principal Solution Architect na SAP. Perfil no LinkedIn: br.linkedin.com/pub/igor-jakuboski/41/28b/88a

Dashboards and the ideal performance

Para ler este post em português clique AQUI

Today a project colleague asked me something that I'd like to share with our friends readers of this blog:

How to evaluate if a dashboard response time is acceptable?

One of the project deliverable, a dashboard with production costs indicators for a mining company, was taking more than a minute in its first execution.

The answer sometimes seems so simple as obvious: when you access a news portal, how soon you expect to see all information on the screen? Even if the portal is the most complete one available with all news of that moment, if every time you access the information you have to wait more than a minute to see the news, you   will probably look for another portal.

It is clear that this analogy does not cover all aspects of a scenario with an enterprise dashboard because it may involve issues such as infrastructure, relevance of information on the company, volumetry, feasibility of having access by another channel and so on. That, all of us technicians, know and know very well. But not always the user, that executive which goes through 5 meetings in the same day and usually can stop only for 15 minutes to pay attention to technology, knows or agrees with this. I've seen some discussions (read "fights") between sponsors and project managers on this subject, each with its reason. The technical side shows that the information previously took two days of a team effort to be obtained and the sponsor argues that during the pre-sale, with just one click, the information was presented instantly.

In my humble opinion, a minute to get some information may be excellent, but provided it is in a report that can run in the background while the user performs its other tasks. In this case, it is common to find reports of not only a minute but hours of execution.

But when we talk about dashboards, whether accessed from a PC or via mobile, the user usually waits for the response to each click, and a minute stopped displaying the information in a meeting or just seeking business answers is often the argument necessary to disable that dashboard that took us one day to develop.

There are techniques to improve the performance of a dashboard; schedule a previous execution of the data is usually one of them, although it often limits the scope of the information provided. Develop a specific data structure for each dashboard during the ETL phase is also a common chosen option, though often frustrated by issues such as cost and governance. The application of in-memory technology is usually the best option, when it is really an option.

In summary, if we realize that the requested information to a dashboard will not meet the minimum requirements of navigability for this kind of front-end, ideally we suggest the customer a report or another front-end solution. Definitely a complete dashboard, in my opinion, is not a dashboard full of information and amazing graphics, but a dashboard that gives the answer to the user before he starts thinking about another kind of question, for example, wouldn't I find this information anywhere else?

About the example mentioned above, since it was not yet planned for this phase of the project the use of in-memory technology, we must seek other solutions. With a series of queries optimizations and better synchronization of them, we were able to reduce the dashboard execution time to around 12 seconds in his first execution and of four seconds, in average, for the response to each click during navigation. The time was considered fair by both technical and functional side, given the quality of the information provided, but it is possible that for some friends readers of the blog this still is not an optimal response time. I consider acceptable, although I believe that this is still the limit to be suggested in the most extreme cases when developing a dashboard without the use of in-memory technology.

Regards,
--------------
Igor Alexandre Jakuboski is a professional of Business Intelligence for over 7 years, having already worked on two of the leading providers of BI solutions in the market and led projects in Brazil and abroad. He currently works as Principal Solution Architect at SAP. LinkedIn profile: 

br.linkedin.com/pub/igor-jakuboski/41/28b/88a

De "ganho rápido" para "prejuízo permanente"

Read this post in English HERE

Há alguns dias, uma amiga minha me contatou para saber minha opinião sobre a estratégia geral do projeto de Business Intelligence (BI) em que ela estava trabalhando: a ideia era entregar a camada de apresentação inteira do front-end (relatórios, dashboards etc.) e só então começar a trabalhar na camada de Data Warehouse o que significa modelagem, estruturação de dados e ETL (Extraction, Transformation and Load). De acordo com a descrição dela, eles não conseguiam ao menos falar todas as fontes de dados que seriam necessárias para entregar a camada de front-end já prometida.

Eu acredito que a maioria de nós já vivenciou uma situação similar. Já a vi sob muitos nomes e conceitos, mas geralmente podemos simplificá-la chamando-a de "ganho rápido". Por "ganho rápido" nós normalmente queremos dizer que alguma coisa (uma parte de um projeto, uma funcionalidade específica ou algo do tipo) pode ser entregue muito rápido (em comparação com o entregável inteiro), com um custo razoável (também em comparação com o entregável inteiro) e, principalmente, que pode entregar um alto valor agregado. Em um mundo ideal, isso significaria gastar 20% dos recursos que trariam 80% do valor agregado (em uma análise simplificada de Pareto).

Devemos mencionar, que enquanto buscando o "ganho rápido" é possível que algumas regras de governança ou diretrizes de melhores práticas sejam negligenciadas no intuito de reduzir ainda mais o total de recursos investidos. Claramente, isso pode ser feito apenas quando previamente acordado com todas as partes interessadas e sob estrito comprometimento de cumprir todos os requerimentos necessários ao implementar o restante do projeto.

Nem é preciso dizer que o advento do "ganho rápido" não tem raízes nos fundamentos técnicos. De acordo com minha experiência, se você perguntar a um técnico se ele gostaria de entregar "a solução perfeita a qualquer custo" ou uma "solução usável a um custo muito baixo", ele explicará com prazer que apesar da solução de baixo custo poder ser usada, tal qual, ela tem uma lista enorme de desvantagens e riscos que deve ser levada em consideração.

Então, a fim de construir uma solução que possa ser efetivamente vendida - a propósito, uma perspectiva muito importante de uma empresa de consultoria, técnicos do mundo todo (eu incluso) dependem dos colegas de marketing, vendas e gerentes de projeto. Que foram brilhantes ao trazer para o negócio soluções que se encaixam às necessidades do cliente e ao padrão de entregar a melhor solução possível através da abordagem de fases, priorização de entregável e, claro, "ganhos rápidos".

Para dizer na lata: eu suporto a abordagem de "ganho rápido" como uma ferramenta para tornar os projetos possíveis e viáveis. Eu acredito que se pudermos encontrar a "coisa" certa (seja um relatório, um processo, um dashboard, um fluxo de trabalho etc.) que possa realmente derrubar a escala de nossos clientes, devemos fazê-la o mais rápido possível a fim de garantir um rápido ROI (Return Over Investment) e, além disso, a vantagem competitiva que eles estão sempre procurando.

No entanto, eu discordo da abordagem, algumas vezes "rápida e suja", que algumas soluções são vendidas e entregues. Discordo da idea de entregar tudo como um "ganho rápido" ou "protótipo produtivo" como já vi acontecer diversas vezes. Eu encorajo todos aqueles dispostos a usar a abordagem do "ganho rápido" a seguir uma lista de verificação muito simples:

1. entenda o ambiente, os problemas, as oportunidades e desafios do seu cliente;
2. proponha uma solução completa e sustentável;
3. destaque as "coisas" que podem ser feitas com uma quantidade pequena de recursos (tempo, dinheiro e pessoas) e que potencialmente podem trazer um grande benefício (produtividade, lucro, eficiência etc.);
4. se necessário - para tornar o projeto viável - crie um roadmap a quatro mãos ou um programa no intuito de aplicar a abordagem de fases.

Com a lista de verificação simples acima, você garantirá não negligenciar o todo.

Abraços,

_______

Eduardo Rodrigues é profissional de Business Intelligence há 8 anos, já atuou como cliente, empreendedor, palestrante, consultor, arquiteto de soluções e gerente de projetos. Casado, pai de dois filhos é ainda autor de um livro de poesias chamado “Poemas de Botequim”. Perfil no LinkedIn: http://br.linkedin.com/in/rodrigueseduardo. Siga-o no Twitter: https://twitter.com/edur0dr1gue5

From "quick win" to "permanent loss"

                                                                                                                                          Para ler este post em português clique AQUI

A few days ago, a friend of mine contacted me asking for my opinion about the overall strategy of a Business Intelligence (BI) project she was working on: the idea was to deliver the entire front-end presentation layer (reports, dashboards, etc.) and only then start working on the Data Warehouse layer meaning the whole modeling, data structuring and ETL (Extraction, Transformation and Load). According to her description they could not even tell all data sources which were needed to deliver the already committed front-end layer. 

I believe most of us have already experienced a similar situation. I have seen it under many names and concepts, but usually we can simplify it by calling it a "quick win". By "quick win" we usually mean something (a part of a project, a specific functionality or something alike) that can be delivered really fast (in comparison to the whole deliverable), in a reasonable cost (also compared with the whole deliverable) and mainly can deliver a high value added. In an ideal world, that would mean to expend 20% of the resources that will bring 80% of the value added (in a simplified Pareto analysis). 

It should be mentioned, that while running for the "quick win", it is possible that some governance rules or best practices guidelines are overlooked in order to reduce furthermore the amount of resources invested. Clearly it can only be done when previously agreed with all stakeholders and under the strict commitment to fulfill all the necessary requirements when implementing the remaining project. 

Needless to say that the advent of the "quick win" bears no roots on technical grounds. Out of my experience, if you ask a technician if he/she would like to deliver "the perfect solution at any cost" or a "usable solution at a very low cost" he/she would gladly explain that although the low cost solution can be used, as such, it has an enormous list of disadvantages and risks that must be taking into consideration. 

So, in order to build up a solution that actually can be sold - a very important perspective of a consultancy company by the way, technicians all over the world (myself included) depend on our marketing, sales and project managers colleagues. Who were brilliant on bringing up to the business solutions that fits both the customers needs and the standard of delivering the best possible solution by introducing the phasing approaching, prioritization of deliverable and, of course, "quick wins".   

To say it straight away: I support the "quick win" approach as a tool to make projects possible and viable. I believe that if we can find the right "thing" (be it a report, a process, a dashboard, workflow, etc.) that can really tip the scale to our customers, we should get it done as soon as possible in order to guarantee a fast ROI (Return Over Investment) and moreover the competitive advantage our customers are always looking for. 

However, I disagree with the approach, sometimes "quick and dirty", some solutions are sold and delivered. I disagree with the idea of delivering everything as a "quick win" or a "productive prototype" as I have seen several times. I would encourage all those willing to use the "quick win" approach to follow a very simple checklist:

1. understand your client environment, its problems, opportunities and challenges;
2. propose a complete and sustainable solution;
3. highlight the "things" that could be done with a small amount of resources (time, money and people) and potentially can bring a huge benefit (productivity, profit, efficiency, etc.);
4. if needed - in order to make the project viable - create a four hands road-map or a program in order to apply the phasing approach.

With the simple checklist above, you will make sure not to overlook the big picture.

Regards,

_______

Eduardo Rodrigues is a Business Intelligence professional for 8 years, he has worked as client, entrepreneur, speaker, consultant, solution architect and project manager. Married with two children, he is also author of a poetry book called “Poemas de Botequim”. LinkedIn profile http://br.linkedin.com/in/rodrigueseduardo. Follow him on Twitter https://twitter.com/edur0dr1gue5

Enriquecendo o front-end

                                                                                                                  Read this post in English HERE

Aos amigos que acompanham o blog, eu gostaria de apresentar alguns tipos de gráficos que poderiam ser um pouco mais explorados nos projetos de BI em geral. Muitas vezes, eles são deixados para cenários mais específicos ou não são nem cogitados por parecerem um pouco mais complexos para demonstração dos dados.

É claro que muitos clientes estão mais acostumados com os tradicionais gráficos de barra/coluna/linha, ou com o famoso gráfico de pizza, e com razão, afinal são gráficos de fácil visualização e respondem a maioria das questões de negócio aplicadas neles. Mesmo assim, muitas vezes podemos buscar valorizar o front-end de um projeto de BI com algumas sugestões de visualizações que podem ser muito úteis durante a análise dos dados. Para não prolongarmos muito o texto, nesse post vamos considerar 2 tipos de gráficos que considero pouco explorados, e dependendo da receptividade do post, demonstramos outras possibilidades nas próximas semanas.

Nota: Os gráficos estão disponíveis em diversas ferramentas de BI e é possível que os nomes sejam variados entre elas.

Bubble Chart

Este tipo de gráfico é bastante conhecido, embora nem sempre utilizado. É apropriado para apresentar três dimensões de dados em um mesmo cruzamento, sendo este um diferencial em relação aos gráficos de coluna/barra/linha e pizza.

Vamos demonstrá-lo com um exemplo bastante simples e de fácil entendimento. Usaremos um exemplo de uma revendedora de automóveis, analisando dados de vendas.

Podemos sugerir uma visualização semelhante a esta:

Veja que no mesmo gráfico, o cliente pode comparar o percentual de vendas de cada um dos automóveis (tamanho do indicador), a quantidade vendida (eixo X) e a rentabilidade alcançada (eixo Y).

É muito provável que o usuário já tenha um gráfico de pizza para a demonstração da proporção de vendas e um ou dois gráficos de coluna/barra/linha para demonstrar os outros dois indicadores. Conseguimos reduzir toda a vista para um gráfico, mantendo a simplicidade na análise dos dados.

E se o cliente ainda sentir falta dos outros formatos tradicionais de gráficos nesta análise, podemos sugerir um “drill” e detalharmos a informação em uma linha de tempo ou com outras comparações relevantes, como neste caso, em que o usuário pode clicar sobre um “bubble” no gráfico e ter a informação detalhada em outros três gráficos “tradicionais”:

Sim, no final, voltamos aos gráficos mais tradicionais, mas criamos um ponto inicial para a análise, que pode orientar o usuário durante a navegação e análise da informação.

Vamos agora falar de outro tipo de gráfico.

Tree Map

Esse gráfico pode ser bastante interessante para demonstrar uma informação estruturada, podendo apresentar mais de um nível de uma hierarquia, bem como diferentes dimensões de dados. 

Neste nosso simples exemplo, seguindo a lógica apresentada acima, temos também as informações de performance de uma revendedora de autos, mas agora não específica para uma categoria, e sim para quantas necessárias (cuidado com o “quantas”, o gráfico precisa ser simples para ser útil).

O gráfico apresenta 4 categorias de automóveis (popular, sedan médio, utilitário e esportivo), sendo o tamanho de cada seção a quantidade de carros vendidos para cada uma. Poderiam ser regiões de vendas, marcas, vendedores ou qualquer outra informação agregada. Dentro de cada uma das categorias, temos novos quadros para cada modelo de automóvel, que também tem suas quantidades vendidas representadas pelo tamanho dos mesmos. A intensidade da cor pode representar ainda outro indicador, sendo neste caso a rentabilidade por modelo de automóvel (as mais claras significam uma rentabilidade maior).

Em resumo, o usuário pode analisar a proporção de vendas em dois níveis diferentes (categoria e modelo) e ainda a rentabilidade para cada modelo. A mesma informação que talvez precisasse de alguns gráficos tradicionais para ser demonstrada está resumida em apenas um, mantendo a simplicidade à  análise.

E porque já não utilizarmos este gráfico, assim como no primeiro exemplo, como um ponto inicial para uma navegação orientada?

Seria interessante se os leitores pudessem comentar outras possibilidades para estes ou para outros gráficos “não tradicionais”, assim como outras maneiras interessantes de aprimorar o front-end em projetos de BI.

Um abraço,
_________

Igor Alexandre Jakuboski é profissional de Business Intelligence há mais de 7 anos, tendo já atuado em dois dos principais fornecedores de soluções de BI do mercado e liderado projetos no Brasil e no exterior. Atualmente atua como Principal Solution Architect na SAP.

A resposta para a vida o universo e tudo mais

Lendo o artigo de Ron Ashkenas (segundo a HBR: "Ron Ashkenas is a managing partner of Schaffer Consulting and a co-author of The GE Work-Out and The Boundaryless Organization. His latest book is Simply Effective") publicado na Harward Business Review: The Art of Asking Questions (A arte de fazer perguntas, em tradução livre) eu lembrei do livro O Guia do Mochileiro das Galáxias.

No livro - que virou filme de mesmo nome - um super computador é construído para calcular a resposta "para a vida o universo e tudo mais", a resposta encontrada depois de anos de cálculo é 42 (como curiosidade, digite no Google: a resposta para a vida o universo e tudo mais). Os personagens, irritados se perguntam: como assim 42? 42 o quê? 

Na minha opinião é EXATAMENTE assim que algumas soluções de BI são construídas, sob a diretriz de entregar a resposta para: 

• todas as perguntas de negócio ou 
• aumentar a lucratividade ou
• reduzir custos ou
• gerar relatórios

Na prática o que acontece é que sem uma PERGUNTA e ser respondida, todas as respostas são válidas, incluindo 42!

Grande abraço,

Edu

BI, comunicação e conscientização

Eu já falei sobre esse assunto aqui, sobre minha crença de que BI pode e deve ser usado como ferramenta de comunicação. Eu falei sobre isso no artigo: Business Intelligence como canal de comunicação.

E o que eu tenho para falar de novidade sobre o assunto? Bom, acontece que eu fui apresentado a um ótimo exemplo. Não necessariamente de BI como ferramenta de comunicação, mas de informação complexa, consolidada e bem apresentada (lembra alguma coisa?) como instrumento de comunicação. 

O exemplo é de Al Gore, Ex-Vice-Presidente Americano no documentário Uma Verdade Inconveniente (An inconvenient truth - no original em inglês) de 2006. O vídeo pode ser visto, com legendas em português aqui:

Uma Verdade Inconveniente - An Inconvenient Truth (2006) Legendado PT from MDDVTM TV7 on Vimeo.

O show - porque aquilo não pode ser chamado de palestra - que Gore nos apresenta é incrível, na minha opinião por 3 motivos principais:

1. Relevância - a mensagem e o assunto discutido de Gore têm impacto na vida de cada um de nós, e ele toma cuidado de deixar isso BEM claro e também de rebater os "mitos" que pregam que o aquecimento global não é um assunto importante.
2. Conteúdo - os dados apresentados por Gore não são apenas extensos (uma medição de 650 milhões de anos não é comum) são também confiáveis, uma vez que foram fornecidos pelos melhores cientistas do mundo e pelos órgãos melhores qualificados para fornecer a informação.
3. Apelo visual - todos os gráficos e números apresentados foram cuidadosamente trabalhados e a visualização re-inforça a mensagem dos números. O ponto máximo para mim, é quando o gráfico "explode" para fora da área de projeção e Gore acompanha o mesmo com uma grua, FANTÁSTICO!

Outro ponto fundamental para o sucesso da comunicação das informações foi a simplicidade com que os dados foram apresentados. Olhando o gráfico que relaciona CO2 e temperatura no planeta é impossível, mesmo para um aluno primário, não ver uma relação.

Fica aí o exemplo de apresentação, coerência e comunicação. Fica a nossa contribuição para espalhar essa mensagem de vida e fica a dica cultural para assistir a esse documentário que já é um clássico.

Grande abraço,

Quando todos acreditavam que a Terra era plana

Quando todos acreditavam que a Terra era plana, se você perguntasse se alguém queria juntar-se a você numa viagem ao redor do mundo todos ririam da sua cara, certo? Esse é o problema do paradigma vigente. Transpondo o exemplo para nossa realidade, quando você pergunta a um cliente: qual sua necessidade para um sistema de BI, em 90% dos casos as respostas variam de um relatório simples a um relatório bonito, chegando ao máximo num Dashboard (que no caso, não vai passar de um amontoado de gráficos dispostos lindamente numa tela de um dispositivo móvel qualquer).

Pode ser uma conclusão óbvia, mas eu me dei conta disso pouco tempo atrás. Quando conversando com um cliente que precisava - um poder de forças maiores - iniciar um processo de coleta de requisitos ANTES de conhecer principios básicos de BI (o que é, pra que serve, o que a ferramenta permite etc.). Resultado? Várias páginas de solicitações para relatórios impressos e listagens com filtros mais completos do que os atuais. Conclusão: é impossível pedir que alguém expresse uma necessidade (análise de crédito em tempo real ou dar a volta ao mundo) sem que essas necessidades sejam colocadas dentro de um contexto de possibilidades.

Mas, por quê? Bom, eu ofereço humildemente duas respostas:

1. A pragmática. O ser humano vive dentro de parâmetros preestabelecidos e é preciso deixar claro quais parâmetros se aplicam quando fazemos uma pergunta.
2. A idealista. Tendemos a viver a vida dentro de parâmetros preestabelecidos, apenas uns poucos arriscaram pisar fora desses parâmetros (os primeiros navegadores, os grandes gênios como Mozart, Eistein, Newton, Camões etc.). Para os demais - nós, pobres mortais - restam os parâmetros e as regras do jogo deixadas pelos gênios.

Sem entrar no mérito de qual a melhor resposta (sugira uma aí na área de comentários), fica clara a nossa função: extrapolar as capacidades técnicas e tecnológicas para o dia-a-dia de nossos clientes, ajudá-los a enxergar os sutis sinais que os permitirão explorar os limites de suas realidades e eventualmente transformar um projeto em VALOR, seja ele aumento de receita, diminuição de receita, reconhecimento de marca etc.

Grande abraço,

A sua solução de BI já é "gente grande"?

Chega um momento na vida de qualquer pessoa e de qualquer solução de BI, em que há que se perguntar: já sou grande? Minha filha de 3 anos tem parâmetros muito claros na cabeça que definem o que é uma "gente grande": tem que trabalhar, ser bem maior que ela em estatura e ter plenos poderes de decisão sobre suas próprias ações.

Claro que o modelo usado pela minha filha ainda é simplista e vai evoluir com o tempo, mas deixa claro a necessidade de ter parâmetros - que influenciem nossas ações hoje - e que nos posicionem num grau de maturidade maior amanhã.

Enquanto pesquisava graus de maturidade de BI para um cliente, acabei achando dois modelos bastante interessantes. O primeiro (da Gartner de dezembro de 2008) é bem simples:

Na minha opinião a beleza do modelo acima está na simplicidade. Qualquer pessoa pode olhar o gráfico acima e mais ou menos se posicionar. O problema é que a avaliação é um pouco subjetiva e difícil de se definir.

Outro modelo bastante interessante é um criado pela TDWI's que pode ser lido clicando aqui. Esse modelo é mais completo e leva em consideração diversos aspectos de uma solução de BI para definir onde se está, levando a uma medida mais acurada.

Não importa a forma que você usa para medir a maturidade de sua solução de BI, o mais importante é medir, ser consistente na medição, mapear onde se está e ter claro onde se quer chegar.

Grande abraço,

Brasil Intelligence: Resultados de Junho

Dando seguimento ao nosso compromisso firmado no artigo: Como definir e calcular suas métricas - Parte 3 (Final), abaixo os resultados referentes a março:

Os resultados do último mês podem ser vistos no próprio gráfico.


Grande abraço,

Os dados que realmente interessam estão fora da sua empresa

Tá bom, eu admito: não são TODOS os dados que interessam que estão fora da sua empresa, mas grande parte. O pior é que uma grande parte desses dados de fora da sua empresa - e por tanto fora do seu controle - não são estruturados.

Me explico. Quando sua empresa faz uma campanha de marketing para reforçar o conhecimento da marca, por exemplo, como você mede o resultado dessa campanha? A primeira parte - os custos - são relativamente fáceis de se medir uma vez que, geralmente, os dados estão no ERP. O problema de verdade é: como medir a reação do público à campanha? Como saber se o público alvo foi atingido? Durante anos, a resposta, a medida dessas campanhas foi feita com base em pesquisas de satisfação ou simplesmente ignoradas. Já tocamos nesse asssunto aqui no artigo: Novos tempos: novos problemas e novas soluções.

O exemplo acima é apenas um de centenas que poderiam ser dados. Outro problemas comum é que, ao definir um KPI (alinhado com um objetivo estratégico, com a estratégia da empresa), sempre fica a pergunta: como está o desempenho dos meus concorrentes neste mesmo KPI? Infelizmente, essa informação não estava disponível.

A SAP, no entanto, promete mudar essa situação com um novo serviço chamado SAP Value Engineering. Para quem se interessar, tem um artigo bem interessante no TI INSIDE aqui. Em resumo, o serviço promete um benchmark para empresas em seus setores com comparações globais e locais. Eu acho essa uma ótima iniciativa, cabe a nós observar como esse serviço evolui e se outros grandes players do mercado embarcam nessa onda.

Grande abraço,

O Estado brasileiro já abriu os olhos, e a sua empresa?

Quando falamos de BI e, especialmente quando falamos de DW (Data Warehouse), o conceito básico diz que o DW é um repositório de informações variadas, otimizadas para consulta e para o armazenamento de informações históricas (igual ou superior a 10 anos, por exemplo).

Aparentemente, apesar de várias multinacionais ainda tropeçarem nesse conceito básico de um repositório único de informações, o famoso EDW - Enterprise Data Warehouse, o Estado brasileiro - ou pelo menos o fisco - já entendeu os benefícios dessa belezinha e caminha a passos largos para chegar lá. Como? Simples, você já ouviu falar de SPEDs e EFDs? Tem um artigo bem bacana na TI INSIDE sobre a evolução das obrigações legais informatizadas que pode ser lido clicando aqui.

Sem demérito ao FISCO, mas a ideia deles não tem nada de original. Eles estão basicamente padronizando e cruzando diversas obrigações com alguns efeitos claros:

1. forçar as empresas a cuidarem melhor de suas bases de dados, evitando erros na transmissão,
2. inibindo transações ilegais ou suspeitas, já que a verificação das informações é massiva e não mais por amostragem,
3. realizando ações pontuais e agindo nas exceções.

Em resumo, apesar da ideia pouco original a abordagem é perfeita e pode servir de exemplo para diversas empresas Brasil a fora.

A pergunta que fica é: quais são as possibilidades? Eu arriscaria dizer que se o Estado estiver disposto a seguir com essa abordagem até o fim: informatizar toda a transmissão de obrigações, armazenar e criar rotinas eficientes para cruzar as informações das diversas empresas: o céu é o limite e os "maus" empresários que se cuidem.

São conceitos de BI em prol de um Brasil sem "jeitinho"!

Grande abraço,

É possível fazer BI com Excel - discussão

Algum tempo atrás publicamos aqui no site o artigo É possível fazer BI com MS-Excel?. Graças a um de nossos leitores, o Geovanni Barros esse artigo foi o ponto inicial de uma discussão bem bacana no LinkedIn, vale a pena conferir clicando aqui.

Grande abraço,

Only because you have the tool does not mean you have to use it

Versão em português aqui.

The phrase that serves as title to this article was told in its original already in English like this: "only because you have the tool does not mean you have to use it" by Kelli Such, at SAPPHIRE NOW this year and then freely translated by me (in the Portuguese version on this article). 

 

Kelli Such is Director of Business Intelligence at Kraft Foods in Chicago, United States. And until I watch the SAPPHIRE NOW session entitled: Building Tomorrow's Enterprise Solutions from SAP with BI, I did not know her.

Actually, to see the entire session, simply visit the event website (http://www.sapphirenow.com), register for free and search by the title: Building Tomorrow's Enterprise Solutions from SAP with BI.

Since then, what changed was simple: I became Kellii's fan. Of course, not only for this sentence. But by the context, by her courage and force behind this phrase. In the midst of the biggest event organized by SAP worldwide, Kelli - under the watchful eyes of the biggest giants in the business world of "tools", shared with us this "pearl". 

The beauty of the concept is the indisputable truth of the statement together with the obviousness of it. As a rough analogy, I could say one has a hammer at home and does not need to use it. I'm pretty sure that in my colleagues circle that statement would cause, without a doubt, a hiatus in the conversation.
The unfolding of the assertion in the field of Business Intelligence and IT in general is enormous. We have been seem that BI solutions market clearly go for the plurality of tools, it is normal and natural: planning tools, reports, dashboards, consolidation, etc.. And in general, all these tools come entagleded together in a "suite" or in a package. 


The idea of ​​packing tools is in principle great. It gives to the customer the possibility to do things that he/she did not foresee or did not know that could be made. But we must avoid the dictatorship of the technology. Decisions about whether to use a tool should ALWAYS be connected directly to a business need or opportunity. 


It is clear that IT, and especially BI professionals, can and should suggest uses not yet considered by our colleagues in other areas (whatever they are: finance, human resources, marketing, production, etc.). But these suggestions MUST be related to a business need or opportunity, otherwise they are pointless.  


If someone disagrees, I have a suggestion: just go home and use the hammer.
   

Huges,

Só porque você tem a ferramenta, não quer dizer que tenha que usá-la

English version here

A frase que serve de título a esse artigo foi dita em seu original em inglês: "only because you have the tool does not mean you have to use it" por Kelli Such, no SAPPHIRE NOW deste ano e depois livremente traduzida por mim.

A Kelli Such é Diretora de Business Intelligence na Kraft Foods em Chicago, Estados Unidos. E até assistir a palestra dela no SAPPHIRE NOW entitulada: Building Tomorrow’s Enterprise with BI Solutions from SAP, eu não a conhecia.

Aliás, para ver a sessão, basta acessar o site do evento (http://www.sapphirenow.com), se registrar gratuitamente e buscar pelo título: Building Tomorrow’s Enterprise with BI Solutions from SAP.

De lá para cá, o que mudou foi simples: eu me tornei fã da Kelli. Claro, não apenas por essa frase. Pelo contexto, pela coragem e pela força por trás dessa frase. No meio do maior evento organizado pela SAP no mundo, a Kelli - sob o olhar atento das maiores gigantes do mundo no ramo de "ferramentas", soltou essa pérola.

A beleza do conceito proposto é a verdade indiscutível da afirmação aliada a obviedade da mesma. Numa analogia grosseira, eu poderia dizer: tenho um martelo em casa e não preciso usar ele. Tenho certeza que em uma roda com meus amigos essa afirmação causaria, sem sombras de dúvida, um hiato na conversa.

O desdobramento da afirmação no ramo de Business Intelligence e em TI de modo geral é enorme. As soluções de BI de mercado caminham claramente para a pluraridade de ferramentas, é normal: ferramentas de planejamento, relatorios, Dashboards, consolidação, etc. E em geral, todas essas ferramentas vêm empacotadas em uma suite, num pacote.

A idéia do pacote é ótima, da ao cliente a POSSIBILIDADE de fazer coisas que ele não previa ou não sabia que poderiam ser feitas. Mas é preciso evitar a ditadura da tecnologia. As decisões sobre a utilização ou não de uma ferramenta devem SEMPRE estar ligadas diretamente a uma necessidade ou oportunidade de negócio.

Claro está que IT, e principalmente os profissionais de BI, podem e devem sugerir utilizações ainda não consideradas por nossos parceiros de outras áreas (sejam elas quais forem: finanças, recursos humanos, marketing, produção, etc). Mas essas sugestões, DEVEM estar ligadas a uma oportunidade ou necessidade de negócio.

Se alguém discordar, eu tenho uma sugestão: ao chegar em casa, use o martelo.

Grande abraço,

Brasil Intelligence: Resultados de Maio

Dando seguimento ao nosso compromisso firmado no artigo: Como definir e calcular suas métricas - Parte 3 (Final), abaixo os resultados referentes a março:

Os resultados do último mês podem ser vistos no próprio gráfico.


Grande abraço,

A Torre de Babel do BI

O CEO entra na sala e pergunta num tom monótono: 

- batemos a meta de vendas para o mês passado?

O responsável por vendas prontamente responde: 

- Sim

No exato mesmo momento, o diretor financeiro dizia: 

- Não

Ta bom, eu sei que a situação acima é cliché e também sei que ela está exagerada. Mas o ponto é válido: em inúmeras organizações (grandes, sérias, sólidas e estruturadas) vemos diversas respostas para a mesma pergunta. Os mais afoitos dirão que existe uma resposta correta e portanto as outras devem estar erradas.

Ledo engano, em muitos casos existem várias respostas certas. No exemplo acima, por exemplo, podemos considerar: 

• vendas líquidas, vendas brutas, vendas com e sem comissão, 
• a meta de vendas para um canal específico, para uma linha de produtos específica ou para toda a empresa,
• a meta de venda para uma filial ou ponto de vendas específico ou para toda a empresa.

Apenas para dar ALGUNS exemplos. A resposta permanece: batemos a meta? Bom, sem querer chover no molhado: o problema está na pergunta. Qual meta? Que meta?

Essa é uma armadilha muito comum quando tentamos desenvolver soluções de BI: não compreender a pergunta e mesmo assim insistir em propor uma resposta. Infelizmente a realidade é mais complexa que isso, cabe a nós, profissionais da área, fazer as perguntas que deixem claro(s) o(s) motivo(s) por trás de uma pergunta. Cabe a nós garantir que conhecemos e compreendemos os termos, as definições, as formulas, as métricas, as variáveis de tempo e as exceções. 

Esse é o começo de um bom metadata e o único caminho seguro para efetivamente suportar a tomada de decisões nas organizações.

Grande abraço,

Ferramentas nacionais de BI

Uma de nossas leitoras, Deborah Barbosa, gostaria de saber quais opções estão no mercado de ferramentas de BI nacional. Além de Senior BI e Sadig. Alguém conhece outra opção? Deixe um comentário, por favor.

Template de BI, a melhor forma de ser igual a todo mundo

Se você é cliente, provavelmente já perguntou em uma reunião de avaliação de software de BI: "essa ferramenta traz templates para o meu modelo de negócio?" e se for um consultor ou responsável pela implantação de uma solução de BI, já se pegou desejando que aquele problema tivesse um guia de solução, tenho certeza.

A verdade é que a maioria das ferramentas de BI traz ou tenta trazer algum template para medir o básico: vendas, contas a pagar, contas a receber, gastos, giro de estoque etc. Algumas empresas dão ótimos nomes a esses templates. A SAP chama seus templates de Business Content.

Mas qual o real benefício que esses templates podem trazer? Vale a pena usar esses templates? Templates são de fato respostas mágicas e maravilhosas para todos os problemas?

Em primeiro lugar eu tenho que fazer uma ressalva: esse texto se refere de forma geral a templates e não a um template em específico. Ou seja, TALVEZ existam templates melhores que a média e certamente existem templates BEM piores.

Minha opinião é clara e já está dita no título desse post: templates são ótimas ferramentas para deixar a sua empresa exatamente igual a todas as outras. Por definição, templates são criados a partir das "melhores práticas" do mercado e portanto deveriam refletir o "estado da arte". É difícil imaginar que alguma inteligência (afinal de contas, fazemos Business Intelligence) pode ser empacotada de forma genérica para qualquer empresa e indústria, não?

Usar os templates, por outro lado, pode acelerar consideravelmente a implantação de indicadores e métricas, além de indicar o caminho a se seguir e estabelecer importantes baselines para começarmos a trabalhar. E por esse motivo, não podem ser ignorados completamente.

Aqui vão algumas dicas antes de sair usando templates:

1. se a sua empresa quer liderar tendências, você deveria pensar duas vezes antes de usar um template de BI. Motivo? Simples, todos os seus concorrentes estarão usando templates parecidos;
2. acredite em templates construídos por quem tem experiência no sistema transacional e não no sistema de BI. Motivo? A empresa que cria o sistema transacional conhece muito bem as regras de negócio e peculiaridades daquele sistema, nenhuma garantia quando o template vem do sistema de BI diretamente;
3. em geral, templates são ótimos para métricas e atividades mais parecidas com commodities. Coisas do tipo: DSO, AOD, Stock Out etc. Métricas e indicadores que são razoavelmente os mesmos em diferentes indústrias e empresas;
4. templates não são verdades absolutas. Usá-los para tornar o processo de implantação mais rápido, para estudar como o fabricante recomenda fazer ou mesmo para partir de um ponto inicial (baseline) é uma ótima idéia. Mas é preciso ter olho crítico e saber decidir o que faz e o que não faz sentido para a situação em questão.

Grande abraço,

Brasil Intelligence: Resultados de Abril

Dando seguimento ao nosso compromisso firmado no artigo: Como definir e calcular suas métricas - Parte 3 (Final), abaixo os resultados referentes a março:

Os resultados do último mês podem ser vistos no próprio gráfico.

Como dá pra ver, o carnaval e o sapforum tiveram um impacto na nossa evolução mensal. Vamos acompanhar.

Grande abraço,