03-13-2017 08:13 AM
When introducing an application to an organization, you might receive some resistance. People don't always appreciate change and may be suspicious of the latest software trick designed to make their work life easier.
Many of you might envision an angry response to the application with co-workers yelling or running through the halls losing their minds. Resistance may not always be angry. In fact it might be passive - for instance people just ignore the new application. You have to understand why people resist before you can plan how to tackle the resistance.
Are they resisting out of fear of the unknown? Maybe the current tool works better? Maybe they don't see any value in the new application? Maybe they simply don't have time to devote to learning the new tool? Perhaps the tool is not fully operational and lacks the needed features?
Before changing people's skills, they must be permitted to decide for themselves how they plan to continue to work.
Each of these reasons can be overcome with patience, training, and communications. Some may resist until the change is at their doorstep or management assists with the decision. Your job is to present what is possible and allow co-workers to decide for themselves how they want to continue or if they want to continue.
Join Brian Bell and me at the SAS Global Forum on April 5 when we present Pillars of a Successful SAS® Implementation with Lessons from Boston Scientific. We explain how cultural resistance was addressed during a tool rollout.
03-13-2017 11:58 AM
Very elightened perspective.
My advice is to first ask if your users are programmers or non-programmers. One steadfast rule for a programmer is that he/she needs an operating system.
Can the programmers work with de-identified data rather than a less secure server with identified data,
Pharma and marketing for instance do not need identified data. Programmers do not develop models on 100 million identifiable data. Very rarely is name, credit card number or SSN needed? Develop on limited data then score on server?
Double blind trials are by definition de-identified?
Finally provide statistics on the new platform
1. Reliability (does your program give the results you want )
a. Does the programmer have admin priv so he can apply hot fixes?
b. Can a programmer upgrade to a later version of SAS as soon as it is available?
a. Is there scheduled down time.
b. IBM once guaranteed airlines no more the 15 minutes of downtime per year.
c. If platform is down have penalties users can use to upgrade their power workstations.
a. Can users use workarounds either provided by SAS or in other languages when
SAS fails and cannot be serviced.
4. Performance (provide benchmarks for users)
How does the server compare to an inexpensive power workstation with says 128gb ram, dual 16 thread processors, mutiple RAID 0 SSD arrays, three monitors, programmable mouse, command line, programmable mouse, prefix area and command macros,
1. A matrix language with command line and/or interface to Python and R
2. Command macros, pipes, interactive environment, R Shiny or Django
3. Internet acess
4. Libname engines
03-14-2017 08:54 AM