I just got back from the 2012 QlikView Qonnections Partner conference, where Infinity Info Systems was presented with the "Implementation of the Year" award for the Americas region.  This award is given annually to the partner with the best QlikView deployment as measured by customer satisfaction, technical proficiency, and overall value.

Leveraging our Life Sciences industry expertise and enterprise-level technical ability, Infinity empowered a pharmaceutical sales force with key analytical information so that they could spread their life-changing drugs to more people.  The implementation started out with just eight people and the value was so immediate and tangible that the dashboards and analytics were expanded to the entire sales force (and its leadership).  QlikView is now used daily by over 160 people!

One of the key reasons for the implementation success was Infinity’s understanding that existing processes do not change overnight and that the most effective solutions are often evolutionary, not revolutionary.  By shaping Business Intelligence (BI) around a business as opposed to requiring wholesale changes to IT and data flow, Infinity was able to deliver an easy, intuitive application that allowed the sales force to make better decisions with accurate data delivered fast.

Now QlikView users access secure, customized BI applications through a web portal while also receiving emails and reports as supplementary information aids.  This new paradigm replaces an old system that used static spreadsheets generated from outside vendors which suffered from slow delivery times and an inability to adapt to the changing needs of the sales force.  Now, analytics can change at the speed of business.

If you’d like to learn more about QlikView or Infinity’s BI offerings click the image below.

There are two questions that I see a lot, hear a lot, and get asked a lot: What is QlikView? And can QlikView support/do ? Here are some thoughts to point you in the right direction:

There are a lot of terms out there used to define QlikView: In-Memory Analytics Tool, BI Tool, Visualization/Dashboard Tool, ETL tool, etc. While QlikView is all these things, I tend to use a different phrase to describe it: data discovery platform or framework (QlikTech uses a similar term: business discovery platform). I like this phrase because it helps convey the idea that QlikView is not just a simple application that lets you take data and use it (e.g. Microsoft Excel, Access). QlikView is a framework that lets you develop your own analysis platform for your data. Now wait, that doesn’t mean that you download it and then it figures everything out on its own, you must go through the following steps:    

1. Data Discovery – Do you understand your data? Do you know its limits? Do you know its strengths? Do you understand the data sources? This is the single greatest failing of any Project (QlikView or otherwise): not understanding what your data can do vs what it can’t do. Spend time on this step. Make sure you, your users and developers understand the data, the various links, the sources, the strengths, and especially, the weaknesses.
   
   QlikView can help as early as this step; however, this step is not about fancy visualizations and dashboards. It’s about understanding your data’s personality and its nuances. Many organizations decide that they need help with this step; they need a fresh pair of eyes, so they bring in a consulting company to help. Great idea! Make sure that this company understands the importance of this step. Also be sure to involve your users, they should be a part of this process from the very beginning. To get the most out of the platform, you must understand the underlying data. Don’t skip this step!
   
   
2. Requirements Gathering – What are you trying to accomplish? Perhaps it is directly related to the data – perhaps not. Do you understand what you want? What do your users want? Based on your understanding of your data, is it possible? Requirements might be specific functionality, specific views, visualizations, etc. Start with a product agnostic view – don’t think QlikView, just think results, what do you want to see? What do your users want to see? Is it possible? What needs to happen for it to be possible?
   
   
3. Understand QlikView – Can QlikView support/do ? Probably. QlikView can do a lot of things; it supports a myriad of deployment scenarios and is quite flexible and extensible. But as I pointed out before, you don’t just download it and things start magically connecting themselves. You need to understand how to best use QlikView and how to unlock and harness its power:

• • Read all you can.
  • Ask the right questions.
  • Get official training, learn the best practices.
  • Realize that QlikView is different from what you are used to. QlikView is not cubes, it is not .NET, it is not PHP, it is not C, it is not Analysis Services – don’t treat it like it is.
  • Be prepared to learn some new ideas that may be in conflict with past learning. The procedures you used to manage all your other development projects probably won’t work the same here. The QlikView development life cycle is different from what you are used to, it’s faster, more flexible, and more agile. Understand this, learn about it, and try it out. You’ll be surprised at the success.

QlikView is more about the user and the data, than it is about the developer, or the IT staff. It’s about giving users what they’ve always wanted: power to analyze their data how they want without consuming precious IT and development resources. It is truly a paradigm shift – a user revolution. Are you ready to unlock your data? 

I’m often asked about the different license types of QlikView that are available. There are currently four different types of CALs: Named User; Document; Session; and Usage. I think the chart below from QlikView walks through all of these in great detail, however, if you have any questions, please just post them in the comments and I’ll be happy to answer them.

The QlikView report layout can be notoriously hard to work with.  It can even seem defiant at times.  Objects have a tendency to move around and are difficult to arrange.  Having an understanding of ‘why’ will not make all of the issues go away, but at least you’ll be informed enough to avoid some of these layout caveats.

What it all seems to boil down to is the grid.  Any slight movements with the mouse send the object flying off into what might as well be the abyss because you have to start over when this happens.  What’s happening is the object is looking for the grid when you let go of the mouse.  No gridline?  Then it’s erroneously placed somewhere else.

See the grid below in the QlikView sheet object.  I created the olive textbox to fit inside the sheet grid.  Its dimensions are 80x30.  Each grid block is actually 80x80. 

 

Under layout in the Report Editor, you can turn on Snap to Grid.  

However, the grid in the report does not match the grid in the sheet; its dimensions are still uniformly distributed.  The width of a block is 20 in the Report Editor.  Its height is 30. Obviously it doesn’t make a lot sense to have two different grids and you’re trying to move objects between them, but that’s just what we have to deal with. 

So what does this mean to you?  Well, we now know that if we make the width of our objects some multiple of 20, it will distribute itself evenly across the grid.  Alignment issues can be totally avoided if you follow this rule.  If you’ve worked with this report editor before, you may already be dancing in the street at this point.  

The height only really matters if you center objects with different heights horizontally.  In most cases, horizontal objects will be top-aligned and the same size so I don’t foresee this as a problem we would encounter often.

Obviously, this presents an ideal scenario where all of your objects can be created with this way.  This isn’t always possible.  As you might have noticed from the screen cap above, the charts are not aligned the way I have described using the 20 rule.  This is because I already have charts created and I’m not recreating them to build this report.  What needs to be done to handle this situation is a manual edit of the item settings width and height.  This isn’t perfect and you’ll still run into sizing issues but it’s the easiest way to accomplish cleaner placement if you can’t use the grid.  The mouse should generally be avoided in report editing unless you’re doing the initial drop or right-clicking to get to the item settings.

Hopefully as a QlikView Developer you’ll find this helpful, I know I did!

There’s an age-old criticism about Pie Charts – allegedly, they are inadequate, difficult to understand, and it is better to choose a different visualization (e.g. Bar Charts). Business folk usually cringe when they hear this, and, inevitably, a debate ensues.

I admit I am one of the perpetrators of said criticism. I’ve seen too many bad uses of Pie Charts that imagining a good use can be difficult.  When I design dashboards for our clients, I try to offer a neutral position, and instead of criticizing the Pie Chart , I allow each user to make their own, informed decision. So I wanted to share those thoughts with you all as well.

First, I will share the very first paper I read on the subject: Stephen Few’s Save the Pies for Dessert (2007). While I won’t summarize Stephen’s findings or opinions – it is important to know that much of the criticism facing Pie Charts today, from BI and Data Visualization professionals, stems from this paper. You may have read this piece before, if you have, read it again, this time, however, imagine it as an Op-Ed piece and not a front page story. Don’t allow yourself to be enraged at the Pie Chart – or those who use them incorrectly – rather read carefully and try to understand the author’s frustrations.

Robert Kosara of eagereyes.org wrote a piece in 2010 called Understanding Pie Charts. Read it much the same way as you did Stephen Few’s paper. You’ll notice that Kosara helps us to understand that Pie Charts are actually very powerful and useful, but the real tragedy is those who use them tend to use them incorrectly – thus feeding the criticism. In 2011 Kosara wrote something of a follow-up: In Defense of Pie Charts. Here Kosara examines the very same psychological study cited by Few in his paper on the subject. Much like the previous two pieces, read this post carefully and digest the information.

So Pie Charts can be great, but they can also be completely useless. Do your research, ask the right questions, test it out – but most importantly, make your own decision based on your data, your audience and what they need to see.

I’ll leave you with one final piece to read – Stephen Redmond’s Defending Pie Charts. It’s a very simple example of using Pie Charts for a “part-to-whole” comparison. Check it out.

Has your opinion of Pie Charts changed after reading a bit more on the subject?