I differ with Marc in one way. It is amazing what people can learn when
you create an emergency for them to do so.
Frank
Marc Schwartz wrote:
On Jul 17, 2009, at 9:57 AM, Kelvin Lam wrote:
I should elaborate the situation a bit more. We store our data in
UNIX and
have been using UNIX SAS for our work. My Biostat dept has 40 SAS users
from which at most 10 also use R. The Epi/Grad Students/Investigators
combine for another 30-40 not-so-frequent SAS users let alone R. So
we are
talking about 80 folks/workhorses in the entire institute.
One of my thoughts is to break up the Biostat group into two so that one
uses R solely to reduce the number of licences. IMHO, the pro is to
worry
a smaller group of users. However, the cons will be who to be
assigned to
respective group.
You have several business, human behavior and budgetary issues to
consider. It is not usually just a matter of making the business case
that saving annual license costs is the sole factor in making a decision
to switch to R.
You have to consider the receptivity of the existing base of SAS users
to changing to R. Are they open to it or are they not motivated to
change? In the latter case, is the organization in a position of forcing
change or not? Being a non-profit organization, you can simply say, due
to funding issues, we are going to have to eliminate some 'x' number of
SAS licenses to stay within our operating budget. That will have an
impact on how many users can in fact continue to use SAS.
However, if you compel wholesale change, are you at risk of losing
people who are resistant and decide to move on? Are they key people
where their loss would have substantive impact on the organization and
project commitments, at least in the short term? Yes, on one level, we
can all be replaced by somebody else, but at what short term cost to the
organization and it's customers?
If there is resistance amongst some proportion of the staff, an
incremental approach would be very appropriate. Balance your funding
issues with the number of staff that would be impacted in the near term.
Can you eliminate 'x' SAS licenses this year, 'y' more next year and so
on so that the transition is implemented over a multi year time frame
while still working within your funding constraints?
Solicit feedback from the staff to see who is open to using R and who is
not. Let that be a key factor in any decisions to partition the staff.
Get an idea as to the scale of the battle that you are facing with
respect to change. Identify the "low hanging fruit" to look for
incremental and consistent wins that you can build on. Those who are
resistant to R may simply need time to see that what they have done in
SAS can indeed be done in R with greater quality, speed, flexibility and
in time, at a lower cost. Once they get over that hurdle, they may come
on board with you and make subsequent transitions easier.
With an eye towards the future, be sure that new hires are skilled in R,
so that as you may need to deal with staff turnover or growth, you are
enabling the future use of R by a growing number of folks who have
pre-existing R skills. Set yourself up for future success.
Consider R related training and the costs associated with it. The costs
are not just what you may have to pay for training, but the opportunity
costs in the short term of getting people up to speed and the loss of
productivity short term, even though as Frank noted, you will realize
notable gains in the long term. Consider how your existing project
commitments would be impacted and how you may have to allocate or
re-allocate the workload during the transition.
Consider the costs and timelines associated with converting an existing
base of SAS code that has perhaps gone through a review and validation
process. What will it take to replicate that functionality in R with the
same level of reliability? What methodological issues will you face in
the transition from SAS to R, given the differing philosophies? How long
will it take, who will do it and what other tasks or projects may be
impacted during the transition?
In some environments (eg. Big Pharma), re-training and especially code
conversion/validation costs alone outweigh the savings of not paying for
SAS licenses. This is why there is a significant hurdle to using R in
that environment even though such companies may pay SAS millions of
dollars per year.
I don't know that there is a one size fits all approach to moving from
SAS to R. Each operating environment has its own characteristics
relative to budgets, politics, people and so forth. The points that I
raise above may be typical but only some may apply to your situation and
there may be others that I have not raised.
HTH,
Marc Schwartz
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
--
Frank E Harrell Jr Professor and Chair School of Medicine
Department of Biostatistics Vanderbilt University
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
