<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />Hi all,
In addition to looking at what data we can gather internally about JMP 11 and JMP 12 update patterns, I was hoping to gather some more qualitative comments from you all about update patterns you see in your own customers.
- If you had to unofficially aggregate your data, what do you hear most often from existing customers about whether they plan to upgrade to JMP 12-and why or why not?
- Do you hear from customers that they will or plan to request an upgrade via the self-service CIVE system or do they call TS or contracts or their JMP rep to ask about it?
- Do you get the sense that your customers use our web updaters after they've ordered whatever installer they have for a given main version?
Any and all comments are welcome on this and related topics like installers and licensing. We look forward anything you would like to share.
(Some background info about this request if you're interested:
Bob and I have been digging into JMP 11 installer download data exported from COMSAT (a SAS internal reporting system), which Jeff and others have looked at in the past. So far this data seems to have all the problems you'd expect-multiple product on some sites (removed those in a first pass), multiple requests per company (e.g, upgrades), multiple sites per company with slightly different spellings or in different countries. I think it will prove useful as we get it cleaned up further but I doubt I've got the steps quite right yet and I can already tell that I will need to spend more time in Recode...
However, I did summarize the table and make indicators for whether customers requested 11.0, 11.1, and 11.2 that removed many site level duplications within the same type of transaction. Now that JMP 12 is out, we are following user requests for JMP 12.0 daily and there have been nearly 250 downloads so far. We're going to work on matching up customers, installer and updater download patterns as best we can to understand more about how (and if) customers are updating installs they deploy. The installer download is kind of where our initial data ends, at least until a customer downloads an update, calls TS or calls one of you.
From what I see in the installer request data so far, the most common installer pattern for our last release seemed to be to download just 11.0 (~2100 unique site names, excluding sites with lots of extra SAS "stuff"). Presumably some of these sites updated their 11.0 installs using web updates afterwards, but that remains to be seen as we work through that data. Next most common pattern was to download 11.2 only (1350), and third most common pattern was 11.1 only (~760). (Again, take the absolute numbers with a grain of salt, and consider them in relative terms until I'm more certain about how to compress and clean up the data.) In any case, it was a less common pattern to get installers for 11.0 and then request installers for a maintenance, or just request the maintenance installers, or get installers for all 11 versions.
We'll continue to look at this data, and as always appreciate your thoughts.
Thanks!
Shannon)
Shannon:
Again, from my seat here in the Mid Atlantic territory (heavy chemical process industries, pharma/life sciences (big and small), and financial/customer services) Paretoizing the 3 reasons why users update to new versions of JMP are as follows:
1. A user says something like, "Why wouldn't I?" These are the folks that just love JMP (and there are many) and they always want to own the newest shiniest version because that's how they roll.
2. I really like new feature (fill in the blank) so I am updating soon. Up to now, the biggest hitters I'm seeing are in no particular order, data table expressions, interactive model fitting, and PowerPoint/HTML5 with data interactivity report functionality expansion.
3. Our company has made the switch and I'm just a cog in a wheel.
Thanks, Peter! I like that-'Paretoize'!
Shannon:
If I had to 'Paretoize' the folks in our patch that aren't planning to update (at least any time soon) it's for the following reasons, 1. Most frequent...
1. Need to revalidate scripts we use with various regulatory agencies like the FDA. This represents lots of nonvalue added work on our behalf.
2. We wait until at least the x.1 release as a matter of policy.
3. Inertia.
