SaaS – Thanks, but No

Last week, I explained why I will not be recommending to my boss that we move our ECM into the cloud. The other thing I won’t be recommending anytime soon is that we move to a Software-as-a-Service (SaaS) solution. The difference between the two decisions is my motivation. As I mentioned last week, we are fairly small; there are roughly four of us who handle IT. We provide storage, SharePoint administration, SQL Server, Exchange, OCS, well, you get the picture. We also design and develop the information systems our company uses to process transactions and report results. Of all of these, storage is the easiest – we buy it, put it on-line, keep it secure and back it up. Systems development, on the other hand, is time consuming difficult work.

SaaS, the “utility model”, offers a pay-as-you-go way to remove this burden from me; any system that I can replace with a service, is a system I don’t have to design, implement, document or maintain. That sounds too good to be true. In fact, it sounded good enough to warrant serious investigation – that’s when the old adage about things that sound too good to be true came to fruition.

The first thing that that falls apart under investigation is the relief from design, implementation and documentation – somebody still has to do that. Sure, you don’t have document the service you are using, but you have to document how the service is used. The reason you have to document that is because nobody is selling exactly what you need. After we “design” the way we would adapt our business model to the service, we would “implement” that modified business model and then “document” that solution.

The next thing that we realized is the stunning narrow focus of these services. The service we found that would “almost” handle our foreign insurance business, had no accounting module. We were told that there were some “bolt-on’s” that might allow us to connect this service to a third-party accounting system. Even if we were willing to go that route, it would not have worked; we had already evaluated the accounting system and found it inadequate to meet the requirements of our business.

The final nail in the SaaS coffin for us was the other thing SaaS was supposed to do for me, relieve me of the task of maintenance. Every system has to be maintained, and the SaaS solutions we looked at touted the fact that they were continually maintained. Bug fixes, enhancements and modifications simply appear as they are developed – this was a show-stopper for me. Actually, I don’t care when software is updated, but my users do. There is a period lasting about four months, during which we do not implement changes, we don’t upgrade systems, we try not to swap or upgrade servers. The period is called year-end, and the people involved in it don’t like changes to their daily routine during that time. It’s not that they don’t like change, okay, they don’t, but this would be a horrible time to change the layout of a report, the fields being downloaded to a spreadsheet, or the information on an invoice. During this time, we are writing new business, closing the previous year and preparing for a financial audit – consistency rules at year-end.

The lack of control, lack of a comprehensive solution and the number of times we were being told: “you should consider ways you might be able to adapt your business to…” made us realize why we write systems in the first place. Business systems are not simply an expense to be managed; they are, in our case, an investment. Adapting these systems to our business makes sense for us.