Business Intelligence software vendor QlikTech* officially published its price list last month, after years of keeping it a not-very-closely-held secret. I was personally pleased, since people occasionally ask me what QlikView costs. But then I looked more closely at the list and realized I wasn’t quite certain what it meant. Happily, it didn’t take long to set up a briefing and clarify matters. Just in case anyone else is also confused, here’s what they told me:
- The lowest entry price for a fully functional version is $1,350. Although this is called a “Named User License”, it does NOT require connection to a server—the specific point I wasn’t sure of. What distinguishes this from the free Personal Edition is that the Named User License can read QlikView files created on other machines, while the Personal Edition cannot. Thus, a company could buy two Named User Licenses for $2,700 and those systems could share files back and forth. Let me state clearly that as a confirmed QlikView fan, I think this is a terrifically low entry price.
- Companies with many infrequent users can purchase a “Concurrent License” that allows one user at a time for $15,000. This figure is so high that I thought it might be a typographic error, but QlikTech assures me it’s correct. In fact, they say it’s a bargain because they’ve found many clients can share more than 11 users on one license. These would be salespeople or other non-analysts who want to occasionally view a report. It seems to me that Murphy’s Law would ensure they all access the system during the same five minutes – presumably the evening before their monthly reports are all due – but I’ll take QlikTech’s word that this isn’t the case. After all, they're the analytical experts, eh?
- Companies who don’t want to spend $1,350 for casual users have some other options. These include a $350 “Document License” for one user for a single document, a $70,000 “Information Access Server” allowing unlimited users to access a single document (usually over a public Web site), and a $3,000 “Extranet Server Concurrent License” that allows one external user at a time to read documents on an $18,000 “Extranet Server”.
There are various other licenses for larger systems and special purposes. The descriptions are more or less self-explanatory, but of course you’d want to talk to QlikTech itself for detailed explanations.
One thing you definitely won’t find is a free or low-cost “reader” licence that lets users view but not change a QlikView document. This is a disappointment to me personally, since we at Left Brain DGA use similar readers to send reports to our clients today. I can’t see those clients paying for Named User Licenses or Concurrent Licenses. But QlikTech is philosophically opposed to the idea of a limited-function reader, which it argues “goes against the current trend toward the democratization of software — in which line of business users can become as adept with an analytics tool as any business analyst or developer.” I can’t say I agree: QlikView takes considerable effort to learn, and many business users don’t have the time, need, or inclination to bother. They would be perfectly happy to consume existing reports without drilling any deeper, but are unlikely to pay $1,350 for the privilege.
I can’t judge how much business, other than mine, the lack of reader is costing QlikTech. Surely some people end up buying the full Named User License and using it as a reader, which makes up for some of the people who don’t buy at all. QlikView also has a strong argument that their total cost of ownership is lower than competitors, even at current pricing levels. The company grew 40% year-on-year as of its last financial report, so they’re clearly doing just fine with their existing approach.
_________________________________________________
* QlikTech is the company, QlikView is the product
Showing posts with label qlikview price. Show all posts
Showing posts with label qlikview price. Show all posts
Wednesday, March 07, 2012
Thursday, July 17, 2008
QlikView 8.5 Does More, Costs Less
I haven’t been working much with QlikView recently, which is why I haven’t been writing about it. But I did receive news of their latest release, 8.5, which was noteworthy for at least two reasons.
The first is new pricing. Without going into the details, I can say that QlikView significantly lowered the cost of an entry level system, while also making that system more scalable. This should make it much easier for organizations that find QlikView intriguing to actually give it a try.
The second bit of news was an enhancement that allows comparisons of different selections within the same report. This is admittedly esoteric, but it does address an issue that came up fairly often.
To backtrack a bit: the fundamental operation of QlikView is that users select sets of records by clicking (or ‘qliking’, if you insist) on lists of values. For example, the interface for an application might have lists of regions, years and product, plus a chart showing revenues and costs. Without any selections, the chart would show data for all regions, years and products combined. To drill into the details, users would click on a particular combination of regions, years and products. The system would then show the data for the selected items only. (I know this doesn’t sound revolutionary, and as a functionality, it isn’t. What makes QlikView great is how easily you, or I, or a clever eight-year-old, could set up that application. But that’s not the point just now.)
The problem was that sometimes people wanted to compare different selections. If these could be treated as dimensions, it was not a problem: a few clicks could add a ‘year’ dimension to the report I just described, and year-to-year comparisons would appear automatically. What was happening technically was the records within a single selection were being separated for reporting.
But sometimes things are more complicated. If you wanted to compare this year’s results for Product A against last year’s results for Product B, it took some fairly fancy coding. (Not all that fancy, actually, but more work than QlikView usually requires.) The new set features let users simply create and save one selection, then create another, totally independent selection, and compare them directly. In fact, you can bookmark as many selections as you like, and compare any pair you wish. This will be very helpful in many situations.
But wait: there’s more. The new version also supports set operations, which can find records that belong to both, either or only one of the pair of sets. So you could easily find customers who bought last year but not this year, or people who bought either of two products but not both. (Again, this was possible before, but is now much simpler.) You can also do still more elaborate selections, but it gives me a headache to even think about describing them.
Now, I’m quite certain that no one is going to buy or not buy QlikView because of these particular features. In fact, the new pricing makes it even more likely that the product will be purchased by business users outside of IT departments, who are unlikely to drill into this level of technical detail. Those users see QlikView as essentially as a productivity tool—Excel on steroids. This greatly understates what QlikView can actually do, but it doesn’t matter: the users will discover its real capabilities once they get started. What’s important is getting QlikView into companies despite the usual resistance from IT organizations, who often (and correctly, from the IT perspective) don’t see much benefit.
The first is new pricing. Without going into the details, I can say that QlikView significantly lowered the cost of an entry level system, while also making that system more scalable. This should make it much easier for organizations that find QlikView intriguing to actually give it a try.
The second bit of news was an enhancement that allows comparisons of different selections within the same report. This is admittedly esoteric, but it does address an issue that came up fairly often.
To backtrack a bit: the fundamental operation of QlikView is that users select sets of records by clicking (or ‘qliking’, if you insist) on lists of values. For example, the interface for an application might have lists of regions, years and product, plus a chart showing revenues and costs. Without any selections, the chart would show data for all regions, years and products combined. To drill into the details, users would click on a particular combination of regions, years and products. The system would then show the data for the selected items only. (I know this doesn’t sound revolutionary, and as a functionality, it isn’t. What makes QlikView great is how easily you, or I, or a clever eight-year-old, could set up that application. But that’s not the point just now.)
The problem was that sometimes people wanted to compare different selections. If these could be treated as dimensions, it was not a problem: a few clicks could add a ‘year’ dimension to the report I just described, and year-to-year comparisons would appear automatically. What was happening technically was the records within a single selection were being separated for reporting.
But sometimes things are more complicated. If you wanted to compare this year’s results for Product A against last year’s results for Product B, it took some fairly fancy coding. (Not all that fancy, actually, but more work than QlikView usually requires.) The new set features let users simply create and save one selection, then create another, totally independent selection, and compare them directly. In fact, you can bookmark as many selections as you like, and compare any pair you wish. This will be very helpful in many situations.
But wait: there’s more. The new version also supports set operations, which can find records that belong to both, either or only one of the pair of sets. So you could easily find customers who bought last year but not this year, or people who bought either of two products but not both. (Again, this was possible before, but is now much simpler.) You can also do still more elaborate selections, but it gives me a headache to even think about describing them.
Now, I’m quite certain that no one is going to buy or not buy QlikView because of these particular features. In fact, the new pricing makes it even more likely that the product will be purchased by business users outside of IT departments, who are unlikely to drill into this level of technical detail. Those users see QlikView as essentially as a productivity tool—Excel on steroids. This greatly understates what QlikView can actually do, but it doesn’t matter: the users will discover its real capabilities once they get started. What’s important is getting QlikView into companies despite the usual resistance from IT organizations, who often (and correctly, from the IT perspective) don’t see much benefit.
Subscribe to:
Posts (Atom)
