Roll out of QlikView

[Anonymous]

I'm new to this forum and wondered if anyone could share their experience of set up of QlikView. I've recently purchased QlikView for my company and we are working with Castle Consultancy to set it up and complete the builds. Does anyone have any experiences they could share during the set up of QlikView and work with their consultants to complete this? I'm really keen to learn what to avoid during this process, or to have tips on good practice. Any advice would be appreciated!

[Anonymous]

Shae

Have a look at the QlikCommunity QlikView Deployment Framework Group.  Loads of useful things in there regarding Deployment & Implementation.

Best Regards,     Bill

[Clever_Anjos]

• First of all, have a good involvement of business staff (Accounting, Financial, HR, Sales). They are the main user areas.
• Plan ahead which applications will be delivered to your users.
• QlikView supports quick development times, so 'release early, release often'. If you have 100 requirements, dashboards, analytics and reports, asks your users which ones are the most important and try to deliver as soon as you can. Using some agile development methodology like SCRUM could be an effective way to have weekly or bi-weeely delivers

[#4]

Check this Doc...

Hope It helps

[datanibbler]

Hi Shae,

welcome to the community!

I'm in the same situation as yourself, I'm in charge of the QlikView_rollout and everything involved (from development to management, everything as in everything 😉

Maybe we can share some of our experiences.

Will the people in your company all have the client_software or will they be using a browser? - for us, it's the latter. That way, you don't have to regularly update it all and the danger of someone changing something inadvertently is lower, but there are drawbacks.

What server setting do you have? Do you have (access to) the QlikView_management_console?

Maybe one thing which me and my colleagues are regularly stumbling over: Have a process set up early on so that you will be informed whenever some underlying list (excel or whatever) is changed or moved

HTH

Best regards,

DataNibbler

[sujeetsingh]

Just go through the Qlikview Server Manual

[#7]

I can only tell you how we did it, and I'm sure that your requirements will be different, but here goes.

The idea of 'release early, release often' is definitely the way to go. We tried to involve users, but they were reluctant to come up with ideas, so we gave them what we thought they would like. Once they saw what they had, they were quick to tell us what they REALLY wanted. All through the implementation, in fact right up to the present time we stress that our QlikView dashboards are work in progress and that we always welcome ideas. We have users who really, really embrace the concept, and they now provide us with a steady stream of ideas.

Try to get the product in the hands of the 'workers' and not just the managers. These are the people who use the data on a daily basis. It's their data and they should get a say about how it's shown.

Finally, if you find the idea of developing dashboards a little daunting, get your QlikView partner to sit down with you and develop something together. Then, when the consultant has gone home, pull the dashboard to bits and find out how it really works. Then use this as a template for your next project.

J Barbour & Sons have been running QlikView for nearly two two years now, and it's been a huge success. More than thirty projects. Over seventy users and still growing.

Good luck, and remember, make learning fun.

John

[Anonymous]

Thanks everyone for your replies, I wasn't sure I'd even get one let alone several responses. Has anyone worked with Castle Consultancy? Any tips here?

[datanibbler]

Hi John,

what you tell is absolutely correct - unfortunately, in my experience, things are not always feasible according to "best practice" ... In our company, we got quite a nr. of standards concerning the layout of Dashboards for the individual areas and they should all have a uniform appearance.

That also led me to m.o.l. use only bar- and combo-charts in my apps, none of the other chart_types.

- We have tabs deactivated as a rule and a navigation_bar on the left-hand side of every sheet of every app, with a button for each chart in the app, in always the same order.

- Then we have a textbox with meta_data (who made a chart, when was it last reloaded, who is responsible in the operative area) and a multi_selection_box.

- Finally, we have a separate diagram with historical values (I use the prior week and the prior month) for every chart; That was a requirement from top_management.

=> All that reduces the screen_space available for the actual data to about 1/3.

But, back to Shae's question, a template is definitely a good idea. There should even be several (or several sheets/ objects in the template) for whatever you want to build in a new app so that you don't have to adjust everything all over again.

Just one more addition by myself: There are two or three places in the properties_dialog to set things like colours and number_formats - use only one of those, and always the same if it can be done - always have in mind that anyone else (colleague or successor) doing any developing on your apps must be able to see what happens and why.

=> It might also be a good idea to have a "developer guide" with your standards.