3 dicas para sobreviver como um consultor SAP BI em 2015

Quer sobreviver como um consultor SAP BI em 2015? Da uma olhada no meu artigo na SCN: http://scn.sap.com/community/bw-hana/blog/2015/01/29/3-tips-to-survive-as-a-sap-bi-consultant-in-2015

abraço
Eduardo

Nova parceria: Carina Mendes

É verdade que não tenho conseguido manter a periodicidade das publicações por aqui. Mas de tempos em tempos, ainda deixo aqui meu recado (ou no site da SCN).

É com muita satisfação que anunciamos mais uma parceria com o Blog da Carina Mendes (http://carinamendes.com/). Recomendo!

Abraços,

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

Pocket BI

Para ler este post em português clique AQUI

Everybody likes what is new and fancy. In this information era everyone gets the information in a click, faster them they could possible imagine a few years ago, but how to assimilate all this information? We are seeing a new whole generation of people who can actually consume faster than us, simply because it’s normal for them as it was normal for us to read a newspaper back in the days.

Happens now that we are exactly between this new and old generation. As in the article Information on your fingertips posted here, never was so easy to get all dashboards and strategic analysis consolidated from a huge amount of information not only locally but globally centralized in one single device like your mobile or tablet which can tell you what you should know to make your decision.  Sales department knows how valuable this real-time information is, in order to accomplish their target on time, however is it really for everyone?

Although from IT perspective, thinking that everyone would have the same opinion, business are more and more flooded with information which sometimes they are not prepared or convinced that they really need that. Their tight schedule and short time between meetings and agreements are another obstacle to contemplate this new output.

I've seen how fine mobile developments can help a lot of operational work simply by reducing the amount of information and transforming it into readable charts that represents what they must know to make their decision on time. Moreover, it's an excellent interface to support decisions on higher levels which are more complex and requires more time, analysis, plan and simulations.

What’s your opinion about this? Is the acceptance of BI on mobile device often used in your company by managers or operations? Please leave your thoughts.

_______

Gabriel Ozaki - SAP Consultant for 8 years, has been working in several knowledge areas for ERP and Business Intelligence additionaly to coordination, solution architect and training. Focused on new trends and technology, is always up to date with the market innovation. Linkedin profile: http://ch.linkedin.com/in/gabas