This is the first in a series of posts where I provide some ‘quick tips’ based on real life scenarios that I have encountered whilst on site delivering QlikView projects.
In this first post I encourage you to delete your QlikView apps.
Setting The Scene
The remit from the client was to provide some assistance streamlining a particularly arduous reload schedule. They had data coming in from depots around the world in Excel spreadsheets. Although a template had been provided once the format from each depot had become different over time, and worse still often changed from week to week. The IT guy didn’t really know the people sending him the data or what they did with the QlikView app he battled to reload each week.
The obvious technical solution to this was to produce a data definition spreadsheet that listed each data source and defined columns and header rows etc for each spreadsheet – so that list could be enumerated around and each file could be loaded in a single loop. Simple.
However, instead of launching into building that solution I asked about who was using the report. What were they doing with the data? Could we engage key users in improving the solution? The answer was that they didn’t know, and they had no easy way of finding out. Step one was therefore to upload and configure QlikView Operations Monitor.
My first reaction was that logging was broken. There had been only two users of the document in the past twelve months. These were the IT guy I was sat with (who tested it on set-up) and someone else in his team who checked the numbers occasionally. The actual intended recipients of the data were not in the logs at all. We decided to test the logging, by getting one of the users who should have been using the document to ‘check something for us’. Sure enough, when he followed the link he showed up in the log soon after.
Where To From Here?
The simple way to speed up the load process was to stop doing it, and simply delete this QlikView app that nobody was using. I armed the IT guy with a spreadsheet showing usage and he was then set to go and argue this with the business.
I reasoned this was going to be my shortest day on site ever, but fortunately I was able spend some time positioning what QlikView could bring to the business and how IT could become champions by delivering this.
In Conclusion
That was just one example of when deletion was the best approach – because the implementation hadn’t been set about in the right way from the off (see post on Starting Your QlikView Project The Right Way). More frequently however, redundant apps come about through sheer volume of apps being pushed to Access Point and no monitoring of who is using what going on. Development, test and simply superseded documents can create clutter and overheads – as reloads may still happen on them and staff may maintain apps despite them bringing no value (and even potential risk). Development and test documents should be on a production server only temporarily – if at all. Keep an eye out for apps that are for a specific time bound period also.
I’m not suggesting a programme of random deletions of useful apps – but I would suggest that keeping on top of what is useful and what is simply not can save you a lot of time and money.
Look out for the next post on QlikView Themes.
Hi Steve,
Excellent post and a very sensible approach. It’s always a good idea to occasionally ask the question “Should we still be doing this?” and the Operations Monitor is a very useful tool to confirm (or refute) your suspicions.
Cheers,
Barry
Even smarter way of doing it. Download the free QlikView Data Governance Dashboard from our QlikMarket here: http://market.qlikview.com/qlikview-governance-dashboard.html
Thanks
Marcus