部署SaaS 让CIO再不必为软件更新而烦恼

　　“软件即服务”(software as a service，下称SaaS)之所以能迅速抢占市场，归根结底在于它拥有几大优势：先期投入较低；能从任何地点通过互联网访问应用服务；有效地利用了宝贵的企业内部资源，让IT部门再不必为软件更新和补丁而烦恼。此外，企业也不必在内部软件和SaaS两者之间做单项选择了，因为几乎每个类别的应用程序都出现了混合型的产品。就连微软公司(Microsoft，下称微软)和甲骨文公司(Oracle，下称甲骨文)这样的软件业巨头也开始为那些与你交恶多年、“体态臃肿”的软件产品提供SaaS版本了。

　　要在企业中实施SaaS，IT部门目前面临着三重挑战：首先，得让业务经理们意识到SaaS天生的优点；其次，要更新技术采购的审批流程，在进行采购时将SaaS纳入考虑；最后，还要增加决策时关注的重点，使之涵盖那些容易被忽视的SaaS实施条件，比如说对带宽的需求以及集成成本等。

　　首先，让我们来检视一下标准的企业应用程序审批流程。每个企业的流程都有所不同，但是根据我们的经验，大多数流程都是将应用程序的特性、好处以及成本等决策要点整理成一长溜的清单，然后IT人员会花时间确定企业的实际需求，找出棘手的业务问题。当这一系列的前期准备工作完成之后，企业才会着手设定应用程序的实施目标以及对厂商的产品要求，并明确应用程序必须具备的基本功能和增强型功能，再对项目实施总成本进行估算。

　　如果购买基于服务的应用程序的计划已被提上日程，那你千万不能忽视以下几个评估要点。首先是整合工具和支持。你绝不能把任何SaaS应用程序看作是孤立存在的东西。首要的评估对象，便是厂商为后端系统集成所提供的工具及套件。我们一位受访者就表示，他最近反复尝试在一个客户关系管理(CRM)应用程序与Exchange的日历之间建立连接，但是屡遭失败，最后不得不放弃。

　　接下来，企业应当了解SaaS应用程序提供哪些数据分析选择。SaaS的报表和导出文件具有固定格式这无可厚非，但问题是大多数厂商对用户直接访问数据库或者自定义报表格式要进行额外收费。另外一项需要考查的内容，则是厂商在收购完成后整合数据的能力。我们的一位受访者声称，数据访问是SaaS的最大缺点之一，他说：“当数据库被托管在外部服务器时，通常认为它是为厂商所持有。如果我们要分析自己的数据，那就会花费好几个月的时间，而且耗资巨大。”

　　2/3以上参与调查的受访者都将数据安全作为了选择厂商时需要考虑的重要因素。数据安全问题对IT人员而言颇难掌控：你可以为企业内部数据的安全把关，但你如何确保SaaS合作厂商能达到你的要求呢？为了搞清楚厂商的真实能力，你可以考察几个简单的问题：

　　1、恢复时间目标(RTO)/恢复点目标(RPO)的服务水准。企业应当要求厂商对恢复时间和恢复点目标出具书面承诺。如果厂商的销售代表根本不知恢复点目标为何物的话，那你还是赶紧另寻别家吧。如果厂商声称其服务具有“五个九”(99.999%)的系统可用时间，那也不能轻信它的一面之词，必须看看它的灾难恢复白皮书。

　　2、审核数据中心。厂商的数据中心采用什么模型？数据中心采取了什么复制策略？对数据归档服务是否额外收费？这些问题企业都要一一调查清楚。此外，你还应当看看厂商的数据转储(data dump)政策是否与你的灾难恢复计划一致，并确认其承诺的交付时限。

　　3、渗透测试和漏洞评估。问问厂商为他们提供测试服务的是哪家公司。如果厂商没有找独立的专业公司进行测试，那你得追问它用的安全认证模式是什么。我们建议企业最好还是找那些经过ISO、ITIL等国际标准认证的厂商。

　　4、历史记录。从通讯服务商到软件厂商，再到纯SaaS厂商，各路人马都想在SaaS市场上分一杯羹。我们的调查结果显示，这几类厂商占有的市场份额均未超过30%。

　　这里我们要向企业提个醒：不要指望传统的软件巨头在SaaS领域也能表现出色。微软最近宣布将与CRM有关的SaaS产品升级，而甲骨文和SAP公司在SaaS领域也不遗余力地推陈出新，这些迹象显示了软件业巨头们参战SaaS的决心。但是，历史经验告诉我们，企业规模大小与成功与否并无的直接关系。还记得Microsoft Business Web、按需Lotus Notes以及英特尔公司(Intel)的网络监控服务(network monitoring service)吗？这些都是前车之鉴。

　　现在问题是，这样的历史会重演吗？大型的企业软件厂商必须调整收入模式，从大笔的软件授权收入转换成细水长流的每月定期收入模式。而在纯SaaS厂商方面，生存早已不是它们面临的问题了。

　　无论你选哪一类的SaaS厂商，都不能马虎大意，因为与套装软件厂商相比，SaaS厂商倒闭造成的后果要严重得多。