As a freelance QlikView consultant I can be drafted in at any stage of a QlikView implementation. My favourite sites tend to be the ones where I come in and do the initial demo to the client (not least because I love seeing the moment when jaws drop in the demo) and then build the solution from the ground up. Often though I am called in where a lot of effort has been expended already but things have got to a sticking point and someone decides expert help is required.
All too frequently what I find when I arrive on site in these cases is a mess that needs to be untangled. Usually it is not because insufficient resource has been put into the implementation and very seldom is it that the people involved (sometimes other consultants) do not know what they are doing. What is common though is that things haven’t been thought through and executed in the correct way right from the start.
So, why is this, and how can it be avoided?
One major contributing factor can often be the ‘SiB’. SiB stands for Seeing Is Believing, and for a long time it was promoted by QlikTech as a way of hooking new clients – and it works. I’ve done many such sessions, where I have turned up on site in the morning, been handed some data or a connection string and by 4pm have built a working document analysing company data that I then present back to the business in a review session at the end of the day. Invariably there is much excitement in the room as people are shown the results – particularly when they identify things about their own businesses that they were not previously aware of. The sale is in the bag, licences are bought, the customer is happy and projects commence. So, where is the problem? It is that all too often this prototype that is built in a day or two becomes the bedrock for a whole implementation. This causes issues as the developer will not have given a lot of thought to architecture or structure (or usually even lunch) and it will rarely be the correct start point for a full blown implementation. I always recommend that the SiB document is put to one side ‘for reference only’ and then the real build can start. Sometimes however this doesn’t happen. If you are commissioning a SiB I would follow this advice:
See It. Believe It. Bin It.
It sounds like clichéd business speak (and it is), but it is important to see the big picture before embarking on an implementation. Whilst it is a good idea to look for the ‘quick wins’ early on in a project; some thought needs to go into how things created at this stage will fit into the completed whole down the line. Only then can thought be properly given to architecture and how things should be structured.
Even something simple like ‘should we go for one big document or many small ones’ deserves some thought – and indeed I have blogged about this very consideration before (Bring Together Or Break Apart). A common failing that I have seen is the folder structure on the server not being thought through in advance – which can lead to problems with implementing security and building a Dev/UAT/Live procedure down the line. What I am trying to say in a nutshell here is not to leave things to chance – work out where you are trying to get to and plan how best to get there.
The single biggest issue that will cause a QlikView implementation to have the potential to go wrong is the data model. There are a number of best practices that should be followed (some of which are referenced in my other blog posts) that are often overlooked. The golden rule here is to simplify. What all to often happens is that the data model from the underlying source database is pulled in, with its existing join fields and system field names. A developer will be forced to deal with some immediate issues, such as synthetic keys, but will sometimes (once they have something that ‘kinda works’) leave it at that. This can sometimes be okay on small data volumes – but it certainly will not scale and causes much extra effort down the line.
As perfecting the data model and approaching it in the right way is such a fundamental part of the process I am going to cover this in a separate post, to follow soon. (See: Perfect Your QlikView Data Model)
The thing to always be aware of is that anything that is done should be thought through up front and not left to chance. This does not necessarily mean that things will take longer – in fact it is more likely that time will be saved by you not having to revisit things later.
There is a lot of advice and documentation out there on best practices with QlikView and following these best practices will undoubtedly mean that your projects are more likely to succeed.
Good post Steve. Thanks gor sharing.
Thanks Steve,
I totally agreed with this post, and specially with the fact that what have been built during a SiB should be discarded. SIB is “quick and dirty”, answers generaly one business cases, makes a lot of assumptions. Many customers expect some gains in reusing the SIB prototype, Sales guys use it as a sales pitch but I always advise to (re)start with a full project methodology, SiB are definitely not part of the implementation!
Here here, well said Steve. For me it always comes back to really simple building blocks, and remembering that the first three of the five listed below should account for about 60% of your time.
I came up with an easy accronym for this.:- I’M DIM
Investigate
Model
Design
Implement
Monitor & Fine Tune
Great post Steve.
I generally find it difficult the articulate exactly what it is Qlikview does, and often find I am trying to rush the client to an SiB session.
And sometimes the client reaction feeds the rush from SiB to finished solution without due consideration for best practice.
But as you say, this can cause extra effort down the line.
Look forward to your future posts on perfecting the data model!
Many thanks for your comments.
Just to let you know that Part Two of this post is now available:
https://www.quickintelligence.co.uk/perfect-your-qlikview-data-model/
Obviously the SIB is very important but on the more complex projects it might be useful to have some more formal structure to the dashboard. I propose a possible qlikview folder structure in this article:
http://webofwork.com/index.php/2-uncategorised/84-qlikview-project-folder-structure
Hi Adam, Thanks for your comment. I completely agree about having a formal structure and the one you propose in your article seems like a sound approach. I’ve commented there regarding how my own structure differs slightly.
great post. can you recommend a good folder structure for server/publisher that would be flexible for dev/uat/production setup like you mentioned? since you said it is number one issue for new projects, i think a lot of people would benefit if you can share your experience
I tend to start with either a QlikView or ‘QlikView Documents’ folder at the top level. Under here will be folders such as Root (for PGO files), Logs, QVD Generation, Data (for QVD), Source Data (for XLSX etc.) and then Published. The published folder is where QVW files for presentation to Access Point will live, and typically this is split down into business unit folders (eg. Sales, HR, Exec) and the a System folder for Ops Monitor etc.
Hope that is helpful.
Very helpful, thank you, Steve!
Agreed Steve and its very much true.. Thanks!
Great article Steve. Very helpful. Will go a long way in keeping things simple yet effective.