I’ll keep my example focused on a single piece of software, CRM (Customer Relationship Management).
When I joined my current firm, they used an on-premises CRM that required a fat client to be installed plus a network drive mapping in order to work. I was responsible for the server hardware (including warranty coverage), the application itself (purchase of the initial product + ongoing support), backing up data on the server, backing up the server itself (which is different), and keeping the server powered up and cooled down.
The positive was that we weren’t being nickel & dimed for every user account. A negative was that the old CRM didn’t work well across a wide area network (WAN) because it was never designed to be used in such a way.
Because the server that housed the CRM sat in a room in an office building, it was vulnerable to any ‘event’ that might affect Houston. A prime example is 2008’s Hurricane Ike.
The new CRM is software-as-a-service (known as SaaS) and thus has business continuity built into it. A SaaS CRM works well across a wide area network because it was designed from the ground up to work in a distributed environment (i.e., the Internet).
A negative aspect of a SaaS CRM is that we are getting nickel & dimed by the vendor when it comes to per-user licensing.
Running reports from the SaaS CRM is painfully slow and as the vendor adds more customers to their shared environment, things get even slower. SaaS vendors only make money by adding more & more customers while not adding additional resources to support their growing environment. It’s the old adage of, “Let’s see how many people we can fit in a telephone booth.”
I still must take backups of my firm’s data from the SaaS CRM (via FTP) just in case something happens to the vendor. Always have a backup plan, whether it’s a cloud based application or on-premises software. That will never change.
I still have to create new user accounts, disable old user accounts, and set access rights to the SaaS CRM just like I did with the old on-premises CRM. That aspect of my job has not changed. What the SaaS vendor provides is the environment and it’s up to the customer to determine who gets access to what.
Overall, I still must administer the CRM, it has built in business continuity features, it works well for all of my office locations, but the SaaS CRM can be slow and is affected by not only your connection to the Internet, but the traffic patterns of the Internet itself.
Something to think about are the “peering agreements” between the major Internet Service Providers. My firm experienced a “peering” issue. What happened? My firm was caught in the middle of a dispute between ISPs. I’ve had real experience with this problem and the most frustrating part was that all the vendors pointed their fingers at the other vendors and said it was their fault – it was like a Three Stooges routine but with terrible consequences. I remember telling the ISP that provided access for my office that when I used my wireless broadband card, I could access the CRM just fine. This stunned the technical support folks and made them realize the problem was larger than they’d first thought (that plus they had dozens & dozens of complaints from other customers of our specific SaaS CRM who experienced the same issue).
So what is the take away from all of this? A SaaS CRM is a mixed bag just as the old on-premises CRM was a mixed bag. I still spend as much time administering the new SaaS CRM as I ever did on the old CRM.