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

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,

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,

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,

Brasil Intelligence: Resultados de Março

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,

Brasil Intelligence: Resultados de Fevereiro

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

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

Continuo achando que ainda é cedo para dizer alguma coisa sobre os resultados, mas existe um forte indício de que as metas que estabelecemos foram muito pessimistas. Talvez no fim do primeiro trimestre tenhamos que revisar essas metas. Vamos acompanhar.

Grande abraço,

Brasil Intelligence: Resultados de Janeiro

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

Acho que ainda é cedo para dizer alguma coisa sobre os resultados. Prefiro fazer uma análise mais detalhadas no fim do primeiro trimestre.

Grande abraço,

Como definir e calcular suas métricas - Parte 3 (Final)

Nos últimos dois posts que publicamos falamos sobre como definir métricas:

• Como definir e calcular suas métricas - Parte 1 - foi uma definição conceitual de o que são métricas,
• Como definir e calcular suas métricas - Parte 2 - foi uma descrição lúdica de quais métricas valem a pena medir e riscos de escolher a métrica errada

O que faltou? Bom, na minha opinião faltou um case real de como definir suas métricas e indicadores ligados aos objetivos organizacionais. Por esse motivo, fecho essa série de 3 artigos com um estudo de caso: definir os objetivos organizacionais do nosso site: Brasil Intelligence e os melhores indicadores para medir o seu desempenho.

Primeiro, o que mais importa: quais são os objetivos organizacionais do nosso blog para 2011? Como esperamos terminar o ano? Em primeiro lugar, estabelecermos o que gostaríamos, nossa missão:

"Queremos ser o blog independente referência em Business Intelligence no Brasil, com um conteúdo atual, acessível, sólido e coerente que favoreça discussões e troca de experiências e se transforme na plataforma na qual o futuro do BI nacional será definido."

Bom, depois da definição de nossa missão, vocês devem ter percebido duas coisas:

1. O Brasil Intelligence ainda está longe do seu objetivo
2. A equipe do blog é bastante ambiciosa

Como não podemos fazer milagre, o próximo passo é definir a curto prazo (durante 2011 no nosso caso) quais objetivos realistas podem ser estabelecidos para tornar nossa missão realidade a longo prazo. Abaixo nossas conclusões:

1. Aumentar nossa base de leitores,
2. Integrar esforços das diversas mídias sociais nas quais o blog atua hoje (Blog, LinkedIn, Twitter) para possibilitar e fomentar discussões trazidas pelos leitores,
3. Registrar nosso domínio para fortalecer o comprometimento com o projeto e auxiliar a construção da nossa marca,
4. Conseguir cobrir os custos do blog com o próprio blog (basicamente com registro de domínio e hospedagem).

Objetivos rascunhados, falta deixá-los mensuráveis:

1. Base de leitores
1. Aumentar o número de visitantes únicos/mês de 300 para 600 até dezembro de 2011,
2. Aumentar o número de seguidores no twitter dos atuais 35 para 100 até dezembro de 2011 (o que aumenta a proporção em relação aos visitantes únicos do blog),
2. Mídia social e colaboração até dezembro de 2011
1. criar uma página no Facebook
2. ligar a página do Facebook ao nosso blog
3. ligar a página do LinkedIn ao nosso blog
4. criar uma lista de discussão para nossa comunidade
3. Registrar domínio e hospedagem até dezembro de 2011
4. Aumentar a arrecadação com o Google Adds dos atuais 0.29 USD/mês para 2.45 USD/mês.

Olhando os objetivos mensuráveis acima, chegamos a uma próxima conclusão: nem todos os nossos objetivos podem ser colocados em lindos gráficos. Parece um pouco decepcionante, mas reflete bem a realidade do mundo cooporativo. Na prática, quando temos objetivos para o ano do tipo: abrir uma nova filial, montar uma força de vendas para o produto X etc., nos deparamos com situações nas quais nossas ferramentas de BI podem nos ajudar, mas de forma limitada.

Tudo considerado, criei a visualização abaixo que pretendo atualizar todo último dia do mês e dividir com vocês:

Claro que contamos com a colaboração de todos vocês para nos ajudar a transformar nosso sonho em realidade.

Espero que tenham gostado, aguardamos sugestões e críticas.

Grande abraço,

Páginas 1 - 2 - 3

Dashboard: visibilidade, resultados e dúvidas - Parte 2 de 2

Como prometemos!

No post anterior: "Dashboard: visibilidade, resultados e dúvidas - Parte 1 de 2", falamos dos aspecto conceituais de um Dashboard. Mas o mundo não é um conceito e saber utilizar conceitos em termos práticos é uma qualidade de poucas pessoas.

Pelo que pudemos observar, a equipe de IT da DIVICOM está fazendo um bom trabalho liderada por Rafael Quadrotti, gerente de Informática da empresa.

A receita parece fácil. A equipe do Rafael foi capaz de:

1. reunir indicadores já existentes;
2. utilizar-se de uma tecnologia de mercado já usada na empresa - Protheus - para evitar re-inventar a roda;
3. conseguir o suporte de pessoas-chave na organização;
4. ter o objetivo de resolver um problema na organização;
5. manter a discussão nas necessidades de negócio e não em detalhes técnicos (veja mais detalhes no artigo: "Eu só quero um relatório simples que...").

Resultado? Um Dashboard simples, reutilizando ferramentas existentes e que de fato atenda a uma necessidade de negócio.

Ainda segundo o Rafael, a idéia não é parar por aí. A DIVICOM já está trabalhando em uma PoC (proof of concept - prova de conceito) em QlikView, colhendo os louros do primeiro projeto. Esse é o espírito, melhorar sempre trazendo valor ao cliente, seja ele interno ou externo.

Abaixo vocês podem conferir a entrevista na íntegra*:

BRINTELLIGENCE - Por que vocês iniciaram o projeto de Dashboard na DIVICOM e quem iniciou o projeto (IT ou alguém do negócio)?

Rafael Quadrotti: Ele se iniciou com uma proposta simples. Entendendo nosso cenário: a TI não possui budget fixo, com isso, todas as aprovações de custos pequenos ou grandes devem passar sempre pela direção financeira. Surgiram necessidades críticas de visão gerencial e de controles que precisavam de uma nova solução sistêmica centralizando diversas informações e definindo os atuais KPIs. Onde surgiram estas necessidades: no financeiro. Ótimo. Foi a oportunidade que encontramos para apresentar uma solução mais inteligente: um Dashboard. Não chegamos a encarecer o projeto, ao contrário, ele foi bem estimado. Desta forma este foi nosso início. Uma necessidade de uma área e uma oportunidade entendida pela TI.

BRINTELLIGENCE - Qual era o objetivo para a implantação do Dashboard? O objetivo foi atingido?

Rafael Quadrotti: O objetivo do Dashboard era a visualização de todas as receitas e despesas em um único local, gerando o resultado operacional da empresa permitindo o drilldown de informações até o nível de um usuário. (Importante, estamos falando de resultados em planos de saúde).

BRINTELLIGENCE - Vocês foram capazes de medir resultados gerados pela implementação do Dashboard?

Rafael Quadrotti: Não diretamente. Quando a ferramenta entrou em produção o antes e o depois foram perceptíveis. O ganho foi em gestão, tomadas de decisões mais rápidas propiciadas pela análise. Hoje esta ferramenta é o coração da gestão Financeira da empresa.

BRINTELLIGENCE - Como definiram os indicadores relevantes?

Rafael Quadrotti: Eles já existiam, traduzimos para uma ferramenta da mesma forma que o usuário estava acostumado.

BRINTELLIGENCE - De onde vem os dados mostrados no Dashboard?

Rafael Quadrotti: Do ERP, de sua base transacional.

BRINTELLIGENCE - Como foi o projeto? Traumático? Qual foi o maior desafio?

Rafael Quadrotti: O projeto foi tranquilo, pois não aguardavam ansiosamente. A entrega foi mais complicada, pois quando notaram o poder da ferramenta, fora inúmeras as solicitações de ajustes e melhorias para chegar ao ideal de vários gestores.

BRINTELLIGENCE - Falando em números: quantas pessoas participaram do projeto? Algum suporte de consultoria? Qual foi o investimento aproximado?

Rafael Quadrotti: 1 Gerente de Projeto, 1 Analista de Processos e Negócios, 1 Consultor SR., 1 Desenvolvedor SR., 3 Stake Holder e Sponsor: Diretor Financeiro.

BRINTELLIGENCE - Algum conselho para quem vai começar um projeto agora?

Rafael Quadrotti: Meu caso é muito peculiar, mas pode ser a fórmula para que tecnologias que aparentam ser muito caras possam ser adotadas nas pequenas empresas.

Os conselhos são os mesmos: atenção ao escopo do projeto; tenha um Sponsor realista e envolvido; foco nas entregas e aceite as alterações coerentes, pois estas alterações permitirão uma transição tranquila; documente; documente; documente; comunique; comunique; comunique. O cliente final precisa estar ciente de tudo. Sempre.

Sobre a DIVICOM: a Divicom é uma empresa de gestão na saúde, que aplica a experiência de cada profissional da empresa nos processos operacionais e estratégicos das organizações de saúde. O caráter inovador do escopo de serviços que a Divicom Administradora de Saúde desenvolve, considera soluções de gestão de custos, receitas e revisão de processos para o segmento da saúde, assim como também a consolidação de vantagens competitivas para operadoras, hospitais, empresas de autogestão e outras corporações do segmento.

Caso você também tenha um case interessante que queira dividir, entre em contato ou deixe um comentário.

Grande abraço,

* As respostas do Rafael Quadrotti foram escritas por ele mesmo, por isso, passaram somente pela revisão ortográfica. Concordância e pontuação não foram alteradas.

Dashboard: visibilidade, resultados e dúvidas - Parte 1 de 2

Chega um momento na vida de toda empresa e, mesmo na vida de todo executivo, em que já é tempo de criar um Dashboard.

Modismos à parte, um Dashboard pode ser muito útil no suporte à tomada de decisões. Mas o que é um Dashboard? Pra que ele serve? Como implementá-lo? Como torná-lo usável? Como garantir consistência? Qual tecnologia utilizar? Quais KPIs considerar? São apenas algumas das muitas perguntas confrontadas pelo pessoal de TI de cada empresa.

Para ajudar a responder essas perguntas, estamos publicando uma série de 2 artigos sobre o assunto. No primeiro artigo, este, abordaremos as questões mais conceituais. Na segunda parte, teremos uma entrevista inédita com Rafael Marchete Quadrotti, Gerente de Informática da DIVICOM e principal responsável pelo projeto de Dashboard lá.

Há alguns anos, eu fui um dos apresentadores de um case de Dashboard no SAPFORUM, você pode conferir a apresentação aqui. Apesar dessa apresentação ter sido feita em 2008, Dashboard ainda é um assunto em voga e merece atenção de profissionais de BI e executivos de TI.

Caso você esteja buscando uma definição mais "formal" sobre Dashboard, eu recomendo a versão resumida da Wikipedia que apesar de curtinha, tem links para diversas outras fontes. Com a evolução do conceito, Dashboards tem sido usados em áreas diversas - incluindo motivação e auto-ajuda. Um exemplo pode ser visto nesse vídeo:



De acordo com minha experiência, um Dashboard é: um conjunto de indicadores apresentados com visualização otimizada (gráficos, tabelas resumidas, links para mais informações) sobre um determinado assunto.


A definição proposta acima não é acadêmica, mas eu a considero bastante completa:

• um conjunto de indicadores --> porque um indicador sozinho não caracteriza um Dashboard;
• com visualização otimizada --> porque um monte de tabelas juntas ou gráficos que ninguém entende não caracterizam um Dashboard;
• sobre um determinado assunto --> é importante ter FOCO ao se construir as visualizações do Dashboard. Três fatores são limitantes:

1. o espaço disponível na mídia de apresentação (a tela do computador, por exemplo)
2. a quantidade de informação que uma pessoa pode assimilar (numa regra não científica, algo em torno de 7 indicadores no máximo)
3. por último e mais importante, o bom senso. É importante não colocar informações inúteis no Dashboard apenas porque "alguém pode querer ver". Pior que não ter informações é ter informações confusas e desencontradas.

Na próxima semana, publicaremos o case da DIVICOM com o Rafael. Até lá.

Grande abraço,