众所周知，ASP(软件托管)模式是SaaS(软件即服务)模式的前身。而ASP模式被证明是失败的。那么SaaS模式在ASP模式上有哪些改进呢?还是只是换汤不换药?对此笔者进行了一番分析。希望这个分析报告能够让大家对SaaS模式有一个更进一步的了解。　　

一、ASP是一对一而SaaS是一对多的

笔者认为，ASP与SaaS最大的区别就是其对应关系的不过。简单的说，ASP是一对一而SaaS是一对多。这是什么意思呢?其实拿ERP软件来说，ASP 就是根据企业的需求从零开始来订制一套软件。而SaaS模式就好像是一种套装软件。不需要根据企业的需要从零开始来开发软件，而是预先开发设计好一套软件，如果企业有需要的话，可以在此基础上进行二次开发。

也就是说，ASP提供客户服务是一对一的关系，即针对不同的客户订制不同的应用。而SaaS提供客户服务是一对多的关系，针对所有的客户(某个行业的客户)都是采用相同的应用服务。那么ASP的这种一对一的操作模式有什么缺点呢?其最大的缺点就是增加了客户的投资成本与项目的周期。因为需要根据客户的需求来开发服务与应用，那么无疑需要配备很多的人员，并且从需求调研到软件开发、测试、交付，也需要一个很长的过程。对于企业用户来说，这个时间与项目投资可能都难以忍受。另外，ASP模式在实施过程中，没有一个流程重组的过程。为此企业即使采用了信息化管理，但是原有的一些不合适的流程由于没有进行重新梳理，为此即是上了信息化应用，那么效果也是非常有限的。这也正是为什么ASP会失败的一个重要原因。

而SaaS模式采取的是一对多的关系，即多个客户使用同一套软件。这不仅可以节省企业的信息化项目投资，而且还可以缩短项目的周期。另外企业为了适用这套软件，必须先根据行业的标准流程来优化自己的操作流程。否则的话，无法适用这个套装流程。而业务流程重组与优化对于提高企业的信息化管理效果具有很大的影响。因为经过业务流程重组，可以把企业管理流程中一些不合理的环节优化或者去掉，从而提高企业的管理效率。

为此，SaaS模式并不是对ASP模式的一个简单升级。而是在一些本质的内容上都有了巨大的改进。

二、服务领域的不同

传统的ASP模式起服务领域是比较狭窄的，其只仅限于应用系统的托管。但是SaaS模式则对这个领域进行了扩展。除了传统的应用系统托管之外，还有其他的一些应用。如更加看重与提供更多的互联网服务。如为企业提供企业邮局，提供在线的办公自动化系统等等。由于其应用领域的扩展，最大的好处就是一个集成。

如企业可能有邮件服务器、OA自动化办公系统、财务预算系统等等。如果光是应用系统托管的话，无法把这几个应用软件集成起来。企业用户可能仍然需要通过不同的渠道去访问这些应用软件。但是如果采用SaaS模式的话，其可以通过WEB平台把这些应用服务集成来一个平台上。那么用户访问这些应用的话，只需要登陆到同一个网站上即可。通过一个网站的不同接口就可以登陆到不同的应用上去。如只需要在开始的时候输入一次用户名与密码，就可以访问各个不同的应用。

显然，由于SaaS模式扩展了其互联网的应用，而不单单只着眼与应用软件托管，让这种集成有了实现的可能性。

三、自定义的要求不同

由于ASP是一对一的，本身就是根据企业的需求来开发服务与应用。为此对于软件的自定义要起并不是很高。但是SaaS模式则不同。由于其是一对多的关系，多个客户要使用相同的软件。但是多个客户之间需求总是有差异的。为了提高客户的满意度，必须要在SaaS的平台上多开发一些应用软件的自定义平台。让企业或者软件公司在不通过二次开发的情况下就可以实现用户需求的自定义。

如SAP原先并没有采用SaaS模式。但是后来其是转向SaaS模式最快的一个企业之一。这是什么原因呢?这主要还是要归根于SAP的软件特点。一方面SAP提供的ERP系统中有大量的参数。通过对这些参数进行调整可以满足不同的用户需求。另一方面SAP也有自己的一个开发平台。这个平台跟其他的开发平台不同。其是专门为SAP ERP这款软件所设计的。为此企业用户可以很容易的通过这个平台来实现自定义。正是因为SAPERP软件在这个自定义平台上表现出色，所以其才可以以最快的速度过渡到SaaS模式，并迅速取得成功。

所以，SaaS模式向对于ASP来说，更加强调自定义平台的重要性。SaaS通过有效的自定义平台，可以让套装软件适合更加广泛的企业用户。所以看看那些成功的SaaS应用，自定义表单与报表、自定义数据结构、自定义业务流程等等自定义功能都是具备的。企业用户可以使用这些自定义的工具来满足企业自己的个性需求。

可见由于SaaS模式提供了这么多的自定义工具与平台，为此其灵活性就比ASP模式要高的多。而且用户如果需要二次开发的话，其成本也可以节省许多。

四、技术实现的方式不同

现在的SaaS应用往往是采用三层开发机制。如采用JAVA平台开发的话，其可能就是视图层、控制层与业务逻辑层。对于不同的客户来说，业务逻辑层往往是相同的。而控制层的内容大部分是相同，可嫩只是一些细节上的控制有所差异。如对于客户的信用额度控制要去不同等等。而不同客户最大的不同就在于视图层。因为不同的客户对于表单与报表的格式要求不同等等。这些都集中体现在视图层。而SaaS模式把这个应用程序分为三层结构开发的话，如果不同企业有不同需求，那么只需要调整视图层的代码即可，而不需要调整其他层中的代码。

所以大部分的SaaS应用都会在WEB服务器与用户之间增加一个中间层。这个中间层就主要用来处理用户的定制、扩展性、和多用户的效率问题。其这么设计的主要目的，就是用户的个性化需求不能够影响到其核心的代码与业务逻辑。就好像用户再怎么进行自定义，不能够更改一棵大树的主干部分，而只能够对其枝条进行修剪。这不仅可以规范企业的业务操作流程;而且也可以提高应用软件的稳定性，降低企业的二次开发成本。当然对于软件企业来说，也是有利的，他可以保证软件的主体架构不受影响。这有利于他们日后进行软件升级。

为此，笔者认为，SaaS模式的三层架构体制，无论对于企业用户来说，还是对于SaaS软件提供商来说，都是双赢的，都是有利的。

从以上的分析中大家可以看出，虽然ASP模式是SaaS模式的一个前身，但是两者在核心内容上有了很大的改变。所以笔者认为如果把SaaS当作ASP的一个升级版本，这可能不怎么合适。准确的来说，从ASP到SaaS模式，不是一个简单的改良，而是一种革命。因为其不仅在技术上，还是在应用上，给人的感觉就是推倒重来的。虽然两者在很多方面有类似，但是一些核心的技术与功能基本上都重新来过了。所以说ASP模式虽然以失败告终，但是SaaS模式并不一定会赴其后尘。从某个角度来说，笔者还是看好SaaS模式的。毕竟起在成本与风险上，都是实实在在的看得见的。