标签：
1 引言
赚钱之道很多，但是找不到赚钱的种子，便成不了事业家。作为职业软件人，我们都寻求使用一种有效而经济的过程来建造一个能够工作的，有用的产品。
________Grady Booch
企业的根本目标是“合法地赚取尽可能多的利润，使企业整体利益最大化”。企业所有的特定目标和行动(例如研发、营销等)都是围绕根本目标开展的，不能和根本目标抵触。SaaS商业模式更关注软件作为服务给企业所创造的经济利润。
2 SaaS商业模式的新转变
商业模式的转变将涉及到：将软件的“所有权”从客户转移至外部供应商;将技术基础设施和管理等方面(如硬件与专业服务)的责任从客户重新分配给供应商;通过专业化和规模经济降低提供软件服务的成本;降低软件销售的最低成本，针对小型企业的长尾市场做工作。
l 将软件作为服务来考虑
为了实现从提供内部部署软件向软件即服务的转变，软件厂商应在三个相互关联的领域中转变思路：一是商业模型;二是应用架构;三是运营结构。
图1 SaaS三个关联的领域
l 转变商业模式
转变商业模式将涉及以下一种乃至更多种情况：
² 将软件的“所有权”从客户转移至外部供应商;
² 将技术基础设施和管理等方面(如硬件与专业服务)的责任从客户重新分配给供应商;
² 通过专业化和规模经济降低提供软件服务的成本;
² 降低软件销售的最低成本，针对小型企业的长尾市场做工作。
为了实现SaaS理念的优势，供应商与客户都应进行思维转型，并且供应商还应帮助客户实现这种转变
l 长尾销售策略
作者Chris Anderson在他于《连线》杂志2004年10月刊3上撰写的“长尾”一文中，介绍了Amazon.com等网络零售商为什么处于有利地位，为什么能针对传统零售商难以以低成本提供服务的领域填补需求空白，从而使“长尾”这一新概念通俗易懂。
图2 长尾理论
书籍、光盘等各种商品门类的需求往往符合“幂次定律分布”。在这种情况下，每年发布的书籍、CD以及DVD数不胜数，但只有少数能长期成为畅销品，其他的往往属于反响平平的长尾类出版物：大量出版物只让少部分有专门爱好的人感兴趣，出版量很小，甚至连几千份的拷贝都没有。
传统的实体型零售商致力于销售最流行的出版物，因为他们不可能把数以百万计的书籍、CD以及DVD等出版物都拿来当存货。不过，网络零售商则不用担心存货问题，他们能直接从全球各大仓库直接向客户发货，即便销售的出版物受欢迎程度很低，其广告和销售成本也毫不受影响，同样像畅销出版物一样大作宣传。因而长尾类低销量出版物也能赢得大量收入。
大型的实体书店能在其书架上存放13万种不同的出版物。而Anderson指出，Amazon.com书籍销量的大部分都来自13万种流行出版物之外，换言之，Amazon.com卖出的书中，大部分都是在传统的实体书店中买不到的。
长尾理论的基本原理是：只要存储和流通的渠道足够大，需求不旺或销量不佳的产品所共同占据的市场份额可以和那些少数热销产品所占据的市场份额相匹敌甚至更大。即众多小市场汇聚成可与主流大市场相匹敌的市场能量。
图3 长尾理论的经济模式
从上述示意图中可以看出，与20/80定律不同是，长尾理论中“尾巴”的作用是不能忽视的，经营者不应该只关注头部的作用。长尾理论已经成为一种新型的经济模式，被成功应用于网络经济领域领域。举例来说，Google就有效地利用了长尾策略。google的Adwords广告使得无数中小企业都能自如投放网络广告，而传统的网络广告投放只是大企业才能涉足的领域。其Adsense广告又使得大批中小网站都能自动获得广告商投放广告。Adwords和Adsense因此汇聚成千上万的中小企业和中小网站，其产生的巨大价值和市场能量足以抗衡传统网络广告市场。如果google只是将市场的注意力放在20%的大企业身上(像许多门户网站的网络广告策略那样)，那么也很难创造现在的辉煌了。同样，网上零售巨人亚马逊的商品包罗万象，而不仅仅是那些可以创造高利润的少数商品，结果证明，亚马逊模式是成功的，而那些忽视长尾，仅仅关注少数畅销商品的网站经营状况并不理想。
复杂的企业软件解决方案供应商面临着相似的市场境况。
图4 长尾理论的2/8定律
与简单的套装软件不同，企业软件需要针对不同客户的需求进行定制，可能包括现场安装、厂商服务队伍上门服务等，通常还需要专门的服务器硬件和支持人员加以管理。提供上述专门服务的成本会一定程度上增加供应商销售软件的最低成本。因此，这种软件通常面向大型企业，只有大型企业才有实力来支付专门服务。不过，相对于购买企业解决方案的大型企业数量而言，有着同样需求的中小型企业的数量要多得多，但他们却难以承担高昂的成本。
图5 长尾理论的“长尾”
SaaS供应商可消除维护成本，利用规模经济效益将客户的硬件和服务需求加以整合，这样就能提供比传统厂商价格低得多的解决方案，这不仅减轻了财务成本，而且大幅减少了客户增加IT基础设施建设的需要。因此，SaaS供应商能面向全新的客户群开展市场工作，而这部分客户是传统解决方案供应商所无力顾及的，因为他们根本就没办法为这部分客户提供低价格的服务。
有效面向小型客户开展市场工作，这就要求习惯于通过人际交往以及传统厂家和客户关系搞营销的供应商们进行思维转型;大多数供应商难以用大规模市场上的较低价格向更大的客户群体提供个性化服务。
搞SaaS营销就像销售手机彩铃或音乐下载服务一样，应该让客户能访问您的Web站点，成为您所提供服务的付费用户，通过信用卡付费就能开始享受服务，整个过程无须供应商方面的人为介入。这不是说您就不用对需求范围广的大规模客户群做人际联系工作。不过，在销售工作的设计、营销、供应和定制过程中从头到尾都是自动化的，因此我们不仅能提供自动化服务，同时又能简化您支持部门员工的工作，因而不用再帮助客户完成相关任务。
3 “点菜”模式
什么是“点菜”模式呢?大家习惯上餐馆去吃饭，吃饭前都要点菜。服务员拿出一本菜单给我们点，我们按一个个菜名点菜。这种最熟悉不过的方式应用在软件开发中将有很大的创新。我们把每一个可独立运行的最小的用户功能模块称之为“一盘菜”。一个系统划分为若干盘菜，若干盘菜可任意组装成一个系统。
SaaS在提供功能服务时先给客户一张菜单，客户在这种菜单上勾勾划划，SaaS平台系统就自动按客户的选择提供一桌菜。这一桌菜以门户网站的形式出现在客户面前。让用户似乎看到的是为自己制作的一个系统，事实上软件厂商根本不需要投入任何其它成本。这一切的完成几乎不需要多少人工由电脑就可自动完成。大家想想，要是有10盘菜，可组装成多少个系统?20盘菜呢?100盘菜呢?这100盘菜几乎要囊括所以的软件了。
3.1 “点菜”模式综述
“菜”的定义
“菜”是指可独立运行(相对平台)的按照软件功能范畴划分和组合的满足用户的需求并供用户选择的最小功能单位。我们可直观地把它理解为一个小型的应用系统，只是它小到不能再划分。“菜”的组成主要包括用户的功能页面、实现的代码集合(类、包、组件库)、数据表、相关文档及配置文件等(从开发角度来看)。
用软件的术语来讲“菜”就是功能组件。一个独立的功能组件也就是一盘“菜”。
按菜的思想来划分软件功能，这里要关注的是什么是菜?怎么细分菜?怎么实现“点菜”模式?有了“菜”，我们就可以通过“点菜”、“配菜”、“加工菜”来达到用户的需求。
“点菜”是让用户来点，软件厂商如果有现存的“菜”，这些“菜”不需要任何修改直觉组装就可满足用户的需求。这对于软件厂商是最好不过的方式。
但并不是所以用户的需求都可通过“点菜”来满足，点不出来的菜再考虑配置，通过“配菜”的方式来实现，用户想吃“蛋炒饭”这盘快餐，您是重新给用户炒一盘新的还是把早炒好的蛋加上现有的饭快速地给用户呢?所谓“配菜”就是指后者。
菜配不出来，那只有要动手术了，这需要在原来的功能上通过代码的修改和补充来满足用户的需求，这就是“加工菜”。
既然一切是以“菜”的思想出发，那么就无所谓系统、子系统了。事实，只要开发好了“菜”，其它系统都是通过“点菜”、“配菜”、“加工菜”来实现的。
所以，把“菜”看成一个最小的系统，“菜”的开发包括软件生命周期的整个过程，从需求分析、设计、实现、测试到维护等整个过程。这里要强调的是，需求分析只是对一盘“菜”要分析，设计同样如此。就是说《需求分析说明书》中的内容只可分析一盘菜，《架构设计说明书》、《详细设计说明书》都是设计这盘菜。菜与菜之间的关系都通过接口实现。菜是独立的，文档也是独立的。从事这盘菜开发、设计的人员组织也是相对独立的。这样打破了传统的按系统划分软件的概念。严格上讲，所谓“人”、“财”、“物”、“事”系统统统都不存在。没有所谓的ERP，没有所谓的HR，没有所谓的OA等等。要构成这些系统，是通过解决方案来实现，解决方案中也是利用“点菜”、“配菜”、“加工菜”来达到最终的目的。
“点菜”模式事实是用最少的开发来实现尽可能多的用户软件，是通过量变达到规模效应。SaaS模式有效地结合“点菜”模式，将大大降低软件厂商开发的成本，从而提高软件利用率，继而产生规模经济效益。
再比如我们习惯了上超市买东西。超市是大卖场，它提供各种花样其全的商品，价格相对也比较合理。客户为什么喜欢上超市买东西?其中原因之一就是可供选择的的品种多。客户可以自己选择。SaaS模式发展到一定成熟阶段，也会转化为软件大超市。大量的软件公司将被并购，在分工合作的统一协调下各自完成软件大超市的某项工作。理论上各大系统都是按零部件组装而成。我们的开发分成零部件的生产和组装这二个重要的环节。
零部件在传统的制造行业体现得很充分。很容易理解。但软件行业却完全不同，软件是不可见的难控的极大灵活度的无形高科技物质。而菜是可见的可控的粒度易把握的。下面我们来看“点菜”模式的组成如图1：
图6 “点菜”模式的组成
“点菜”模式由四部分组成
1) 菜的来源及划分：依据需求来源定义出各种“菜”。
2) 菜的实现：由配置开发模式、修改模式和开发模式生产出“菜”。
3) 菜入库：把做好的“菜”放入组件库。
4) 装配：按用户需求把“菜”组装成的产品供用户使用。
3.2 “点菜”模式开发过程
图7 “点菜”模式的开发过程
“点菜”模式开发过程划发为：组件慨信念、组件分析、组件开发、组件入库、产品发布、产品测试、内部验收、产品交付、产品维护9个阶段，包括以下11个子过程：
1) 需求来源：收集共利益者的需要、期望、限制条件和产品组件需求。
2) 需求分析：细化客户需求，开发产品和产品组件需求。
3) 配置模式：通过自定义工具快速开发功能组件。
4) 修改模式：通过修改源代码的方式开发功能组件。
5) 开发模式：通过软件程序开发方式开发功能组件。
6) 组件库：功能组件的管理与维护。
7) “点菜”(产品装配)：从组件库中按项目业务需求装配功能组件。
8) 系统测试：从需求的角度对系统的正确性进行验证。
9) 验收：由客户对产品进行确认，并向客户交付产品。
10) 维护：产品维护阶段的管理过程。
11) 软件问题管理：记录并管理软件项目开发/维护过程中所发现的各种软件问题。
3.3 需求来源与分析
需求来源的过程包括如图8：
图8 需求来源
l 需求来源渠道
1.销售，2.市场，3.意向客户，4.合同，5.公司定位，6.行业协定
l 需求收集
收集各种需求，包括行业标准，行业解决方案，咨询服务信息等。
l 需求整理
筛选并归纳整理，通过评审确定后形成的“菜”的原始材料。
需求分析的过程包括如图9：
图9 需求分析流程
功能组件定义：依据需求来源，按“菜”的标准划分并定义出功能组件。
功能组件清单：按模板格式列出功能组件清单，并给各功能组件命名、编号。此清单是功能组件入库和系统测试、验收的依据。
组件库查找：如果此功能组件已经在库中则可直接供，跳过开发路线这个过程。
确定开发路线：分析并评价功能组件的需求，确定开发方式，在配置模式、修改模式、开发模式中选择一种最快最适合的组件生产流水线。
3.5 组件库
图10 组件库
l 组件库定义
组件库是用来存放功能组件的仓库。相当物流公司的存货库。此仓库常由数据库来实现。功能组件按照分类和规律存放在数据库中。按照用户的需求可装配成不同的产品打包给用户。
l 组件库设计
合理实用的组件库是“点菜”的关键。软件的不可见性增大了组件库设计的难度。超市里的商品摆设都是很有讲究的，它是一门艺术学问。
组件库的设计包括组件库的框架、组成部分、逻辑结构设计、技术实现、物理结构、操作界面、入库与出库标准的定义、接口、类关系等设计。
l 组件库开发
实现组件库的功能，包括建立数据模型，操作界面，入库出库的方式，查找与匹配等功能代码的编写与单元测试、组装测试。
3.6 产品装配
产品装配是按客户功能清单从组件库中提取出功能组件，通过装配工艺组装成产品提交给用户。此时的客户可能就是公司的产品部。
装配清单：产品包、补丁包，平台基础支持组件等。
图11 产品装配流程图
3.7 系统测试
l 准备
1. 系统测试计划：测试范围(内容)，测试方法，测试环境与相关工具，测试完成准则，人员及任务安排。
2. 设计系统测试用例：测试用例应能够完整验证定义的产品需求客功能。
3. 同行评审。
4. 准备测试工具。
5. 建立测试环境。
l 测试
1. 获取集成了所有应交付产品组件，并且通过集成测试的产品，根据《系统测试计划》和系统测试用例，并对照需求对产品进行测试。
2. 将测试中发现的缺陷/问题按照软件问题管理流程进行管理;
3. 比较实际结果和预期结果，识别产品没有得到满足的需求，识别测试方法、标准和环境方面的问题;
3.8 验收
图12 验收流程
l 验收准备
1. 开发方、客户方以及其他项目相关方，共同协商，建立产品验收组，并指验收负责人。
2. 验收小组制定出《验收计划》，并获得双方的负责人批准。
l 产品确认
1. 为验收组成员提供培训
2. 产品审查
3. 验收测试
l 召开验收会
1. 会议前确认产品审查和验收测试活动已结束;
2. 验收测试组提供：产品审查记录和验收测试报告等材料;
3. 按照验收会安排，召开验收会议;
4. 根据评价结果和已定义的验收准则，得出验收结论，并形成《验收报告》。
5. 如果产品需要复评，开发方应给出纠正措施，双方对再次验收的时间进行
6. 协商。
l 产品交付
发布已通过验收的产品。
3.9 交付产品
按照《验收计划》中定义的交付方式和交付进度，将产品交付给客户。
图13 产品交付流程
l 包装设计
产品光盘，光盘套封面，安装说明等设计。
l 产品打包
产品打包，包括数据库结构、数据库建立文件、编译过的程序文件、配置文件、辅助
文件、页面文件、用户安装手册、用户使用帮忙说明书、补丁、平台支撑文件、其他工具文件等打包成安装文件。
打包好的文件刻成光盘或者放在网上供下载安装。
l 产品实施
打包好的文件供实施人员去客户现场安装实施。
3.10 维护
图14 维护流程
l 准备
在产品通过验收，正式发布后，产品相关方(如开发部门、销售部、产品部、技术支持部、客户方等)应协商建立产品维护小组，并指定维护负责人。产品维护组成员的组成可以是产品开发项目组的成员，也可以不是项目组的成员。
l 制定维护实施计划
由维护负责人负责维护计划的编制。
l 实施产品维护
1. 维护需求的识别
2. 维护需求的评估
3. 实施维护
4. 后续工作
如果需要向客户交付维护后的产品，更新受影响的客户软件，期过程应严格遵循《配置管理程序文件》，通过CCB批准后，变更运行基线。
3.11 软件问题管理
图15 软件问题管理流程
l 问题的发现与登记
软件项目开发或维护过程中，开发、集成或测试人员一旦发现了软件问题，应立即填写《软件问题报告单》，并将《软件问题报告单》提交项目指定的问题管理人员;
l 分析分类
根据引入问题的开发阶段，确认问题的类型;
评估是否修改，对某些问题是否投入资源和工期进行修改有争议时，项目经理是最终决策者;
指定问题修改的责任组或责任人和解决问题的优先级。
l 问题发布
根据分析的结果，问题管理人员对问题进行分发和跟踪;
将《软件问题报告单》的副本分发到指定的负责部门或人员;
跟踪问题的解决情况，维护《软件问题状态登记表》记录相关信息，
l 问题和解决与验证
问题负责部门或人员对问题报告进行进一步的分析，解决问题，填写《软件问题报告单》，修改《软件问题状态登记表》的状态。
如果问题无法解决，可以选择在这个版本中不给予解决，搁置问题。但必须由项目经理进行批准。
如果问题的修订将会引起配置基线的变更，变更的过程应按照《配置管理程序文件》中的“配置变更管理”子过程进行。
问题解决后必须经过测试验证才能确认问题关闭。
4 通过“点菜”模式提升SaaS的商业价值
4.1“点菜”模式不同于构件开发方式
事实上，软件业中组件化开发、构件化开发的思想早存在，有不少公司在从事这方面的工作并取得不错的成绩。但是失败的确定不少。其失败的原因是多方面的。其中主要的是组件/构件的粒度把握得不准。这种可大可小的抽象性的东西用不同的观点不同的人去划分就会有种种不同意结果。
但“点菜”模式却不同，菜是可看得见的。划分与开发的难度要小得多。菜是供用户最终吃的，而不是构件是供软件从业从员自己用。菜是功能性的，站在用户的立场来看待问题。菜的粒度比构件要粗。事实上构件更形象地可看作是构成菜的原料。定义与开发原料是件极大的挑战。
4.2 正确运用“点菜”模式
“点菜”模式在传统软件业上也适应，只是软件公司在这方面研究得并不够，实际操作上存在许多困难，发挥作用也不明显。如何解决好这些问题，这里我们提如下几条建议：
1. 成立一个专家小组，该小组从整体、全局上走规划、定义“菜”，并进行相关的培训、指导和规范。
2. 定义并制定出配置模式、修改模式、开发模式。
3. 打破传统的以项目型为主的开发模式，建立以“菜”为中心的小组。但也可以以小组组成大的组，这个大组只是重在管理和协调上。小组以3至5人最适宜，3至5人的小组更易沟通、管理，开发效率极高。
4. 规范并明确点“菜”的开发模式，包括从需求到设计的快速响应，各盘“菜”支持参数化定制、数据模型定制与工作流程定制。
5. 配置管理逐步实现点“菜”模式。可自动快速地通过“菜”组装成不同应用系统。
6. 整理上布局SaaS模式，点“菜”模式有效地与SaaS结合，实现平民化软件，走软件超市之路，建立软件服务运营平台。
7. 对原有的系统分情况分阶段按“菜”标准重新定义和重构，重视接口设计。
8. 提供客户在线快速订购组件，自动配置组装客户门户系统，平台提供统一的定制门户入口，并且按实际的使用量灵活计费。
9. SaaS下组件是细碎零散的，为了避免组件过于细碎零散，能够按主题如某行业应用Mashup起来。
10. SaaS下组件数量众多，大规模的多租客架构，要求可扩展的部署平台与监控机制。
11. 组件在数据、服务、界面等层次共享与组合，提供数据总线、服务总线与Mashup Server等基础设施，提供可扩展的行业数据模型;SaaS组件必须是可定制扩展的。
12. 应该大大简化客户的订购、使用产品，提供统一的页面风格与用户体验。
13. 研究而创新“菜”的扩展性、源码的开发性，可提供二次开发。
14. 支持在线测试、部署应用，组件的设施与企业内部IT系统的良好互联，可定制企业门户。
15. 面向组件库的开发与面向客户的开发完全分离开来。
4.3 SaaS模式促进软件大超市的早日到来
商品化的超市购物方式已经深入人心，人人都享有进超市购物的权利。商家不一定是商品的生产者，经营超市的商家承担了商品的采购与销售的职责，这不仅仅极大方便地给顾客提供了物美价廉的商品，也让自己赚得钵满满。事实，我们在90年代初还是上小杂货店或者百货大楼指着货物叫销货员拿给我们，这样既没有更多选择的范围也没法保证商品的质量，价格也难降下来，商品大超市的出现提高了人们生活的质量，人人享受购物的乐趣。软件一样是商品，软件又怎么不会走向大超市呢?如果只是把软件当作光盘卖，那叫不上超市，不管您的软件种类怎么多，也不管您光盘数量有多少。因为那样买的是一整套软件。
我们完全可以把整理的软件细分为模块，模块与模块可以组合，用户只是根据自己的所需购买一个由多个模块组成的系统，而不是买了财务软件还要买OA系统。一大堆软件事实用到的功能还不到20%。因此我们完全可以通过点菜模式来满足用户的真正需求，我们最终提供给用户的一个系统，这个系统可覆盖用户的所有功能需求。
这样，我们在网上开个软件大超市，让用户按模块来选择功能，再通过组合控制方法形成一个独立的系统，真正做到了这点会很快让软件走向平民化、大众化，人人都可享受软件就是人人都可享受美食一样。SaaS模式会快速地推动软件大超市的早日到来。
5 小结
SaaS商业模式与传统产业的商业模式都是为了推广自己的产品，占有更多的市场份额，最终达到获取更多的经济利润。
本章介绍了“以服务为导向”的SaaS模式如何以商业的思维来理解软件，通过“点菜”模式来提升SaaS的商业价值。通过配置模式满足用户的定制要求，从于抓住更多的用户。通过建立品牌并推广，明确谁是自己的客户，推销什么产品给客户等战略的高度来营销SaaS软件，创造更好的经济效益。
标签：
原文地址：http://www.cnblogs.com/sopestar/p/4301593.html
